Spacecraft Design II: The System Engineering V Diagram and Design Review Framework

Abstract

The System Engineering V Diagram provides a structured lifecycle framework for spacecraft development, mapping decomposition of mission needs into detailed design on the left side and corresponding integration and verification activities on the right. This article derives the logical flow of design reviews—System Requirement Review, System Design Review, Preliminary Design Review, and Critical Design Review—that enforce traceability and prevent requirements from being lost during implementation. We examine how each review gates progression to the next phase and how the build-to baseline emerges as the authoritative reference for manufacturing.

Background

Spacecraft development is inherently complex: a single mission requirement may decompose into dozens of subsystem specifications, each of which spawns component-level designs. Without a structured framework, requirements can be misinterpreted, lost, or implemented incorrectly. The System Engineering V Diagram addresses this by establishing a bidirectional process that mirrors decomposition with integration and verification ^{[system-engineering-v-diagram]}.

The left side of the V represents the decomposition phase: mission needs flow downward through feasibility studies, concept of operations, system requirements, and progressively detailed 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 that support both sides.

The key insight is that every requirement defined on the left side must have a corresponding verification activity on the right side. This ensures traceability and prevents the common pitfall of building something that does not meet the original mission needs. Each level of decomposition (system → subsystem → unit) has a matching level of integration and testing, creating a balanced, verifiable development path.

Key Results: The Design Review Sequence

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 capture and decompose the original mission objectives. By catching misinterpretations or gaps in requirements translation early, SRR 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 bridges requirements and detailed design by examining high-level architectural decisions ^{[system-design-review]}. SDR assesses:

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

This review 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. It prevents architectural mistakes that would be expensive to correct later.

Preliminary Design Review (PDR)

The Preliminary Design Review represents a significant commitment point in the development timeline ^{[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:

• The proposed design is expected to meet all functional and performance requirements
• 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 is the final design review that certifies the detailed design is complete, correct, and ready for manufacturing and assembly ^{[critical-design-review]}. 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 and Configuration Control

Once the build-to baseline is approved at CDR, it becomes the single source of truth for the 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 essential because post-CDR changes are exponentially more expensive than design-phase corrections.

Documentation Markers: TBD and TBC

During design development, not all details can be determined simultaneously. Two markers are used to flag unresolved 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 Confirmed (TBC) indicates items that are not yet finalized but are expected to be confirmed during development ^{[to-be-confirmed-tbc]}. 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. TBCs are acceptable if confirmation is scheduled and tracked, but they must be resolved before manufacturing begins.

Conclusion

The System Engineering V Diagram and its associated design reviews create a disciplined framework that prevents requirements from being lost or misinterpreted during spacecraft development. Each review gates progression to the next phase and enforces traceability from mission needs through detailed design to manufacturing. The build-to baseline that emerges from CDR provides the authoritative reference for implementation, and formal change control ensures that any post-CDR modifications are carefully assessed and documented. This structured approach reduces risk, prevents costly rework, and increases the probability that the final spacecraft will actually perform its intended mission.

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 class notes from Spacecraft Design II. The AI was used to organize, paraphrase, and structure the material for clarity and coherence. All factual claims are cited to the original notes. The author reviewed and validated all content for technical accuracy.