Thursday, January 15, 2015

Some Very Expensive Software Failures

Why Concentrate on Failure?

"So long as a man attends to his business the public does not count his drinks. When he fails they notice if he takes even a glass of root beer." - Corra May Harris

Logically, direct measurement of value should be the first place an organization starts to look at itself, but that's not how it usually happens. Instead, the trigger for most organizations to embark on some self-examination is failure—either one whale of a failure or thousands of annoying failure mosquitoes.

This concentration on failure may seem illogical—and may be illogical in many circumstances—but it does fit with our understanding of quality as subjective value. Of all the troublesome aspects of using computers, failures are by far the most annoying to the most people. Without ever conducting a detailed impact case study, or even a greatest single benefit study, people know that they don't like it when their computer fails. Thus, customers heap abundant praise and appreciation on the software organization that doesn't fail them.

Of course, the definition of failure changes with time, as expectations change. Once customers become accustomed to a certain level of service, a lapse from that level becomes a failure. Some customers have come to expect a succession of "breakthroughs" in software, so that achieving only a modest gain is seen as a failure. Thus, the first step in managing failures is to manage customer expectations—but that's always the first step in managing quality.

What Do Failures Cost?

Some perfectionists in software engineering are overly preoccupied with failure, and most others don't rationally analyze the value they place on failure-free operation. Nonetheless, when we do measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software. In this section, we'll take a look at a few examples that should convince you.

Case history 1: A national bank

The national bank of Country X issued loans to all the banks in the country. Each loan was confirmed by a telegram showing the amount of the loan, the repayment conditions, and the interest rate. The telegram became the legal loan document for the loan. The COBOL program that composed and sent these telegrams had been in operation for almost 15 years, and had worked flawlessly. Somebody noticed, however, that the serial number field would run out of digits and begin duplicating serial numbers within a few months. As each loan was legally identified by the serial number on the telegram, duplication could not be allowed.

Management directed that the serial number field be expanded. The programming manager assigned the job to one of the team leaders, who gave it to a programmer, saying, "Expand the serial number field by two digits." The programmer made this trivial change, ran a few tests, and the system was put into operation the next day. Everything worked fine.

Some time later, a financial analyst noticed a slight discrepancy between estimated loan receipts and actual loan receipts. After much searching, it was discovered that the serial number expansion had overlaid the low order digits of the interest rate field, causing the final two digits of every interest rate to be truncated to "00." Although the difference between 7.3845% and 7.3800% is quite small, when you are lending hundreds of billions of dollars, it quickly adds up to something significant. In this case, it added up to more than a billion dollars that the national bank could never recover.

Case history 2: A public utility

A utility company was changing its billing algorithm to accommodate rate changes (a utility company euphemism for "rate increases"). All this involved was updating a few numerical constants in the existing billing program.

Management directed that the constants be updated. The programming manager assigned the job to one of the team leaders, who gave it to a programmer, saying, "Replace these constants in the program." The programmer made this trivial change, ran a few tests, and the system was put into operation the next day. Everything worked fine.

Some time later, the Comptroller's office noticed a slight discrepancy between estimated receipts and actual receipts. After much searching, it was discovered that two low order digits in one of the constants had been entered with "75" transposed to "57", causing a number of the bills to be short by a small amount. Billing millions of customers, this small difference added up to X dollars that the utility could never recover.

The reason I say "X dollars" is that I've heard this story from four different clients, with different values of X. Estimated losses ranged from a low of $42 million to a high of $1.1 billion. Given that this happened four times to my clients, and given how few public utilities are clients of mine, I'm sure it's actually happened many more times.

Case history 3: A state lottery

I know of this one through the public press, so I can tell you that it's about the New York State Lottery:

A few years ago, the New York State legislature authorized a special lottery to raise extra money for some worthy purpose. As this special lottery was a variant of the regular lottery, the program to print the lottery tickets had to be modified. Fortunately, all this involved was changing one digit in the existing program.

Management directed that the change be made. The programming manager assigned the job to one of the team leaders, who gave it to a programmer, saying, "Change this digit to a five." The programmer made this trivial change, ran a few tests, and the system was put into operation the next day. Everything worked fine.

