Safety Requirements/ Criteria Analysis
The safety requirement/criteria analysis (SRCA) is an analysis for evaluating system
safety requirements (SSRs). As the name implies, SRCA evaluates SSRs and the criteria behind them. SRCA has a twofold purpose: (1) to ensure that every identi?ed hazard has at least one corresponding safety requirement and (2) to verify that all safety requirements are implemented and are validated successfully. The SRCA is essentially a traceability analysis to ensure that there are no holes or gaps in the safety requirements and that all identi?ed hazards have adequate and proven design mitigation coverage. The SRCA applies to hardware, software, ?rmware, and test requirements. The SRCA also applies to the traceability of design criteria and guidelines to SSRs, such as those speci?ed in the DoD Joint Software System Safety Handbook (DoDJSSSH)  and Electronic Industries Association SEB6-A for software , and MIL-STD-1316 for fuze systems . Guideline traceability ensures that the appropriate safety guidelines and criteria are incorporated into the SSRs.
This analysis technique falls under the requirements design hazard analysis type (RD-HAT). The basic analysis types are described in Chapter 3. Alternate names
Hazard Analysis Techniques for System Safety, by Clifton A. Ericson, II Copyright # 2005 John Wiley & Sons, Inc.
SAFETY REQUIREMENTS/CRITERIA ANALYSIS
for this technique are requirements hazard analysis (RHA) and requirements traceability analysis. The purpose of the SRCA is to ensure that all identi?ed hazards have corresponding design safety requirements to eliminate or mitigate the hazard and that the safety requirements are veri?ed and validated as being successful in the system design and operation. The intent is to ensure that the system design requirements have no “safety” gaps (i.e., no hazard has been left unmitigated) and to verify that all safety requirements are adequately implemented or created as necessary. The SRCA is applicable to analysis of all types of systems, facilities, and software where hazards and safety requirements are involved during development. SRCA is particularly useful when used in a software safety program. The SRCA technique, when applied to a given system by experienced safety personnel, is very thorough in providing an accurate traceability of safety design requirement veri?cation and safety test requirement validation. A basic understanding of system safety and the design requirement process is essential. Experience with the particular type of system is helpful. The technique is uncomplicated and easily learned. Standard easily followed SRCA worksheets and instructions are provided in this chapter. The SRCA is very useful for ensuring that design safety requirements exist for all hazards and that the safety requirements are in the design and test speci?cations. SRCA provides assurance that safety requirements exist for all identi?ed hazards and ensures that all safety requirements are incorporated into the design and test speci?cations. The application of the SRCA to software development has proven to be very effective for successfully evaluating software to ensure compliance with safety requirements.
The SRCA technique was established very early in the history of the system safety discipline. It was formally instituted and promulgated by the developers of MIL-STD-882.
As previously stated, the purpose of the SRCA is to ensure that safety requirements exist for all identi?ed hazards, that all safety requirements are incorporated into the design and test speci?cations and that all safety requirements are successfully tested. Figure 10.1 shows an overview of the basic SRCA process and summarizes the important relationships involved in the SRCA process. This process consists of comparing the SSRs to design requirements and identi?ed hazards. In this way any missing safety requirements will be identi?ed. In addition, SSRs are traced into the test requirements to ensure that all SSRs are tested.
SRCA Process Input
? ? ? ? ? Hazards SSRs Design requirements Test requirements Guidelines
1. Correlate every hazard to an SSR. 2. Correlate every SSR to a design and test requirement. 3. Correlate guideline requirements to SSRs. 4. Document process.
? Correlation matrix - Design Req’ts - Test Req’ts - Safety Req’ts ? Guideline Req’ts Matrix
Figure 10.1 SRCA overview.
Figure 10.2 shows an overview of the SRCA thought process for the SRCA technique. The idea behind this thought process is that a matrix worksheet is used to correlate safety requirements, with design requirements, test requirements, and identi?ed hazards. If a hazard does not have a corresponding safety requirement, then there is an obvious gap in the safety requirements. If a safety requirement is not included in the design requirements, then there is a gap in the design requirements. If a safety requirement is missing from the test requirements, then that requirement cannot be veri?ed and validated. If an SSR cannot be shown to have passed testing, then the associated hazard cannot be closed.
Test Requirements Software Requirements Design Requirements
Safety Guidelines SSRs Hazards
Figure 10.2 SRCA methodology.
? ? ? ? ?
Hazards SSRs Test Requirements Test Results Guidelines
SAFETY REQUIREMENTS/CRITERIA ANALYSIS
TABLE 10.1 SRCA Process Step 1 2 3 4 5 6 7 Task Acquire requirements. Acquire safety data. Acquire safety guidelines. Establish an SSR traceability matrix. Establish guideline traceability matrix. Identify requirement gaps. Recommend corrective action. Track hazards. Document SRCA. Description Acquire all of the design (hardware and software) and test requirements for the system. Acquire all of the hazards and SSRs for the system. Acquire all safety guidelines that are applicable to the system. Correlate SSRs with hazards, design requirements, and test requirements. Correlate safety guidelines and criteria with SSRs. Identify hazards that have no corresponding safety requirement. Determine if the design controls present are adequate and, if not, recommend controls that should be added to reduce the mishap risk. Transfer identi?ed hazards into the hazard tracking system (HTS). Document the entire SRCA process on the worksheets. Update for new information as necessary.
The SRCA is a detailed correlation analysis, utilizing structure and rigor to provide traceability for all SSRs. The SRCA begins by acquiring the system hazards, SSRs, design requirements, and test requirements. A traceability matrix is then constructed that correlates the hazards, SSRs, design requirements, and test requirements together. The completed traceability matrix ensures that every hazard has a corresponding safety requirement and that every safety requirement has a corresponding design and test requirement. The SRCA consists of two separate correlation traceability analyses: (1) an SSRs correlation and (2) a guideline compliance correlation. The guideline correlation only applies to systems where guidelines exist and are applied to the system design. For example, the safety guideline requirements from the DoDJSSSH are generally applied to the design of software, and the guideline requirements from MIL-STD1316 are applied to fuze system designs. Table 10.1 lists and describes the basic steps of the SRCA process.
The SRCA is a detailed hazard analysis utilizing structure and rigor. It is desirable to perform the SRCA using specialized worksheets. Although the format of the analysis worksheet is not critical, typically, matrix or columnar-type worksheets are used to help maintain focus and structure in the analysis. Software packages are available to aid the analyst in preparing these worksheets.
The purposes of the SRCA are to establish traceability of SSRs and to assist in the closure of mitigated hazards. As a minimum, the following basic information is required from the SRCA: 1. Traceability matrix of all identi?ed hazards to corresponding SSRs 2. Traceability matrix of all safety design requirements to test requirements and test results 3. Identi?cation of new safety design requirements and tests necessary to cover gaps discovered by items 1 and 2 above 4. Traceability matrix of all safety guidelines and criteria to SSRs 5. Data from items 1, 2, 3, and 4 above supporting closure of hazards The speci?c worksheet to be used may be determined by the managing authority, the safety working group, the safety team, or the safety analyst performing the analysis. Figures 10.3 contains an example SRCA requirements correlation worksheet for the traceability of SSRs. The information required under each column of the requirements correlation matrix worksheet is described below: 1. System This column identi?es the system under analysis. 2. Subsystem This column identi?es the subsystem under analysis. 3. System Safety Requirement (SSR) Number This column identi?es the SSR number. 4. SSR This column states the actual verbiage of the SSR. 5. Safety Critical (SC) Place a Yes in this column to indicate that the SSR is an SC requirement.
1 System: Subsystem:
SSR Traceability Matrix HAR No. TLM No. Design Req. No.
SRCA Test Req. No. Test M C R
SSR No. System Safety Requirement (SSR) SC
Figure 10.3 SRCA requirements correlation matrix worksheet.
SAFETY REQUIREMENTS/CRITERIA ANALYSIS
6. Hazard Action Record (HAR) Number This column identi?es the HAR or HARs associated with the SSR. The SSR may be providing mitigation for one or more hazards. 7. Top-Level Mishap (TLM) Number This column identi?es the TLM associated with the SSR. 8. Design Requirement Number This column identi?es the speci?c design requirement that implements the SSR. 9. Test Requirement Number This column identi?es the speci?c test requirement or requirements that test the SSR. 10. Test This column provides information regarding testing of the SSR. Three different types of information are provided: a. M This column identi?es the test method used: test (T), analysis (A), inspection (I), and not (N) done. b. C This column identi?es the test coverage: explicitly (E) tested by a speci?c test or implicitly (I) tested through another test. c. R This column identi?es the test results: pass (P) or fail (F). Figure 10.4 contains the recommended SRCA correlation worksheet for the traceability of SSR compliance with safety guideline and criteria. The information required under each column of the guideline correlation matrix worksheet is described below: 1. System This column identi?es the system under analysis. 2. Subsystem This column identi?es the subsystem under analysis. 3. Guideline Number This column identi?es the requirement number from the guideline or criteria document.
System: 1 Subsystem: Guideline Number
Guideline Compliance Matrix Guideline Requirement SSR Number
Implement F P N
Figure 10.4 Guideline correlation matrix worksheet.
10.8 ADVANTAGES AND DISADVANTAGES
4. Guideline Requirement This column contains the actual text of the guideline requirement. 5. SSR Number This column identi?es the speci?c SSR that implements the design guideline requirement. 6. Comments This column provides for any necessary discussion associated with the guideline requirement. For example, if the guideline is only partially implemented or not implemented at all, suf?cient rationale and justi?cation must be provided. 7. Implement This column provides information regarding implementation of the design guideline. Check the particular column that is applicable: a. Full (F) implementation by the SSR b. Partial (P) implementation by the SSR c. Not (N) implemented (not applicable or not possible)
This example involves a fuze subsystem for a missile weapon system, which includes both hardware and software. In these examples, not all of the SSRs or design requirements are included, only a small example portion of the overall requirements to demonstrate the technique. Note from this example that more than one safety requirement may exist for a particular hazard. Also, note that the hazard action record (HAR) number is provided for each hazard. The identi?ed design requirement is derived from the program design speci?cation document, and the test requirement is derived from the program test requirements document. Table 10.2 provides an SRCA requirements traceability matrix for this example system. Note that only a single page is shown for this example. A typical SRCA would consist of many pages. Table 10.3 provides a compliance matrix for the DoDJSSSH software guidelines . A software SRCA correlation compliance would include the review of each of these guidelines, determine if it were applicable to the system design, provide rationale for those not applicable, and provide the corresponding safety requirement reference in the speci?cation for those found to be applicable. Table 10.4 provides a MIL-STD-1316 (Series) compliance matrix for this example system. Table 10.5 provides a MIL-HDBK-454 (Series) compliance matrix for this example system. 10.8 ADVANTAGES AND DISADVANTAGES
The following are advantages of the SRCA technique: 1. SRCA is easily and quickly performed. 2. SRCA correlates SSRs to hazards and design requirements and speci?cations.
SSR Traceability Matrix Safety Requirements/Criteria Analysis Test T/A/I/N T E/I E P/F P HAR Number TLM Number Design Req’t Number Test Req’t Number TS 4.7.21 SS 7.7.21 1 21 81, 95 1 SS 7.7.22 TS 4.7.22 T E P Page:
TABLE 10.2 SRCA Requirements Traceability Matrix Example
System: Lark Missile
Subsystem: Fire Control System
System Safety Requirement (SSR)
No single point failure can result in missile launch. Three separate and independent means are required for missile arming.
SSR 33 SSR 34
TABLE 10.3 DoDJSSSH Compliance Matrix Example Safety Requirements/Criteria Analysis Compliance Comments F X P N
DoDJSSSH Software Compliance Matrix
DoDJSSSH Number SSR 71
Primary computer failure. The system shall be designed such that a failure of the primary control computer will be detected and the system returned to a safe state. CPU selection. CPUs, microprocessors, and computers that can be fully represented mathematically are preferred to those that cannot.
Not possible for program to obtain a CPU meeting this requirement. Intel Pentium II has been selected and approved. This requirement is too stringent for program. SSR 72 X
E.9.4 SSR 73
SSR 74 SSR 75
Operational checks. Operational checks of testable safety critical system elements shall be made immediately prior to performance of a related safety critical operation. Safety critical displays. Safety critical operator displays, legends, and other interface functions shall be clear, concise, and unambiguous and, where possible, be duplicated using separate display devices. Modular code. Software design and code shall be modular. Modules shall have one entry and one exit point. Variable declaration. Variables or constants used by a safety critical function will be declared/initialized at the lowest possible level. Unused executable code. Operational program loads shall not contain unused executable code. SSR 76
TABLE 10.4 MIL-STD-1316E Compliance Matrix Example Safety Requirements/Criteria Analysis Compliance Comments F P X N
SSR Number SSR 47 SSR 48 SSR 49 Veri?ed by FTA X X Page:
MIL-STD-1316E Compliance Matrix
Arming delay. A safety feature of the fuze shall provide arming delay, which assures that a safe separation distance can be achieved for all de?ned operational conditions. Manual arming. An assembled fuze shall not be capable of being armed manually. Safety system failure rate. The fuze safety system failure rate shall be calculated for all logistical and tactical phases from manufacture to safe separation. The safety system failure rate shall be veri?ed to the extent practical by test and analysis during fuze evaluation and shall not exceed the rates given for the following phases: Prior to intentional initiation of the arming sequence: 1 ? 1026 to prevent arming or functioning. Prior to the exit (for tubed launch munitions): 1 ? 1024 to prevent arming 1 ? 1026 to prevent functioning Between initiation of arming sequence and safe separation: 1 ? 1023 to prevent arming ALARPa with established risk to prevent functioning
ALARP, as low as reasonably practical.
TABLE 10.5 MIL-HDBK-454 Compliance Matrix Example Safety Requirements/Criteria Analysis Compliance Comments F X P N
Subsystem: SSR Number SSR 101
MIL-HDBK-454 Compliance Matrix
4.2 SSR 102 SSR 103
4.3b SSR 104
The equipment shall provide fail-safe features for safety of personnel during installation, operation, maintenance, and repair or interchanging of a complete assembly or component parts. Electric equipment shall be bonded in accordance with MIL-B-5087, Class R/L/H. At an ambient temperature of 258C, the operating temperature of control panels and operating controls shall not exceed 498C (1208F). At an ambient temperature of 258C (778F), exposed parts subject to contact by personnel (other than control panels and operating controls) shall not exceed 608C (1408F). X Page:
Source: MIL-HDBK-454M, general guidelines for Electrical Equipment, guideline 1—Safety Design Criteria for Personnel Hazards.
SAFETY REQUIREMENTS/CRITERIA ANALYSIS
3. SRCA veri?es and validates SSRs through correlation of test results. 4. Software packages are available to aid the analyst in preparing SRCA worksheets. There are no major disadvantages of the SRCA technique.
COMMON MISTAKES TO AVOID
When ?rst learning how to perform an SRCA, it is commonplace to commit some typical errors. The following is a list of common errors made during the conduct of an SRCA: 1. Failing to put all safety guidelines and requirements into SSRs 2. Failing to perform a traceability compliance analysis on all safety guidelines and requirements SSRs
This chapter discussed the SRCA technique. The following are basic principles that help summarize the discussion in this chapter: 1. The primary purpose of the SRCA is to assess the SSRs and: . Identify hazards without associated SSRs (gaps in the design SSRs).
Identify requirements that are not in the system design requirements. Identify requirements that are not tested and validated for effectiveness.
3. 4. 5.
Identify safety guidelines and requirements that are not implemented in the SSRs. The SRCA relates the identi?ed hazards to the design SSRs to ensure that all identi?ed hazards have a least one safety requirement, whose implementation will mitigate the hazard. The SRCA relates the design SSRs to the test requirements to ensure all safety requirements are veri?ed and validated by test. The SRCA is also used to incorporate safety guidelines and requirements that are speci?cally safety related but not tied to a speci?c hazard. The SRCA process ensures that the design safety requirements are properly developed and translated into the system hardware and software requirement documents. The use of the recommended SRCA worksheets simpli?es the process and provides documentation of the analysis.
1. DoD, DoD Joint Software System Safety Handbook (DoDJSSSH), Appendix E—Generic Requirements and Guidelines, 1999. 2. Electronic Industries Association, EIA SEB6-A, System Safety Engineering in Software Development, Appendix A—Software System Safety Checklist, Electronic Industries Association, 1990. 3. MIL-STD-1316 (Series), Safety Criteria for Fuze Design—DoD Design Criteria Standard. 4. MIL-HDBK-454M (Series), General Guidelines for Electronic Equipment, Guideline 1— Safety Design Criteria for Personnel Hazards.