Spacecraft Design II: The V-Diagram Framework and Design Review Gates

Abstract

Spacecraft development is a complex, multi-phase process where requirements must flow seamlessly from mission objectives through detailed design and into manufacturing. This article examines the System Engineering V-Diagram and the formal design review gates that structure this process, with emphasis on how decomposition and verification activities maintain traceability and prevent costly rework. Understanding these frameworks is essential for engineers managing complex spacecraft projects.

Background

Spacecraft projects face a fundamental challenge: translating high-level mission needs into detailed hardware and software specifications while ensuring nothing is lost in translation. Without a structured approach, teams risk building systems that fail to meet original objectives, discovering critical flaws only after significant investment.

The System Engineering V-Diagram addresses this challenge by establishing a bidirectional development path ^{[system-engineering-v-diagram]}. The left side of the V represents decomposition—breaking mission needs into progressively more detailed requirements and designs. The right side represents integration and verification—building components, testing them, and reassembling them while confirming each level meets its corresponding requirements. The bottom of the V contains the actual development work: manufacturing, assembly, and integration activities.

This structure embodies a core principle: every requirement defined during decomposition must have a matching verification activity during integration. This traceability prevents requirements from being lost and ensures the final product actually solves the original problem.

Key Results

The Design Review Gate System

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

System Requirement Review (SRR) 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. By catching misinterpretations early, SRR prevents downstream rework when changes are least costly. This review acts as a checkpoint before significant design effort is invested.

System Design Review (SDR) follows SRR and bridges requirements and detailed design ^{[system-design-review]}. SDR evaluates how system requirements have been allocated across configuration items (subsystems and components) and assesses manufacturing feasibility. This review ensures the proposed system decomposition is sound and that each requirement has been assigned to responsible subsystems. It prevents architectural mistakes that would be expensive to correct later.

Preliminary Design Review (PDR) represents a major commitment point ^{[preliminary-design-review]}. By this stage, trade studies are complete, technologies have been selected, and preliminary designs exist for all major subsystems. PDR demonstrates that the chosen 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 detailed implementation.

Critical Design Review (CDR) is the final design review ^{[critical-design-review]}. It certifies that the detailed design is complete, correct, and ready for manufacturing. CDR ensures the "build-to" baseline contains all specifications necessary to manufacture and assemble the spacecraft. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft. Changes after CDR are exponentially more expensive because they may require rework of already-manufactured components.

The Build-to Baseline

The build-to baseline is the approved, detailed set of hardware and software specifications established at CDR ^{[build-to-baseline]}. It serves as 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. This baseline prevents ambiguity, ensures consistency across manufacturing activities, and provides traceability from requirements through the final product.

Managing Uncertainty: TBD and TBC

During design development, not all details can be determined simultaneously. Two markers help teams manage this uncertainty.

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 requiring active decision-making before design can be considered complete. In spacecraft design, TBDs are tracked rigorously because unresolved decisions cascade into schedule delays and design conflicts. Design reviews require that TBDs be minimized and justified.

To Be Confirmed (TBC) indicates items that are not yet finalized but are expected to be confirmed during development ^{[to-be-confirmed-tbc]}. Unlike TBD, TBC assumes an existing value or approach that will be validated later through analysis, testing, or vendor feedback. Using TBC explicitly in documentation maintains traceability and ensures stakeholders understand which items are provisional versus firm commitments.

Worked Example: Requirement Traceability Through the V-Diagram

Consider a communications satellite with a mission requirement: "The spacecraft shall transmit data at 100 Mbps to ground stations."

Left side (decomposition):

• Mission need: High-bandwidth Earth observation data downlink
• System requirement: Transmit 100 Mbps
• Subsystem requirements: RF subsystem must generate 100 Mbps signal; power subsystem must supply 500 W to RF amplifier; thermal subsystem must dissipate 300 W waste heat
• Component specifications: Amplifier model X with 50 W output; modulator with 100 Mbps throughput; power supply rated 600 W

Right side (integration/verification):

• Unit test: Verify amplifier produces 50 W at specified frequency
• Subsystem test: Verify RF subsystem generates 100 Mbps signal with required modulation
• System test: Verify spacecraft transmits 100 Mbps to ground station in thermal vacuum
• Validation: Confirm mission data downlink meets 100 Mbps requirement in orbit

Each level of decomposition has a matching verification activity. If the system test reveals the RF subsystem only achieves 95 Mbps, traceability allows engineers to trace back through subsystem and component specifications to identify the root cause—perhaps the amplifier specification was insufficient, or the modulator has latency not accounted for in the original decomposition.

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). All factual claims are cited to source notes. The worked example is illustrative and not drawn from a specific project. The author reviewed and verified all technical content for accuracy.