If you are a systems or software engineer tasked with writing or reviewing a requirements specification, knowing what makes a requirement a “good” one is extremely important. After 30 years working in system and software testing, I know that having access to a requirements document is rare when testing a new system, and having a useful, prescriptive one is rarer still. So I wanted to apply my own experience to help others create requirements specifications that deliver the intended result – higher quality software – as efficiently as possible.
From my perspective, a good requirement is a testable requirement. As you draft the requirement, ask yourself “How would I test this requirement to know that it was satisfied?” From this one qualifying condition, a number of other dimensions of requirement quality will flow.
In this blog series, I am examining these dimensions of requirements quality –
Part 1 discussing Unambiguity can be found HERE
Part 2 discussing Atomicity can be found HERE
Part 3 discussing Precision can be found HERE
Part 4 discussing Verifiability can be found HERE
Part 5 discussing Independence can be found HERE
– and this sixth installment in the series focuses on another critical dimension:
Flexibility
Flexibility, in this case, refers to avoiding the temptation to slip design suggestions into the requirements. This can prove especially difficult if you are an engineer who will also be responsible for implementing the requirements you’re writing, and you’d like to slip in some of your ideas about how the system should be designed. This is a trap!
Requirements should specify only what is needed, not how the need will be provided. A well-written requirement should provide complete flexibility regarding how the requirement could be satisfied or the system should be designed in the first place. Here’s an example of a poorly written requirement:
- A speech recognition sub-system shall provide a voice interface for the cruise control system.
This requirement actually defines a sub-system, which should be left to the designer. While it may in fact be better for there to be a separate speech recognition subsystem, it may not be the best design available. But by being prescriptive like this, the requirements writer is overstepping their responsibilities and constraining the design in the process. It would be better to state the requirement as follows:
- The cruise control system shall provide an interface for users to input voice commands
However, if there is an actual constraint on the design, then this does become a valid part of the requirement. In this example, if there is already an existing speech control sub-system mandated for use by this manufacturer, then the requirement can be stated in this manner:
- The cruise control system shall provide an interface for users to input voice commands, via the usage of the XYZ speech recognition subsystem.
Adding details about planning is another error that can creep into poorly written requirements. Here’s an example of what that might look like:
- A cruise control display panel prototype shall be available for testing by the end of Phase 3
Although this timing is couched in terms of the requirement, it should be part of it at all. It’s part of the plan, and as we know, plans can change – perhaps even more than requirements! Both plans and design recommendations should be separated from the requirements in order to provide maximum flexibility to the individuals responsible for addressing your requirements.
In the next post, I will be looking at another aspect of a good requirement, Positivity.
About the Author
Ian Compton is a Solutions Architect for the pre-sales team at Persistent Systems. Ian has worked with requirements management for twenty years, starting at QSS with the DOORS V4 release, and via acquisitions on to system testing IBM’s lifecycle solutions through their various iterations.
