The art and science of disambiguation
Jeff Gray reports in his Collection of Ambiguous or Inconsistent/Incomplete Statements that “the 500 words used most in the English language each have an average of 23 different meanings.” I think there are few times in life when you better grasp this fact than when you are either writing software requirements or when you are teaching English to a two-year old. Since I am actively engaged in both of these tasks right now, I thought I would spend a little time looking at the topic of ambiguity.
I find that starting a discussion of ambiguity with this example is a powerful means of grounding the participants in just how pernicious the problem can be. Once people realize that a simple and well-known nursery rhyme can be accurately distorted into something that bears absolutely no resemblance to its former self, it is far easier to convince them that they need to actively hunt down and root out the ambiguity in their software requirements.
Where to start? An excellent resource for someone who is looking for a primer on the topic of ambiguity can be found here – the ambiguity handbook. Written by two computer scientists and a lawyer, the handbook looks at the challenges of ambiguity with a special emphasis on software requirements.
The authors cover a wide range of topics over the course of 80 pages, but there were three sections that I found particularly compelling.
Techniques for dealing with ambiguity - Here, the authors present multiple techniques for dealing with ambiguity during each of three requirements activities - elicitation, documentation, and validation. The establishment of a shared context is identified as a key elicitation technique. During requirements documentation, the authors suggest it is important to work on actively increasing the precision of natural language. Finally, communicating an interpretation of the requirements document back to the original author is suggested as a technique for removing ambiguity when requirements are being validated.
Ambiguous, vague, and uncertain words - This section comprises a large portion of the document and is filled with many examples of words to be wary of along with numerous ways in which each be parsed. A common misuse of “all” is highlighted by showing how the phrase “all persons have a unique national insurance number” can be interpreted two extremely different ways. Does each person have their own unique number, or does everyone share the same number?
Examples - The authors take the lessons discussed previously and illustrate a sample of them using actual ambiguities from real projects. One example is taken from a set of requirements for an electronic toy, the Tamagotchi cyber chicken. If you don’t recall, this toy presented the user with an electronic chicken that needed to be “fed” and “cared for” in order for it to stay alive. One of the requirements reads “the Tamagotchi dies when it is not fed for one day.” What exactly does this mean? Will the electronic chicken “die” when it is not “fed” for one day, or will the toy itself cease to function if it isn’t given new batteries daily? Probably both, but that is a different issue altogether.
Of course, the reality is that ambiguity is all around us and always will be. I know for a fact that some of you will read this entry and have a few chuckles as you count the number of ambiguities that this “article about ambiguity” actually contains. Unfortunately, the cost-benefit analysis for removing all possible ambiguity from this blog post does not support me taking the time to do so. Can the same be said of your software requirements? If you think the answer is no, then spending some time learning about the research around ambiguity will likely pay off in the long term.
Mary had a little lamb.What exactly does this phrase mean to you? Here are some possible answers.
Mary owned a lamb.Far more than being an exercise in silliness, I have found that this example is a fantastic embodiment of the challenge inherent in casually using the English language as an everyday tool. The “Mary had a little lamb” and “Mary conned the trader” heuristics were developed by Gerald Weinberg and Donald Gause in their book Exploring Requirements: Quality Before Design. The authors suggest that writers of requirements must break each statement down into its component parts and explore how the various interpretations of each word may lead the overall meaning to diverge wildly from the original intent.
Mary gave birth to a small sheep.
Mary ate some mutton.
Mary conned a mild-mannered person.
I find that starting a discussion of ambiguity with this example is a powerful means of grounding the participants in just how pernicious the problem can be. Once people realize that a simple and well-known nursery rhyme can be accurately distorted into something that bears absolutely no resemblance to its former self, it is far easier to convince them that they need to actively hunt down and root out the ambiguity in their software requirements.
Where to start? An excellent resource for someone who is looking for a primer on the topic of ambiguity can be found here – the ambiguity handbook. Written by two computer scientists and a lawyer, the handbook looks at the challenges of ambiguity with a special emphasis on software requirements.
The authors cover a wide range of topics over the course of 80 pages, but there were three sections that I found particularly compelling.
Techniques for dealing with ambiguity - Here, the authors present multiple techniques for dealing with ambiguity during each of three requirements activities - elicitation, documentation, and validation. The establishment of a shared context is identified as a key elicitation technique. During requirements documentation, the authors suggest it is important to work on actively increasing the precision of natural language. Finally, communicating an interpretation of the requirements document back to the original author is suggested as a technique for removing ambiguity when requirements are being validated.
Ambiguous, vague, and uncertain words - This section comprises a large portion of the document and is filled with many examples of words to be wary of along with numerous ways in which each be parsed. A common misuse of “all” is highlighted by showing how the phrase “all persons have a unique national insurance number” can be interpreted two extremely different ways. Does each person have their own unique number, or does everyone share the same number?
Examples - The authors take the lessons discussed previously and illustrate a sample of them using actual ambiguities from real projects. One example is taken from a set of requirements for an electronic toy, the Tamagotchi cyber chicken. If you don’t recall, this toy presented the user with an electronic chicken that needed to be “fed” and “cared for” in order for it to stay alive. One of the requirements reads “the Tamagotchi dies when it is not fed for one day.” What exactly does this mean? Will the electronic chicken “die” when it is not “fed” for one day, or will the toy itself cease to function if it isn’t given new batteries daily? Probably both, but that is a different issue altogether.
Of course, the reality is that ambiguity is all around us and always will be. I know for a fact that some of you will read this entry and have a few chuckles as you count the number of ambiguities that this “article about ambiguity” actually contains. Unfortunately, the cost-benefit analysis for removing all possible ambiguity from this blog post does not support me taking the time to do so. Can the same be said of your software requirements? If you think the answer is no, then spending some time learning about the research around ambiguity will likely pay off in the long term.
posted by Anonymous at 2/07/2006 10:45:00 PM
2 Comments:
NO TOP BUN! This reminds me of a funny story that one of our users told at our User Conference. He asked for his hamburger with no top bun because he was dieting - so when his order came, it had a bottom bun underneath his burger as expected and another bottom bun on the top his burger. And he didn't get a top bun as requested...
Shared context should not be sought. It doesn't exist. JAD, an executive sponsor, any other technique that's been invented doesn't create a shared context. It forces the requirements down people's throats. Then, they come back and take it out on the developers through requirements volitility. Requirements volitility comes from office politics.
The reason that shared context is sought is that it is more efficent for developers to create an application this way. But, beyond requirements volitility, this only inserts negative use costs into the organization and its cost structure.
When an application doesn't meet a particular users requirements, that user must make up the difference. What was supposed to be automated only does half the job, and really it only does four different, disjunt eights of the job.
Try to get marketing and sales to agree on what a customer is? They can't. It isn't personal. It's cultural. The difference shouldn't stop you from serving both cultures. You just can't do it using the same user cognative models or interfaces.
A corporation involves more cultures than just "THE CORPORATE CULTURE." Every functional unit has its own culture. Every generation has its own paradigm. Within a functional unit, paradigms are fought over. Across functional units, the discipline specific cultures fight to preserve their performance. They are not fighting for fun.
These cultural boundaries should be respected, instead of glossed over, or busted. A busted silo is a broken company. Imposed requirements bust all silos. Developers just have to deal with the requirements volitility the requirements elicitor created.
Post a Comment
<< Home