Unambiguous Requirements Models

We’ll see that the concept of ambiguity of (requirements in software engineering) models comprises structural as well as material aspects, on all model levels (top to bottom).

Unambiguous is a core quality characteristic of software requirements specs (SRS). For example, IEEE 830 defines:

“An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.”

Apart from linguistic confusions, like the escalator sign “Dogs must be carried” etc, even in a clearly stated requirement there can be numerous ways of interpretation.

Unambiguous in Higher Level Models

For example, in “Every Employee works for at least one Company” the unary predicate Employee(x) can be interpreted in various ways, and thus needs to be defined. Picturing this as part of an entity-level model (e.g. ER model) such a definition can be given by an informal (material) description in natural language, as for example: “A person that works part-time or full-time under a contract of employment.”. Since this kind of definition is the best one can do on the entity level, the model (pictured only on this level) can be practically considered unambiguous.

Unambiguous in Bottom Level Models

Subsequently, during the process of specification the predicate will usually be specified on a deeper level. In the above case attributes can be attached to the entity Employee, like “First name”, “Last name”, “Social security number” (SSN), etc, with a formally defined data type each, like char(7) for SSN, perhaps even with some further restrictions in a formal language like “^[A-Z]{3}[0-9]{4}$” (3 letters and 4 digits). Thus, by rigid typing on the bottom level the attribute be can structurally (up to isomorphism) defined.

Thus

Does that mean one can do away with all material descriptions of SSN like “A SSN is …”, the descriptive name “Social security number” itself (and replace it by “X”), and consequently with the entity-level description (“A person that …”) as well? In other words, would one consider a solely structural definition of SSN as unambiguous? Certainly not! Thus, unambiguity consists of a structural and material part. This connects it with, but also sets it apart from correctness, completeness, and consistency.

So long
|=

PS
The structural unambiguous specification on the bottom level is one important aspect that distinguishes software engineering from physical engineering disciplines.