Spacecraft Design II: An Overview of Systems Engineering and Design Review Processes
Abstract
This article synthesizes core concepts from a Spacecraft Design II course, focusing on the systems engineering framework and formal design review process that structure spacecraft development. The V-diagram model provides a conceptual backbone for understanding how requirements decompose into detailed designs and then integrate back through verification and validation. Four major design reviews—System Requirement Review, System Design Review, Preliminary Design Review, and Critical Design Review—serve as quality gates that progressively lock down the design baseline. Together, these elements form a disciplined approach to managing complexity and reducing risk in spacecraft projects.
Background
Spacecraft development is inherently complex: a single system must integrate hundreds of subsystems and thousands of components, each with interdependent requirements and constraints. Without a structured development framework, requirements can be lost, interfaces can conflict, and designs can diverge from mission objectives. The systems engineering V-diagram and formal design review process address this challenge by imposing a disciplined, bidirectional flow from mission needs through detailed design and back through verification.
The System Engineering V-Diagram
The V-diagram is a conceptual model that maps the entire spacecraft lifecycle [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: detailed designs flow upward through unit testing, subsystem verification, system verification, and validation back to operational requirements. The bottom of the V 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 [system-engineering-v-diagram]. This ensures traceability and prevents requirements from being lost during implementation. Each level of decomposition—system to subsystem to unit—has a matching level of integration and testing, creating a balanced, verifiable development path.
Key Results: The Design Review Process
Spacecraft development proceeds through a series of formal design reviews that serve as quality gates. Each review validates that the design has matured sufficiently to proceed to the next phase and that requirements remain properly allocated and traceable.
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 derived requirements properly translate high-level mission needs into actionable system specifications. 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 the allocation of system requirements to configuration items (subsystems and components), manufacturing feasibility, and planning for the next development phase [system-design-review]. 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.
Preliminary Design Review (PDR)
The Preliminary Design Review is a major milestone that demonstrates the proposed design approach is feasible and mature enough to proceed to final detailed design [preliminary-design-review]. 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 [preliminary-design-review]. It represents a significant commitment point: passing PDR signals confidence that the team understands the problem and has a viable solution path.
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 [critical-design-review]. After CDR approval, the design is "frozen" and becomes the authoritative baseline for building the spacecraft. This review is critical because changes after CDR are exponentially more expensive.
The Build-to Baseline
The build-to baseline is the approved, detailed set of hardware and software specifications that serves as the authoritative reference for manufacturing and assembly of the spacecraft [build-to-baseline]. It is formally established and approved at Critical Design Review and contains all detailed specifications necessary to manufacture, assemble, integrate, and test the spacecraft to meet functional and performance requirements [build-to-baseline].
Once the build-to baseline is approved, 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 baseline prevents ambiguity, ensures consistency across all manufacturing activities, and provides traceability from requirements through final product [build-to-baseline].
Documentation Status: TBD and TBC
During design development, not all details can be determined simultaneously. Two markers are used to flag incomplete items:
To Be Decided (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 [to-be-decided-tbd]. In spacecraft design, TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts.
To Be Confirmed (TBC) indicates 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 [to-be-decided-tbd].
Conclusion
The systems engineering V-diagram and formal design review process provide a disciplined framework for managing spacecraft development complexity. By decomposing mission needs into detailed designs on the left side of the V and integrating them back through verification on the right side, this approach ensures traceability and prevents requirements from being lost. The four major design reviews—SRR, SDR, PDR, and CDR—serve as quality gates that progressively mature the design and reduce risk. The build-to baseline, locked at CDR, becomes the authoritative reference for manufacturing and ensures that what is built matches what was designed to meet mission needs.
References
- [system-engineering-v-diagram]
- [system-requirement-review]
- [system-design-review]
- [preliminary-design-review]
- [critical-design-review]
- [build-to-baseline]
- [critical-design-review]
- [preliminary-design-review]
- [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. The AI was instructed to paraphrase note content, verify all factual claims against source notes, and avoid inventing unsupported claims. All citations are explicit and traceable to the original notes. The author retains responsibility for accuracy and interpretation.