Spacecraft Design II: Systems Engineering and Design Review Frameworks

Abstract

Spacecraft development is a high-stakes, irreversible process where design errors discovered late in the project cycle become exponentially more expensive to correct. This article examines the structured frameworks and formal review checkpoints that govern modern spacecraft design, with emphasis on the System Engineering V-Diagram and the sequence of design reviews that validate progress from mission concept through manufacturing readiness. These mechanisms ensure traceability between mission requirements and final specifications while managing risk through staged commitment and formal verification.

Background

Spacecraft are among the most complex engineered systems, combining mechanical, electrical, thermal, propulsive, and software subsystems under extreme constraints of mass, power, and reliability. Unlike terrestrial systems where prototyping and iteration are feasible, spacecraft often represent single or few-unit production runs where the first unit must function correctly in an environment that cannot be easily accessed for repair.

This reality has driven the aerospace industry to adopt rigorous systems engineering disciplines. The core challenge is bidirectional: requirements must flow downward from mission objectives into detailed design specifications, and verification must flow upward from component testing through subsystem and system validation back to mission success criteria. Without structured frameworks, requirements become lost, verification activities fail to address actual needs, and the final product diverges from stakeholder intent.

The System Engineering V-Diagram

The System Engineering V-Diagram provides the foundational architecture for this bidirectional process ^{[system-engineering-v-diagram]}. The diagram's left side represents decomposition: mission needs flow downward through feasibility studies, concept of operations, system requirements, and progressively finer 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 development processes, timelines, and documentation activities.

The V-shape itself encodes a critical principle: 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 to subsystem to unit—has a matching level of integration and testing, creating a balanced, verifiable development path.

Design Review Checkpoints

Spacecraft development proceeds through a sequence of formal design reviews, each serving as a quality gate and commitment point.

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]}. SRR validates that derived requirements properly decompose and capture the high-level system requirements established during mission definition. By catching misinterpretations or gaps in requirements translation early, when changes are least costly, SRR prevents downstream rework and ensures the entire development effort remains aligned with stakeholder needs.

System Design Review (SDR)

Following SRR, the System Design Review bridges requirements and detailed design ^{[system-design-review]}. SDR assesses the allocation of system requirements to configuration items (subsystems and components), evaluates manufacturing feasibility, and confirms readiness for the next development phase. 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 represents a significant commitment point ^{[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 is the last major review before the design is "locked down" for final implementation, reducing 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 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, and that the final design fulfills all specifications and commitments established at PDR. 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.

Configuration Management and Baselines

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 detailed specifications necessary to manufacture, assemble, integrate, and test the spacecraft. Once approved, it 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, preventing ambiguity and ensuring consistency across all manufacturing activities.

Documentation Markers: TBD and TBC

In practice, not all design details can be determined simultaneously. Two documentation markers manage this reality.

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 Confirmed (TBC) indicates an item that is not yet finalized but is 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. This is distinct from TBD, which implies the decision-making process itself is still pending.

Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. TBC items, by contrast, represent provisional values that are expected to converge to firm specifications through normal development activities.

Key Insights

The design review framework achieves several objectives simultaneously:

1. Traceability: Every mission requirement can be traced downward to a design specification and upward through verification activities back to mission success criteria.

2. Risk management: Formal reviews at defined maturity gates prevent premature commitment to detailed design and manufacturing before fundamental feasibility is established.

3. Cost control: Catching errors early—at SRR or SDR—costs orders of magnitude less than discovering them after CDR or during manufacturing.

4. Stakeholder alignment: Each review includes representatives from requirements, design, manufacturing, test, and mission operations, ensuring diverse perspectives are considered before proceeding.

5. Configuration integrity: The build-to baseline and formal change control prevent design drift and ensure the final product matches approved specifications.

This framework is not bureaucratic overhead; it is the mechanism by which complex, irreversible systems are built correctly on the first attempt.

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 AI assistance from class notes (Zettelkasten) compiled during Spacecraft Design II coursework. The AI was instructed to paraphrase note content, cite all factual claims, and avoid inventing results not present in the source material. All mathematical and technical claims are grounded in the cited notes. The author reviewed the output for accuracy and technical coherence before publication.