Page 40 - Software and Systems Requirements Engineering in Practice

n
I
C h a p t e r 1 :
o
r
t
n
c
u
d
o
i
t
C h a p t e r 1 : I n t r o d u c t i o n 13 13
was that “the developers will finish writing the requirements.” But
when doing a risk analysis, it was nearly always quite clear that
having the developers complete the requirements was not an
appropriate process, due to
• Limited access to subject matter experts
• Lack of experience or bias when defining product requirements
At the back end of the project, the failure to properly define the
requirements almost always caused a greater delay than would have
happened by allowing the requirements specification to be completed
with the appropriate level of detail up front.
Traceable
Requirements traceability is the ability to describe and follow the life
of a requirement, in both a forward and backward direction, i.e., from
its origins, through its development and specification, to its
subsequent deployment and use, and through periods of ongoing
refinement and iteration in any of these phases” [Gotel et al. 1994].
Traceability is required for proper requirements management and
project tracking.
A requirement is traceable if the source of the requirement can be
identified, any product components that implement the requirement
can easily be identified, and any test cases for checking that the
requirement has been implemented can easily be identified.
Tracing is sometimes mandated by a regulatory body such as the
Federal Aviation Administration (FAA) or Food and Drug
Administration (FDA) for product safety. Furthermore, there are
some rare situations where failure to create the appropriate traces
between requirements can have legal repercussions. Traceability is
discussed in more detail in Chapter 7.

Other Project- or Product-Specific Characteristics
Occasionally, the requirements for a specific project or product have
characteristics that do not apply to all the projects or products. While
it can be argued that an attribute that crosscuts all other requirements
is just another requirement, when treated as a characteristic it is more
likely that the requirement will be fulfilled. For example, if a new
system is being built that must be downward compatible with an
older system, it could be argued that the need for downward
compatibility is just a nonfunctional requirement. However, we have
found that having such all-encompassing requirements converted to
characteristics makes it more likely that the completed system will be