Developing Safety-related Requirements

Mike Allocco, PE, (CSP- retired)

Introduction

Depending on system assurance risk or the safety criticality of the design, product, or process safety-related requirements may need to be emphasized and be written, developed, and designed with the consideration of system assurance, system safety, safety engineering and safety management practices in mind. 

In the matter of safety requirements there are many system assurance-related aspects to address in the areas of system or product assurance especially when addressing the human, automation, firmware, software and the environment. All of these elements come into play in “system thinking” consequently many of these aspects are discussed below. Within this treatise these safety-related concepts are highlighted in the context of requirements development and implementation.   

Safety Requirement Context

A requirement is a statement that describes essential, necessary, or a desired attribute, which is a particular operational, physical, or functional need… that a design, product, or process must be able to perform. A safety-related requirement addresses the aspect of mitigation, the hazard/thret/vulnerability, or risk control needs that may be within a design or may equate to an administrative activity or procedure. Safety requirements must be explicit, concise, and succinct. Safety requirements are statements of “what” the mitigation within the system should do rather than how it should be implemented. The actual implementation involves the specific design of the engineered or administrative control. 

Consensus, national, or international standards…

Depending on the entity, there may exist high-level or generic safety-related consensus, national, or international standards that are applicable to a particular design, product, or process. Such requirements may have to be incorporated; keeping in mind that there may be limitations and applicability considerations involving the consensus or the generic nature of the requirement. It is suggested that an existing safety requirement be evaluated to assure suitability for the particular mitigation need and consequently revised if necessary. Generally, meeting these generic standards provide a minimal level of protection. More specific derived safety requirements become further applicable and should raise the level of protection.

Derived requirements…

Derived requirements are the output of various safety and design analyses, inspections, surveys, or observations, or tests. Consider that the hazards/threat/vulnerabilities[1] associated with the risks are eliminated, or controlled to acceptable levels via various forms of mitigation… hazard or risk controls; which are safety requirements. 

Within this safety perspective these requirements must be validated; in that the mitigation is proven to be effective against the particular hazard. Further, such mitigations must be verified; in that the mitigation has been successfully incorporated into the system. There may be the need for continuous validation and verification via formal manual or automatic monitoring.

Consider that there may be other derived safety requirements that become apparent as a result of inputs from end users, from customers, and other designers or developers. It is helpful to consider a particular hazard, risk, or mitigation from many points of view and thinking out of the box may provide a new perspective. 

Depending on the participant, requirements may be written from many points of view: System requirements may be detailed describing functions the system needs to do. User requirements may be written from the user point of view, in narrative form…the user must be able to… Designers or developers may have requirements that equate to system performance, system assurance, and other engineering or technical concepts.

Life cycle considerations…

In addressing and developing safety requirements there are further understandings involving the design, product, or process life cycle; in that safety requirements may need to be dynamic and time related to track along a life cycle or be effective within a particular time phase. There is also applicability involving the system accident life cycle. Mitigations may include early automatic detection, isolation, and automatic correction of the system prior to harm. 

Further, mitigation comes into play throughout the accident life cycle; abnormal energy release may be controlled; there may be mitigations involving casualty, contingency, and recovery, in order to stabilize the system. In some dynamic situations real-time controls may be revised, changed, or enhanced to eliminate or decrease system risks. 

System requirements…

In the consideration of system level requirements there are complex interrelationships to consider. A system requirement may have to meet many needs to enable integration. In this context think in terms of integrated system requirements, which may satisfy many system objectives. This is why various system engineering disciplines must work together to develop an appropriate inclusive system specification. Most system assurance requirements are directly related to risk mitigation; hence not meeting these requirements may introduce uncontrolled safety-related risks. Needless to say system requirement integration must involve:  reliability, availability, maintainability, quality, logistics, human factors, security, survivability, software assurance, and system safety. 

Avoiding disjointed requirements…

An appropriately designed safety requirement should be easily validated and verified. Safety requirements should be detailed to enable development of an engineering control, which may be a specific design or a safety system, safety device, automatic failure detection, isolation and correction capability. There are further needs involving associated administrative controls, which may include: safety operating procedures, manual inspection, testing, or monitoring procedures, the use of protective equipment, exposure limitations, training needs, and conducting real-time safety review or safety or other supportive analyses.

