Ambiguity in Stating Requirements

by Donald C. Gause and Gerald M. Weinberg

Whenever you use tools that ignore the human aspect, you describe requirements imperfectly and create ambiguities. Ambiguities, in turn, lead to diverse interpretations of the same requirement.

2.1 Examples of Ambiguity

For instance, Figures 2-1, 2-2, and 2-3 show three rather different structures built in response to the same ambiguous problem statement:

Create a means for protecting a small group of human beings from the hostile elements of their environment.

Figure 2-1.
Igloo—an indigenous home constructed of local building materials.

Figure 2-2.
Bavarian castle—a home constructed to impress the neighbors.

Figure 2-3.
Space station—a mobile home with a view.

First of all, these three structures do represent effective solutions to the problem as stated, yet the solutions are strikingly different. Examining the differences among the solutions, we find clues to some of the ambiguity in the requirements.

2.1.1 Missing requirements

Sometimes requirements are missing. For instance, there is no requirement concerning properties of materials, properties such as local availability, durability, or cost. Thus, it's not surprising the three solutions differ widely in their use of materials.

The problem statement is equally ambiguous as to the structure, or how the building materials will be assembled. We don't know the desired size, shape, weight, or longevity of the structure.

Little is said or even implied about what functions will be performed inside these structures, leaving open the question of specific functional elements such as stoves, servants' quarters, beds, and ballrooms.

Nothing is said about the physical environment, either internal or external. The structure could reside on land, sea, or in the air, on an ice pack, or even in outer space. Then, too, we know nothing about the specific hostilities from which we are to protect the inhabitants.

What about the social and cultural environment? Is this small group of human beings a family unit, and if so, just what constitutes a family unit in this particular culture? Perhaps it is a working group, such as hunters or petroleum engineers, or possibly a recreational group, such as poker players or square dancers.

2.1.2 Ambiguous words

Even when requirements are stated explicitly, they may use ambiguous words. For instance, the word "small" does not adequately specify the size of the group. Beware of comparative words, like "small" or "inexpensive," in problem statements. A group of 25,000 would be "small" if we're talking about football fans at a University of Nebraska home game, where a new doomed stadium could fulfill the stated requirements.

Another dangerous word in the problem statement is "group," which implies that people will interact, somehow, but it's not clear how. A group of people performing The Marriage of Figaro don't interact in the same way as a group of people having coffee in the Figaro Cafe. Designing a structure for one group would be quite different from designing for the other.

Even the term "structure" carries a load of ambiguity. Some readers would infer that "structure" means something hard, durable, solid, opaque, and possibly heavy. If we slip unconsciously into that inference, we subliminally conclude the problem is to be solved with traditional building materials, thus limiting the range of possible effective designs.

2.1.3 Introduced elements

Of course, we can guard against ambiguous words by carefully exploring alternative meanings for each word in the problem statement, but that won't protect us from another problem. The term "structure" never actually appeared in the problem statement, but somehow slipped into our discussion without our noticing. The problem statement actually says "create a means," not "design a structure."

Some problem ambiguities are so obvious that they would be resolved in casual designer-client conversations long before the actual design process began. More subtle ambiguities, however, may be resolved unconsciously in the designer's mind. In this case, an innovative, but nonstructural, "means" of protecting a small group might be overlooked. For instance, the designer might

1. protect against rain by electrostatically charging the raindrops and repelling them with electrical fields.
2. protect against belligerent crowds by supplying aphorisms such as "Sticks and stones may break my bones, but names will never hurt me," or "I may have to respond to what other people do, but they don't define me."
3. protect against winter by south, and against summer by moving north.

 

 

2.2 Cost of Ambiguity

These few elementary examples of ambiguity in requirements can only suggest the enormous impact of the problem. Billions of dollars are squandered each year building products that don't meet requirements, mostly because the requirements were never clearly understood.

For instance, Boehm [1] analyzed sixty-three software development projects in corporations such as IBM, GTE, and TRW and determined the ranges in cost for errors created by false assumptions in the requirements phase but not detected until later phases. (See Table 2.1 and Figure 2-4.)

Phase In Which Found

Cost Ratio

Requirements	1
Design	3-6
Coding	10
Development testing	15-40
Acceptance testing	30-70
Operation	40-1000

Although Table 2.1 vividly shows the importance of detecting ambiguities in requirements, the figures may actually be quite conservative. First of all, Boehm studied only projects that were completed, but some observers have estimated that approximately one-third of large software projects are never completed. Much of the enormous loss from these aborted projects can be attributed to poor requirements definition.

