An Angry Wife: A Lesson in Requirements Engineering

Ever got in trouble with your wife for bringing the wrong items from the market? Imagine this:

Your wife asks you to go to the store to pick up the following items because she wants to make a cake:

• 5 pounds of flour
• 12 large eggs
• 5 pounds of sugar
• 1 pound of butter

Off you go to the nearest convenience mart (which is close to your home). At the store, you realize that you are not sure if she wants white or brown sugar. So, you call her from your cell phone and ask which kind of sugar she wants; you learn she needs brown sugar. You make your purchases and return home.

But your wife is unhappy with your selections. You bought the wrong kind of flour; she informs you that she wanted white and you bought wheat. You bought the wrong kind of butter; she wanted unsalted. You brought the wrong kind of sugar too, dark brown; she wanted light brown. Now you are in trouble.

So, you go back to the mart and return the flour, sugar, and butter. You find the white flour and brown sugar, but you could only find the unsalted butter in a tub (not sticks), but you assume a tub is acceptable to her. You make your purchase and return with the items. But now you discover that you made new mistakes. The light brown sugar purchase is fine, but the white flour you brought back is bleached; she wanted unbleached. And the butter in the tub is unacceptable—she points out that unsalted butter can be found in stick form. She is now very angry with you for your ignorance.

So, you go back to the store and sheepishly return the items, and pick up their proper substitutes. To placate your wife’s anger, you decide to also buy some of her favorite chocolate candy.

You return home and she is still unhappy. While you finally got the butter, sugar, and flour right, now your wife remembers that she is making omelets for supper, and that a dozen eggs won’t be enough for the omelets and the cake—she needs 18 eggs. She is also not pleased with the chocolate—she informs you she is on a diet and that she doesn’t need the temptation of chocolate lying around.

One more time you visit the mart and return the chocolate and the dozen eggs. You pick up 18 eggs and return home. You think you have gotten the shopping right when she queries: “Where did you buy these things?” When you note that you bought the items at the convenience mart, she is livid—she feels the prices there are too high—you should have gone to the supermarket a few miles further down the road.

We could go on and on with this example—each time your wife discovering a new flaw in your purchases, changing her mind about quantity or brand, adding new items, subtracting others, etc.

But what does this situation have to do with requirements engineering and stakeholders? The situation illustrates many points about requirements engineering.

First, you need to understand the application domain. In this case, having a knowledge of baking would have informed you ahead of time that there are different kinds of butter, flour, and sugar and you probably would have asked focused questions before embarking on your shopping trip.

Another point from this scenario—customers don’t always know what they want—your wife didn’t realize that she needed more eggs until after you made three trips to the store.

And there is yet one more lesson in the story: never make assumptions about what customers want—you thought that the tub butter was acceptable; it wasn’t. You finally learned that even providing customers with more than they ask for (in this case her favorite chocolate) can sometimes be the wrong thing to do.

But in the larger sense, the most important lesson to be learned from this encounter with a customer is that they can be trouble. They don’t always know what they want, and, even when they do, they may communicate their wishes ineffectively. Customers can change their minds and they may have high expectations about what you know and what you will provide.