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.

Mary had a little lamb.

What exactly does this phrase mean to you? Here are some possible answers.

Mary owned a lamb.
Mary gave birth to a small sheep.
Mary ate some mutton.
Mary conned a mild-mannered person.

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.

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.