Spacecraft Design II: Applications to Engineering Problems
Abstract
Spacecraft design is fundamentally a problem of translating mission objectives into verifiable hardware and software specifications while managing risk and cost. This article examines the system engineering framework used in spacecraft development, with emphasis on the V-diagram lifecycle model and the critical design review checkpoints that ensure requirements remain traceable from conception through manufacturing. We illustrate how these tools prevent costly rework and maintain alignment between stakeholder needs and engineering implementation.
Background
Complex spacecraft projects face a common challenge: how to ensure that what is built actually meets what was promised. Without a structured approach, requirements can be misinterpreted, architectural decisions can be made without full understanding of their implications, and design flaws discovered late in development become prohibitively expensive to fix.
The System Engineering V Diagram provides a framework for managing this complexity [system-engineering-v-diagram]. The diagram maps the entire lifecycle from mission conception through retirement as a bidirectional process. The left side represents decomposition—flowing downward from mission needs through feasibility studies, concept of operations, system requirements, and progressively detailed design phases. The right side represents integration and verification—flowing upward through unit testing, subsystem verification, system verification, and validation back to operational requirements. The bottom contains development processes, timelines, and documentation activities.
The key insight of the V-diagram 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. Each level of decomposition (system → subsystem → unit) has a matching level of integration and testing, creating a balanced, verifiable development path [system-engineering-v-diagram].
Key Results: Design Review Checkpoints
The V-diagram is operationalized through a series of formal design reviews that serve as quality gates. These reviews ensure that design maturity increases progressively and that fundamental errors are caught early, when they are least costly to fix.
System Requirement Review (SRR)
The System Requirement Review occurs near the top of the V-diagram, before significant design effort is invested [system-requirement-review]. Its purpose is to validate that high-level mission needs have been correctly translated into derived system requirements. By verifying that lower-level derived requirements properly capture and decompose the original mission objectives, SRR prevents downstream rework and ensures the entire development effort remains aligned with stakeholder needs [system-requirement-review].
System Design Review (SDR)
Following SRR, the System Design Review bridges requirements and detailed design by examining high-level architectural decisions [system-design-review]. SDR assesses the allocation of system requirements to configuration items (subsystems, components), manufacturing considerations and feasibility, and planning for the next development phase. This review ensures that the proposed system decomposition is sound and that each requirement has been assigned to responsible subsystems [system-design-review].
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 proceed to final detailed design. The review confirms that the chosen approach is sound before investing in detailed specifications, drawings, and procurement, reducing risk by catching fundamental design flaws before they propagate into expensive detailed work [preliminary-design-review].
Critical Design Review (CDR)
The Critical Design Review is the final design review that certifies 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, and that the final design fulfills all specifications and commitments established at PDR [critical-design-review].
CDR occurs after detailed design is complete but before manufacturing begins. 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 [critical-design-review].
The Build-to Baseline
Once the Critical Design Review is complete, the approved detailed specifications become the Build-to Baseline [build-to-baseline]. This baseline contains all detailed specifications necessary to manufacture, assemble, integrate, and test the spacecraft to meet functional and performance requirements. Once approved, it becomes the single source of truth for the manufacturing and assembly teams. All drawings, specifications, and interface definitions are locked and controlled through formal change management processes [build-to-baseline].
Managing Uncertainty: TBD and TBC
Not all design details can be determined simultaneously. Two documentation markers help manage this reality: To Be Decided (TBD) and To Be Confirmed (TBC).
TBD indicates items where the decision-making process is still pending and the outcome is uncertain [to-be-decided-tbd]. TBD flags areas where active decision-making is required 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-decided-tbd].
TBC, by contrast, is used to flag items that are not yet finalized but are expected to be confirmed during development [to-be-confirmed-tbc]. TBC allows teams to proceed with design work while acknowledging that certain parameters, component selections, or performance values will be confirmed 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. This distinction between TBD and TBC is critical for maintaining clarity about which items represent genuine open decisions versus provisional values awaiting confirmation.
Conclusion
The system engineering framework—centered on the V-diagram and operationalized through formal design reviews—provides a structured approach to spacecraft development that prevents costly rework and maintains traceability from mission needs through final implementation. By establishing clear checkpoints where design maturity is validated and requirements are verified, this approach reduces risk and ensures that stakeholder objectives are met. The progression from SRR through SDR, PDR, and CDR creates a disciplined path from abstract mission concepts to concrete manufacturing specifications, with each review gate ensuring that the design remains sound and aligned with original objectives.
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 personal class notes from Spacecraft Design II. The AI was used to organize, paraphrase, and structure the material for clarity and coherence. All factual claims are cited to the original notes. The author retains responsibility for the accuracy and interpretation of the content.