A few weeks later, when ticket sales were in full swing, one of the players bought two tickets and noticed that they had identical numbers. As there were supposed to be no duplicates in this lottery, he brought his tickets to the Daily News, which printed a photo of him and his two tickets on the front page. Public confidence in the lottery plunged, and the explanation that the error was "trivial" did not restore public confidence. In order to satisfy the public outcry, all lotteries were shut down pending the report of a blue ribbon investigating committee (this is government, after all). Altogether, it took 11 months for the matter to be resolved and the lotteries to be reestablished. At that time, the lotteries had been netting the state about $4 million to $5 million per month, so the total loss of revenue was estimated between $44 million and $55 million.

What's Next?

I have many more cases of failure, but to keep this blog short, I'll pause here. In my next blog essay, I'll give a few more cases, then describe the universal pattern of huge losses. After that, I'll provide some guides for preventing such failures.


This essay is adapted from a portion of Chapter 2 from Responding to Significant Software Events. 

This book, in turn, is part of the Quality Software Bundle, with is an economical way to obtain the entire nine volumes of the Quality Software Series (plus two more relevant volumes).

Sunday, January 04, 2015

How You Can Help Your Favorite Author

In spite of popular myths, writing books is a tough way to make a living. The writing itself is tough enough for most people, which is probably why most people don't consider becoming writers themselves. But for all the writers I know, the writing is probably the easiest part of the job. The hard part is promoting your books so people will buy them and, hopefully, will read them.

One of my writing buddies recently released a new book, A Murder of Crows. To accompany the release, she wrote a blog essay in which she said, "I am, of course, in panic mode, because I have a release-day checklist in which I do more than whisper a quiet announcement on Facebook and slink back into my hidey hole, as usual, so make snarky comments and post nerdy links. The dreaded promotion phase of writing. I think I know like two writers who enjoy promoting themselves. The rest of us are terrified."
I'm not one of those two writers. I don't enjoy promoting myself, not because I dread it, but because I don't enjoy doing things I don't do well. I didn't adopt a writing career because I was a good self-promoter. Fortunately, I have done quite well in my writing career because other people do a good job of promoting my stories.
That's true for most any successful writer. They succeed because their fans promote them. So, if you would like to help your favorite author, here are some options:
1) Buy their book today. With the advent of e-books, this act is easier and cheaper than it's ever been in the past. Various services report the  sales of books, and the more that are sold, the more the stores promote them. The more people who buy the book, the better it seems to look to the stores' algorithms and the more visible they make those books to complete strangers who happen to be looking for something to read. Buying the book is not required, but it should be a huge help to your author's reputation.
2) Ask the for a free copy of the book. For instance, I have formats set up for all major ereaders as well as on your computer. If you have no intention of reading the book but want to pass it on to someone who miiiiiight want it like six years from now, I have no problem with that. Ask away
3) Review the book at Amazon, Goodreads, LibraryThing, Smashwords, on your blog or other social media, on the back of a napkin, sealed up into a bottle and tossed into the ocean...[Note: Anywhere you mention the book—or link to it—on the Internet helps brainwash Google and other search engines into making it just slightly more visible.]
4) Pass the word. There’s a local commercial that always ends up with, “If you like our service, tell a friend. If you don’t, tell me.” That’s it exactly.
As far as social media goes, you may copy the picture of the cover off the author's blog and use it to help promote the book. (Most social media give extra weight to posts with pictures attached, which is why you see so many dang cats).
5) Sign up for the author's mailing list, which might produce a newsletter or other forms of information about the book or other books by the same or similar authors.
6) Chat with the author. Dayle says, and I agree: "I will listen to you complain about/praise the book. I will take typo oopsies if you catch any in the book. I will take invitations to write on your blog. I will talk with your book group. I will send free copies of books to libraries. If you have a favor to ask, ask it. Because trading favors is what makes the writing world go ’round.
7) Give the author hugs. Appreciative feedback encourages authors to write more and better books and stories.
In summary, to help your favorite author,
  1. buy books
  2. review someplace
  3. tell a friend
  4. give the author hugs
