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

Abstract

Spacecraft development is a complex, multi-phase endeavor requiring rigorous alignment between mission objectives and implementation. This article examines the System Engineering V-Diagram as a structural framework for spacecraft design and traces the sequence of formal design reviews that serve as quality gates throughout development. By understanding how requirements decompose on the left side of the V and how integration and verification flow upward on the right, engineers can maintain traceability and prevent costly rework. We illustrate this framework through the progression of reviews from System Requirement Review through Critical Design Review, emphasizing the role of each checkpoint in locking down design baselines.

Background

Spacecraft projects operate under severe constraints: cost, schedule, and technical risk must be balanced simultaneously, and changes late in development are exponentially more expensive than early corrections. The aerospace industry has developed formal processes to manage this complexity. The System Engineering V-Diagram ^{[system-engineering-v-diagram]} provides a conceptual map of the entire spacecraft lifecycle, from mission conception through retirement, organized as a bidirectional flow.

The left side of the V 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 the actual development work—manufacturing, assembly, and testing activities.

The key insight is that every requirement defined on the left must have a corresponding verification activity on the right. This ensures traceability and prevents requirements from being lost during implementation. Each level of decomposition (system → subsystem → unit) has a matching level of integration and testing, creating a balanced, verifiable development path.

Design Review Checkpoints

Formal design reviews serve as quality gates that prevent the project from advancing until critical milestones are met. Four major reviews structure the spacecraft design 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 derived requirements properly capture and decompose the original mission objectives.

The value of SRR lies in its timing. By catching misinterpretations or gaps in requirements translation early, when changes are least costly, the review prevents downstream rework and ensures the entire development effort remains aligned with stakeholder needs. It acts as a quality gate before proceeding to detailed system design.

System Design Review (SDR)

Following SRR, the System Design Review ^{[system-design-review]} bridges requirements and detailed design by examining high-level architectural decisions. SDR assesses:

• Allocation of system requirements to configuration items (subsystems, components)
• Manufacturing considerations and feasibility
• Planning for the next development phase

SDR ensures that the proposed system decomposition is sound, that each requirement has been assigned to responsible subsystems, and that manufacturing constraints have been considered early. This prevents architectural mistakes that would be expensive to correct later.

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 objectives are:

• Show that the proposed design is expected to meet all functional and performance requirements
• Demonstrate sufficient maturity in the design approach to justify proceeding to final detailed design

PDR is the last major review before the design is "locked down" for final implementation. It reduces 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 that certifies the detailed design is complete, correct, and ready for manufacturing and assembly. CDR ensures:

• The "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements
• The final design fulfills all specifications and commitments established at PDR

CDR occurs after detailed design is complete but before manufacturing begins. 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

Once the build-to baseline ^{[build-to-baseline]} is approved at CDR, 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. 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 essential because changes late in development cascade through manufacturing, assembly, integration, and test schedules.

Documentation Markers: TBD and TBC

During design development, not all details can be determined simultaneously. Two documentation markers help teams manage uncertainty while maintaining rigor.

To Be Decided (TBD) ^{[to-be-decided-tbd]} flags items where the decision-making process itself is still pending and the outcome is uncertain. TBDs are tracked rigorously because unresolved decisions can cascade into schedule delays and design conflicts.

To Be Confirmed (TBC) ^{[to-be-confirmed-tbc]} indicates an item that is not yet finalized but is expected to be confirmed during development. Unlike TBD, TBC assumes an existing value or approach that will be validated later through analysis, testing, or vendor feedback.

Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. By the time CDR is complete, the vast majority of TBDs should be resolved, and remaining items must be explicitly justified and tracked.

Key Results

The V-diagram framework and associated design reviews create several critical outcomes:

1. Traceability: Every mission requirement can be traced downward through system requirements, subsystem specifications, and component designs, and upward through unit testing, subsystem verification, and system validation.

2. Early error detection: By validating requirements at SRR and architectural decisions at SDR, the process catches misalignments before design effort is invested.

3. Controlled commitment: Each review (SRR, SDR, PDR, CDR) represents an explicit commitment to proceed to the next phase, reducing the risk of building the wrong thing or building it wrong.

4. Cost management: Changes are least expensive early in development. By locking requirements at SRR and design at CDR, the process minimizes expensive late-stage rework.

5. Configuration integrity: The build-to baseline, established at CDR, provides a single authoritative reference for manufacturing and prevents ambiguity or inconsistency.

Conclusion

The System Engineering V-Diagram and its associated design reviews form the backbone of rigorous spacecraft development. By structuring the project as a symmetric flow of decomposition and integration, with formal checkpoints at each level, the process ensures that mission needs are translated into verifiable designs and that the final product meets its intended purpose. Understanding these frameworks is essential for any engineer involved in spacecraft design, whether at the system level or in detailed subsystem work.

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 structure, synthesis, and explanatory text were generated by an AI language model based on the provided notes. The author is responsible for accuracy and has reviewed all citations.