SD 413.3-4, Program Requirements Document

CONTROLLED DOCUMENT OFFICE OF PRIMARY INTEREST (OPI): AVAILABLE ONLINE AT: Office of Enterprise Project Management http://directives.nnsa.doe.gov printed copies are uncontrolled SUPPLEMENTAL DIRECTIVE Approved: 09-15-21 Certification Due: 09-15-24 PROGRAM REQUIREMENTS DOCUMENT NATIONAL NUCLEAR SECURITY ADMINISTRATION Office of Acquisition and Project Management NNSA SD 413.3-4 http://directives.nnsa.doe.gov/ THIS PAGE INTENTIONALLY LEFT BLANK NNSA SD 413.3-4 1 09-15-21 PROGRAM REQUIREMENTS DOCUMENT 1. PURPOSE. To establish a National Nuclear Security Administration (NNSA) supplemental directive (SD) for developing and maintaining a Program Requirements Document (PRD) to fulfill mission needs for programs being executed by the NNSA. 2. AUTHORITY. DOE Order (O) 413.3B, Program and Project Management for the Acquisition of Capital Assets, table 2.0. 3. CANCELLATION. NNSA Business Operating Procedure (BOP) 413.2, Program Requirements Document for Construction Projects, dated 3-20-14. 4. APPLICABILITY. a. Federal. (1) Pertains to all Acquisitions within the meaning of DOE O 413.3B by NNSA or managed by NNSA personnel on behalf of other government agencies with an estimated top end of the Rough Order of Magnitude (ROM) cost range equivalent to the threshold in DOE O 413.3B. (2) Applies to one-of-a-kind, high hazard, nuclear, or special criteria projects between the DOE O 413.3B applicability and the minor construction threshold that would benefit from a PRD. Not applicable to commercial type projects (e.g., office buildings, fire stations, roads, etc.). b. Contractors. This SD does not apply to contractors. c. Equivalencies/Exemptions. (1) Equivalency. In accordance with the responsibilities and authorities assigned by Executive Order 12344, codified at 50 United States Code (U.S.C.) sections 2406 and 2511, and to ensure consistency throughout the joint Navy/DOE Naval Nuclear Propulsion Program, the Deputy Administrator for Naval Reactors (Director) will implement and oversee requirements and practices pertaining to this Directive for activities under the Director’s cognizance, as deemed appropriate. (2) Exemption. None. 5. BACKGROUND. The PRD establishes the mission and program level requirements that apply to the development and execution of the Acquisition. It translates the need in the Mission Need Statement (MNS) into top-level requirements addressing components such as performance, supportability, physical and functional integration, human integration, security, test and evaluation, implementation and transition, quality assurance, and configuration management. 2 NNSA SD 413.3-4 09-15-21 Experience has shown that a formal process resulting in an agreed-upon definition of requirements for new systems, new capabilities, updates, or enhancements to systems is a prerequisite to proceeding to system/capability design. Failure to create a PRD can result in rework and unnecessary costs and delays in schedule. The intent is to establish a framework for the development of PRDs for Acquisitions which defines the requirements associated with project scope, assumptions, and constraints in more detail than the MNS. 6. REQUIREMENTS. a. The PRD must contain the set of program requirements sufficient to close the gap identified in the MNS. Program requirements identified in the PRD prior to Critical Decision (CD)-2 are equivalent to preliminary key performance parameters (KPPs) as described in DOE G 413.3-5A, U.S. Department of Energy Performance Baseline Guide.