An Offer of Free Books to Reviewers
That summarizes (or plagiarizes) Dayles blog post. Now here's something of my own. I've always offered free books to reviewers, but don't always receive reviews in return. In fact, my experience and that of author colleagues is this: Only about one in three (1/3) of free books produce reviews. The rest produce nothing. So, I'm going to try a slightly different policy for reviewers, as follows:
  1. You obtain one of my books (buy, beg, borrow, steal, or find laying on the sidewalk).
  2. You read the book, or at least attempt to read it.
  3. You write a review telling what you think others ought to know about the book. The review can be long or short, favorable or unfavorable, serious or funny.
  4. You submit the review to be published somewhere, and also send a copy to me.
  5. As your reward, I will send you two of my ebooks—you have dozens of books to choose from. Tell me your choices when you send me the copy of your review. You will receive your reward a day or two later.
  6. (You can then repeat the process by reviewing one or both of your reward books. You can repeat until I have no more books with which to reward you.)
That's all there is to it. You can find all of my ebooks at <>—there are currently 44 books listed there, so you won't run out quickly.
And by the way, if I'm not one of your favorite authors, check with your favorites and ask what kind of reward they offer. The important thing is to support those writers you love, so the world can share your pleasure.

Monday, December 08, 2014

Free Books for Gift Giving

At this point in my professional life, at my advanced age, most of what I do professionally is teach workshops and write—mostly write. I don't write for money. All my writing income is given to charity: animal rescue, research on animal health, and civil liberty education (over $500,000, so far).

I write to pass along what I've learned, just as others have passed along their learnings to me. My goal is to reach as many readers as possible. Consequently, I'm always trying to think of ways to reach new readersm, and for this holiday season, I've thought of a way you can help me reach that goal.

Here's the deal. When you buy one of my ebooks, you can easily copy that book and give it to your friends and colleagues. If my primary interest was the money, I wouldn't be happy to know you're copying the ebook. But, although I do want money to go to my charities, I'm pleased that that a free copy has gone to someone who might otherwise not even know it exists.

So, this year, when you buy one of my books, I encourage you to copy it and give it to someone who might otherwise not know it, or could not afford it.

Yes, I know you could do this without my encouragement, but I also know that some readers don't feel right about taking something for free. And, generally, that's not entirely honest, so I'm not encouraging you to do this for other authors without their permission. But for my books, you have my permission, so go ahead and copy with a clear conscience.

(If you want to "pay" me, drop me a little email note saying how many free copies you distributed. That will satisfy my curiosity, and might encourage me to make this offer every year.)


To make this offer even more attractive, remember that I'm offering a list of bargain book bundles from Take a look at the books in each bundle by clicking one of these links:
Experiential Learning (3 volumes @$45)

Fable Bundle (2 volumes @$7.99)

Residue Class Mystery Series (3 volumes@$11.99)

Quantum Stringer Series (3 volumes@$14,99)

The Testers Library (8 volumes@$49.99)

Secrets of Consulting  (2 volumes@$14.99 )

Quality Software  (11 volumes@$49.99)

General Systems Thinker Bundle (5 volumes@$29.99 or less)

Requirements  (2 volumes@$14.99)

Using these bundles with the copying offer, you'll be able to fulfill an enormous gift list with minimal expense.

Thursday, December 04, 2014

Gifts for Any Time, but Especially Now

Now that we're finished with that Black Friday and CyberMonday hysteria, it's time for my annual Christmas poem:

Twas the week before Christmas,
And all through the house,
Every creature was fretting
And starting to grouse.

Then from UPS
Came a gift flowerpot
From a friendly old colleague
Whose gift I'd forgot.  

But then I remembered:
Don't feel like a schnook
In just a few minutes
I can send a great book

No wrapping, no breakage,
No address to scrawl,
No trade-ins, no trouble,
'Cause one size fits all.

So boot up your browser,
And don't be a schnook.
In a fistful of keystrokes
You can send a fine book.

Naturally, I recommend one of my novels for a fun read and fitting gift—perfect for smart adults and bright teenagers.

For just $6.99 each (or less when buying more than one), you can go to to read about each story and what reviewers said. Then you can send your friends engaging, exciting stories, each one that also carries one or more science/technology themes. 

These novels are my attempts to put the science back in science fiction and the techno back in techno-thrillers.

The Residue Class Mysteries Themes
The Freshman Murders: Computers, Culture, Genealogy
Where There's a Will There's a Murder: Mathematics, Anthropology
The Death Lottery: Randomness, Programming, Espionage

