SRR, PDR, CDR, TRR and PRR are systems engineering reviews used to determine whether a program has reached defined points of technical maturity. In simple terms, the System Requirements Review confirms the requirements, the Preliminary Design Review evaluates the preliminary design, the Critical Design Review evaluates the detailed design, the Test Readiness Review authorizes planned testing, and the Production Readiness Review assesses whether the product and production system are ready to build units consistently.
These reviews are more than presentation dates. Each should evaluate objective evidence against planned entrance and exit criteria. However, their timing, scope, approval authority and required products vary by acquisition pathway, agency, program and contract.
SRR, PDR, CDR, TRR and PRR at a glance
- SRR — System Requirements Review: Are the system requirements sufficiently complete, consistent, traceable, testable and achievable?
- PDR — Preliminary Design Review: Does the preliminary design satisfy the allocated requirements with acceptable risk, allowing detailed design to proceed?
- CDR — Critical Design Review: Is the detailed design mature enough to support fabrication, coding, assembly, integration and test?
- TRR — Test Readiness Review: Are the test article, procedures, facility, personnel, configuration and data processes ready for a specific test?
- PRR — Production Readiness Review: Can the program produce the required units with adequate manufacturing processes, resources, quality controls and support?
The sequence appears linear, but actual programs often conduct reviews at several system levels. A subsystem CDR may precede the system CDR, while multiple TRRs may support environmental, qualification, cybersecurity and system-level testing. Software-intensive programs may also use incremental or release-based reviews.
The DoD Engineering of Defense Systems Guidebook describes technical reviews as assessment points used to determine whether planned technical maturity has been achieved. The exact review architecture should align with the program’s acquisition strategy, Systems Engineering Plan, technical baseline and contract.
System Requirements Review: define what the system must do
The System Requirements Review evaluates the maturity of the system requirements. The review asks whether the requirements reflect the approved capability need and whether the development team understands them well enough to continue system definition.
A credible SRR normally examines:
- Functional and performance requirements
- External and internal interface requirements
- Requirements traceability to higher-level needs
- Verification methods and testability
- Key performance, safety, cybersecurity and supportability considerations
- Technical performance measures and margins
- Requirements-related risks, assumptions, interfaces and dependencies
- Cost and schedule feasibility
SRR does not prove that the design works. Instead, it confirms that the program has a sufficiently sound requirements foundation for architecture development, functional analysis and subsequent design work.
Scheduler interpretation of SRR
The integrated master schedule should show the work that matures the requirements before SRR. Examples include requirements analysis, interface identification, verification-method assignment, requirements traceability and internal review cycles.
Do not insert a date-only SRR milestone between two summary bars. The schedule should show which products drive the review and which activities depend on its outcome. For programs organized around a product-oriented structure, WBS and statement-of-work traceability helps connect the review to the responsible system elements.
Preliminary Design Review: confirm the design approach
The Preliminary Design Review assesses whether the preliminary design can satisfy the allocated requirements within acceptable technical, cost and schedule risk. A successful PDR generally supports the decision to proceed into detailed design.
The review commonly addresses:
- System and subsystem architecture
- Allocation of requirements to lower-level elements
- Preliminary hardware, software and interface designs
- Trade-study results and design selections
- Prototypes, models and critical technology demonstrations
- Verification and validation planning
- Manufacturing, integration and product-support approaches
- Technical performance against planned margins
- Open risks and the resources required to retire them
DoD guidance associates PDR with establishing or confirming the allocated baseline. In practical terms, the team should understand what each system element must accomplish and how the elements will interact before detailed drawings or code-to documentation mature.
PDR is not simply a percentage-complete event
Teams sometimes describe PDR as a fixed percentage of design completion. That convention may support internal planning, but it is not a universal regulatory definition. The program should judge readiness against approved technical products and criteria rather than an unsupported percentage.
For Major Defense Acquisition Programs, PDR assessment provisions have specific statutory and DoD policy treatment. Those provisions should not be generalized into a claim that every contractor or every acquisition pathway must conduct an identical PDR. The applicable acquisition documentation and contract govern the requirement.
Critical Design Review: prove the design is ready to build
The Critical Design Review evaluates the detailed design and its readiness to support fabrication, coding, assembly, integration and test. The review focuses on build-to, code-to and related technical documentation, remaining design risks and the maturity of the initial product baseline.
A CDR package may include:
- Detailed drawings, models and software design descriptions
- Interface definitions and interface-control status
- Requirements-to-design and requirements-to-verification traceability
- Engineering analyses and updated technical performance measures
- Safety, cybersecurity, reliability and maintainability evidence
- Updated integration and test plans
- Material, supplier and manufacturing considerations
- Configuration status and unresolved design actions
CDR should not become a ceremonial approval of a design that is still changing materially. If major interfaces remain undefined or critical analyses remain incomplete, the schedule should show the remaining work and its effect on fabrication, software development or test readiness.
Model both the review and its closure
Schedulers should consider separate milestones for CDR Conducted and CDR Complete when the review generates formal actions. The first records the meeting. The second represents satisfaction of the approved exit criteria or closure of the actions required before proceeding.
This distinction prevents the program from reporting CDR complete while significant review item discrepancies still block design release. It also preserves a logical path from design maturity through fabrication and integration.
Test Readiness Review: authorize a defined test
The Test Readiness Review determines whether the program can safely and effectively begin a planned test or series of tests. Unlike SRR, PDR and CDR, TRR is usually repeatable. A program may conduct separate TRRs for component qualification, environmental testing, software qualification, cybersecurity testing and system verification.
A TRR typically evaluates whether:
- The test objectives trace to approved requirements
- The test article has the correct configuration
- Test procedures are complete and reviewed
- Test equipment and facilities are available and certified as required
- Personnel are trained and assigned
- Safety and hazard controls are in place
- Required software, instrumentation and data systems are ready
- Data collection, reduction and control processes are defined
- Known defects and waivers have been dispositioned
The NASA Systems Engineering Handbook provides another authoritative example of using defined entrance and success criteria for life-cycle and technical reviews. NASA criteria do not create DoD contractual requirements, but they illustrate the evidence-based nature of a well-run review.
Schedule each TRR against its test scope
A single generic TRR milestone rarely provides enough visibility for a complex development program. Instead, link each significant TRR to its test procedures, article configuration, facility readiness and prerequisite engineering work. Then link successful completion to the applicable test execution activities.
Also distinguish TRR from an Operational Test Readiness Review or other agency-specific readiness reviews. Similar names do not make the reviews interchangeable.
Production Readiness Review: confirm repeatable production
The Production Readiness Review evaluates whether the design, producer and supporting processes are ready to manufacture the required quantity at the planned rate and quality. PRR focuses on more than the technical design. It examines the production system needed to reproduce that design consistently.
Typical areas include:
- Design stability and configuration control
- Manufacturing planning and work instructions
- Tooling, facilities and special test equipment
- Supplier readiness and material availability
- Production-process capability
- Quality planning and acceptance methods
- Workforce skills and staffing
- Producibility and manufacturing risks
- Initial logistics and product-support readiness
- Plans for resolving qualification or production issues
PRR does not always occur once. A program may conduct an initial review before low-rate production and later assessments before increasing rate or moving to full-rate production. The review structure depends on the product, acquisition pathway and production strategy.
How to model technical reviews in the IMS
The integrated master schedule should treat technical reviews as event-based maturity points. Each milestone needs a credible network of predecessor and successor activities.
- Define the criteria. Identify the required products, maturity expectations, approval authority and action-closure rules.
- Schedule artifact development. Include analysis, drafting, modeling, peer review, updates and configuration control.
- Add internal readiness reviews. These reviews reduce the chance that the formal event becomes the first integrated examination of the material.
- Model customer delivery. If the contract requires advance delivery of a review package, include that submission and the customer review period.
- Schedule the review event. Use a zero-duration milestone unless the scheduling procedure directs otherwise.
- Plan action resolution. Assign owners and logic for review item discrepancies, requests for action and required updates.
- Connect downstream work. Fabrication, formal testing or production should depend on the applicable authorization or completion milestone.
Review packages and other data items become contractual deliverables only when the contract requires them. Review the statement of work, specifications and Contract Data Requirements List rather than assuming a guidebook creates a contractor obligation. See what a CDRL controls for additional context. For research and development contracts, FAR Part 35 also emphasizes tailoring the work statement and identifying required reporting or furnished items.
Fictional example: Harbor Shield sensor subsystem
Assume the fictional Harbor Shield program is developing a shipboard sensor subsystem. Its SRR depends on completing system requirements analysis, interface identification and verification-method assignment. After SRR, architecture and allocation activities drive the subsystem PDR.
The team then completes detailed electronics drawings, software design, interface-control updates and thermal analysis before CDR. However, the CDR meeting produces two actions that must close before drawing release. Therefore, the scheduler places CDR Conducted before the action-resolution activities and uses CDR Complete to authorize fabrication.
Later, the program conducts separate TRRs for environmental qualification and system integration testing. Each TRR has different procedures, facilities and article configurations. Finally, the PRR depends on qualification results, production tooling, supplier qualification, work instructions and quality planning.
This network gives management more information than five isolated milestone dates. It shows what drives each review, what remains open and which downstream activities face risk.
Technical reviews and earned value management
A review milestone is not automatically an earned value technique or a basis for claiming progress. Control accounts and work packages should define objective completion criteria for the products that support the review. The team should earn value in accordance with the approved performance measurement approach.
However, review movement can reveal significant forecast risk. A late PDR may compress detailed design, while a late CDR may affect material release, fabrication and test. Therefore, the schedule and cost systems should maintain consistent scope, dates and responsibility. The guide to how the IMS supports earned value management explains this relationship in more detail.
Moving a review date also does not automatically authorize a baseline change. The program must follow its approved change-control process and distinguish current forecast movement from changes to the performance measurement baseline.
Common planning failures
- Using unsupported hard constraints: A mandated date may belong in the schedule, but readiness work should still drive the milestone so the IMS can calculate variance and float.
- Equating the meeting with completion: Open actions may prevent the program from satisfying the exit criteria.
- Using one TRR for every test: Different tests often require different articles, procedures, facilities and approvals.
- Ignoring lower-level reviews: System-level reviews should integrate evidence from the relevant subsystem and configuration-item reviews.
- Leaving action closure outside the IMS: Significant actions can drive design release, test entry or production even after the formal meeting ends.
- Treating guidance as contract language: A handbook may describe good practice without creating a deliverable or contractor obligation.
- Scheduling reviews only from a template: The review sequence must reflect the actual technical and acquisition strategy.
Frequently asked questions
Are SRR, PDR, CDR, TRR and PRR mandatory on every DoD contract?
No. Requirements vary by acquisition pathway, program category, agency policy, tailoring decisions and contract. Review the applicable acquisition documentation and contract terms before assigning a requirement to the contractor.
Should technical reviews be zero-duration milestones?
Usually, the formal decision or completion point should be a zero-duration milestone. Preparation, package delivery, meeting activities and action closure should appear as separate tasks when they affect execution.
Can a program combine reviews?
Yes, when the governing authority and program documentation allow it. The combined review still needs clear criteria and enough objective evidence to support each intended decision.
What is the most important scheduling rule?
Schedule the evidence and readiness work, not just the review date. A technical review milestone is credible only when a logically connected network demonstrates how the program will become ready.