- MP001 – primary and secondary function dependency
Failure of a system’s secondary function may not lead to the failure of the primary function. Also the non-existence of secondary functions (because they are still being developed) may not have consequences for the performance of the primary function.
- Product Development process steps
Product development
- Requirements Quality
What makes a requirement a good requirement? Is it how it is written? What determines the quality of a requirements and who should be the judge of that?
A requirement is an element in an information translation chain. This chain usually starts with stakeholder needs that are translated into system requirements. These system requirements are input for design and test processes.
During the translation process there are a number of moments that can help us assuring the quality of a requirement.
Step 1: Understand the stakeholder need
one of the first process steps in the Requirements Engineering process is Elicitation. Elicitation offers a rich palette of tools and techniques that help us as Requirements Engineers to understand the stakeholder need.
Step 2: Assess the impact
the second process step in the RE process is the Analysis. In this step the impact on the system of interest (SoI) is assessed, in combination of all the information that is available at that moment. The stakeholder need is analysed against the known system requirements, company policy, applicable standards, interfaces, design restrictions.
The outcome of the analysis (documented as an Analysis Statement) is used to write the system requirement.Step 3: Write the requirement
a) write the requirement with the Analysis Statement as guidance to make sure the semantics (the intention or meaning) of the stakeholder need is clearly documented.
b) use the applicable templates, acronyms, guidelines, tooling that help to write the requirement according to the agreed standards in the company, department or team. The aim here is to get the requirements syntax (the format, wording) right.Step 4: Verify requirement with peers and quality professionals
To ensure that the requirement is written according to the agreed (often internal) standards, rules and guidelines, the requirement is reviewed by colleagues, peers and quality professionals that can confirm compliance to these agreed standards and rules. This is also called the CRAFTSMANSHIP check.
Step 5: Validate the requirement with the stakeholder
to ensure that the requirement is conform the stakeholders’ expectation, the stakeholders are asked if the stakeholder need was correctly understood and translated into a requirement. This is also called the CONFORMANCE check to ensure that no information was lost or added during the translation.
Step 6: Validate the requirement with the receiving stakeholders
To ensure that the requirement is understood and has the necessary qualities for the receiving stakeholders (e.g. designers, testers, integrators) a review with these stakeholders is organized. One of the most effective techniques to use during the review sessions, is to let the receiving stakeholders explain in their own words how they interpret the requirement. In case two or more stakeholders give a different explanation, there might be an ambiguity issue. And if the explanation does not match the intention of the author, it means there is a risk of losing information in this translation. This is also called the FITNESS-FOR-USE check.
Step 7: Make the necessary corrections, and release the requirement
Lessons learned
- the quality of requirements is for the largest part determined by the semantics. A limited part of a requirement can be improved by applying dedicated tooling, checklists and templates to ensure that the format is according to the agreed standards.
- it seems best to organize two separate reviews (step 5 and 6) for the stakeholders that gave input (looking for conformance) and the receiving stakeholders (seeking the right amount of detail, unambiguity, clarity).
- Requirements trees
Many textbooks on requirements management show examples of representations of a requirement linked to other requirements. It is seldom explained what this link means.
What does the line between Requirement 001 and Requirement 101 mean? Is Requirement 001 a “parent” requirement? Whatever it means. Is Requirement 101 “derived” from Requirement 001? If so, where is this information stored? Is there a relation between Requirement 101 and Requirement 201?
As soon as you start asked questions like these, you find out that it really does not make any sense to link requirements to other requirements. Requirements are input for design and architecture processes.
If you follow the Pace Requirements Method you would be able to answer the following two questions for any requirement, wherever it is located in your documentation:
- why is there a need for this requirement (where does it come from, where is it derived from?)
- why does this requirement have this value (in case of quantified requirements)?
Anyone who has participated in a real project with real requirements and a proper development process has seen that in between requirements is either an analysis statement (from the Requirements Engineering Analysis process step) or a design decision that answer the two questions above.
In the example above system-level requirements R-001 and R-002 are analysed. During the analysis it was agreed that if a decision must be made for a particular component’s characteristics mass and cost, the priority lies with mass. This analysis statement AS-001 gives guidance to the two system-level budget tables (both are part of the system design) and are formatted as Design Decisions.
Four requirements are derived from these budget tables R-101 states how much of the mass budget is allocated to physical module XYZ and R-201 states how much mass is allocated to physical module ABC. Similar for cost: R-102 is part of the total cost budget that is allocated to physical module XYZ and R-202 for physical module ABC.In this way tracelinks, Design Decisions and Analysis Statement can perfectly help to account for the reason why these requirements are there and also why the requirements have these specific values.
‘Terrible’ examples
Here are some examples from our current practices that demonstrate how not to do it.
SEBoK – System Requirements Definition
In the Systems Engineering Book of Knowledge a page on the System Requirements Definition shows an image with a so-called Requirements Tree. The tree is created without any practical reference to the real world. Mixing up the functional and physical architectures that are leading for not only the requirements but also for the designs that need to satisfy the requirements. In practice requirements are never related to other requirements. Either an analysis statement or a design decision will explain the relation (if any).
It is advised to avoid that page completely. - System Requirements Engineering training
