responsibility to the appropriate service organization; and approves the fPRD, final Business  Case, and the final ISPD, all of which take safety into account. 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.  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.  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. 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,  2_SRMGSA_202003  Originally published March 2020  Uncontrolled copy when downloaded  15 2.3.4.1.2.1 System Development Assurance  2.3.4.1.3  fPRD  2.3.4.1.2  PHA  2.3.4.1.1  PSP  2.3.4.1  Safety Requirements 