Safety maxims associated with requirements… 

Without an understanding of system safety mistakes can be made when safety requirements are inappropriately written or designed; consider the following:

·      Design the requirement to mitigate a specific identified hazard;

·      State what has to be accomplished to enable mitigation;

·      Use straightforward language and try to keep it simple;

·      The requirement must reflect a specific safety-related need;

·      Design high-level system requirements to enable connectivity or integration with other related system requirements;

·      Higher-level requirements should be design to be decomposed into lower-level detailed requirements for traceability deductively from “grandparent, parent, down to child”;

·      Design the requirement to be validated and verified via test, analysis, or other formal means;

·      Quantify requirements when appropriate;

·      Use conventional naming, terms, and language;

·      Use proven formal methods within digital, firmware and software design;

·      Conduct requirements analysis and review;

·      Conduct appropriate hazard analysis and risk assessment of developed requirements;

·      Enable good communication between designers, developers, customers or end users;

·      Design requirements to accommodate the system and accident life cycle;

·      Design requirements with the consideration of foreseeable dynamic changes to minimize the risk related requirements creep;

·      Consider the integrated system and intended use and misuse;

·      Independence as to the scope or objective of the requirement should be maintained to eliminate requirements overlap or requirements redundancy;

·      Understand the interaction and interfaces between requirements to assure integration;  

·      Apply logical probabilities, thresholds, boundary’s, to accommodate for random variation and probability distribution;

·      Conduct hazard control analysis;

·      Identify adverse progressions and provide multiple controls to abate or otherwise control or decrease risk;

·      Understand hazard control attributes consistent with safety axioms;

·      Use the following criteria in the development of mitigations:

o   Design for minimal risk

o   Incorporate safety devices

o   Provide safety alerts

o   Develop standard procedures

o   Provide training

Prioritizing Safety Requirements…

Within new or modified designs consider that the requirements are developed as the program progresses. Requirements development is an iterative and interactive process. Classic system safety (system assurance) efforts should start early within the life cycle. Initial safety-related and risk management judgment is applied to assure that systems are designed with minimal risk. Early safety efforts involve developing a preliminary hazard list which is further refined into a preliminary hazard analysis and risk assessment, (other similar safety analysis methods are applied within related safety practices). The system safety engineer should work with the designers to assure a minimal risk design. In this situation almost real-time safety requirements are developed and communicated. Consequently and ideally the designers can make appropriate decisions up front to minimize risk or provide other means such as substitution to eliminate hazards very early in the concept through design phases. Such early activities should develop safety requirements that are risk-based, consequently fixing higher risks first; providing a priority which is based upon safety-related risk.

Safety specification development…

Preferably a safety specification should be developed early to track along with the design. The safety specification should be updated as the design becomes mature. There is an iterative set of safety-related activities that include appropriate hazard analysis, risk assessment, and safety review that directly tracks with the design. The classic preliminary hazard analysis and risk assessment matures into subsystem or system hazard analysis. Eventually, all safety-related risk should be identified, eliminated or controlled to acceptable levels. Consider all the risk or hazard controls are refined into safety requirements that are included within a safety specification. In some situations this safety specification will be the system safety section with the more inclusive system specification.

Further integration is conducted to enable the accommodation of all system assurance requirements that will directly be in concert with system safety activities. These efforts require concurrent reviews with system engineering to assure integration both horizontally and vertically.  Various forms of requirements analyses are conducted to enable this inclusive integration: requirements cross-check analysis, requirements traceability analysis, requirements walkthroughs, requirements-design verification, various forms of testing, quality reviews, design reviews and simulations.

The system specification should also include additional supportive details such as an overview of the system, system of systems, or families of systems; various depictions, models, diagrams, schematics, Etc. 

Additional safety-related integration is required associated with the other important design documentation, which should include software specification, interface control specifications, functional and operational descriptions, design review results, engineering note books, test reports, and supportive administrative controls. Various abstractions which define the system operations, concepts, signal flows, functions, automated logic, modes, actions or hardware and human involvement all are important aspects that may be included within the system specification.  

[1] This discussion includes the concept of a system risk in that many hazards, security threats or vulnerabilities will have an effect on system safety; in that everything is connected within the system under evaluation.