Page 318 - Software and Systems Requirements Engineering in Practice

280 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

(from our experience), where situation #1 is a positive situation and
situation #2 is a negative situation. The two situations illustrate the
differences between well-organized and poorly organized
requirements necessary to conduct a hazard analysis. In situation #1,
the requirements are well organized, let’s say in three levels:
business requirements, customer requirements, and system
requirements. The traces between the requirements exist and are
correct, and the customer requirements are tied to a preliminary
architecture. We assume a ratio of 1:10 between the customer
requirements and the system requirements (often, the ratio is higher).
This means, ten system requirements exist for each customer
requirement. Let’s assume there are 500 customer requirements. This
would mean we have 5000 system requirements. For a hazard
analysis, we would need to analyze the 500 customer requirements. If
we assume that the analysis of each customer requirement requires
1 person hour, it would require 500 person hours.
In situation #2, we assume poorly organized requirements; e.g.,
requirements are not organized in levels and are listed randomly.
Traces do not exist, and only some requirements are tied to a
preliminary architecture. In this situation, we need to analyze all 5500
requirements because we do not know which of the requirements
belong to which level. Applying the previous assumptions, it might
take 5500 person hours in this case to determine which requirements
need to be analyzed for hazards.
Reflecting Actions into the Requirements Database
Hazard analysis activities are “reflected” in a database whenever
mitigating action is required (see Figure 11.2). In Figure 11.3, an
analysis has resulted in identification of risk, justifying the addition of
new requirements. For example, a train door might close on a passenger,

REQ 1.0
REQ 1.1
Analyze for
REQ 1.2 Possible Hazard Identify Risks
REQ 1.3
REQ 1.4
REQ 1.5 Create
REQ 2.0 Mitigating
REQ 2.1 Requirements
REQ 2.2
MITREQ 2.3
MITREQ 2.4 Create Traces

FIGURE 11.2 Mitigation “reflection” in requirements management