Spacecraft Design II: Real-World Engineering Case Studies

Abstract

Spacecraft development demands rigorous, structured processes to manage complexity and reduce risk. This article examines the System Engineering V Diagram framework and its associated design review checkpoints—System Requirement Review, System Design Review, Preliminary Design Review, and Critical Design Review—as they apply to real-world spacecraft projects. We explore how each review gate enforces traceability between mission requirements and final specifications, and how the build-to baseline locks the design before manufacturing begins.

Background

Complex systems like spacecraft cannot be designed, built, and validated in a linear sequence. Requirements emerge from mission needs; designs must be decomposed into subsystems; each subsystem must be verified; and all subsystems must be integrated and validated against the original mission objectives. Without a structured framework, this bidirectional flow of information becomes chaotic, requirements are lost, and expensive rework occurs late in development.

The System Engineering V Diagram provides a visual and conceptual model for managing this complexity ^{[system-engineering-v-diagram]}. The left side of the V represents decomposition—breaking down mission needs into progressively detailed requirements and designs. The right side represents integration and verification—combining subsystems and testing them against requirements at each level. The bottom of the V contains the actual development activities: detailed design, manufacturing, assembly, and testing.

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 requirements from being lost during implementation ^{[system-engineering-v-diagram]}.

Key Results: Design Review Checkpoints

Spacecraft development is punctuated by formal design reviews that serve as quality gates. Each review occurs at a specific point in the V-diagram and has distinct objectives.

System Requirement Review (SRR)

The 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 ^{[system-requirement-review]}. SRR validates that derived requirements properly capture and decompose the original mission objectives. Its purpose is to catch misinterpretations or gaps in requirements translation early, when changes are least costly ^{[system-requirement-review]}.

System Design Review (SDR)

Following SRR, the System Design Review bridges requirements and detailed design by examining how system requirements have been allocated across the spacecraft's configuration items (subsystems and components) ^{[system-design-review]}. SDR also assesses manufacturing feasibility and plans for the next development phase. This review prevents architectural mistakes that would be expensive to correct later ^{[system-design-review]}.

Preliminary Design Review (PDR)

The Preliminary Design Review is a major commitment gate where the design team demonstrates that the proposed design approach is feasible and mature enough to proceed to final detailed design ^{[preliminary-design-review]}. By PDR, trade studies have been completed, technologies have been selected, and preliminary designs for all major subsystems have been developed. The review confirms that the chosen approach is sound before investing in detailed specifications, drawings, and procurement ^{[preliminary-design-review]}.

Critical Design Review (CDR)

The Critical Design Review is the final design review, occurring after detailed design is complete but 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 ^{[critical-design-review]}.

After CDR approval, the design is "frozen" and becomes the authoritative baseline for building the spacecraft ^{[critical-design-review]}. This is critical because changes after CDR are exponentially more expensive, as they may require rework of manufacturing plans, tooling, and already-produced components.

The Build-to Baseline

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]}. It is formally established and approved at Critical Design Review and contains all detailed specifications necessary to manufacture, assemble, integrate, and test the spacecraft ^{[build-to-baseline]}.

Once approved, the build-to baseline 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 ^{[build-to-baseline]}. This prevents ambiguity, ensures consistency across all manufacturing activities, and provides traceability from requirements through final product.

Documentation Discipline: TBD and TBC

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

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.

To Be Confirmed (TBC) flags items that are not yet finalized but are 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.

Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline ^{[to-be-decided-tbd]}.

Practical Implications

The V-diagram framework and its associated review gates enforce several critical practices:

1. Traceability: Every requirement must be traced through design decisions to final specifications and verification activities. This prevents requirements from being lost or misinterpreted.

2. Risk reduction: Early reviews (SRR, SDR, PDR) catch fundamental flaws before expensive detailed work or manufacturing begins. Each review reduces risk by validating assumptions and locking down decisions at the appropriate level of maturity.

3. Configuration control: The build-to baseline, approved at CDR, becomes the single source of truth. All subsequent changes are managed through formal change control, maintaining integrity and auditability.

4. Cost management: By catching errors early and preventing scope creep after CDR, the V-diagram approach minimizes rework and change orders—the primary drivers of cost overruns in spacecraft projects.

5. Stakeholder alignment: Formal reviews ensure that mission stakeholders, design teams, manufacturing teams, and quality assurance all understand and agree on requirements, design decisions, and acceptance criteria.

References

• ^{[system-engineering-v-diagram]}
• ^{[system-requirement-review]}
• ^{[system-design-review]}
• ^{[preliminary-design-review]}
• ^{[critical-design-review]}
• ^{[build-to-baseline]}
• ^{[critical-design-review]}
• ^{[preliminary-design-review]}
• ^{[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 completeness of citations.