Ambiguity is a major problem in requirements specification. We ignore intentional ambiguity or the ambiguity that exists in early stages of requirements elicitation and focus on ambiguity that remains in a so-called final natural language requirements document.

Amiguity is a problem because the different readers of the requirements specification may understand different things. If the implementors' understanding of the document differs from that of the customer or users, then the customer and the users are likely not to be satisfied with the implementation produced by the implementors.

Many times, ambiguity is not noticed by anyone looking at the requirements document. Very often, each subconsciously disambiguates the document to the first interpretation he or she finds and he or she thinks that this first interpretation is the only interpretation.

There are two elements to this work, first, a Ph.D. thesis by Eirk Kamsties, one of Berry's Ph.D. students, and the second some joint work between Berry and Kamsties and two lawyers, Michael M. Krieger and David G. Kay, both with computer science backgrounds.

1. In industrial requirements engineering (RE), natural language is the most frequently used representation to state the requirements that are to be met by information technology products or services. Natural language is universal, flexible, and wide-spread, but unfortunately also inherently ambiguous. Even worse, often neither customers nor software developers recognize an ambiguity, and each derives an interpretation that differs from that of others without noticing this difference. Consequently, software developers design and implement a system that does not behave as intended by the customers. Semi-formal and formal representation techniques, such as UML or SCR, have been proposed to overcome the weaknesses of natural language. However, they only shift the problem; an ambiguity simply becomes an unambiguously wrong specification statement, which must be detected by the customers in reviews or simulations of the specification.

   This thesis addresses the problem of detecting ambiguities in natural language requirements. We distinguish between linguistic and RE-specific ambiguities. Linguistic ambiguities are the commonly known ambiguities of natural language, such as ambiguous pronoun references. RE-specific ambiguities arise from the RE context, which comprises the application, system, and development domain. The requirement The system injects coolant to [...] when the pressure falls below a 'low' threshold is ambiguous because of the system domain, i.e., it is not clear whether injecting coolant is a discrete action or continuous activity. An experiment was performed to understand the problems that the different types of ambiguity cause during the formalization of informal requirements.

   This thesis presents the ADTD approach, which allows developing techniques for detecting ambiguities in natural language requirements on the basis of existing and industrially proven techniques, namely checklists, scenario-based reading, and agendas. A technique for detecting ambiguities must be tailored to a particular RE context to be effective, because RE-specific ambiguities depend heavily on the context in which an RE takes place. For this purpose, the ADTD approach provides heuristics to investigate metamodels, which capture information about an RE context. These heuristics help identify the RE-specific types of ambiguities that are typical for the particular RE context.

   A set of ambiguity detection techniques for the domain of embedded systems was developed using the ADTD approach to show its feasibility. To quantify the benefits of the ADTD approach, the resulting techniques were empirically validated in five experiments. The goals were (1) to validate that the investigation of metamodels pays off in terms of higher efficiency of the resulting technique and (2) to show that our ambiguity detection techniques are superior to existing ones.

   From a practitioner's perspective, a set of validated techniques for detecting ambiguities is provided, which allow improving current RE processes of different maturity. The ADTD approach is available for developing additional techniques if the provided ones do not fit the situation at hand. From a researcher's perspective, new insights are provided on the problems that defects, and ambiguities in particular, cause when semi-formal or formal specifications are developed from an informal statement of requirements. Also, the thesis provides a comprehensive understanding of the various facets of ambiguity in RE. This understanding clarifies the currently ambiguous use of the term in the literature.

2. The work with the lawyers stems from the observation that software requirements specifications and legal contracts are similar in several key aspects:
   • each is usually written in mostly natural language,
   • each must anticipate all possible contingencies, and
   • each must be correct, consistent, complete, and unambiguous.

   Consequently the team is preparing a handbook titled, ``From Contract Drafting to Software Specification: Linguistic Sources of Ambiguity'', which can be used both as a guide to preparing unambiguous requirements specifications and contracts and as a checklist for ambiguity inspectors of requirements specifications and contracts.

   The handbook observes the similarity between software requirements specifications and legal contracts. Particulary when these are written, as they usually are, in natural language, ambiguity is a major cause of their not specifying what they should. Simple misuse of the language in which the document is written is a significant source of these ambiguities. The handbook details the problems arising from common difficulties with ``all'', ``each'', and ``every'' to denote 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. Examples from requirements documents and legal documents are examined. The handbook is suggested as a guide both for writing better requirements or contracts and for inspecting them for potential ambiguities.

   At some point, someone should do a study to determine the effectiveness of this handbook, both as a guide for writing specifications and as a guide for checking specifications.