System safety program requirements reporting

The MORT tools and techniques can be helpful in preparing a safety analysis report (SAR), the upstream safety product most frequently required for new DOE programs, but the more common system safety products (system safety program plan, preliminary hazard analysis, system/subsystem hazard analysis, operating hazard analysis) are not a dominant part of the MORT program and are seldom even referenced in System Safety Development Center (SSDC) documents. 

It would be useful to check these impressions against the official statistics on occupational risk collected by the Bureau of Labor Statistics (BLS), but these are notoriously unreliable. Indeed, the National Research Council, an offshoot of the National Academy of Sciences that reports on public policy issues, found the BLS data inadequate for monitoring the effectiveness of safety programs (Saddler, 1987). There are several problems. First, the data are collected as part of the Occupational Safety and Health Act (OSHA) reporting system, which subjects them to distorting incentive effects. Firms are required to maintain logs of fatal and nonfatal accidents, but they have an incentive to underreport this information since it could be used as evidence to support workers compensation or tort claims by workers, and because... 

The paradigm shift that The Baker Report helped bring about was an understanding that process safety requires its own management systems and that they do not necessarily correlate closely with traditional personal/occupational safety programs. In its ten key findings, the report uses the term process safety seven times. 

The Rogers Commission was surprised that in the many hours of testimony, NASA s safety staff was never mentioned. They also discovered that there were no safety representatives on the mission management team that made key launch decisions on January 20. The investigators found (Bunn, 1986) four significant failures in the NASA safety program lack of problem reporting requirements, inadequate trend analysis, misrepresentation of criticality, and lack of involvement in critical discussions. The commission also concluded that the safety team was not independent for creating a set of checks and balances in the system. 

Depending on the industry and the complexity of the project, there exists a proliferation of requirements managanent tools that systems engineers may use to allocate requirements and establish traceability. These tools are used to capture source requirements, generate the SRD, and establish requirements traceability matrices (RTMs), which list the traces of requiranents in a top-down and bi-directional path. As the system life cycle matures, inCTeasing effort will be directed toward verification that the demonstrated capability of the systan meets its requirements as expressed in allocated requirements captured in the system specifications. Traceability is achieved when all requirements at a particular level of the system hierarchy have been placed in the Requirements Database, and traced top to bottom as well as in a bi-directional view. Requirements must be traced to the verification program (e.g., plans, procedures, test cases, safety proofs, and reports) to provide closed-loop verification. Traceability should be maintained at aU levels of documentation, as follows ... 

Safety analysis report (SAR) A document prepared to document the results of a hazard analysis performed on a system, subsystem or operation. Hie specific minimum data elements for an SAR will be defined by data deliverable requirements for the program or project (NSTS 22254). 

---