Risk Driven Specification & Identification
Critical systems specification supplements the normal requirements specification process by focusing on the dependability of the system. Its objective is to understand the risks faced by the system and generate dependability requirements to cope with them. The risk-driven specification has been widely used by safety and security-critical systems developers. In safety-critical systems, the risks are hazards that can result in accidents; in security-critical systems, the risks are vulnerabilities that can lead to a successful attack on a system. Because of the increasing importance of security.
The risk-driven specification process involves understanding the risks faced by the system, discovering their root causes, and generating requirements to manage these risks.
Risk identification Potential risks that might arise are identified. These are dependent on the environment in which the system is to be used.
- Risk analysis and classification The risks are considered separately. Those that are potentially serious and not implausible are selected for further analysis. Algorithm this stage, some risks may be eliminated simply because they are very unlikely ever to arise (e.g., simultaneous lightning strike and earthquake).
- Risk decomposition Each risk is analyzed individually to discover potential root causes of that risk. Techniques such as fault-tree analysis (discussed later in this chapter) may be used.
- Risk reduction assessment Proposals for ways in which the identified risks may be reduced or eliminated are made. These then generate system dependability requirements that define the defenses against the risk and how the risk will be managed if it arises.
For large systems, risk analysis may be structured into phases. Multiphase risk analysis is necessary for large systems such as chemical plants or aircraft. The phase of risk analysis include:
- Preliminary risk analysis where major risks are identified
- More detailed system and sub-system risk analysis
- Software risk analysis where the risks of software failure are considered
- Operational risk analysis is concerned with the system user interface and risks that arise from operator errors.
The objective of risk identification, the first stage of the risk analysis process, is to identify the risks that the critical system must cope with. This can be a complex and difficult process because risks often arise from interactions between the system and rare environmental conditions. The Warsaw accident that I discussed earlier happened when crosswinds generated during a thunderstorm caused the plane to tilt so that it landed on one rather than two wheels.
In safety-critical systems, the principal risks are hazards that can lead to an accident. You can tackle the hazard-identification problem by considering different classes of hazards, such as physical hazards, electrical hazards, biological hazards, radiation hazards, service failure hazards, and son. Each of these classes can then be analyzed to discover associated hazards. Possible combinations of hazards must also be identified.Like many medical devices, this is a safety-critical system. Some of the hazards or risks. that might arise in this system are:
- Insulin overdose (service failure)
- Insulin underdose (service failure)
- Power failure due to the exhausted battery (electrical)
- Electrical interference with other medical equipment such as a heart pacemaker (electrical)