Application Lifecycle Management: What makes a good requirement? – Part I

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 will examine these dimensions of requirements quality, starting with:

Unambiguity

This is the most important aspect of a good requirement. If you are not sure what the requirement is trying to say, then you won’t be able to test it. To avoid ambiguity, a requirement needs to be clear and simple, and thus understandable. There are a few simple stylistic rules that benefit reader and writer alike by:

• Giving the requirements writer a structure to formulate their thoughts clearly.
• Providing a consistent style helps the reader quickly grasp what the requirement is conveying.

Stylistic Rules

A requirement should be a single, complete and correct sentence, with a subject, verb, and result.

• The subject is a user type, for user requirements, or system component, for system requirements. Examples:
  • Administrator
  • Customer
  • All users
  • Search system
  • Engine
• The verb is a stock one, to indicate that this is a requirement: shall. Some suggest that you could also include must, for mandatory requirements, and should for optional requirements. I’m not a proponent of that approach because:
  • It introduces ambiguity into the requirement, rather than reducing it.
  • From my perspective, all requirements should be mandatory, or they are not really “requirements”.
• Others believe will can be used as an alternative verb, expressing a statement of fact rather than a requirement. This seems to be a rather fine and not particularly useful distinction. If the requirement cannot be expressed by using shall, then it probably is not a requirement.
• The result is a desired state or outcome, ideally with some metric or measure for it if it is not already clearly measurable.

Examples

• All registered users shall be able to log in to the system.

Here the subject is All registered users, which is a clearly defined set. The verb is shall, and the result is to be logged in to the system, which is clearly measurable. But this requirement could be made even stronger by adding some performance criterion.

• All registered users shall be able to log in to the system in under two minutes.

This is better because otherwise this requirement could be considered satisfied even if it took an hour to log in!

• The engine shall develop at minimum power of 110 bhp

Here the subject is the engine, which is a clearly defined sub-system. Shall is the verb and the result is a minimum power, which is clearly measurable.

So, my first aspect of writing good requirements is that they should be unambiguous. As you are writing, consider if there is an exact test you could devise that would verify whether the requirement is met. If so, that’s is a good indication the requirement is unambiguous.

In the next post, I will be looking at another aspect of a good requirement, Atomicity.

If you would like to learn more check out our Requirements Management Webinar Series.

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.