Page 39 - Software and Systems Requirements Engineering in Practice

12 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

whereas a user interface requirement might specify that the logo be at
the bottom center of the screen. There are now two conflicting
requirements, and even though a requirements specification may be
internally consistent, the specification would still be inconsistent
because of conflict with corporate standards. Creating documentation
that is both internally and externally consistent requires careful
attention to detail during reviews.
Complete
A requirements specification is complete if it includes all relevant
correct requirements, and sufficient information is available for the
product to be built. When dealing with a high-level requirement, the
completeness characteristic applies holistically to the complete set
of lower-level requirements associated with the high-level feature
or requirement. Completeness also dictates that

• Requirements be ranked for importance and stability.
• Requirements and test plans mirror each other.

A requirements specification is complete if it includes the following
elements [IEEE 1998]:

1. Definition of the responses of the system or product to all
realizable classes of input data in all realizable classes of
situations. Note that it is important to specify the responses
to both valid and invalid input values and to use them in test
cases.
2. Full labels and references to all figures, tables, and diagrams
in the specification and definitions of all terms and units of
measure.
3. Quantification of the nonfunctional requirements. That is,
testable, agreed-on criteria must be established for each
nonfunctional requirement.

Nonfunctional requirements are usually managed by the project’s
chief architect. In order for the completed product to be correct and
complete, it must include the testable requirements that have been
derived from the high-level nonfunctional requirements.
It is difficult to create complete specifications, yet complete
specifications are mandatory under certain circumstances; e.g.,
where the implementation team has no domain knowledge, or where
communication between subject experts and developers will be
problematic. We have seen projects where the requirements definition
phase was shortened for schedule reasons. The general consensus