Spacecraft Design II: Real-World Engineering Case Studies

Abstract

Spacecraft development is a high-stakes, irreversible process where early design decisions propagate downstream with exponential cost consequences. This article examines the System Engineering V Diagram as a practical framework for managing that complexity, and traces how formal design reviews enforce traceability from mission needs through manufacturing. Using real-world checkpoints and baselines, we show how structured decomposition and verification prevent costly rework and ensure alignment between what is built and what was promised.

Background

Spacecraft are among the most complex engineered systems: they must operate in an unforgiving environment, cannot be easily repaired, and often represent years of investment and institutional knowledge. Unlike terrestrial systems, a design flaw discovered after launch is not a problem to be patched—it is a mission failure.

This reality has driven the aerospace industry to adopt rigorous systems engineering practices. The most widely used framework is the System Engineering V Diagram ^{[system-engineering-v-diagram]}, which structures the entire lifecycle from conception to retirement as a bidirectional process. The left side of the V represents decomposition: breaking down mission needs into feasible requirements and progressively detailed designs. The right side represents integration and verification: building up from unit tests through subsystem and system verification back to operational validation. The bottom of the V contains the actual development work—manufacturing, assembly, and integration.

The power of the V-diagram lies in its enforced symmetry. Every requirement defined on the left must have a corresponding verification activity on the right. This prevents the common pitfall of building something that technically works but does not meet the original mission objectives.

Key Results: The Design Review Hierarchy

Spacecraft development is gated by formal design reviews, each serving a distinct purpose in the decomposition and verification process.

System Requirement Review (SRR)

The System Requirement Review ^{[system-requirement-review]} occurs near the top of the V-diagram, after mission needs have been translated into derived system requirements but before significant design effort is invested. SRR validates that lower-level requirements properly capture the original mission objectives. By catching misinterpretations early, when changes are least costly, SRR acts as a quality gate that prevents downstream rework and ensures the entire development effort remains aligned with stakeholder intent.

System Design Review (SDR)

Following SRR, the System Design Review ^{[system-design-review]} bridges requirements and detailed design by examining how system requirements have been allocated across the spacecraft's configuration items—its subsystems and major components. SDR also assesses manufacturing feasibility and planning for the next 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 ^{[preliminary-design-review]} represents a significant commitment point. 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," reducing risk by catching fundamental design flaws before they propagate into expensive detailed work.

Critical Design Review (CDR)

The Critical Design Review ^{[critical-design-review]} is the final design review, occurring after detailed design is complete but before manufacturing begins. CDR certifies that the "build-to" baseline—the approved, detailed set of hardware and software specifications ^{[build-to-baseline]}—is complete, correct, and ready for manufacturing and assembly. 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.

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 baseline prevents ambiguity, ensures consistency across all manufacturing activities, and provides traceability from requirements through final product.

Any changes to the baseline after CDR must go through formal change control to assess impacts and maintain configuration integrity. This discipline is not bureaucratic overhead—it is the mechanism that prevents a small change in one subsystem from silently breaking another, or from introducing a requirement violation that would not be discovered until on-orbit.

Documentation Discipline: TBD and TBC

Two simple markers—TBD (To Be Decided) and TBC (To Be Confirmed)—are critical to managing uncertainty in spacecraft design.

A TBD ^{[to-be-decided-tbd]} indicates that a decision has not yet been made and the outcome is uncertain. TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts. Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline.

A TBC ^{[to-be-confirmed-tbc]}, by contrast, indicates an item that is not yet finalized but is expected to be confirmed during development. 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 distinction—between decisions still pending (TBD) and values expected to be confirmed (TBC)—maintains traceability and ensures stakeholders understand which items are provisional versus firm commitments.

Why This Matters

The V-diagram and its associated reviews are not optional formality. They exist because spacecraft development has a long history of expensive failures caused by:

• Requirement creep: Mission needs that were never formally captured or traced through design
• Architectural mistakes: High-level design decisions that seemed sound but created unforeseen conflicts downstream
• Manufacturing surprises: Designs that were theoretically correct but practically impossible to build
• Integration failures: Subsystems that worked independently but failed when combined

Each design review is a checkpoint that reduces one of these risks. SRR prevents requirement creep. SDR catches architectural mistakes. PDR validates feasibility before detailed design. CDR ensures manufacturability before fabrication begins.

The cost of a design change increases exponentially as the project progresses. A requirement clarification at SRR might cost a few engineering hours. The same clarification discovered at PDR might require redesign of multiple subsystems. Discovered at CDR, it may require canceling procurement orders and reworking detailed drawings. Discovered after launch, it is a mission failure.

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 structure the material, paraphrase content, and ensure logical flow. All factual claims are sourced from the original notes and cited explicitly. The author reviewed the final text for technical accuracy and relevance.