Requirement Gathering

Approximate Process Flow

1. Customer wants a system to be developed.
2. Architect gathers requirements by interviewing customer.
• architect writes up requirements in Requirement Gathering, and documents the verification criteria for each requirement
• architect reviews the requirements with the customer
• architect plans an architecture to fulfil known requirements, also in Requirement Gathering, refining it in as much detail as necessary to know whether everything is clear, will work, and is implementable; this includes components, interfaces, verification criteria, and anything else necessary
• this usually leads to additional questions, leading to new requirements or changes to existing ones

3. Customer signs off on the requirements as being correct and complete.
• this is tagged in the git repository

4. Architect refines the architecture, if needed, to produce a work plan.

5. Architect produces the work items needed to implement the architecture.
6. Architect, project manager, and developers estimate work to be done, by breaking work items into smaller parts, when needed, etc.
7. If necessary, project manager and sales negotiate with customer to agree on the price, scope, and timeline for the project.
8. Developers do the work.
• To facilitate this, developers break down the work items into ‘doable’ cards in the Kanban. The architect may need to help here.

9. When (not if) there is a need to change requirements or architecture, the architect discusses the changes with the customer or developers, and prepares a change in Requirement Gathering in a new branch.
   • the architect updates the requirements, architecture, components, interfaces, and work items as necessary

10. The architect and project manager discuss the proposed branch, making estimates (perhaps with the developers) on the impact on the amount of work to be done, and the project manager prepares the corresponding changes to work schedule and project cost.
11. Project manager discusses the changes with the customer, who either accepts or rejects them, or wants to have the plan for the changes amended.
12. Once the customer accepts the changes, the architect merges the new branch to master, and creates a tag for the new state of the agreement with the customer.
13. Repeat until done.

In rough graphical form:

The above graph is not authoritative.

Data model A project is represented in Requirement Gathering as a set of nodes, which are linked to each other in various ways. Each node has a kind:

• project: Core information about the project as a whole.
• requirement: Customer requirement on project.
• component: A part of the system.
• interface: An interface of a component.
• integration-strategy: A way to describe how to combine sub-components into a coherent supercomponent.
• verification-criterion: How do we know a requirement is met, or a component works?
• work-item: Lumps of work needed to implement the project.
• tag: Arbitrary tags on other nodes. The following UML diagram shows the relationship between different kinds of nodes.

The data is expressed using YAML. Each node is an “object” consisting of some key/value pairs. Some constraints:

• Every project SHOULD have a “project” node.
• Every requirement SHOULD be verifiable, and must have one or more verification criteria to express how that happens. Verification criteria SHOULD be designed so that verification can be made automatic with sufficient effort.
• By the time the architecture is finished, every requirement MUST be fully mapped.
• Every project SHOULD have exactly one top-level component.
• Every component with sub-components SHOULD have an integration strategy.
• Every integration strategy SHOULD have exactly one architecture parent.
• Every large component SHOULD have one or more components that implement it.
• Every component SHOULD have exactly one component parent. (excluding the top level component)
• Every component SHOULD have either more components, or else a work item as a child.
• Every component SHOULD have one or more verification criteria.

License management in projects Every project must manage the licenses in the components it includes to achieve several goals:

• Follow licenses of all components.
• Avoid including code under unwanted licenses in the end result. For more information, see the wiki. The list of licenses for each component, or each file in each component, known as the “bill of materials”, is stored with project documentation in a manner suitable for the project. Capturing the choice of licenses is done in the Requirement Gathering document using tags.