Figure 2-4.
Boehm's observations on project cost.

The situation looks even worse when we consider the catastrophes resulting from incorrect design decisions based on early false assumptions. For example, on the Ford Pinto manufactured in the 1970s, the position of the fuel tank mounting bolts was a perfectly fine design decision based on an assumption, there will be no rear impact collisions. As this assumption proved to be false, the Ford Motor Company, by its own estimates, spent $100 million in litigation and recall services. And what value are we to place on the lost lives?

Or take another case. The decision by the Johns-Manville Corporation to develop, manufacture, and market asbestos building materials was based on the assumption that asbestos, in the form used in their products, was environmentally safe to all exposed people. Many fine ideas found their way into Johns-Manville products based on what we now understand to be a false assumption. Epidemiology Resources, Inc. of Cambridge, Massachusetts estimated that this high-level decision would eventually produce 52,000 lawsuits costing approximately $2 billion in liabilities. Indeed, the company's entire organization, culture, and capital investment was so dedicated to the production of asbestos materials that it went bankrupt and reorganized as the Manville Company.

2.3 Exploring to Remove Ambiguity

For the past three decades, we have both been working to help people avoid costly errors, failed projects, and catastrophes, many of which have arisen from ambiguous requirements. We have written this book to show you successful methods for exploring requirements in order to constrain ambiguity. These methods are general and can be applied to almost any kind of design project, whether it be a house in Peoria or a castle in Bavaria, an on-line information system or a manufacturing organization, an advertising campaign or a biking vacation in New Zealand.

2.3.1 A picture of requirements

Figure 2-5 is a picture illustrating what we mean by requirements. Many ancient peoples believed that the universe emerged from a large egg, so we've used the "egg" to represent the universe of everything that's possible. We've drawn a line at the middle of the egg to divide what we want from what we don't want. If we could actually draw, or describe, such a line, we would have a perfect statement of requirements.

Figure 2-6 is a picture illustrating what we mean by exploring requirements. The first egg shows a rather wavy boundary that represents the first approximation to the requirements line. This line might represent the first vague statement of the problem. The second egg shows the results of some early exploration techniques. The line is still wavy, indicating there are still some things described that we don't want, and some not described that we do want. But at least some of the biggest potential mistakes (areas furthest from the requirements line) have been eliminated

Figure 2-6.
Exploring requirements: The black area represents what we want that we don't ask for, or what we ask for that we don't want. Through the repeated use of requirements tools, we reduce these areas and get closer to what we want, and only what we want.

Each new egg, which represents the next stage in the requirements process, produces a better approximation to the true requirements line. Unfortunately, the line will never match the true requirements perfectly, because in real life that's an almost impossible task. Through explorations, though, developers try to get it reasonably straight before paying too dearly for the wiggles.

2.3.2 A model of exploration

The process for straightening the wiggly line is an exploration, patterned after the great explorers like Marco Polo, Columbus, or Lewis and Clark. Roughly, here's what all explorers do:

1. Move in some direction.
2. Look at what they find there.
3. Record what they find.
4. Analyze their findings in terms of where they want to be.
5. Use their analysis and recordings of what they find to choose the next direction.
6. Go back to step 1 and continue exploring.

This is the same process used in exploring requirements, as we'll show in the rest of the book.

2.4 Helpful Hints and Variations

• Our colleague Ken de Lavigne suggests that some great examples of the consequences of requirements ambiguity are described in Deming's book, Out of the Crisis [2], under the subject of "operational definition."
• Even better than looking at other people's examples is finding a few of your own. Next time you notice that a product isn't quite what you like, ask yourself, "What was the requirement that produced this way of creating the product?"

2.5 Summary

Why?
Attack ambiguity because ambiguity costs!

When?
Attack ambiguity as early as possible, because although you may eventually get rid of it, the cost of correction in early stages of product development is much, much less than later.

How?
How to attack ambiguity is the subject of the entire book. But above all, remember to use your mind in a playful way—exploration should be fun!

Who?
You, of course.

[1] Barry W. Boehm, Software Engineering Economics (Englewood Cliffs, N.J.: Prentice Hall, 1981).

[2] W. Edwards Deming, Out of the Crisis (Cambridge, Mass.: MIT Center for Advanced Engineering Study, 1986).