Page 290 -

CHAPTER 10 SYSTEM ENGINEERING 261

• Is the system specification structured in a way that leads to easy understand-
ing, easy reference, and easy translation into more technical work products?

• Has an index for the specification been created?
• Have requirements associated with system performance, behavior, and oper-
ational characteristics been clearly stated? What requirements appear to be
implicit?
Checklist questions like these help ensure that the validation team has done every-
thing possible to conduct a thorough review of each requirement.
WebRef
An article entitled
“Making Requirements 10.5.6 Requirements Management
Management Work for In the preceding chapter, we noted that requirements for computer-based systems
You” contains pragmatic
guidelines: change and that the desire to change requirements persists throughout the life of the
stsc.hill.af.mil/cross system. Requirements management is a set of activities that help the project team to
talk/1999/apr/ identify, control, and track requirements and changes to requirements at any time as
davis.asp
the project proceeds. Many of these activities are identical to the software configu-
ration management techniques discussed in Chapter 9.
Like SCM, requirements management begins with identification. Each requirement
is assigned a unique identifier that might take the form

<requirement type><requirement #>
where requirement type takes on values such as F = functional requirement, D = data
Many requirements requirement, B = behavioral requirement, I = interface requirement, and P = output
management activities requirement. Hence, a requirement identified as F09 indicates a functional require-
are borrowed from
SCM. ment assigned requirement number 9.
Once requirements have been identified, traceability tables are developed. Shown
schematically in Figure 10.4, each traceability table relates identified requirements to
one or more aspects of the system or its environment. Among many possible trace-
ability tables are the following:
When a system is Features traceability table. Shows how requirements relate to important cus-
large and complex, tomer observable system/product features.
determining the Source traceability table. Identifies the source of each requirement.
“connections” among Dependency traceability table. Indicates how requirements are related to one
requirements can be a
daunting task. Use another.
traceability tables to Subsystem traceability table. Categorizes requirements by the subsystem(s)
make the job a bit that they govern.
easier.
Interface traceability table. Shows how requirements relate to both internal
and external system interfaces.
In many cases, these traceability tables are maintained as part of a requirements data-
base so that they may be quickly searched to understand how a change in one require-
ment will affect different aspects of the system to be built.