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
instance, Figures 2-1, 2-2, and 2-3 show three rather different structures built
in response to the same ambiguous problem statement:
a means for protecting a small group of human beings from the hostile elements
of their environment.
Iglooan indigenous home constructed of local
Bavarian castlea home constructed to impress
Space stationa 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.
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
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
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
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."
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
against rain by electrostatically charging the raindrops and repelling them with
- 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
- protect against winter by south, and against summer
by moving north.
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  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.)
Relative Cost to Fix an Error
Phase In Which Found
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.
Boehm's observations on project cost.
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.
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
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
What we mean by requirements.
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
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.
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.
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:
in some direction.
- Look at what they find there.
- Record what
- Analyze their findings in terms of where they want to be.
- Use their analysis and recordings of what they find to choose the next
- Go back to step 1 and continue exploring.
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 , 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
ambiguity because ambiguity costs!
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 to attack ambiguity is the subject of the entire book. But above all, remember
to use your mind in a playful wayexploration should be
You, of course.
 Barry W. Boehm, Software Engineering Economics (Englewood
Cliffs, N.J.: Prentice Hall, 1981).
 W. Edwards Deming, Out of the Crisis (Cambridge, Mass.:
MIT Center for Advanced Engineering Study, 1986).