Skip to content

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

  1. 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.
  2. 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).

Loading

Leave a Reply

Your email address will not be published. Required fields are marked *