Page 336 - Software and Systems Requirements Engineering in Practice
P. 336
298 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
is propagated upward to the root node. Thus, the extractable metric
would be that the feature is testable, and that is true if and only if all
the leaves in the tree formed by its downward traces are testable (see
Figure A.2).
Automatic Downward Propagation of Attributes
Just as some high-level attributes of a requirement can only be
determined by traversing all of its downward traces, so too can some
requirement attributes be calculated with an upward trace. However,
whereas downward tracing is through a tree structure, upward
tracing is through a directed graph. For example, certain safety-
critical features in medical products fall under FDA regulations that
require that a hazard analysis be performed on the requirement.
However, a product feature may have several hundred derived
system requirements. If the analysis can be performed at the feature
level, then, by implication, all of the derived requirements inherit the
analysis. But it is not that simple; a low-level system requirement
may trace back up a graph to several product features. If any one of
those high-level features has not been marked as having a completed
hazard analysis, then the low-level system requirement cannot be set
to “analysis completed.” Downward propagation can then be used to
improve productivity by reducing the workload of analysts; e.g.,
automatically marking hot spots and propagating attribute values
where appropriate (see Figure A.3).
Customer Requirement
Testable Testable
Not Testable
System Requirements
FIGURE A.2 Upward propagation—for the Customer Requirement to be
considered testable, all of its system requirements must be testable