Spacecraft Design II: The V-Diagram Framework and Design Review Checkpoints
Abstract
The development of spacecraft and complex aerospace systems demands a structured approach to translating mission objectives into hardware and software. 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 practical tools for managing requirements traceability, architectural decisions, and manufacturing readiness. These mechanisms form the backbone of modern spacecraft development, ensuring that every requirement has a corresponding verification activity and that design decisions are validated before costly fabrication begins.
Background
Spacecraft development involves multiple stakeholders, competing constraints, and irreversible decisions. A single architectural mistake or misaligned requirement can render months of detailed design work obsolete or, worse, result in a spacecraft that fails to meet its mission. Traditional linear development approaches—where requirements flow downward into design and then into manufacturing—lack explicit verification that the final product actually satisfies the original mission needs.
The System Engineering V-Diagram addresses this problem by structuring development as a bidirectional process [system-engineering-v-diagram]. The left side of the V represents decomposition: mission needs flow through feasibility studies, concept of operations, and progressively more detailed requirements and design specifications. The right side represents integration and verification: unit testing, subsystem verification, system verification, and validation flow back upward to confirm that operational requirements are met. The bottom of the V contains the actual development work—manufacturing, assembly, and integration activities.
The key insight is that every requirement defined on the left side must have a corresponding verification activity on the right side. This ensures traceability and prevents requirements from being lost during implementation [system-engineering-v-diagram]. Without this bidirectional structure, teams risk building systems that are technically sound but operationally irrelevant.
Key Results: Design Review Framework
System Requirement Review (SRR)
The System Requirement Review occurs near the top of the V-diagram, after mission definition but before significant design investment [system-requirement-review]. Its purpose is to validate that high-level mission needs have been correctly translated into derived system requirements. SRR acts as an early quality gate: by catching misinterpretations or gaps in requirements translation before detailed design begins, it prevents costly downstream rework [system-requirement-review].
System Design Review (SDR)
Following SRR, the System Design Review bridges requirements and detailed design by examining how system requirements have been allocated across configuration items (subsystems and components) [system-design-review]. SDR also assesses manufacturing feasibility and plans for the next development phase. This review prevents architectural mistakes that would be expensive to correct later and confirms the team is ready to proceed with detailed subsystem design [system-design-review].
Preliminary Design Review (PDR)
The Preliminary Design Review represents a significant 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. It is the last major review before the design is "locked down" for final implementation [preliminary-design-review].
Critical Design Review (CDR)
The Critical Design Review is the final design review, occurring after detailed design is complete but before manufacturing begins [critical-design-review]. CDR certifies that the "build-to" baseline—the approved, detailed set of hardware and software specifications—is complete, correct, and ready for manufacturing and assembly [build-to-baseline].
CDR ensures that every requirement has a corresponding design specification, that all interfaces are properly defined, and that the design is producible [critical-design-review]. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft [build-to-baseline]. Changes after CDR are exponentially more expensive because they may require rework of manufacturing tooling, procurement, or already-fabricated components.
Traceability and Documentation Control
A critical aspect of the V-diagram framework is the use of explicit documentation markers to track design maturity. Two key markers are used throughout spacecraft development:
To Be Decided (TBD) indicates 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 [to-be-decided-tbd].
To Be Confirmed (TBC) indicates items that are not yet finalized but are expected to be confirmed during development [to-be-confirmed-tbc]. TBC is distinct from TBD: it assumes an existing value or approach that will be validated later through analysis, testing, or vendor feedback [to-be-confirmed-tbc].
Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline [to-be-decided-tbd]. This discipline prevents ambiguity in manufacturing and maintains traceability from high-level mission requirements through final detailed design.
Practical Implications
The V-diagram framework and its associated reviews serve several practical functions:
-
Risk reduction: Each review gate catches errors at a phase where correction is least costly. A requirement error caught at SRR costs far less to fix than one discovered during system integration.
-
Traceability: The bidirectional structure ensures that every requirement has a verification path. This traceability is essential for mission assurance and regulatory compliance.
-
Stakeholder alignment: Design reviews provide formal checkpoints where stakeholders can validate that the project remains aligned with mission objectives.
-
Manufacturing readiness: By the time CDR is complete, manufacturing teams have unambiguous specifications and can proceed without design uncertainty.
-
Configuration control: The build-to baseline established at CDR becomes the single source of truth for manufacturing and assembly, controlled through formal change management [build-to-baseline].
Conclusion
The System Engineering V-Diagram and its associated design review checkpoints form a structured, verifiable approach to spacecraft development. By ensuring that every requirement has a corresponding verification activity and that design decisions are validated before costly fabrication, this framework reduces risk, maintains traceability, and increases the probability that the final spacecraft will meet its mission objectives. The discipline of explicit documentation markers (TBD, TBC) and formal design reviews transforms spacecraft development from a linear, error-prone process into a controlled, bidirectional system where decomposition and integration are balanced and traceable.
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 assistance from an AI language model based on personal class notes from Spacecraft Design II (ASE 4543). The AI was used to structure the material, paraphrase concepts, and organize the narrative. All factual claims are cited to the original notes. The author reviewed and validated all content for technical accuracy and relevance.