The Quantum Stringers Series Themes
Quantum String Quartet: Physics, Social Psychology
Quantum String Sextet:: Team Building, Communication
Quantum String Band:: Space Travel, Psychology

The Women of Power Series Themes
Mistress of Molecules: Chemistry, Politics
The Hands of God: Parallel Computing, Neurophysiology, Prosthetics
Earth’s Endless Effort: Unconventional Computers, Alien Contact

The Aremac Project Series Themes
The Aremac: Software Development, Testing, Security
Aremac Power: Risks and Rewards of Invention

And, of course, Computers in every story!

And if you've already gifted everyone on your list, I invite you to try one of my novels for yourself. As always, if it doesn't fit for you, I’ll gladly return your money.

Have a wonderful Holiday every day,

p.s. You can also gift your techie friends with some of my non-fiction ebooks: See

Saturday, November 15, 2014

The Compulsion to Give Feedback

Continuing the the series of samples from various books, this week I'm posting a chapter from What Did You Say?: The Art of Giving and Receiving Feedback.
 The ebook version is posted on and other sites for only $9.99. It is also part of the Bargain Book Bundle, The Tester's Library, a collection of seven books for only $49.99:
Perfect Software and Other Illusions About Testing
Are Your Lights On: How to Know What the Problem Really Is
Handbook of Technical Reviews (4th edition)
General Systems Thinking: An Introduction
What Did You Say?: The Art of Giving and Receiving Feedback
More Secrets of Consulting: The Consultant's Tool Kit
Becoming a Technical Leader
The Aremac Project

The Compulsion to Give Feedback

The best way to convince a tenderfoot is to let him have his own way.

Even When Requested, Feedback Describes the Giver
Jerry was presenting a workshop in Lincoln, where he then lived. It was the first time he had offered this particular workshop, and he was quite anxious about how well it was going. At the end of the first day, Jerry gave Foster a ride home. While they rode, he asked Foster, "How did it go?"

Foster said, "Jerry, there's only one thing that I don't understand out of our discussion today."

"And what's that?" Jerry asked.

"If you're such a good consultant, why do you drive such an old car?"

Jerry may have thought he was asking for feedback about his workshop, or about himself. Instead, he got information about Foster. This suggests the first of The Giver's Fact:

Even when it's given at the receiver's request,
feedback describes the giver more than the receiver.

Why should this be so? The Satir's Interaction Model gives us some clues:

  1. The giver only perceives certain aspects of the receiver's behavior. Nobody can give feedback on behaviors that are outside of their perception.
  2. Second, givers then organize these perceptions in ways that are meaningful to them. Nobody will comment on things that they do not see as having meaning.
  3. The giver selects certain aspects out of thousands that might be commented upon, according to the emotional reaction triggered in them. That day, Foster happened to be interested in new cars.
  4. The giver's inner feelings and rules for commenting determine the style, choice of words, emotional tone, and non-verbal cues that comprise the entire feedback package.

All of this provides information on how the giver sees other people and behaves towards them. In fact, clever individuals often seek feedback solely to diagnose the giver, paying little or no attention to the content as it applies to them.

The Second Most Essential Human Need
The Giver's Fact says we reveal ourselves by giving feedback. Don't we respect our privacy enough to be unwilling to reveal so much about ourselves? So why don't we keep our feedback to ourselves?

The simple truth is that we cannot help ourselves. Giving feedback seems to be the second most essential ingredient of life itself–after air, and before water. Humans can live for about three minutes without air, three days without water, and three months without food. But according to our observations, most people cannot live more than three hours without offering someone else an observation about themselves–often in the form of advice.

Although we cannot hope to eliminate so fundamental a need, we might be able to help you tame your impulses. If we could stretch the three hours to four, or slow the reflex long enough for you to shape the feedback more appropriately, then we will have made an immense contribution to human welfare.

Perhaps the following facts about helping will help you not be so impatient to be helpful.

Nobility Isn't Good Enough
We often think since we're trying to help by giving feedback, it will be easy to succeed. As a result, we often become careless.

Fact: Wanting to help people may be a more noble motive than some, but that doesn't make feedback any easier.

