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 I discussing Unambiguity can be found HERE
Part 2 discussing Atomicity can be found HERE
– and this post will focus on:
Precision
A precise requirement is defined in a way that is measurable, and thus testable. I hate to recall the number of times in my career I have seen requirements along the lines of:
- The performance of the system under normal load shall be good
Although this may seem like a reasonable aspiration, it is far too non-specific to be testable in any way, which makes it useless as a requirement. Defining the characteristics and thresholds that determine a “normal load” or “good performance” would likely require several pages of non-functional requirements specification. Any terms in your requirement need to testable, which means they must be both precise and measurable. Another example of an imprecise requirement would be:
- The system shall provide a user-friendly data entry system
“User-friendly” is neither defined nor measurable, along with these other terms to avoid:
- Easy
- Quick
- Rapid
- As soon as possible
- Adequate
- Sufficient
- Minimize
- Maximize
- Versatile
- Flexible
- Modern
Non-functional requirements are particularly difficult to define precisely, and they may have to refer to other specifications. This is fine, as long as those specifications are defined and available. For example, a performance requirement might read:
- The system, running on the minimum hardware specification, (see Appendix 2), shall perform a customer update request in less than 1.5 seconds, with 300 concurrent users running the standard user load (see Appendix 3)
Defining non-functional requirements that address usability is even more difficult, given their subjective nature. They can also take a lot of care to define precisely, as seen in the example below:
- 80% of new users of the system, from a sample of at least 50, shall rate the usability as “pleasant and helpful,” or better, using the standard usability questionnaire (see Appendix 4)
In this case, measurability is introduced through tester surveys, relying on a statistically valid sample size to provide the precision that good requirements need.
In the next post, I will be looking at another aspect of a good requirement, Verifiability.
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.
