Daniel M. Berry

School of Computer Science
University of Waterloo
Waterloo, ON, Canada

Abstract:

When requirements are written, as they usually are, in natural language, ambiguity is a major cause of their not specifying what they should and implementers' implementing the wrong system. Simple misuse of the language in which the document is written is one source of these ambiguities.

This talk describes the ambiguity phenomenon from several points of view, including linguistics and software engineering. Gause's phenomenon of subconscious disambiguation is observed. Several strategies for avoiding and detecting ambiguities are presented. Strong emphasis is given on the problems arising from the use of heavily used and seemingly unambiguous words and phrases such as ``all'', ``each'', and ``every'' in defining or referencing sets; positioning of ``only'', ``also'', and ``even''; precedences of ``and'' and ``or''; ``a'', ``all'', ``any'', ``each'', ``one'', ``some'', and ``the'' used as quantifiers; ``or'' and ``and/or''; ``that'' vs. ``which''; parallelism; pronouns referring to an idea; multiple adjectives; etc. Each occurrence of any of these words and phrases is a potential ambiguity. Many, somewhat humorous, examples from requirements documents are examined.

It turns out that the most useful time to identify potential ambiguities is when reading initial requirements descriptions from clients. Each potential ambiguity is the source of a question to the client to determine exactly what he or she means and to avoid subconscious disambiguation on the parts of the implementers.