System Requirements Review (SRR)

A System Requirements Review (SRR) is the first major formal technical review on a defense acquisition program, conducted to assess whether the system's requirements are complete, traceable to mission needs, and technically feasible before the team commits to a preliminary design approach.

What is a System Requirements Review?

The SRR occurs early in the Technology Maturation and Risk Reduction (TMRR) or Engineering and Manufacturing Development (EMD) phases, after the system's top-level operational requirements have been established but before detailed technical requirements have been fully allocated to subsystems. It is defined in MIL-STD-15288 (Systems Engineering - System Life Cycle Processes) and the Defense Acquisition Guidebook.

The SRR evaluates the System Requirements Specification (SRS) or System Performance Specification to assess whether: all stakeholder needs have been captured, requirements are testable and unambiguous, interfaces with external systems are identified, the requirements are technically achievable within the anticipated cost and schedule, and requirements traceability has been established from mission objectives down to system-level functions.

SRR success criteria typically include: 100% of allocated operational requirements traced to system requirements, no unresolved system-level interface requirements, Technical Performance Measures (TPMs) identified and measurement approaches defined, and the systems engineering team's assessment that no requirements are technically infeasible. Action items from the SRR drive the requirements baseline refinement leading into the Preliminary Design Review.

Why the SRR matters for government contractors

A thorough SRR prevents requirements problems from propagating into design. Requirements that are ambiguous, contradictory, or technically infeasible at the SRR stage are exponentially more expensive to resolve after the Preliminary Design Review or Critical Design Review. The SRR is the contractor's first opportunity to formally surface requirements concerns and seek clarification before design commitments are made.

Example

A defense contractor conducting the SRR for a new electronic warfare system discovers that two requirements are mutually exclusive: one requires the system to operate in a fully sealed enclosure (for environmental protection), while another requires active cooling fans (for thermal management). The SRR identifies this as a Type 1 (critical) action item. The systems engineering team works with the customer to revise the thermal requirement before the Preliminary Design Review, preventing a fundamental design conflict from propagating forward.

Frequently Asked Questions

What documents are typically reviewed at an SRR?

Key SRR input documents include the System Requirements Specification, Interface Control Documents (ICDs) for external interfaces, the Concept of Operations (CONOPS), the preliminary WBS, and the requirements traceability matrix showing linkage from operational needs to system requirements.

Who attends an SRR?

SRR attendees typically include the contractor's systems engineering team and program management, the government program office and its technical representatives, the Technical Review Chair (usually a senior government systems engineer), and representatives from major subcontractors with interface responsibilities.

What happens if the SRR is not successfully completed?

An unsuccessful SRR does not prevent the program from proceeding, but the government program office may impose conditions, such as resolution of all critical action items before the preliminary design review, or conduct an additional focused review before authorizing the next phase.

How does the SRR relate to the requirement for a Functional Baseline?

The approved Functional Baseline, the set of approved, contracted system performance requirements, is formally established at or shortly after a successful SRR. This baseline is then controlled through the configuration management process and can only be changed through formal Engineering Change Proposals.