b. The PRD must provide the bridge between the MNS, and the more detailed lower- level requirements contained in description documents (e.g., Facility Design Document, System Requirements Document, System Design Description, and General Design Criteria). c. At a minimum, the PRD must include an approval signature block for the Head of the funding NNSA Element and a submitted by signature block for the Program Manager (PM) of the funding NNSA Element. d. The approved PRD must be completed as part of the CD-0 documentation package. After CD-0 approval, the PRD must be placed under configuration management and maintained during the life of the Acquisition. e. The PRD must be reviewed and updated if the requirements should change (e.g., following the Analysis of Alternatives). f. The PRD must be written using the format provided in Appendix A, PRD Format and Content. g. Subsequent project documentation (e.g., Critical Decision Packages, design documents to include Facility Design Document, System Requirements Document, and others) must align with the requirements of the PRD. (1) This documentation must be reviewed against the PRD to ensure alignment and consistency of requirements throughout the design phase. Reviews can be performed in conjunction with design reviews or independent reviews or annual project reviews. (2) If documentation does not align to the PRD, resolution is required. h. The PRD must be independent of a particular solution. NNSA SD 413.3-4 09-15-21 7. RESPONSIBILITIES. a. Office of Acquisition and Project Management (NA-APM). (1) Maintains the PRD SD. 3 (2) Assists the Program Office in preliminary planning activities in support of the PRD. b. Program Manager. (1) Develops, maintains, and signs the original or revised PRD to include updating the PRD if requirements change as the Acquisition progresses to ensure goals and objectives are met. (2) Ensures a procedure is established for configuration management of the PRD. c. Heads ofNNSA Elements. d. e. (1) Approves and signs the original PRD and any revisions to the PRD. (2) Determines projects that would benefit from a PRD between the minor construction threshold and DOE O 413.3B applicability. Headquarters Project Manager. Provides advice and assistance to the PM in suppo1i of PRD development. Federal Project Director. Ensures that Acquisition documents throughout design are aligned with the requirements in the PRD and suppmis program office revisions of the PRD. 8. DEFINITIONS. See DOE O 413.3B. 9. ACRONYMS. See Appendix B. 10. REFERENCES. See Appendix C. 11. CONTACT. Acquisition and Project Management, NA-APM-1, 202-586-5627. BY ORDER OF THE ADMINISTRATOR: Jill Hruby Administrator 4 NNSA SD 413.3-4 09-15-21 Appendixes: A. PRD Format and Content. B. Acronyms. C. References. THIS PAGE INTENTIONALLY LEFT BLANK NNSA SD 413.3-4 Appendix A 09-15-21 APA-1 APPENDIX A: PROGRAM REQUIREMENTS DOCUMENT (PRD) FORMAT AND CONTENT 1. PROCESS. The PRD format and required content are as follows: a. Title Page. Identifies the specific project(s), date, revision number, classification, and the origin of the document. b. Concurrence/Approval Page. Provides signature and dating space for the federal officials including (at a minimum) the Deputy Administrator/Associate Administrator and the Program Manager (PM). c. Configuration Control Log. Provides a short discussion of approved changes made to the PRD. Lists references to applicable documentation that provide justification for the changes.

