Spacecraft Design II: Systems 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 foundational frameworks that govern spacecraft design: the System Engineering V Diagram and the sequence of formal design reviews that structure development from concept through manufacturing. These mechanisms ensure traceability, catch errors early, and prevent costly rework by enforcing bidirectional verification at each level of system decomposition.
Background
Spacecraft are among the most complex engineered systems, combining mechanical, electrical, thermal, and software subsystems under severe constraints of mass, power, and reliability. Unlike many terrestrial systems, spacecraft cannot be easily serviced or modified after launch, making design correctness paramount. The cost of fixing a design flaw grows exponentially as development progresses: changes caught during concept cost orders of magnitude less than those discovered after manufacturing begins.
To manage this complexity and cost risk, the aerospace industry has developed structured processes that enforce discipline and traceability throughout development. Two key frameworks guide this process: a conceptual model (the V Diagram) and a series of formal checkpoints (design reviews) that validate progress at critical junctures.
The System Engineering V Diagram
The System Engineering V Diagram provides a conceptual map of the entire spacecraft development lifecycle [system-engineering-v-diagram]. Rather than a linear sequence, the V-shape captures a fundamental principle: every requirement defined during the decomposition phase must have a corresponding verification activity during integration and validation.
The left side of the V represents decomposition—the progressive breakdown of mission needs into increasingly detailed requirements and designs. This flow begins with high-level mission objectives and flows downward through feasibility studies, concept of operations, system requirements, and subsystem design specifications. Each level of decomposition answers the question: "What must this element do?"
The right side represents integration and verification—the reassembly and testing of components to confirm they meet their requirements. This flow moves upward from unit testing through subsystem verification, system verification, and finally validation against operational requirements. Each level of integration answers: "Does this element do what was required?"
The critical insight is that the V-diagram prevents requirements from being lost or forgotten. A requirement that is defined on the left side without a corresponding verification activity on the right side represents a gap in the development process. Conversely, verification activities without corresponding requirements indicate scope creep or misalignment. The V-diagram enforces this bidirectional traceability [system-engineering-v-diagram].
Design Review Checkpoints
Formal design reviews serve as quality gates that validate progress before significant resources are committed to the next phase. Four major reviews structure the spacecraft design process:
System Requirement Review (SRR)
The System Requirement Review occurs early in development, near the top of the V-diagram [system-requirement-review]. Its purpose is to validate that high-level mission needs have been correctly translated into derived system requirements. SRR ensures that lower-level requirements properly capture and decompose the original mission objectives [system-requirement-review].
By conducting this review before detailed design begins, the project catches misinterpretations or gaps in requirements translation when changes are least costly. SRR acts as a quality gate that prevents the entire development effort from proceeding on a flawed foundation.
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 [system-design-review].
This review ensures that the proposed system decomposition is sound and that each requirement has been assigned to responsible subsystems. By considering manufacturing constraints early, SDR prevents architectural mistakes that would be expensive to correct later.
Preliminary Design Review (PDR)
The Preliminary Design Review is a major commitment point that demonstrates the proposed design approach is feasible and mature enough to proceed to final detailed design [preliminary-design-review]. By PDR, 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 [preliminary-design-review]. It reduces risk by catching fundamental design flaws before they propagate into expensive detailed work.
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 contains detailed hardware and software specifications capable of meeting all functional and performance requirements [critical-design-review].
CDR 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].
Configuration Baselines and Change Control
The build-to baseline is the approved, detailed set of hardware and software specifications that serves as the authoritative reference for manufacturing and assembly [build-to-baseline]. Established and approved at Critical Design Review, the build-to baseline contains all specifications necessary to manufacture, assemble, integrate, and test the spacecraft [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]. This prevents ambiguity, ensures consistency across manufacturing activities, and provides traceability from requirements through final product.
Documentation Markers: TBD and TBC
During design development, not all details can be determined simultaneously. Two documentation markers flag items that are not yet finalized:
To Be Decided (TBD) indicates items where the decision-making process itself 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 in that it assumes an existing value or approach will be confirmed, rather than a decision that must still be made [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].
Key Principles
The frameworks described above embody several core principles:
-
Early error detection: Catching errors during concept or preliminary design is far less costly than discovering them during manufacturing or operation.
-
Traceability: Every requirement must be traceable through design, verification, and validation. The V-diagram enforces this bidirectional traceability.
-
Formal checkpoints: Design reviews serve as quality gates that validate progress and prevent proceeding to the next phase with unresolved issues.
-
Configuration control: Once a baseline is approved, changes are managed through formal processes to maintain integrity and prevent unintended consequences.
-
Explicit uncertainty: Using markers like TBD and TBC makes uncertainty explicit rather than hidden, allowing stakeholders to understand which aspects of the design are firm versus provisional.
Conclusion
The System Engineering V Diagram and the sequence of formal design reviews provide a structured framework for managing the complexity of spacecraft development. By enforcing bidirectional traceability, conducting reviews at critical junctures, and controlling configuration baselines, these mechanisms reduce risk and prevent costly rework. While the specific details of these processes vary across organizations and programs, the underlying principles—early validation, explicit traceability, and formal change control—are fundamental to successful spacecraft design.
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, structure, and paraphrase the source material into a coherent scholarly format. All factual claims are cited to the original notes. The author is responsible for the accuracy and interpretation of the content.