Avoiding Ambiguity

Whether your source of requirements is written documents or verbal statements from interviews, you should be aware of the enormous potential for ambiguity and the misunderstanding that comes from it. Ambiguity may arise from several sources.

First, the English language is full of homonyms. The language contains an estimated 500,000 words, which have been added to the language and used by many different people over a long period of time. This gradual growth has led to different usages and meanings of the same word. Consider the word "file," which is used so commonly in information technology. In addition to meaning an automated storage place for information, it means a metal instrument for abrading or smoothing; a collection of documents; a row of people, as in "single file"; a slang term for an artful or shrewd person; a verb meaning to rub away or smooth; and more recently a verb used by lawyers, as when they "file suits." Of course, "suit" itself also means the clothing the lawyer wears in court, as well as a set of playing cards such as hearts, diamonds, spades, and clubs. It is difficult to imagine why, when the language contains so many words, so many of them have multiple meanings.

When writing requirements, we have to contend with more challenges than just homonyms. If the context of your product is not clear, then it will also lead to ambiguity. Suppose you have a requirement such as this:

The product shall show the weather for the next 24 hours.

The meaning here depends on the type of requirement and what is near it in the specification. Does the requirement mean the product is to communicate the weather that is expected to happen in the forthcoming 24 hours, or must it communicate some weather and continue to do so until a day has elapsed?

We advise you to group your requirements by product use case. This system of organization will, to some extent, reduce ambiguity. For example, consider this requirement:

The product shall communicate all roads predicted to freeze.

Does "all" refer to every road known to the product? Or just those roads being examined by the user? The use case scenario tells us that the actor has previously identified a district or a section of the district. Thus we may safely say that "all" refers to the geographical area selected. In fact, the meaning of almost any requirements depends on its context. This is quite a good thing, because we do not need to waste stakeholders' time by laboriously qualifying every word of every requirement. While anything has the potential to be ambiguous, the scenario, by setting a context for the requirement, minimizes the risk of ambiguity.

We loved the example erected by the city traffic authority in New York some years ago when it introduced red zones. Red zones were sections of streets where the authorities were particularly anxious that traffic not be impeded. The zones were designated by red-painted curbs and adorned by signs:

Although the last directive is ambiguous, the workers at the traffic authority made a reasonable judgment in taking the ambiguity risk. They decided that no driver was foolish enough to think they intended that drivers should not make jokes in their cars or give birth to baby goats. In other words, the authority made a reasonable assessment of how the majority of drivers would interpret the sign.

Similarly, when one of the engineers says, "We want to have the trucks treat the roads before they freeze," it is fairly clear that he does not mean that the roads have to be treated before the trucks freeze. At the very least, the context in which it was said should indicate the meaning.

We record the meaning of special words used by the project in section 5, Naming Conventions and Definitions, of the Volere Requirements Specification Template. We have found that this practice makes inroads into eliminating ambiguity.

You can also reduce ambiguity by eliminating all pronouns from your requirements and replacing them with the subject or object to which the pronouns refer. (Note the potential difference in meaning of the preceding sentence if we had said "they" instead of "the pronouns.")

When you write a requirement, read it aloud. If possible, have a colleague read it aloud. Confirm with your stakeholder that you both reach the same understanding of the requirement. This may seem obvious, but "send the bill to the customer" may mean that the bill goes to the person who actually bought the goods or that the bill is sent to the account holder. It is also unclear whether the bill is sent immediately after the purchase or at the end of the month. And does "bill" refer to an invoice, a bill of materials, or a bill of lading? A short conversation with the appropriate stakeholders will clarify the intention.

Keep in mind that you are writing a description of the requirement. The real requirement is revealed when you write the fit criterion. Until you add the fit criterion, a good description is both worthwhile and sufficient.