Spacecraft Design II: System Engineering and Design Review Frameworks
Abstract
Spacecraft development is a complex, multi-phase endeavor requiring rigorous alignment between mission objectives and implementation. This article examines the system engineering V-diagram and the formal design review process that structures spacecraft projects from concept through manufacturing. We discuss how requirements flow through decomposition and verification phases, and how design reviews serve as quality gates at critical junctures. The framework presented here is foundational to modern aerospace practice and essential for managing risk and cost in large-scale projects.
Background
Spacecraft design is not a linear process. Early decisions about mission needs must propagate through multiple levels of abstraction—from high-level objectives to subsystem specifications to individual component selections—and then be verified at each level before integration. Without a structured approach, requirements can be lost, misinterpreted, or left unverified, leading to costly rework or mission failure.
The system engineering discipline emerged to address this challenge. A core tool in this discipline is the System Engineering V-diagram [system-engineering-v-diagram], which maps the entire lifecycle of a spacecraft from conception through retirement. The diagram's structure reflects a fundamental principle: every requirement defined during the decomposition phase must have a corresponding verification activity during integration and testing.
The left side of the V represents decomposition—the progressive breakdown of mission needs into feasible, detailed requirements and designs. The right side represents integration and verification—the assembly and testing of components, subsystems, and the complete system to confirm they meet the original objectives. The bottom of the V contains the actual development work: design, manufacturing, assembly, and testing activities.
This bidirectional structure prevents a common pitfall in complex projects: building something that technically meets the specifications but fails to satisfy the original mission. By ensuring traceability between requirements and verification, the V-diagram keeps the entire team aligned.
Key Results: Design Review Framework
Spacecraft projects use formal design reviews as quality gates. Each review occurs at a specific point in the development lifecycle and has distinct objectives. Understanding these reviews is essential for managing risk and controlling cost.
System Requirement Review (SRR)
The System Requirement Review [system-requirement-review] is an early checkpoint that validates the translation of high-level mission needs into derived system requirements. It occurs near the top of the V-diagram, before significant design investment. The review ensures that lower-level derived requirements properly capture and decompose the original mission objectives. By catching misinterpretations or gaps early, SRR prevents downstream rework and keeps the development effort aligned with stakeholder needs.
System Design Review (SDR)
Following SRR, the System Design Review [system-design-review] bridges requirements and detailed design. It evaluates how system requirements have been allocated across the spacecraft's configuration items (subsystems and components) and assesses manufacturing feasibility. SDR ensures that the proposed system decomposition is sound and that each requirement has been assigned to responsible subsystems. This review prevents architectural mistakes that would be expensive to correct later.
Preliminary Design Review (PDR)
The Preliminary Design Review [preliminary-design-review] is a major milestone demonstrating that the proposed design approach is feasible and mature enough to proceed to final detailed design. By this stage, the design team has completed trade studies, selected technologies, and developed preliminary designs for all major subsystems. PDR confirms that the chosen approach is sound before investing in detailed specifications, drawings, and procurement. It is the last major review before the design is "locked down" for final implementation.
Critical Design Review (CDR)
The Critical Design Review [critical-design-review] is the final design review, certifying that the detailed design is complete, correct, and ready for manufacturing and assembly. CDR ensures that the "build-to" baseline [build-to-baseline] contains detailed hardware and software specifications capable of meeting all functional and performance requirements. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft. Changes after CDR are exponentially more expensive, making this review critical.
The Build-to Baseline and Configuration Control
Once the build-to baseline is approved at CDR, it becomes the single source of truth for manufacturing and assembly teams [build-to-baseline]. All drawings, specifications, and interface definitions are locked and controlled through formal change management processes. This prevents ambiguity, ensures consistency across all manufacturing activities, and provides traceability from requirements through final product.
Documentation Markers: TBD and TBC
In practice, not all design details can be determined simultaneously. Two documentation markers are used to flag unresolved items:
To Be Decided (TBD) [to-be-decided-tbd] indicates items where the decision-making process is still pending and the outcome is uncertain. TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts.
To Be Confirmed (TBC) [to-be-confirmed-tbc] indicates items that are not yet finalized but are expected to be confirmed during development. Unlike TBD, TBC assumes an existing value or approach that will be validated later through analysis, testing, or vendor feedback.
Design reviews, particularly CDR, require that TBDs be minimized and justified. This ensures the project moves toward a locked baseline and prevents indefinite deferral of critical decisions.
Practical Implications
The design review framework serves multiple functions:
-
Risk management: Each review reduces uncertainty by validating that the design approach is sound before proceeding to the next phase.
-
Cost control: Early detection of flaws is far less expensive than discovering them during manufacturing or testing.
-
Traceability: The reviews ensure that every requirement has a corresponding design specification and verification plan.
-
Stakeholder alignment: Formal reviews provide checkpoints where stakeholders can assess progress and confirm that the project remains aligned with mission objectives.
-
Documentation and knowledge: The review process generates formal records that serve as project history and support future missions.
Conclusion
The system engineering V-diagram and associated design review framework represent decades of aerospace industry experience. By structuring spacecraft development as a bidirectional process—decomposing requirements on the left side and verifying them on the right—the framework ensures that mission objectives are not lost in the complexity of implementation. The formal design reviews (SRR, SDR, PDR, CDR) serve as quality gates, each with distinct objectives and each reducing risk before the next phase begins. For spacecraft designers and project managers, understanding and applying this framework is essential for delivering systems that meet mission requirements on schedule and within budget.
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 grounded in the original notes and cited accordingly. The author retains responsibility for the accuracy and interpretation of the content.