The days of large, word-processed requirements documents are over. These days, there are too many questions that a manager needs answered quickly?quicker than a word-processed document can manage. For example, a manager needs to know the following:

How many requirements are there?

How many high-priority requirements have been delayed to a release after Release 2.0?

What percent of the requirements for Release 2.0 are low-priority?

Which requirements in Release 2.0 are high-priority, are being built for Customer X, and are the responsibility of Sally?


The need for quick answers to questions like these convinces me that the only way to record requirements when pressed for time is as a list of discrete requirements, each annotated with multiple attributes. In a 1993 article, my coauthors and I put forth a long list of attributes that a well-written set of requirements should exhibit. I must have been feeling obsessive-compulsive at the time. Although it was an interesting academic discourse, the article left one wondering what a practitioner could possibly do with such an enormous list. After much analysis and experience, I now have to admit that only eight attributes are truly important, and of these, some are not even possible to achieve. Here is the list of attributes that I think are important for today's just enough world (in decreasing order of importance).

Correct

A requirement is correct if it helps to satisfy a stakeholder need. This is by far the most important attribute because it gets right to the essence of why we are documenting requirements: to help satisfy stakeholder needs. If a requirement helps to support these needs, it is correct; otherwise, it is incorrect. For example, consider the following requirement: The system shall provide a red button labeled stop. This is correct if one or more stakeholders need such a button. If no stakeholder has this need, it is incorrect. Only the stakeholders can determine the correctness of a requirement. A project cannot hire a consultant to come in and find correctness errors unless that consultant is intimately familiar with the application and the needs of every stakeholder. The reason this attribute is so important is simple. If a requirement is incorrect, the product will fail to meet stakeholder expectations.

Consistent

A requirement is consistent if its satisfaction does not conflict with the satisfaction of another requirement, a set of requirements, or some other previously approved document. A developer choosing to satisfy requirement A in a manner that is inconsistent with another requirement does not make requirement A inconsistent. Instead, inconsistency is only an inherent attribute of a requirement in relation to other requirements. If there is some way to satisfy requirement A that does not conflict with other requirements, then it is the developer's responsibility to discover and use that approach.

The reason this attribute is rated so highly is simple. If a requirement is inconsistent with other expectations, development will find it impossible to satisfy without failing to satisfy other stakeholder needs.

Achievable

A set of requirements is achievable if it is possible to construct some system that satisfies all requirements in that set. Achievability is meaningful only within a context defined by the capabilities of team members, the state of technology, the amount of available resources, and the desired delivery date. This attribute is very important because a lack of achievability makes it impossible to satisfy stakeholder needs.

Annotated

A requirement is annotated if it is easy for us to find characteristics of the requirement, including its relationships with other requirements. We discussed annotating requirements by their relative priority (to facilitate triage), estimated cost (to facilitate both triage and project management), and necessity, effort, subset, and cover dependency (to further facilitate triage and project management). Here, we discuss a few more annotations: origin, advocate, responsible party, primary customer, details, and tasks.

The origin (also called a backward trace or upstream trace) of a requirement is a pointer to or notation concerning why it exists. For example, if the requirement is derived from an earlier system-level requirement, this should be a pointer to the specific system requirement. If the requirement is being satisfied because the customer said, "Read my lips?I want the system to be green," then the origin is a notation to that effect. The primary benefit of recording the origin is that it provides the team with a place of referral whenever somebody suggests changing the requirement at a later date.

Traceable

A requirement is traceable if it has a unique identifier. Although the creation of such traces is not part of requirements activities, it is important to give every requirement a unique identifier so that later tracing is possible.

Unambiguous

A requirement is unambiguous if it has only one possible interpretation. If you attempt to squeeze out all remnants of ambiguity, you will be forced to use formal methods, your costs will skyrocket, and you will run the risk of alienating customers. The alternative is to remain in natural language and accept some degree of ambiguity. Yes, you should endeavor to remove glaring ambiguities. No, you should not accept an ambiguous requirement that resulted from a compromise among multiple parties who clearly do not agree. And no, do not go on a crazy ambiguity-hunt just so you can say you did.

Complete

Of what value is a discussion of the completeness of a requirements document when we all know it is impossible to achieve? The needs of the customer are in constant flux. Time changes needs. The best definition of completeness I can come up with is this: "A requirements document is complete if it includes all the requirements that the stakeholders expect to have satisfied in the corresponding release."

Verifiable

A requirement is verifiable if there is a finite, cost-effective method to check that the system, as built, meets the requirement as stated. If the requirement is ambiguous (see discussion above), then by its very nature, it cannot be verified, for it possesses multiple interpretations. The best way to define a verifiable requirement, then, is to state that "A requirement is verifiable if there exists some finite, cost-effective method to check that the system as built meets the requirement as stated, to a degree sufficient to convince all relevant parties."

Other Attributes

As mentioned above, my 1993 paper included many other attributes. The attribute "understandable by customers" is still important, but I have combined its essence into the discussion of unambiguous requirements. It is of course important for a requirements document to be "modifiable"; however, I'm no longer sure what a non-modifiable requirements document would look like. It is still important for requirements to be "traced" to their origins and "organized," but I now treat those concepts as annotations.

The concept of "design independent" is important as well, but once we have agreed that a requirement is only a requirement if it maintains an external perspective and that every requirement by its nature limits design alternatives, it seems unnecessary to insist that a requirement should be design independent. As far as "conciseness" goes, yes, it would be nice if the requirements document was concise, but if it isn't, then what? I would not waste any time trying to make a requirements document any smaller than it is.

No matter how hard you try, you will not be able to squeeze out every last drop of requirements defect. You should strive to make sure that the document is correct, consistent, achievable, and at least annotated by effort and relative priority. The remaining attributes are nice to have, but in attempting to achieve them, be careful not to lose your ability to do requirements in a just enough manner.

Alan M. Davis