Skip to content

pattern/common-requirements #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Aug 31, 2017
Merged

pattern/common-requirements #11

Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
3ee41c4
from Wiki try 2
nyeates Nov 30, 2016
4c2c73e
formatting to match template (try 2)
nyeates Nov 30, 2016
1c69700
removed typo
nyeates Dec 15, 2016
5d4a893
Added idea on using cust. req. negotiation
nyeates Dec 15, 2016
7627259
Small reword
nyeates Dec 15, 2016
9d7ef82
Fixed typo: isn't
NewMexicoKid Jan 23, 2017
3fb5b47
Merge branch 'master' into pattern/commonRequirements
nyeates Feb 2, 2017
2faad14
Align with PLoP 2017 draft.
rshanmer Aug 31, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions common-requirements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
## Title
Common Requirements

## Context
Many projects are trying to use common code. There is a shared repository that all the projects access. This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects. Each project has its own delivery schedule, set of deliverables and customers.
Statement of Problem: The common code in the shared repository isn’t meeting the needs of all the projects that want to use it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this line seems to be duplicated by line 9


## Problem Statement
The common code in the shared repository isn’t meeting the needs of all the projects that want to use it.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to specify in the problem statement why the common code isn't meeting the needs? I.e., ... due to conflicting requirements from the participating projects.


## Forces
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any relevant forces related to the human factor in all this we should consider? For me personally, InnerSource is much more about culture and the human factor than it is about code and processes.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a side note, one force that is human-related is that system engineers might tend to try to fill customer requirements locally within their own BL rather than reaching out to other BLs that support the same customer. Might be unrelated to this particular pattern, but this might be an InnerSource donut.

The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same.
Requirements on code should be derivable from real customer needs.
The needs of different customers are generally quite similar; however they might be expressed differently or weighted differently between customers.
Many customers want the supplier to help them know what they need.
The company has many “Systems Engineers” writing requirements for the products. These requirements are supposed to be a distillation of customer needs to guide development of the product.
Reusing code is an important goal to save the company time and money.

## Solution
Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my old product line days I remember, that bringing about such an alignment requires an incentive for both the customers (usually price and TTM) and for the company itself. Should we mention this here or would that unduly bloat the pattern? Maybe this could go in the Resulting Context section, too.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds like a reasonable thing to add to the pattern at this location.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good comment for resulting context. It's a reflection that the problem (getting alignment) might introduce new problems (that require solutions like discounts).

## Resulting Context
This might require negotiating requirements changes with the customer. It might also require other involvement by the sales teams and product managers to get alignment on the requirements.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also mention the need to incentivize reuse and to make explicitly make a decision on the components scope (which requirements are in scope, which are not).

Copy link
Contributor

@gruetter gruetter Dec 7, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just as an idea: in the forces you mention that the customers sometimes expect the company to help them clarify their requirements. My idea is that this situation should be taken advantage of by bringing about the alignment during the customer requirements negotiations and change the customers requirements rather than changing the component.


## Author
Robert Hanmer, 22 Aug 2016, 20 Sept 2016

## Status
Draft pattern