Spacecraft Design II: Design Review Checkpoints and the V-Diagram Framework
Abstract
Spacecraft development is a high-stakes, irreversible process where design errors discovered late incur exponential costs. This article examines the System Engineering V-Diagram and its associated design review checkpoints—System Requirement Review (SRR), System Design Review (SDR), Preliminary Design Review (PDR), and Critical Design Review (CDR)—as a structured framework for managing risk and maintaining requirements traceability throughout the development lifecycle. We illustrate how each review serves as a quality gate and discuss the role of design baselines and documentation practices in preventing costly rework.
Background
The V-Diagram as a Development Framework
The System Engineering V-Diagram is the canonical framework for spacecraft and complex system development [system-engineering-v-diagram]. It structures the entire lifecycle as a bidirectional process: the left side decomposes mission needs into progressively detailed requirements and designs, while the right side integrates and verifies those designs back against the original requirements. The bottom of the V contains the actual development, manufacturing, and testing activities.
The key insight of the V-Diagram is that every requirement defined on the left must have a corresponding verification activity on the right. This ensures traceability and prevents requirements from being lost during implementation. Without this structure, teams risk building a system that is technically sound but fails to meet the original mission objectives—a catastrophic outcome in spaceflight.
Why Design Reviews Matter
In spacecraft development, the cost of correcting a design error grows exponentially with project phase. A requirement misinterpretation caught during concept exploration costs thousands of dollars to fix; the same error discovered during manufacturing costs millions. Design reviews are formal checkpoints that catch errors early, when they are least expensive to correct.
Each review serves a specific purpose in the development timeline and answers a distinct set of questions about design maturity, feasibility, and traceability.
Key Results
System Requirement Review (SRR)
The System Requirement Review occurs near the top of the V-Diagram, after mission needs have been defined but before significant design effort is invested [system-requirement-review]. Its purpose is to validate that derived system requirements properly translate high-level mission objectives into actionable specifications.
SRR answers the question: Have we correctly understood what the customer needs, and have we captured that understanding in a complete, unambiguous set of requirements?
By catching misinterpretations early, SRR prevents downstream rework and ensures the entire development effort remains aligned with stakeholder intent. This review is a quality gate before proceeding to system design.
System Design Review (SDR)
Following SRR, the System Design Review bridges requirements and detailed design by examining how system requirements are allocated across the spacecraft's configuration items (subsystems and components) [system-design-review]. SDR also evaluates manufacturing feasibility and plans for the next development phase.
SDR answers: Is the proposed system decomposition sound? Has each requirement been assigned to a responsible subsystem? Are manufacturing constraints understood?
This review 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 is a major commitment point [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.
PDR answers: Is the chosen design approach sound? Have we selected appropriate technologies? Are we ready to invest in detailed specifications and procurement?
PDR is the last major review before the design is "locked down" for final implementation. Proceeding past PDR without resolving fundamental design questions is a high-risk decision.
Critical Design Review (CDR)
The Critical Design Review is the final design review and the last opportunity to catch design errors before manufacturing begins [critical-design-review]. CDR certifies that the detailed design is complete, correct, and ready for manufacturing and assembly.
CDR ensures:
- The "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements
- The final design fulfills all specifications and commitments established at PDR
- Every requirement has a corresponding design specification
- All interfaces are properly defined and the design is producible
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.
Design Baselines and Configuration Control
The Build-to Baseline is the approved, detailed set of hardware and software specifications established at CDR [build-to-baseline]. Once approved, it becomes the single source of truth for manufacturing and assembly teams. 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.
Documentation Discipline: TBD and TBC
Two critical documentation markers help teams manage uncertainty during design:
To Be Decided (TBD) flags items where the decision-making process is still pending and the outcome is uncertain [to-be-decided-tbd]. TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts. Design reviews like CDR require that TBDs be minimized and justified.
To Be Confirmed (TBC) flags items that are not yet finalized but are expected to be confirmed during development [to-be-confirmed-tbc]. Unlike TBD, TBC assumes an existing value or approach that will be validated later through analysis, testing, or vendor feedback.
Using these markers explicitly in documentation maintains traceability and ensures stakeholders understand which items are provisional versus firm commitments. However, the number of TBDs and TBCs must decrease as the project progresses toward CDR. A design with many unresolved TBDs at CDR is not ready for manufacturing.
Worked Example: Traceability Through the V-Diagram
Consider a notional Earth observation satellite with a mission requirement: "The spacecraft shall acquire panchromatic imagery with 1-meter ground sample distance (GSD) from a 500 km sun-synchronous orbit."
At SRR: This mission requirement is decomposed into derived system requirements:
- Orbital altitude: 500 km (±10 km)
- Orbital inclination: 98.2° (sun-synchronous)
- Payload GSD: 1 meter at nadir
- Payload swath width: ≥100 km
- Spacecraft pointing accuracy: ±0.1° (3-sigma)
The review confirms that these derived requirements, taken together, satisfy the original mission need and are internally consistent.
At SDR: The system requirements are allocated to subsystems:
- Orbital altitude → Propulsion subsystem (delta-v budget)
- Pointing accuracy → Attitude Determination and Control subsystem (ADCS)
- Payload GSD → Payload subsystem (optical design)
- Swath width → Payload subsystem (detector array size)
The review confirms that each subsystem has been assigned clear, measurable responsibilities and that no requirement has been orphaned.
At PDR: Preliminary designs for each subsystem are presented:
- Propulsion: Monopropellant hydrazine system with 8 thrusters
- ADCS: Three-axis stabilized with star tracker and reaction wheels
- Payload: Refractive telescope with 0.5-meter aperture, 1024×1024 detector array
The review confirms that these preliminary designs are expected to meet the allocated requirements and that the team is ready to proceed with detailed design.
At CDR: Detailed specifications are complete:
- Propulsion: Specific thruster models, tank sizing, feed system architecture
- ADCS: Detailed control laws, sensor specifications, momentum management strategy
- Payload: Optical prescription, detector specifications, data handling architecture
The review confirms that manufacturing can proceed without ambiguity and that every requirement has a corresponding design specification.
On the right side of the V: As the spacecraft is built, tested, and integrated, each design specification is verified against the detailed design, each subsystem is verified against its allocated requirements, and the integrated spacecraft is validated against the original mission requirements. Traceability flows upward, ensuring nothing is lost.
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 from class notes (Zettelkasten). All factual and mathematical claims are cited to source notes. The worked example is original and illustrative; it does not represent an actual spacecraft design.