Any time someone asks you for feedback–or even worse, pays you for feedback–you may think how smart and good you must be–so you grow careless. Giving or receiving feedback effectively always requires precise work. Careless feedback is a sure ticket to disaster.

They Have to Want It
If you're not absolutely sure they want your feedback, it's best to check it out. One way to check it out is by asking, which we seldom ever bother to do.

Fact: If people don't want your feedback, you'll never succeed in reaching them, no matter how smart or wonderful you may be.

We stress the importance of not giving uninvited feedback, not because it's morally wrong, but because it doesn't work. It's okay to do it if you don't care about your relationship with the other person. Or you don't mind wasting your own time. Indeed, that's a pretty good description of when you are likely to yield to the temptation to give unsolicited feedback:

We don't really care about the other person, and we don't have anything very useful to do with our time.

No Invitation is Forever
Even when you care about people who ask you for feedback, they may change their minds when they discover what your feedback will cost them. Once we start to give feedback, we often fail to recognize obvious clues that our feedback is no longer welcome.

What are such obvious clues? As the interaction advances, you may find yourself growing progressively more rude, impatient, and suspicious. If you feel that way toward someone you're trying to help, perhaps you're sensing that they don't want your help any longer.

Fact: Even when people agree that they want your help, that agreement is not usually a lifetime contract.

When you agree to provide feedback, you're not committed to continue giving it. You are committed to continue monitoring the situation to discover when the feedback is no longer wanted.
And then to stop.

Some Things Are Worse Than Failure
Just stopping seems hard to do, especially when "just one last word" will patch up the worsening situation. Whenever you find yourself thinking things couldn't get a lot worse, just remember that they can–a lot worse.

Fact: Even when you agree to give feedback to someone, that agreement need not be a lifetime contract. You're allowed to stop when you've had enough.

It's all right to admit you failed in your generosity, especially if it helps you stop before you make things a lot worse.

You Ain't No Saint
People who want to give feedback to other people generally expect to get something out of it for themselves–though they may not be aware of this expectation. Before you yield to the temptation to give feedback, become aware of your expectations.

Fact: There are very few living saints–at least, we've never had the pleasure of meeting any.

Most people agree that this moral applies to other people. Few people realize it applies to them. Certainly not any of your authors.

The Best Use of Giving Feedback
Giving feedback is often a way of exercising influence via the Trojan Horse. It looks as though it is for the benefit of the receiver but disguises the payoff to the sender. Regardless of the utility to the receiver, such feedback serves as a convenient vehicle for avoiding, displacing, attacking, gaining status, and justifying the status quo for the sender.

Fortunately for world peace, receivers can usually sense the existence of hidden motives in feedback. When they do, there's little chance of their accepting the ostensible message. If you're really interested in helping people, you'll do well to start your feedback by opening your own motives to inspection, perhaps by using the interaction model.

Of course, this seems a rather tedious way to start feedback, but most of the time, introspection and care with words will be far more efficient and effective than sending Trojan Horse Feedback. More often than not, however, we stop short of a full explanation of our motives. Instead, we settle for something quick, easy, comfortable, compatible, or self-limiting.

As a sender, your best use of feedback is to note your impulse to give, then reflect on what is going on inside you. There are unlimited opportunities of other things you might do to improve your relationships. What makes offering feedback your most appealing alternative? Have you become a feedback junkie? Have you forgotten there are other ways?


For the end of this year, I'm offering a list of bargain book bundles from Take a look at the books in each bundle by clicking one of these links:

Sunday, November 09, 2014

Measuring Requirements Ambiguity

Chapter 19 Ambiguity Metrics
Continuing the the series of samples from various books, this week I'm posting a chapter from Exploring Requirments Two, just posted to as a bargain bundle with Exploring Requirements One. - See more at:

