Spacecraft Design II: Comparisons with Related Concepts
Abstract
Spacecraft design operates within a structured lifecycle framework that decomposes mission needs into verifiable requirements and detailed specifications. 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)—comparing their roles, timing, and relationships within the development process. By clarifying how each review enforces traceability and prevents costly downstream rework, we establish a foundation for understanding why systematic design governance is essential in aerospace projects.
Background
Spacecraft development is inherently complex: a single mission may involve hundreds of requirements, dozens of subsystems, and thousands of components. Without structured governance, requirements can be misinterpreted, architectural decisions can conflict, and manufacturing can begin before designs are mature. The System Engineering V Diagram provides a conceptual framework that addresses this challenge [system-engineering-v-diagram].
The V-diagram organizes development as a bidirectional process. The left side represents decomposition: mission needs flow downward through feasibility studies, concept of operations, and system requirements, progressively branching into subsystem and unit-level designs. The right side represents integration and verification: unit testing flows upward through subsystem verification, system verification, and validation, converging back to operational requirements. The bottom of the V contains the actual development work—manufacturing, assembly, and integration activities [system-engineering-v-diagram].
This structure embodies a critical principle: every requirement defined during decomposition must have a corresponding verification activity during integration. This ensures traceability and prevents requirements from being lost or overlooked during implementation. Each level of decomposition (system → subsystem → unit) has a matching level of integration and testing, creating a balanced, verifiable development path.
Key Results
Design Review Hierarchy and Timing
Four major design reviews punctuate the spacecraft development lifecycle, each serving a distinct purpose and occurring at a specific maturity level.
System Requirement Review (SRR) occurs early, near the top of the V-diagram, and validates that high-level mission needs have been correctly translated into derived system requirements [system-requirement-review]. Its purpose is to catch misinterpretations or gaps in requirements translation before significant design effort is invested. By verifying that lower-level derived requirements properly capture the original mission objectives, SRR prevents downstream rework and ensures alignment with stakeholder needs [system-requirement-review].
System Design Review (SDR) follows SRR and evaluates how system requirements have been allocated across the spacecraft's configuration items (subsystems and components) and assesses manufacturing feasibility [system-design-review]. SDR bridges requirements and detailed design by examining high-level architectural decisions, ensuring that the proposed system decomposition is sound and that each requirement has been assigned to responsible subsystems [system-design-review].
Preliminary Design Review (PDR) represents a major commitment point and demonstrates that the proposed design approach is feasible and mature enough to proceed to final detailed design [preliminary-design-review]. By this stage, trade studies are complete, technologies are selected, and preliminary designs exist for all major subsystems. PDR confirms that the chosen approach is sound before investing in detailed specifications, drawings, and procurement [preliminary-design-review].
Critical Design Review (CDR) is the final design review, certifying that the detailed design is complete, correct, and ready for manufacturing and assembly [critical-design-review]. CDR ensures that the "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements [critical-design-review]. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft [critical-design-review].
The Build-to Baseline
A critical artifact that emerges from CDR is the build-to baseline—the approved, detailed set of hardware and software specifications that serves as the authoritative reference for manufacturing and assembly [build-to-baseline]. Once approved, the build-to baseline 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 [build-to-baseline].
The build-to baseline prevents ambiguity, ensures consistency across all manufacturing activities, and provides traceability from requirements through the final product. Any changes to the baseline after CDR must go through formal change control to assess impacts and maintain configuration integrity [build-to-baseline].
Documentation Markers: TBD and TBC
During design development, not all details can be determined simultaneously. Two documentation markers—TBD (To Be Decided) and TBC (To Be Confirmed)—allow teams to proceed while acknowledging uncertainty [to-be-decided-tbd], [to-be-confirmed-tbc].
TBD indicates that the decision-making process itself is still pending and the outcome is uncertain [to-be-decided-tbd]. TBC, by contrast, indicates that an item is not yet finalized but is expected to be confirmed during development, implying that the decision direction is known but details remain provisional [to-be-confirmed-tbc].
In spacecraft design, TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts [to-be-decided-tbd]. Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline [to-be-decided-tbd].
Comparisons and Relationships
The four design reviews form a progression that reflects increasing design maturity and decreasing flexibility. SRR and SDR occur during the conceptual and preliminary phases, where architectural decisions are still malleable and changes are relatively inexpensive. PDR marks the transition to detailed design, committing the team to a specific technical approach. CDR locks the design for manufacturing, after which changes become exponentially more costly.
This progression mirrors the V-diagram's left-side decomposition: each review ensures that the next level of detail is consistent with higher-level decisions. SRR validates that requirements are correct; SDR validates that the architecture is sound; PDR validates that the preliminary design is feasible; CDR validates that the detailed design is complete and correct.
The reviews also differ in their focus. SRR and SDR emphasize requirements and architecture; PDR emphasizes feasibility and maturity; CDR emphasizes completeness and manufacturability. Together, they create multiple checkpoints where errors can be caught before they propagate downstream.
The build-to baseline represents the culmination of this process. It is not merely a collection of drawings; it is the frozen, traceable embodiment of all decisions made during the design reviews. By locking the baseline at CDR, the project establishes a clear boundary between design and manufacturing, reducing ambiguity and enabling parallel work across manufacturing teams.
Conclusion
The System Engineering V Diagram and its associated design reviews provide a structured framework for managing the complexity of spacecraft development. By enforcing traceability from mission needs through detailed specifications, and by establishing clear checkpoints where design maturity is validated, this framework prevents costly rework and ensures that the final spacecraft actually performs its intended mission. The progression from SRR through CDR, culminating in the build-to baseline, reflects a deliberate strategy of catching errors early, when changes are least expensive, and locking the design only when it is sufficiently mature for manufacturing.
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 the assistance of an AI language model based on class notes provided by the author. The AI was used to organize, paraphrase, and structure the material into a coherent narrative. All factual claims are cited to the original notes. The author is responsible for the accuracy and completeness of the content.