Page 289 -

260 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

We build system models for much the same reason that we would develop a blue-
print or 3D rendering for the kitchen. It is important to evaluate the system’s com-
ponents in relationship to one another, to determine how requirements fit into this
picture, and to assess the “aesthetics” of the system as it has been conceived. Fur-
ther discussion of system modeling is presented in Section 10.6.

10.5.5 Requirements Validation

The work products produced as a consequence of requirements engineering (a sys-
tem specification and related information) are assessed for quality during a valida-
tion step. Requirements validation examines the specification to ensure that all system
requirements have been stated unambiguously; that inconsistencies, omissions, and
errors have been detected and corrected; and that the work products conform to the
standards established for the process, the project, and the product.
The primary requirements validation mechanism is the formal technical review
A key concern during
requirements (Chapter 8). The review team includes system engineers, customers, users, and other
validation is stakeholders who examine the system specification looking for errors in content or
5
consistency. Use the interpretation, areas where clarification may be required, missing information, incon-
system model to
ensure that sistencies (a major problem when large products or systems are engineered), con-
requirements have flicting requirements, or unrealistic (unachievable) requirements.
been consistently Although the requirements validation review can be conducted in any manner that
stated. results in the discovery of requirements errors, it is useful to examine each require-
ment against a set of checklist questions. The following questions represent a small
subset of those that might be asked:
• Are requirements stated clearly? Can they be misinterpreted?
• Is the source (e.g., a person, a regulation, a document) of the requirement
identified? Has the final statement of the requirement been examined by or
against the original source?
• Is the requirement bounded in quantitative terms?
• What other requirements relate to this requirement? Are they clearly noted
via a cross-reference matrix or other mechanism?

Requirements • Does the requirement violate any domain constraints?
• Is the requirement testable? If so, can we specify tests (sometimes called vali-
dation criteria) to exercise the requirement?
• Is the requirement traceable to any system model that has been created?
• Is the requirement traceable to overall system/product objectives?

5 In reality, many FTRs are conducted as the system specification is developed. It is best for the
review team to examine small portions of the specification, so that attention can be focused on a
specific aspect of the requirements.