Page 328 -
P. 328

12.1   Risk-driven requirements specification  311



                                             Risk                               Risk
                                          Identification    Risk Analysis   Decomposition     Risk Reduction




                                             Risk              Risk           Root Cause      Dependability
                     Figure 12.1  Risk-    Description      Assessment         Analysis       Requirements
                     driven specification



                                12.1 Risk-driven requirements specification


                                       Dependability and security requirements can be thought of as protection require-
                                       ments. These specify how a system should protect itself from internal faults, stop
                                       system failures causing damage to its environment, stop accidents or attacks from
                                       the system’s environment damaging the system, and facilitate recovery in the
                                       event of failure. To discover these protection requirements, you need to under-
                                       stand the risks to the system and its environment. A risk-driven approach to
                                       requirements specification takes into account the dangerous events that may
                                       occur, the probability that these will actually occur, the probability that damage
                                       will result from such an event, and the extent of the damage caused. Security and
                                       dependability requirements can then be established, based on an analysis of possi-
                                       ble causes of dangerous events.
                                          Risk-driven specification is an approach that has been widely used by safety- and
                                       security-critical systems developers. It focuses on those events that could cause the
                                       most damage or that are likely to occur frequently. Events that have only minor con-
                                       sequences or that are extremely rare may be ignored. In safety-critical systems, the
                                       risks are associated with hazards that can result in accidents; in security-critical sys-
                                       tems, the risks come from insider and outsider attacks on a system that are intended
                                       to exploit possible vulnerabilities.
                                          A general risk-driven specification process (Figure 12.1) involves understanding
                                       the risks faced by the system, discovering their root causes, and generating require-
                                       ments to manage these risks. The stages in this process are:

                                       1.  Risk  identification Potential  risks  to  the  system  are  identified.  These  are
                                           dependent on the environment in which the system is to be used. Risks may
                                           arise from interactions between the system and rare conditions in its operating
                                           environment. The Warsaw accident that I discussed earlier happened when
                                           crosswinds generated during a thunderstorm caused the plane to tilt so that
                                           (unusually) it landed on one wheel rather than two wheels.

                                       2.  Risk analysis and classification Each risk is considered separately. Those that
                                           are potentially serious and not implausible are selected for further analysis.
   323   324   325   326   327   328   329   330   331   332   333