More on requirements: a few simple rules -

More on requirements: a few simple rules


Last week’s article about “needing them stinkin’ requirements” generated quite a bit of response. I recommended Karl Wiegers’ book “Software Requirements” as a great introduction to the art and science of gathering – and, as one poster noted – analyzing requirements.

But there is a five second “elevator talk” version. Some years ago, at a conference in Mexico, I attended a talk Steve Tockey 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?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .

2 thoughts on “More on requirements: a few simple rules

  1. Your article has three bullets: (1) unambiguous (2) binding, (3)testable. I will assert that after my 18 years DOA-178 experience that it is impossible to express in words a requirment meeting criteria (1) and (3). I can and have taken textually worded req

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.