Chapter 2 Ambiguity in Stating Requirements
Whenever your tools ignore the human aspect, you will 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.
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 dangers 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.
Ambiguous words
Even when requirements are stated explicitly, they may employ 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 domed stadium seating 150,000 could fulfill the stated requirements.
Another dangerous word in the problem statement is "group," which implies the 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 "structure" means something hard, durable, solid, opaque, and possibly heavy. If we slip unconsciously into such an inference, we subliminally conclude the problem is to be solved with traditional building materials, thus limiting the range of possible effective designs.
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 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
a. protect against rain by electrostatically charging the raindrops and repelling them with electrical fields.
b. 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."
c. protect against winter by moving toward the equator, and against summer by moving away from it.
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 not meeting requirements, mostly because the requirements were never clearly understood.
For instance, Barry Boehm analyzed sixty-three software development projects in corporations such as IBM, GTE, and TRW. He 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.)
Table 2.1 Relative Cost to Fix a Requirements Error in Each Waterfall Phase
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 completed projects, but some observers have estimated 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 the 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 an assumption: namely, 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 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 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-5. What we mean by requirements.
Figure 2-6 is a picture illustrating what we mean by exploring requirements. The first egg shows a rather wavy boundary representing 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 but we don't want, and some not described yet 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 areas represent what we want but don't ask for, or what we ask for but we don't want. Through the repeated use of requirements tools, we reduce these areas and grow 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 that's an almost impossible task in real life. Through explorations, though, developers try to make the line 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.
BARGAIN BUNDLES
For the end of this year, I'm offering a list of bargain book bundles from Leanpub.com. Take a look at these bundles by clicking these links:
No comments:
Post a Comment