Page 37 - Software and Systems Requirements Engineering in Practice

10 S o f t w a r e & S y s t e m s R e q u i r e m e n t s E n g i n e e r i n g : I n P r a c t i c e

The Use of the Terms “Valid” and “Correct”
The IEEE Standard 830 uses the term “correct.” We use the term “valid”
instead because “correct” can be misleading. Something that is “correct”
is said to be “without error,” or mathematically provable. However, in
the context of a requirement, “valid” is more appropriate, as the
requirement may be exactly what the customer wants, but it may still
contain errors or be an inappropriate solution.

Unambiguous
A requirement is unambiguous if it has only one interpretation. Natural
language tends toward ambiguity. When learning writing skills in
school, ambiguity can be considered a plus. However, ambiguity is
not appropriate for writing the requirements for a product, and care
must be taken to ensure that there is no ambiguity in a requirements
specification. For example, consider this statement:
“The data complex shall withstand a catastrophe (fire, flood).”
This statement is ambiguous because it could mean “The data
complex shall withstand a catastrophe of type fire or flood,” or it
could mean “The data complex shall withstand any catastrophe, two
examples being fire and flood.” A person skilled in writing requirement
specifications would rephrase as
“The data complex shall be capable of withstanding a severe fire.
It shall also be capable of withstanding a flood.”
An example of an ambiguous statement is “The watch shall be
water resistant.” An unambiguous restatement is “The watch shall
be waterproof to an underwater depth of 12 meters.”
A measure of the quality of a requirements specification is the
percent of requirements that are unambiguous. A high level of
ambiguity could mean that the authors of the specification likely
need additional training. Ambiguity often causes a project to be late,
over budget, or both, because ambiguity allows freedom of
interpretation. It is sometimes necessary to take a holistic view of
ambiguity; e.g., a requirement may be ambiguous, but when placed
in the context of the background, domain, or other related
requirements, it may be unambiguous. Product features found in
marketing literature (e.g., shock resistant) are typically ambiguous.
However, when placed in the context of the detailed specifications
used by manufacturing, the ambiguity is no longer present. On the
other hand, a requirement may be unambiguous, but when placed
in the context of related requirements, there may be ambiguity.