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
Part 3 discussing Precision can be found HERE
Part 4 discussing Verifiability can be found HERE
– and this fifth installment in the series focuses on another critical dimension:
Independence
As well as expressing a single idea, a requirement should also stand alone. It should not refer to some other requirement, so there is no need to refer to any other requirement to be able to understand it.
Put yourself in the place of a tester, reading and working on a single requirement in isolation. Ask yourself: “Do I have enough information to verify the requirement?” For example:
- REQ1: A user shall be able to display a list of records created that day
- REQ2: The list of records shall include an ID, first name, surname and address
- REQ3: The list shall be sorted by surname
Here you would not know what “The list” refers to in the second two requirements, without referring to the first. Here’s another example of a set of dependent requirements:
- REQ1: The user shall be able to perform a search for an inventory item
- REQ2: If the search returns at least two items, these shall be displayed as a list
- REQ3: If the search returns no items, then a list of suggested alternatives shall be displayed
Here you would not know what “The search” refers to in the second two requirements, without referring to the first.
How to Write Independent Requirements
Although the requirements will be longer, it is always better to write requirements so they remain independent, like the list below:
- REQ1: The user shall be able to perform a search for an inventory item
- REQ2: If the user performs a search for an inventory item, and it returns at least two items, these shall be displayed as a list
- REQ3: If the user performs a search for an inventory item, and it does not return any items, then a list of suggested alternatives shall be displayed
It is also perfectly acceptable to refer to information outside the requirement that further clarifies it, as long as this information does not refer to another requirement. Here’s another example of how this can be expressed properly:
- 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)
In the next post, I will be looking at another aspect of a good requirement, Flexibility.
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.
