responsibility to the appropriate service organization; and approves the fPRD, final Business Case, and the final ISPD, all of which take safety into account. 

## 2.3.4.1 Safety Requirements 

## 2.3.4.1.1 PSP 

Prior to soliciting contractor proposals, the PSP must once again be updated (if needed) and expanded as it forms the basis of the contractor’s corresponding SSPP (refer to Appendix B for more information about SSPPs). The PSP supports the FID and is completed and approved prior to the JRC Secretariat’s cut-off date for the FID. 

## 2.3.4.1.2 PHA 

The PHA is a common hazard identification and analysis tool used in nearly all SMS applications. Its broad scope allows for the identification of issues that may require more detailed hazard identification tools. The PHA focuses on the details of the solution architecture, including the implications for human reliability. 

The PO conducts the PHA with input from the OSA, CSA, FHA, FA, and/or models such as the Bow-Tie Model. It is important to note that the OSA and CSA may not have been performed if the ATO Chief Safety Engineer waived the requirement to perform those assessments. Although an FA, FHA, and/or Bow-Tie Model is not required, they are all highly recommended as tools that can assist in the hazard identification process and subsequent portions of the analysis. A human reliability analysis or assessment may also be conducted. 

The PO conducts the PHA after the JRC has selected a single alternative as the best option. This means it is conducted after the CSA is approved and before the FID. The SRM document must be completed and approved prior to the JRC Secretariat’s cut-off date for the FID. The PHA also becomes the basis of the monitoring plan that must be followed after system deployment. 

See Appendix E for further information on preparing a PHA. 

## 2.3.4.1.2.1 System Development Assurance 

The final DALs are determined from the PHA and included in the fPRD and PSP. The impact of any changes to the DALs must be described in the final versions of the Business Case and ISPD prior to the FID. 

## 2.3.4.1.3 fPRD 

The fPRD contains all new and existing system safety requirements accepted by the PO. The mitigations identified in the SRM document that are allocated to the program may show up as architectural, functional, design, or performance requirements in the fPRD or as Statement of Work (SOW) tasks with deliverables. These safety items must be uniquely identified and any requirements must be parsed into the SRVT. If all the identified safety requirements in the fPRD are eventually fulfilled and verified, then the program is expected to attain its predicted residual risk. If not, the resultant risk rating may be as high as the initial risk rating determined in the PHA. 

Changes in the NAS environment in which the new capability is targeted to operate may evolve while solution development takes place. Setting baselines of requirements, design, production, and “as-built” configuration makes fulfilment of new safety needs more expensive under this original program segment or capability increment. Future investment segments, increments, 

