Major Capability Acquisition (MCA)

AAF  > MCA  >  Technical Reviews  >  System Requirements Review

System Requirements Review (SRR)

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

Figure 22. Weapon Systems 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

Product SRR Criteria
Cost Estimate
  • Preliminary Cost Analysis Requirements Description (CARD) is consistent with the approved system performance specification
  • Preliminary software development estimates established with effort, schedule, and cost analysis
  • Updated cost estimate fits within the existing budget
Risk Assessment
  • Technical risks are identified, and mitigation plans are in place
System Performance Specification
  • Contractor clearly demonstrates an understanding of the system requirements consistent with the ICD and draft CDD
  • System requirements are sufficiently detailed and understood to enable functional definition and functional decomposition
  • System requirements are assessed to be verifiable (see Chief Developmental Tester in CH 8–4.2.)
  • Requirements can be met given the plans for technology maturation
  • External interfaces to the system have been documented in interface control documents
  • SoS technical interfaces are adequately defined, including interdependences associated with schedule, test, and configuration changes
  • Preliminary identification of all software components (tactical, support, deliverable, non-deliverable, etc.) are completed
  • Human Systems Integration (HSI) and sustainment requirements have been reviewed and included in the overall system design (See CH 3–4.3.10. and CH 5–4.)
  • Contractor has adequately expanded the system performance specification to reflect tailored, derived and correlated design requirements
  • Bidirectional requirements traceability between the draft CDD, the Statement of Work (SOW) and the system performance specification has been documented
  • System performance specification is approved, including stakeholder concurrence, with sufficiently conservative requirements to allow for design trade space
Technical Plans
  • Contractors Systems Engineering Management Plan (SEMP) is complete and adequate
  • Cost and critical path drivers have been identified
  • The program schedule is executable with an acceptable level of technical and cost risk
  • Adequate processes and metrics are in place for the program to succeed
  • SE is properly staffed
  • Program is executable within the existing budget
  • Software functionality in the system performance specification is consistent with the software-sizing estimates and the resource-loaded schedule
  • Programming languages and architectures, security requirements and operational and support concepts have been identified
  • Hazards have been reviewed and mitigating courses of action have been allocated within the overall system design
  • Key technology elements have been identified, readiness assessed and maturation plans developed
  • Software development strategy is complete and adequate
  • Program technical risks are adequately identified and documented such that there is a clear understanding regarding the contractor’s ability to meet the specification requirements
  • Draft verification methodologies have been adequately defined for each specification requirement
  • Certifying agencies have been identified and certification requirements are understood
  • Draft test plans have been developed in support of the TMRR phase (See Chief Developmental Tester in CH 8–4.2.)
  • Government and contractor configuration management (CM) strategies are complete and adequate
  • Planning for creation and/or use of models and simulations has begun and is captured in appropriate program plans.
  • The manufacturing and production strategy is complete and adequate
  • Integrated Master Schedule (IMS) adequately identifies the critical path and is resourced at reasonable levels, based on realistic performance/efficiency expectations
  • Unique work requirements for risk reduction prototyping and competitive prototyping have been identified
  • Product support plan and sustainment concepts have been defined with the corresponding metrics

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.