Spacecraft Design II: Design Review Checkpoints and the V-Diagram Framework
Abstract
Spacecraft development follows a structured lifecycle that balances decomposition of mission needs with systematic verification and integration. This article examines the System Engineering V-Diagram as an organizing framework and walks through the sequence of design reviews—System Requirement Review (SRR), System Design Review (SDR), Preliminary Design Review (PDR), and Critical Design Review (CDR)—that serve as quality gates throughout the development process. Understanding these checkpoints and their purpose is essential for managing requirements traceability and controlling cost and schedule risk.
Background
Complex spacecraft projects involve hundreds of stakeholders, thousands of requirements, and millions of dollars in development and manufacturing costs. Without a structured approach, requirements can be misinterpreted, design decisions can conflict with mission objectives, and expensive rework occurs late in the project lifecycle when changes are costliest.
The System Engineering V-Diagram provides a conceptual framework for managing this complexity [system-engineering-v-diagram]. The diagram maps the entire spacecraft lifecycle as a bidirectional process: the left side decomposes mission needs progressively into detailed design specifications, while the right side integrates and verifies those designs back up through subsystem and system-level testing. The bottom of the V contains the actual development, manufacturing, and assembly activities. This structure ensures that every requirement defined during decomposition has a corresponding verification activity during integration, preventing requirements from being lost or overlooked.
The intuition behind the V-shape is straightforward but powerful: traceability and balance. Each level of system decomposition (system → subsystem → unit) must have a matching level of integration and testing. This prevents the common pitfall of building something that technically works but does not meet the original mission needs.
Key Results: The Design Review Sequence
System Requirement Review (SRR)
The System Requirement Review occurs near the top of the V-diagram, early in the project lifecycle [system-requirement-review]. Its purpose is to validate that high-level mission needs have been correctly translated into derived system requirements. At this stage, the project team has completed concept exploration and mission definition, and is preparing to move into detailed system design.
SRR acts as a quality gate by catching misinterpretations or gaps in requirements translation before significant design effort is invested. Because changes are least costly early in development, this review prevents downstream rework and ensures the entire development effort remains aligned with stakeholder intent.
System Design Review (SDR)
Following SRR, the System Design Review bridges requirements and detailed design [system-design-review]. SDR evaluates how system requirements have been allocated across the spacecraft's configuration items (subsystems and components) and assesses manufacturing feasibility. The review examines the high-level architectural decisions: whether the proposed system decomposition is sound, whether each requirement has been assigned to responsible subsystems, and whether manufacturing constraints have been considered early.
SDR prevents architectural mistakes that would be expensive to correct later and confirms the team is ready to proceed with detailed design work on individual subsystems.
Preliminary Design Review (PDR)
The Preliminary Design Review represents a significant commitment point in the development timeline [preliminary-design-review]. By this stage, the design team has completed trade studies, selected technologies, and developed preliminary designs for all major subsystems. PDR demonstrates that the proposed design approach is feasible and mature enough to justify proceeding to final detailed design.
The review confirms that the chosen approach is sound before investing in detailed specifications, drawings, and procurement. It reduces risk by catching fundamental design flaws before they propagate into expensive detailed work. PDR is the last major review before the design is "locked down" for final implementation.
Critical Design Review (CDR)
The Critical Design Review is the final design review and the last major checkpoint before manufacturing begins [critical-design-review]. CDR certifies that the detailed design is complete, correct, and ready for manufacturing and assembly. The review ensures that the "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements, and that the final design fulfills all specifications and commitments established at PDR.
CDR is critical because it is the last opportunity to catch design errors without incurring manufacturing costs. After CDR approval, the design is "frozen" and becomes the authoritative baseline for building the spacecraft. Changes after CDR are exponentially more expensive because they may require rework of already-manufactured components or assemblies.
The Build-to Baseline and Configuration Control
Once the build-to baseline is approved at CDR, it becomes the single source of truth for manufacturing and assembly [build-to-baseline]. All drawings, specifications, and interface definitions are locked and controlled through formal change management processes. This baseline prevents ambiguity, ensures consistency across all manufacturing activities, and provides traceability from requirements through final product.
Any changes to the baseline after CDR must go through formal change control to assess impacts and maintain configuration integrity. This discipline is essential because a spacecraft is a tightly integrated system where changes to one subsystem can affect power budgets, thermal margins, structural loads, and interface compatibility across multiple other subsystems.
Documentation Markers: TBD and TBC
During design development, not all details can be determined simultaneously. Two documentation markers are used to flag unresolved items:
To Be Decided (TBD) indicates items where the decision-making process is still pending and the outcome is uncertain [to-be-decided-tbd]. TBD flags areas requiring active decision-making before the design can be considered complete. In spacecraft design, TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts.
To Be Confirmed (TBC) indicates items that are not yet finalized but are expected to be confirmed during development [to-be-confirmed-tbc]. TBC assumes an existing value or approach that will be confirmed later through analysis, testing, or vendor feedback. This is distinct from TBD, which implies the decision itself is still pending.
Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. Items marked TBC are more acceptable at CDR because they represent confirmation of provisional values rather than unresolved decisions.
Conclusion
The System Engineering V-Diagram and its associated design reviews provide a structured framework for managing spacecraft development from mission conception through manufacturing. Each review serves as a quality gate that validates progress at a specific level of decomposition and integration, ensuring traceability from high-level mission needs to detailed design specifications. By understanding the purpose and timing of SRR, SDR, PDR, and CDR, project teams can identify and resolve issues early, when changes are least costly, and maintain configuration control throughout the development lifecycle.
References
- [system-engineering-v-diagram]
- [system-requirement-review]
- [system-design-review]
- [preliminary-design-review]
- [critical-design-review]
- [build-to-baseline]
- [to-be-decided-tbd]
- [to-be-confirmed-tbc]
AI Disclosure
This article was drafted with AI assistance using Anthropic's Claude. The content is derived from course notes on Spacecraft Design II and represents a synthesis and paraphrase of those materials. All factual claims are cited to source notes. The author reviewed and validated all technical content for accuracy before publication.