Contrary to what some people think, requirements do have to be tested. At least, they must be tested if the project is to have a fighting chance of success. Part V of Exploring Requirements Two, develo specific ways in which requirements can be tested.
19.1 Measuring Ambiguity
The whole purpose of the requirements process is to reduce ambiguity in the development process, so the most basic test of any requirement is to measure its ambiguity. We've discussed requirements ambiguity, but the term "ambiguity" is itself ambiguous. There are many ways to reduce the ambiguity in "ambiguity," but the best would be to specify a precise way of measuring it. After all, there's little ambiguity in this requirement:
A. Draw a straight line on a blank sheet of 8.5" x 11" white paper, 13.150 ± .025 centimeters in length, .500 ± .025 centimeters in width, using a freshly sharpened Dixon Ticonderoga 1388 number 2 pencil. The line should be parallel to the top of the page, 2.000 ± .025 centimeters from the top, and touching the unbound edge.
On the other hand, we've already seen how much ambiguity there can be in a requirement that says:
B. Design a transportation device.
If "ambiguity" is a property of a requirement, then we'd like to be able to measure it in such a way that statement A has a small amount and statement B has a large amount.
19.1.1 Using the ambiguity poll
The ambiguity measure we will develop is based on something we already observed in the "Design a transportation device" example. We gave statement B to a thousand individuals, instructing them to work independently on a solution. As we saw, this problem statement lacks many essential ingredients, and we could have anticipated that each participant would resolve each one uniquely. Even if all solvers were trained to use the same design process, we'd be shocked to find that even two had produced exactly the same design.
Now suppose we gave statement A to a thousand individuals, working independently on a solution. The problem statement lacks a few essential ingredients, and since people are different, we would expect some individuals would create idiosyncratic solutions. Generally speaking, though, we'd expect there would be only a few variations, and most solutions would be indistinguishable.
This mental experiment suggests we can measure ambiguity as the diversity of interpretation. We have actually performed this experiment with large groups. For problem A, we measured the diversity by comparing the lines drawn. Everyone drew a single line, in pencil, and there were only minor variations in line length and placement on the page.
For the transportation problem (B), we gave each person one minute to develop a conceptual solution. At the end of that time, we asked each to give a single number as an estimate of the manufacturing cost of the proposed transportation device. Obviously, if they all had designed the same solution, their manufacturing costs would have varied somewhat, but not by much. In fact, for roughly a thousand people, the cost estimates varied from $10 to $1.5 billion. This ratio of 1,500,000,000/1 indicates an extreme difference of opinion regarding the meaning of the problem, but isn't that precisely what we mean by ambiguity?
Such a ratio of largest to smallest estimate in a poll of informed individuals can be used as an ambiguity metric, a measurable entity for which we can obtain a precise value. Of course, a precise metric may not be extremely accurate, but it's far better than no measure at all. Indeed, it's a rather practical measure, one we have often used in real design situations.
19.1.2 Applying the polling method
A manufacturer of precision electrical components was studying the feasibility of developing an automated system for handling catalog information requests. The company's president had cost estimates ranging from "moderately inexpensive" to "moderately expensive," and didn't know whether to authorize the project. We asked each of 14 qualified individuals to write an independent estimate of the project cost. The estimated amounts ranged from $15,000 to $3 million. When the company president saw this 200/1 ratio, he halted the feasibility study to wait for a less equivocal requirement.
19.1.3 Polling on different bases
"Manufacturing cost" is only one possible basis for an ambiguity poll. Others that come quickly to mind are
1. total design and development cost
2. worker-years required for design and development
3. number of unique parts in the solution
4. minimum calendar time required to deliver the first product
These measures would apply to any project, but others would be more specific. For instance, in the transportation device problem, we might ask for estimates of
5. efficiency: average energy consumption per hour of use
6. range: how far it could transport
7. capacity: maximum weight it could carry at one time
19.2 Using the Metric as a Test

One useful model of design says design is the process of removing ambiguity. In terms of this model, design proceeds through a series of steps: creating an approximate design, testing for ambiguity, removing the ambiguity found, and retesting the new approximation. Eventually, the tests say the latest approximation is close enough, and design stops.
(In the book, the text continues to explain in detail how to use the ambiguity metric as a test in several different ways.)


For the end of this year, I'm offering a list of bargain book bundles from Take a look at the books in each bundle by clicking one of these links:

(Get both Volume One and Volume Two in a single bargain bundle)

Sunday, November 02, 2014

Ambiguity in Stating Requirements

Continuing the the series of samples from various books, this week I'm posting a chapter from Exploring Requirments One, just posted to as a bargain bundle with Exploring Requirements Two.

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.


For the end of this year, I'm offering a list of bargain book bundles from Take a look at these bundles by clicking these links: