By Jack Ganssle

More on Requirements

Summary: What makes great requirements? A few simple rules serve as guidance.

But there is a five second "elevator talk" version. Some years ago, at a conference in Mexico, I attended a talk Steve Tockey's gave about requirements. He very ably and succinctly summed up the rules for requirements, which I'll paraphrase here:

 A requirement is a statement about the system that is unambiguous. There's only one way it can be interpreted, and the idea is expressed clearly so all of the stakeholders understand it.

 A requirement is binding. The customer is willing to pay for it, and will not accept the system without it.

 A requirement is testable. It's possible to show that the system either does or does not comply with the statement.

The last constraint shows how many so-called requirements are merely vague and useless statements that should be pruned from the requirements document. For instance, "the machine shall be fast" is not testable, and is therefore not a requirement. Neither is any unmeasurable statement about user-friendliness or maintainability.

An interesting corollary is that reliability is, at the very least, a difficult concept to wrap into the requirements since "bug-free" or any other proof-of-a-negative is hard or impossible to measure. In high-reliability applications it's common to measure the software engineering process itself, and to buttress the odds of correctness by using safe languages, avoiding unqualified SOUP, or even to use formal methods (actually, the latter is not a common practice, but is one that has gained some traction).

What do you think? Does your group do a good job eliciting and analyzing requirements?

Published July 27, 2007