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).
| Comments |
Enjoyed that Karl,
Just yesterday, I stopped by a coffee store and ordered 6 fruit muffins.
On reaching home, to my consternation, I found out they were 6 of the same type.
I had assumed they were going to give me 6 different ones (cranberry, blueberry...), but by neglecting to use the key word ' different '. I failed to communicate my requirements accurately.
Just goes to show that if even in a small transaction, a requirements misunderstanding can occur, imagine the risk for a large complex project
Cheers !
Karl, in truth specifications using natural languages could contain ambiguities that could ultimately lead to wrong execution of projects. That being the case, how should specifications be presented?
Karl,
We see a trend in the use of simulation tools like "iRise" in defining and capturing requirements as an answer to overcome the difficulties created by natural language.
Will this be the new norm?
Jey
@gjohn: I agree completely, natural language is prone to ambiguities. That is one reason why I recommend using multiple views of the requirements, such as graphical models, tables, pictures, and other representations to supplement natural language. I don't expect us to replace natural language, simply because that is how people are used to communicating. However, I do think that most BAs can do a much better job than we do at present of writing textual requirements that are less ambiguous, if we are conscious of the many sorts of ambiguity that we can encounter.
In the late 1970s there was a movement toward "structured analysis." The thinking at that time was that we could dispense with the traditional written requirement specification and replace it with models. That does not work in practice, partly because analysis models and text often represent information at different levels of abstraction. If you read the rest of the articles in this series as they appear, you will understand why I endorse using a variety of representation techniques.
In fact, when I talk about "writing requirements," I really mean "representing requirements information." The creative BA will have a rich tool kit of techniques available and some judgment to use when selecting an appropriate knowledge representation technique for a given situation.
@Jey: I learned long ago not to try to predict the future, particularly when it comes to computing, so I'm not going to make a prediction as to exactly what methods and tools will become the new "norm" in requirements development. Simulation tools, prototyping tools, modeling tools, and the like are very valuable for exploring requirements. However, I think it's risky in most cases to conclude that a visual design will suffice to communicate enough information about a system's requirements to the stakeholders who need to do work based on those requirements. There's a lot going on behind the scenes it isn't obvious from a visual design, so simply prototyping screens doesn't replace the need to represent information in other forms, IMHO.
A combination of techniques is the best approach, thoughtfully applying simulation, visual design, natural language, analysis models, and so forth in a sensible way to achieve the two objectives of discovering requirements and recording requirements knowledge in an appropriate level of detail to reduce overall project risk.
I second the idea that the combined approach is the best way to go. And, I would add that often the most effective use of visual models is for the most complex part of a process - where there are multiple paths, decisions, alternative actions, and different outcomes. That complexity can be described in words but should be supplemented with an appropriate visual to reinforce the words. It is not necessary to create a visual for every part of a textual description.
In terms of the written requirments, I advise that you review and question yourself ... especially when you use an adjective. Ask "what do I mean by that"? In the case of the "high mileage" example above, a better choice may have been "fuel efficient" or better yet a more specific ... "vehicle that gets at least 50 miles per gallon".
Only registered users may post comments.
|
|