Spacecraft Design II: Requirements, Reviews, and the Path to Manufacturing
Abstract
Spacecraft development is a complex, multi-phase endeavor that demands rigorous traceability between mission objectives and final hardware. This article examines the structural framework and key checkpoints that govern spacecraft design, from initial requirement decomposition through manufacturing readiness. We focus on the System Engineering V Diagram as an organizing principle, the sequence of design reviews that validate progress, and the role of configuration baselines in preventing costly rework.
Background
The design of a spacecraft is not a linear sequence of activities but a carefully orchestrated process that balances decomposition (breaking down mission needs into detailed specifications) with integration and verification (assembling subsystems and confirming they meet requirements). Without a structured approach, teams risk building systems that fail to meet stakeholder needs, exceed budgets, or miss schedules.
The System Engineering V Diagram provides the conceptual framework for this balance [system-engineering-v-diagram]. The left side of the V represents decomposition: mission needs flow downward through feasibility studies, concept of operations, system requirements, and progressively more detailed design phases. The right side represents integration and verification: unit testing flows upward through subsystem verification, system verification, and validation back to operational requirements. The bottom of the V contains the actual development work—manufacturing, assembly, and integration 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: The Design Review Sequence
Spacecraft development is punctuated by formal design reviews that serve as quality gates and commitment points. These reviews occur at specific points along the V-diagram and ensure that the design matures in a controlled, traceable manner.
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 catching misinterpretations or gaps in requirements translation early, 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 how system requirements have been allocated across the spacecraft's configuration items (subsystems and components) and evaluates manufacturing feasibility. 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 [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 justify proceeding to final detailed design. It reduces 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, 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. It 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. Changes after CDR are exponentially more expensive because they may require rework of manufacturing tooling, procurement, or already-fabricated components [critical-design-review].
The Build-to Baseline and Configuration Management
Once the build-to baseline is approved at CDR, it becomes the single source of truth for the manufacturing and assembly teams [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 [build-to-baseline].
Any changes to the baseline after CDR must go through formal change control to assess impacts and maintain configuration integrity. This disciplined approach protects the project from scope creep and unintended consequences of late-stage modifications.
Managing Uncertainty: TBD and TBC
Not all details can be determined simultaneously during spacecraft design. Two key documentation markers help teams manage this uncertainty while maintaining traceability.
To Be Decided (TBD) flags items where the decision-making process is still pending and the outcome is uncertain [to-be-decided-tbd]. TBD indicates that the actual choice or direction has not been determined. In spacecraft design, TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts [to-be-decided-tbd].
To Be Confirmed (TBC) indicates an item that is not yet finalized but is expected to be confirmed during development [to-be-confirmed-tbc]. Unlike TBD, TBC assumes confirmation of an existing value—for example, a component selection that is pending vendor feedback or a performance parameter that will be verified through analysis or testing [to-be-confirmed-tbc].
Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. TBCs are more acceptable at CDR because they represent expected confirmations rather than open decisions.
Conclusion
The spacecraft design process is fundamentally about managing the translation of mission needs into hardware specifications while maintaining rigorous traceability and verification. The System Engineering V Diagram provides the conceptual framework; the sequence of design reviews (SRR, SDR, PDR, CDR) provides the checkpoints; and configuration management provides the discipline to prevent costly rework.
By understanding this structure, spacecraft design teams can navigate the inherent complexity of their work, catch errors early when they are least expensive to fix, and deliver systems that actually meet their intended mission 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. All factual claims are cited to source notes. The structure, synthesis, and explanatory text were generated by the AI; the underlying course material and technical content remain the author's responsibility.