d. Table of Contents. Lists the contents of the PRD and the location of major topics. e. Main Body of the PRD: (1) Introduction and Purpose. Provides a discussion of the purpose of the PRD where the intent is to document more detail than the MNS that can be used to define the program requirements for the Acquisition scope, assumptions, and constraints. Assigns lead responsibility to the federal PM to develop and maintain the PRD under change control. (2) Background (Optional). Provides relevant background of the program or capability gap to improve the reader’s understanding. (3) Relationship to Mission Need. The MNS should be referenced, and a short synopsis provided. This discussion should include a brief summary describing how the Acquisition, as implemented pursuant to the PRD, will meet the need identified in the MNS. (4) Requirements Development. Provides a summary discussion of how the requirements were identified or derived. Explanations of processes, documentation, direction, or guidance that govern the derivation or development of the requirements should be included. Incorporating information by reference is an acceptable method for providing the development history, where available. The basis for the requirements, where not obvious, should be traceable to decisions or source documentation. If desired details relating to the traceability of requirements may be included in an attachment to the PRD. (5) Program Assumptions, Constraints, and Key Interfaces. Documents the critical assumptions, constraints, and interfaces that are germane to the Acquisition (not to be confused with contract method or vehicle.) If the Appendix A NNSA SD 413.3-4 APA-2 09-15-21 Acquisition is dependent on, or provides input to, other programs or decisions the dependencies should be stated, and their relevance and impact explained. Incorporation of information by reference is acceptable. (a) Assumptions. An assumption is a presumed outcome, value, or condition whose actual outcome value or condition cannot be known or controlled by the project. The assumptions need not include assumptions that are generic inherencies, such as “Congress will provide adequate funding,” or “The project will conform to applicable rules and regulations,” because these assumptions prevail whether specified or not. Typical valid assumptions include expected outcomes of uncertain future events that will impact the project such as “The preferred alternative in the Draft EIS is selected by the Secretary,” or “The research and development activities for the project will resolve the technical uncertainties for the project’s specialty equipment by FY XX.” (b) Constraints. A constraint is an external demand or proscription that limits degrees of freedom to the project on how the project team might choose to execute the project. As above, generic inherencies need not be stated. Constraints might be physical or administrative (e.g., “The project shall be limited to deploying proven technologies.”) (c) Key Interfaces. The interfaces of the project to other projects and to programs that could impact upon execution of the project should be identified. (6) Requirements. A requirement is something that the system must meet in order to successfully close the performance gap identified in the MNS. (a) Requirements must be clear stand-alone statements (e.g., free of conjunctions like “and”) that are clearly differentiated as requirements.

(b) A requirement must be articulated with sufficient specificity that one can make a clear determination whether the requirement is satisfied or not. (c) There must be at least one requirement, but there is no maximum number. (d) Requirements are designated by “must” in conforming to SD 251.1B, Directives Management. (e) Context or background provides clarification, traceability, or understanding of why a requirement exists. Incorporating this information by reference to other documents is acceptable. NNSA SD 413.3-4 Appendix A 09-15-21 APA-3 (f) Program Requirements. The program requirements must be the first section of the requirements. Collectively the program requirements should be a comprehensive set of WHAT the project must provide to close the gap identified in the MNS. 1 Program requirements must include the foundational requirements which would include answers to the following kinds of questions: a What functions and capabilities must be provided to meet the mission need? b What size or capacity is required? c What interfaces must the project satisfy that are imposed by the program? d Are any requirements unique to meeting the mission need? 2 Program requirements include the management requirements which, in addition to budget limitations and schedule demands, describe criteria that must be met during Acquisition definition and execution by the project as set by the program that go beyond requirements that are already set by law, contract, or directive. The scope of possible program requirements includes physical integration, human integration, safety, security, health, and quality assurance as examples. a Examples of valid program requirements: • The HEUMF must provide storage for a minimum of 28,000 canned assembly storage racks. • CMRR shall integrate with PF-4 such that the pair of facilities, along with the supporting infrastructure at or near TA-55, must operate as a system to meet nuclear mission assigned to LANL. b Examples of requirements that are not program requirements: • The project shall conform to DOE Order 413.3B. (Whereas this is a valid requirement, it is not a program Appendix A NNSA SD 413.3-4 APA-4 09-15-21 requirement. The requirement informs how one executes the project, not what need the project serves.) • Safety is the number one priority for the project. (Whereas this demand may be valid for the project, it is an expression of HOW the project should be executed, not what it does.) • Project systems and equipment should be functionally independent to enhance system reliability. (This is a design criterion not a program requirement.) 3 Program requirements identified in the PRD prior to Critical Decision (CD)-2 are equivalent to preliminary key performance parameters (KPPs) as described in DOE G 413.3-5A, U.S. Department of Energy Performance Baseline Guide. Final KPPs are approved at CD-2 at which point they should be included in an updated PRD. 4 Program requirements must include product and process requirements that define the essential attributes for a system, subsystem, or component that addresses the mission need. 5 Program requirements may include requirements that the Acquisition (not to be confused with contract method or vehicle) must follow during implementation. Included would be Acquisition aspects that are imposed by the program beyond requirements set by law, contract, or directive. 6 Program requirements will typically include threshold and objective values as defined in DOE G 413.3-5A.

