Chapter 9
Specification for critical systems is important. Because of the high potential costs of system failure, it is important to ensure that the specification for critical systems accurately reflects the real needs of users of the system.
System functional requirements may be generated to define error checking and recovery facilities and features that provide protection against system failures. Non-functional requirements may be generated to define the required reliability and availability of the system.
Critical systems specifications’ objective is to understand the risks faced by the system and generate dependability requirements to cope with them. The process of risk analysis consists of four steps:
Risk identification. Potential risks that might arise are identified. These are dependent on the environment in which the system is to be used. In safety-critical systems, the principal risks are hazards that can lead to an accident. Experienced engineers, working with domain experts and professional safety advisors, should identify system risks. Group working techniques such as brainstorming may be used to identify risks.
Risk analysis and classification. The risks are considered separately. Those that are potentially serious and not implausible are selected for further analysis. Risks can be categorised in three ways:
Intolerable. The system must be designed in such a way so that either the risk cannot arise or, if it does arise, it will not result in an accident. Intolerable risks are those that threaten human life or the financial stability of a business and which have a significant probability of occurrence.
As low as reasonably practical (ALARP). The system must be designed so that the probability of an accident arising because of the hazard is minimised, subject to other considerations such as cost and delivery. ALARP risks are those which have less serious consequences or which have a low probability of occurrence.
Acceptable. While the system designers should take all possible steps to reduce the probability of an ‘acceptable’ hazard arising, these should not increase costs, delivery time or other non-functional system attributes.
Risk decomposition. Each risk is analysed individually to discover potential root causes of that risk. Different techniques for risk decomposition exist. The one discussed in the book is Fault-tree analysis, where analyst puts hazard at the top and place different states which can lead to that hazard above. States can be linked with ‘or’ and ‘and’ symbols. Risks that require a combination of root causes are usually less probable than risks that can result from a single root cause.
Risk reduction assessment. Proposals for ways in which the identified risks may be reduced or eliminated are made. Three possible strategies of risk deduction that can be used are:
Risk avoidance. Designing the system in such a way that risk or hazard cannot arise.
Risk detection and removal. Designing the system in such a way that risks are detected and neutralised before they result in an accident.
Damage limitation. Designing the system in such a way that the consequences of an accident are minimised.
In the 1980s and 1990s, as computer control become widespread, the safety engineering community developed standards for safety critical systems specification and development. The process of safety specification and assurance is part of an overall safety life cycle that is defined in an international standard for safety management IEC 61508 (IEC, 1998).
Security and safety requirements have something in common; however, there are some differences between these types of requirements.
The conventional (non-computerised) approach to security analysis is based around the assets to be protected and their value to an organisation. The stages in this process are:
Asset identification and evaluation
Threat analysis and risk assessment
Threat assignment
Technology analysis
Security requirements specification
Reliability is a complex concept that should always be considered at the system rather than the individual component level. Component in the system are interdependent, so a failure in one component can be propagated through the system and affect the operation of other components. Three types of reliability should be taken in consideration – hardware reliability, software reliability and operator reliability.
My thoughts
I think almost every system can be dangerous somehow, it’s a nature of things that if something does something, this something can be done in other, more insecure or unsafe way. Especially, in such a complex structures as software systems. Engineers do their best to develop better, more secure and safe systems, but while increasing the size of system all the problems and risks increase, so all techniques of risk avoidance or reduction are in this infinite race between system size and safety. Previous chapters were all about important thing about functional part of a system, how system should be developed etc. This chapter is also about developing and designing the system, but it shows the importance of other side.
