Requirements are ready for SRR, PDR or CDR when the review board can identify the applicable baseline, follow each material obligation to its source and solution, understand unresolved changes, and see a credible path to objective verification evidence at the maturity expected for that stage. Readiness is not a document count; it is confidence that the technical decision can be made from controlled, internally consistent information.
This checklist provides one practical structure for that assessment. It is deliberately vendor-neutral and must be tailored. NASA, ECSS, customers, primes and internal programmes use different lifecycle models and review names. The binding entrance and success criteria come from the applicable contract, programme plan, standards and approved review plan—not from a general web article.
What changes from SRR to PDR to CDR?
| Readiness dimension | SRR | PDR | CDR |
|---|---|---|---|
| Decision supported | Are the system requirements responsive to the mission and mature enough to baseline and continue definition? | Does a feasible preliminary design satisfy the allocated baseline with acceptable risk? | Is the detailed design mature enough to release build-to/code-to information and proceed to fabrication, integration and verification? |
| Requirements state | System-level functional, performance, interface and constraint set is coherent, feasible and baselined or ready for baseline. | Requirements are allocated to lower levels; derived requirements and interfaces support the preliminary design. | Requirements and interfaces supporting the detailed design are controlled; remaining changes are exceptional, bounded and managed. |
| Traceability | Stakeholder and parent needs trace to system requirements, with initial downward allocation strategy. | Bidirectional traceability reaches subsystems, interfaces, key design elements and planned verification. | Traceability reaches build/code items, controlled interfaces, procedures or cases, configurations and available evidence. |
| Verification | Preliminary method and level are identified for each requirement; difficult proof problems are visible. | The V&V plan is baselined, facilities and models are credible, and acceptance logic is defined. | Procedures, models, articles, facilities, success criteria and schedules are sufficiently mature to execute the remaining programme. |
| Open changes | TBRs and proposed changes have owners, rationale and resolution plans. | Changes are impact-assessed against requirements, interfaces, budgets and the preliminary design. | Late changes are tightly controlled and cannot leave build-to information or verification plans internally inconsistent. |
| Evidence | Analyses and prototypes support feasibility; evidence gaps are planned. | Preliminary analyses and test results support margins and major design choices. | Detailed analyses, qualification planning and available test results support the design; post-CDR evidence remains linked to planned closure. |
NASA's current procedural guidance identifies baselined requirements at SRR, a preliminary design solution and baselined integration and V&V plans at PDR, and a baselined detailed design at CDR. Those are useful maturity anchors, but they are not universal contractual rules. Apply the project-specific tailoring and success criteria.
SRR requirements-readiness checklist
The System Requirements Review asks whether the requirements and preliminary plans can support the mission. The set need not contain final lower-level design detail, but it should be stable and coherent enough that decomposition and architecture work are not built on unresolved mission intent.
| Check | Ready when | Typical objective evidence |
|---|---|---|
| Mission and stakeholder alignment | Every material system requirement has a valid source or recorded derivation and supports the intended operational concept. | Needs and objectives, concept of operations, source links, rationale and stakeholder approvals. |
| Requirement quality | Statements are necessary, feasible at the current level, unambiguous, consistently defined and independently verifiable. | Quality-review record, glossary, assumptions, TBR/TBD register and resolved comment history. |
| Coverage | Functions, performance, interfaces, environments, operations, safety, security, reliability and lifecycle constraints have been considered for applicability. | Coverage model, requirement categories, scenarios, hazard inputs and interface inventory. |
| Bidirectional traceability | System requirements trace upward to needs and parents; the plan for allocation to the next level is credible. | Traceability view, orphan and duplicate checks, initial product breakdown and allocation strategy. |
| Interfaces | External boundaries, counterparties, ownership and the most important exchanged quantities are identified. | Interface register, context diagram, draft ICD/IRD records and named interface authorities. |
| Verification concept | A preliminary method and level exist for each requirement, and high-risk or impractical verification is already being resolved. | Initial verification matrix, facility assumptions, model strategy and verification-risk list. |
| Ownership and control | Every requirement, interface, TBR and action has an accountable owner; the baseline and change authority are defined. | Responsibility model, SEMP or equivalent, workflow, approval policy and change register. |
| Feasibility and risk | Budgets, technology assumptions and major constraints do not reveal an unowned contradiction with the proposed mission. | Early mass/power/data budgets, trade studies, risk register and technology-maturation plan. |
SRR not-ready signs
- Major requirements still use “fast”, “lightweight”, “sufficient” or “as required” without an owned plan to define acceptance.
- The concept of operations and the requirements describe different mission scenarios.
- External interfaces have no counterpart owner or controlled source.
- Requirements are presented as a list with no source, rationale or baseline identity.
- The proposed verification method is unknown for high-consequence or environment-dependent requirements.
- Open issues are absent from the pack because they live in meeting notes or individual spreadsheets.
PDR requirements-readiness checklist
The Preliminary Design Review connects the allocated baseline to a feasible solution. The board should be able to see how requirements shaped the architecture, how interfaces and budgets close with margin, and how the programme intends to verify the resulting product.
| Check | Ready when | Typical objective evidence |
|---|---|---|
| Allocation | System requirements are allocated to appropriate elements, with derived requirements justified and conflicting allocations resolved. | Product hierarchy, functional allocation, parent/child traceability and derivation rationale. |
| Architecture satisfaction | The preliminary architecture shows credible functions, behaviours and design elements for the allocated obligations. | Architecture views, trade studies, functional models and requirement-to-element links. |
| Interface maturity | Critical interface values, tolerances, protocols, directions and authorities are agreed or have bounded closure plans. | Controlled interface records, N² or context views, interface working-group decisions and change history. |
| Budgets and margins | Mass, power, thermal, data, link, timing and other applicable budgets are internally consistent with the same configuration. | Budget reports, model baselines, assumptions, margin policy and sensitivity results. |
| Verification baseline | Each requirement has method, level, article/model, acceptance logic and planned evidence; combined methods state what each proves. | Baselined V&V plan and matrix, model-validation strategy, facility plan and test-flow definition. |
| Change impact | Changes since SRR have been assessed across requirements, interfaces, architecture, budgets, risks and verification. | Change dossiers, decisions, owner responses and closure actions. |
| Evidence to date | Analyses, breadboards and development tests reduce the important feasibility risks and remain tied to known configurations. | Analysis reports, prototype results, model-correlation records and anomaly dispositions. |
| Forward plan | Remaining design, supplier, verification and risk-reduction work has owners, dates and dependencies consistent with CDR. | Integrated technical schedule, procurement status, action register and CDR maturity plan. |
PDR not-ready signs
- The architecture looks plausible, but material requirements cannot be traced to the elements intended to satisfy them.
- Both sides of an interface use different values, versions or units.
- A verification method is assigned, but no suitable article, model, facility or acceptance criterion exists.
- Margins come from models using different configurations or unstated assumptions.
- Open changes could invalidate the proposed architecture, yet appear only as ordinary actions.
- Evidence from a prototype is presented without stating how it represents the flight design.
CDR requirements-readiness checklist
The Critical Design Review establishes whether the detailed design is mature enough to proceed into its next controlled implementation and verification work. It does not mean every verification result already exists. It means the team understands what will be built, which baseline it satisfies, how compliance will be demonstrated and what residual work or risk remains.
| Check | Ready when | Typical objective evidence |
|---|---|---|
| Detailed baseline consistency | Requirements, interfaces, drawings, models, bills, software definitions and procedures refer to compatible controlled configurations. | Baseline index, configuration audit, build-to/code-to package and model/version identifiers. |
| Traceability completeness | Applicable requirements trace through the detailed solution to planned verification cases; gaps and non-applicable items have approved rationale. | Coverage report, exception register, suspect-link review and configuration-filtered trace matrix. |
| Interface control | Critical interfaces are agreed, released at the required maturity and protected by a defined change authority. | Approved ICDs/IRDs, interface verification cases, issue closure and counterpart concurrence. |
| Verification implementation | Procedures or cases, success criteria, resources, models, articles, instrumentation, data handling and approval responsibilities are defined to the planned maturity. | Procedure set, verification control record, facility readiness, calibrated-equipment plan and analysis plans. |
| Evidence validity | Completed evidence identifies the requirement, method, article/model, configuration, result, anomalies and approval; obsolete evidence is not counted. | Approved reports, result records, anomaly dispositions and evidence-to-requirement links. |
| Late changes | Every material proposed change has a visible blast radius, authority, schedule effect and closure condition; none makes the presented design conclusion unreliable. | Impact assessments, waivers/deviations where applicable, decisions and incorporation status. |
| Risk and margins | Residual technical risk and margins are understood, accepted by the proper authority and consistent with remaining verification work. | Current risk register, detailed analyses, margin report, qualification logic and authority decisions. |
| Production and integration handoff | Teams receiving the design know which requirements, interfaces, inspections, tests and records govern their work. | Released work instructions, acceptance requirements, integration sequence and supplier data status. |
CDR not-ready signs
- The requirement baseline and build-to or code-to package describe different configurations.
- Verification cases exist as titles, but inputs, success criteria, articles or approval responsibility remain undefined.
- Previously accepted evidence is reused after a design change without an applicability assessment.
- Supplier interfaces or compliance evidence are late enough to undermine the integrated design.
- Negative margins, unresolved hazards or major anomalies appear as presentation footnotes rather than controlled decisions.
- The programme plans to “clean up traceability after CDR”, making it impossible to assess actual coverage at the review.
How much traceability should the board expect?
The useful question is not whether every object has the maximum possible number of links. It is whether the board can follow the engineering claims that support the decision. Bidirectional traceability should expose missing intent, unsupported design constraints, unverified obligations and evidence tied to the wrong configuration.
| Relationship | SRR expectation | PDR expectation | CDR expectation |
|---|---|---|---|
| Need/parent → requirement | Material system requirements connected | Maintained through allocated levels | Controlled with approved changes incorporated |
| Requirement → architecture/design | Allocation approach visible | Preliminary satisfying elements connected | Detailed satisfying items and configurations connected |
| Requirement ↔ interface | External boundaries and owners identified | Critical values and counterpart requirements aligned | Controlled interface and verification records linked |
| Requirement → verification | Preliminary method and level | Planned case, model/article and success logic | Executable plan plus available result and evidence links |
| Change → affected items | Open intent changes visible | Architecture and plan impacts assessed | Detailed design, evidence and production impacts controlled |
A requirements traceability or verification matrix can present these relationships compactly. It should be a view of the controlled programme record, not a manually curated table that silently diverges from the requirements, cases and results it claims to represent.
How should open changes appear at a review?
Do not force artificial closure by hiding uncertainty. Each material TBR, deviation, waiver, proposed requirement change or unresolved review item should show its affected baseline, consequence, owner, authority, decision date and closure path. The board can then decide whether the residual uncertainty is acceptable for the next lifecycle step.
Use a proportional engineering change impact assessment for changes that can affect interfaces, architecture, qualification, evidence, suppliers or schedule. A review action is not an impact assessment. The assessment explains what the change touches and what evidence must be repeated or replaced; the action records who will do the work.
What does verification readiness mean before results exist?
Verification readiness grows in layers. At SRR, the method and level need to be credible. At PDR, the programme needs a baselined strategy showing articles or models, facilities, environments, success logic and combined methods. At CDR, the remaining work should be executable: procedures and models are at the planned maturity, configurations are controlled, resources and instrumentation are known, and ownership is explicit.
Evidence only counts for the claim it actually supports. A development test can reduce risk without closing a flight requirement. An analysis can support a requirement only when its inputs, assumptions, model validity and applicable configuration are known. ECSS-E-ST-10-02C Rev.1 describes formal verification in a customer-supplier setting and may be tailored; programmes outside that setting should still preserve the same basic discipline of objective, configuration-correct evidence.
Who owns readiness?
| Role | Readiness responsibility |
|---|---|
| Requirement owner | Confirms intent, quality, source, applicability and response to proposed changes. |
| Design or architecture owner | Shows how the solution satisfies allocated requirements and manages relevant margins and assumptions. |
| Interface owner | Maintains agreement across the boundary, including counterpart approval and interface verification. |
| Verification owner | Defines method, case, article/model, configuration, success criteria, evidence and closure authority. |
| Configuration/change authority | Identifies the review baseline and decides whether proposed deltas and residual risk may move it. |
| Review chair or board | Assesses the approved success criteria and records decisions, requests for action and conditions for progression. |
One person may hold several roles in a small team, but the decisions should remain explicit. An empty owner field is not “no issue”; it means the programme does not yet know who is accountable for resolving the issue.
How to run the checklist without creating a document exercise
- Freeze or identify the exact candidate review baseline and configuration.
- Tailor the checks against the programme's approved entrance and success criteria.
- Run automated coverage and consistency checks, then have owners assess the engineering meaning.
- Record each gap as evidence, an accepted exception or an owned closure action—not as an undocumented promise.
- Review the highest-consequence unknowns and changes before presentation polish.
- After the review, preserve decisions and conditions beside the affected baseline and verify their closure.
How Arc supports lifecycle review readiness
Arc connects requirements, architecture, interfaces, tests, evidence, owners and changes in one programme workspace. Teams can filter the applicable review baseline, inspect missing or suspect relationships, compare proposed changes as diffs and assemble evidence without recreating status across disconnected spreadsheets. The review board still makes the decision; Arc keeps the claims and their provenance inspectable.
Related reading
Improve individual statements with 25 before-and-after spacecraft requirement examples, organise coverage with the traceability and verification matrix guide, and control review-period deltas with the engineering change impact assessment template.
Frequently asked questions
What is requirements readiness at SRR?
At SRR, requirements readiness means the system requirements are responsive to stakeholder and parent needs, clear enough to baseline, traceable, feasible at the current level, owned, and supported by a credible plan for lower-level allocation and verification.
How does requirements readiness change between PDR and CDR?
At PDR, allocated requirements and interfaces should support a feasible preliminary design and a baselined verification plan. At CDR, the detailed design, controlled interfaces, build-to or code-to information and verification implementation should be mature enough to proceed with fabrication, integration and formal verification at acceptable risk.
Must every requirement be verified before CDR?
No. Many formal verification activities occur after CDR. Before CDR, each applicable requirement should have a credible method, level, configuration, success criterion, owner and scheduled verification activity, with completed evidence available where the lifecycle plan calls for it.
Can open requirement changes remain at a design review?
Yes, when the programme’s success criteria allow them and each material change has a bounded impact, owner, decision date and closure plan. A review is not ready when open changes make the presented baseline or design conclusion unreliable.