There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant. The first man wrapped his arms around the elephant’s leg and said, “Why, an elephant is just like a big tree.” “No,” said the man who held the elephant’s tail, “an elephant is like a rope.” The third man felt the side of the elephant and reported, “This elephant is like a big wall.” 
The fourth man gripped the elephant’s trunk and declared, “You’re all wrong. The elephant is like a giant snake.” The fifth man rubbed the elephant’s tusk and said, “I think an elephant resembles a spear.” “No, no, no!” said the final man, who touched the elephant’s ear. “An elephant is like a big fan.”
The blind men were all correct. The elephant has all the characteristics they described, but no single feature of the elephant provides a complete description of what an elephant is all about. Each man had but a limited view of the elephant and could draw conclusions only from that view.
There’s an analogy with software requirements. I learned long ago from requirements guru Alan Davis that no single view of the requirements tells us everything we need to know about them. Often it’s desirable to represent requirements in multiple ways, thereby giving the readers a richer, more holistic understanding of the requirements elephant. Unfortunately, nearly every requirements specification I have read contains just a single view: natural language text. The adroit business analyst can do better than that.
Limitations of Natural Language
Natural language is, well, natural for people to use. We employ it every day of our lives in diverse forms. But natural language has some shortcomings. One of the biggest limitations is ambiguity. I once was talking with my father about cars. I said, “For my next car, I’d like to get one of those high-mileage gas-electric hybrids.” My father replied, “I don’t know if you’re going to be able to find a used one.” Used one? I didn’t say anything about buying a used car. When I said high-mileage, I meant, “gets many miles per gallon.” When my father heard high-mileage, he thought, “big number on the odometer.” These are both perfectly sensible interpretations of the phrase high mileage. Ordinary, natural language led to a miscommunication in a casual discussion with someone I knew rather well.
In conversation, we rely on context, body language, and the chance to ask questions for clarification to ensure that we understand what we heard. We have an opportunity during discussions to detect and quickly correct ambiguity. Written communication, such as a requirements specification, doesn’t allow for this opportunity. Confusion can result from misinterpretations and ambiguity, and ambiguity is one of the big risks that natural language poses for requirements. This is one reason why you should never expect an SRS to replace conversations among BAs, developers, and customer representatives. However, when collaborating on software development over long distances, you don’t have many opportunities for conversations. High-quality written communication becomes essential for success.
Writing in natural language also leads to bulky and verbose specifications. In an attempt to clarify what he’s trying to say, the BA might duplicate a piece of information or state it in more than one way. Redundancy often is not helpful in requirements specifications. It can introduce additional ambiguities and inconsistencies. And, frankly, long documents with page after page of text are boring to read and daunting to review. There’s a good chance that reviewers will glaze over and fail to find some of the problems in the document. This is unfortunate, because well-executed reviews of requirements documents are one of the highest-leverage quality practices you can perform on a software project. Detecting and removing defects while they are just ideas is much faster and cheaper than correcting problems in the code.
Another issue is that detailed textual requirement statements represent a low level of abstraction. Each requirement describes but a small fragment of the system’s functionality or characteristics, with little context. Specification readers can have a hard time grasping the big picture and seeing how each individual requirement contributes to it. This makes it difficult for them to judge whether each requirement is correct, complete, and necessary. So the ability to depict requirements knowledge at multiple levels of abstraction and from different perspectives provides a much richer understanding than can any single view.
In this series of four articles, I will describe why it is so valuable to create various views of your requirements. I’ll tell you about some of the analysis models and other techniques you can use to represent requirements information and give you some ideas about how to choose an appropriate model. These articles are adapted from my book, More about Software Requirements (Microsoft Press, 2006).
Contine on to article # 2: Why Create Multiple Requirements Views?
About Author :
Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons (www.PearlsFromSand.com).