a Threshold values describe the minimum acceptable performance necessary. b Objective values describe the desired performance. 7 Program requirements are of three types, which must be understood by a program office but do not need to be specifically identified within a PRD: a Performance requirements are quantitative requirements of system performance and specify how well (e.g., how fast, how much, how far, how NNSA SD 413.3-4 Appendix A 09-15-21 APA-5 frequent) something must perform. Performance requirements are usually directly measurable (e.g., miles per hour, gallons per minute, feet, minutes) and control the overall system design by providing specific parameters that must be met by the design. b Design requirements (often referred to as constraints) are limits or restrictions on the design solution. These typically come from laws, regulations, DOE Orders, codes and standards, previous design decisions, operating/maintenance experience, etc. c Interface requirements are requirements imposed on one system by another. (7) Preferences, Principles, and Goals. Beyond specific requirements, the PRD affords the Deputy Administrator/Associate Administrator the opportunity to state its preferences, principles, and goals to frame how the Acquisition (not to be confused with contract method or vehicle) should be executed. Note, requirements in this section shall not pre-judge a solution to closing the capability gap. A preference, principle, or goal differs from a requirement in that the demonstration of it may not be straightforward or binary, the demand is tempered (should vs. must), or the statement is made as an approach versus an established endpoint. Some preferences may be less rigid than requirements. This does not imply that their importance is any less than requirements. (a) Examples of preferences, principles, or goals that might be included in a PRD: 1 “The Acquisition should have a goal that it shall not displace more than Y cubic yards of excavated soil during construction.” (This statement tells of a preference but does not explicitly demand a particular outcome). 2 “The system must meet its safety design performance requirement in any event, but the project should minimize the need for actuating safety systems to meet those performance requirements.” (The latter sentence specifies an approach to minimize, which is expressed as a preference). (8) References. Provide a list of references with document title, origin, and date that can be readily associated to the specific citations in the main body of the PRD. NNSA SD 413.3-4 Appendix B 09-15-21 APB-1 APPENDIX B: ACRONYMS a. BOP Business Operating Procedure b. CD Critical Decision c. DOE U.S. Department of Energy d. DOE G DOE Guide e. DOE O DOE Order f. FPD Federal Project Director g. HQPM Headquarters Project Manager h. MNS Mission Need Statement i. NA-APM NNSA Office of Acquisition and Project Management j. NNSA National Nuclear Security Administration k. PM Program Manager l. PRD Program Requirements Document m. ROM Rough Order of Magnitude NNSA SD 413.3-4 Appendix C 09-15-21 APC-1 APPENDIX C: REFERENCES a. DOE O 413.3B, Program and Project Management for the Acquisition of Capital Assets, current version. b. DOE G 413.3-5A, U.S. Department of Energy Performance Baseline Guide, current version. c. Systems Engineering Fundamentals 2001, Defense Acquisition University, Part 2 Chapter 4, “Requirements Analysis.”

d. NNSA Defense Programs Enterprise-wide Requirements Management Process, Revision 2, dated January 2020. e. DOE NNSA Office of Defense Programs, Requirements Engineering and Management Guidance, dated January 2017. PROGRAM REQUIREMENTS DOCUMENT 1. PURPOSE 2. AUTHORITY 3. CANCELLATION 4. APPLICABILITY. a. Federal. b. Contractors c. Equivalencies/Exemptions. 5. BACKGROUND 6. REQUIREMENTS. 7. RESPONSIBILITIES. a. Office of Acquisition and Project Management (NA-APM). b. Program Manager. c. Heads of NNSA Elements. d. Headquarters Project Manager e. Federal Project Director 8. DEFINITIONS. See DOE O 413.3B. 9. ACRONYMS. See Appendix B. 10. REFERENCES. See Appendix C. 11. CONTACT APPENDIX A: PROGRAM REQUIREMENTS DOCUMENT (PRD)FORMAT AND CONTENT APPENDIX B: ACRONYMS APPENDIX C: REFERENCES