Which one of the following major reviews formalises the system requirement specification (syrs)?

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: DAG CH 3-3.3.2 System Requirements Review

The System Requirements Review (SRR) is a multi-disciplined technical review to ensure that the developer understands the system requirements and is ready to proceed with the initial system design. This review assesses whether the system requirements as captured in the system performance specification (sometimes referred to as the System Requirements Document (SRD)):

• Are consistent with the preferred materiel solution (including its support concept) from the Materiel Solution Analysis (MSA) phase.
• Are consistent with technology maturation plans.
• Adequately consider the maturity of interdependent systems.

All system requirements and performance requirements derived from the Initial Capabilities Document (ICD) or draft Capability Development Document (CDD) should be defined and consistent with cost, schedule, risk and other system constraints and with end-user expectations. Also important to this review is a mutual understanding (between the program office and the developer) of the technical risk inherent in the system performance specification.

Major Defense Acquisition Programs (MDAPs) require a Milestone A before approving release of the final Request for Proposal (RFP) for the Technology Maturation and Risk Reduction (TMRR) phase; therefore, it is suggested that the program office perform a review similar to an SRR to assess readiness and risks of the technical content of the draft RFP(s) prior to Milestone A and ensure performance requirements are traceable to capability requirements. This program office review should occur after the selection of the preferred solution and after sufficient analysis has occurred to develop a draft system performance specification.

If the program’s Acquisition Strategy (AS) includes competing contractual efforts during the TMRR phase, an SRR should be held with each participating developer to ensure the requirements are thoroughly and properly understood and they are ready to proceed into initial system design with acceptable risk. This review also ensures that system of systems (SoS) requirements, in the form of logical and physical interfaces and desired performance outcomes, have been levied on the system to be procured and are consistent with the ICD and/or draft CDD. These requirements are documented in the system performance specification and managed through external communication and technical interfaces in accordance with the Systems Engineering Plan (SEP).

Roles and Responsibilities

Reference Source: DAG CH 3-3.3.2 System Requirements Review

  The unique Program Manager (PM) responsibilities associated with an SRR include:

• Approving, funding, and staffing the SRR as planned in the SEP developed by the Systems Engineer.
• Managing and approving changes to the system performance specification.
• Establishing the plan to System Functional Review (SFR) in applicable contract documents, including the SE Master Plan, Integrated Master Schedule (IMS) and Integrated Master Plan (IMP).
• Ensuring the plan includes subject matter experts to participate in each review.

The unique Systems Engineer responsibilities associated with an SRR include:

• Ensuring all performance requirements, both explicit and derived, are defined and traceable (both directions) between requirements in the draft CDD including Key Performance Parameters (KPPs), Key System Attributes (KSAs), other system attributes and the system performance specification (see JCIDS Manual (Enclosure D)) (requires Common Access Card (CAC) to access website).
• Ensuring verification methods are identified for all system requirements.
• Ensuring risk items associated with system requirements are identified and analyzed, and mitigation plans are in place.
• Ensuring adequate plans are in place to complete the technical activities to proceed from SRR to the SFR.
• Ensuring plans to proceed to SFR allow for contingencies.
• Ensuring all interface are documented for the SoS and included in the performance specification.

Inputs and Review Criteria

Reference Source: DAG CH 3-3.3.2 System Requirements Review

Figure 22 provides the end-to-end perspective and the integration of SE technical reviews and audits across the acquisition life cycle. The SRR criteria are developed to best support the program’s technical scope and risk and are documented in the program’s SEP at Milestone A.

Figure 22: Weapon System Development Life Cycle

Table 29 identifies the products and associated review criteria normally seen as part of the SRR. The Chief Engineer should review this table and tailor the criteria for the program. The system-level SRR review should not begin until the criteria, identified by the Chief Engineer and documented in the SEP, are met and any prior technical reviews are complete and their action items closed. This is also an opportunity to assess whether technical requirements from all acquisition documentation (e.g., Program Protection Plan (PPP), Test and Evaluation Master Plan (TEMP), Reliability, Availability, Maintainability, and Cost Rationale (RAM-C) Report) are flowed to specifications. If the program’s AS includes competing contractual efforts, an SRR should be held with each developer. A resource for SRR preparation is IEEE 15288.2 “Standard for Technical Reviews and Audits on Defense Programs”. This is a best practice review.

Table 29: SRR Products and Criteria

Output and Products

Reference Source: DAG CH 3-3.3.2 System Requirements Review

The Technical Review Chair determines when the review is complete. Once the products have been reviewed and approved in SRR, they provide a sound technical basis for proceeding with the system’s functional definition and preliminary design.