Spacecraft Design II: System Engineering and Design Review Frameworks

Abstract

Spacecraft design is a complex, multidisciplinary endeavor that demands rigorous structure to prevent costly rework and ensure mission success. This article examines the foundational frameworks used in spacecraft design methodology, focusing on the System Engineering V Diagram and the sequence of formal design reviews that govern the transition from mission concept through manufacturing. These tools enforce traceability between requirements and verification activities, creating a balanced development path that reduces risk at each phase.

Background

Spacecraft projects operate under severe constraints: cost, schedule, and the irreversibility of launch. Unlike terrestrial systems where prototyping and iteration are economically feasible, spacecraft often represent singular or limited-production systems where design errors cannot be corrected post-launch. This reality has driven the aerospace industry to adopt formal systems engineering practices that emphasize early verification, clear requirement allocation, and staged maturity gates.

The System Engineering V Diagram provides the conceptual backbone for these practices ^{[system-engineering-v-diagram]}. Rather than a linear waterfall, the V-diagram represents a bidirectional process: the left side decomposes mission needs into progressively detailed requirements and designs, while the right side integrates and verifies those designs back against the original requirements. This symmetry ensures that every requirement defined during decomposition has a corresponding verification activity, preventing requirements from being lost or forgotten during implementation.

The formal design review process operationalizes this V-diagram structure through a series of gated checkpoints. Each review validates that the design has matured sufficiently to proceed to the next phase and that no critical gaps or misalignments exist between requirements and design decisions.

Key Results

The System Requirement Review (SRR)

The System Requirement Review occurs near the top of the V-diagram, immediately after concept exploration and mission definition ^{[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 quality gate, ensuring the entire development effort remains aligned with stakeholder intent before significant design investment begins.

The System Design Review (SDR)

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

The Preliminary Design Review (PDR)

The Preliminary Design Review represents a major commitment point ^{[preliminary-design-review]}. By PDR, 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. This review reduces risk by catching fundamental design flaws before they propagate into expensive detailed specifications, drawings, and procurement activities.

The 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—the approved, detailed set of hardware and software specifications—is complete, correct, and ready for manufacturing and assembly ^{[build-to-baseline]}. At this stage, all design decisions must be locked down with sufficient detail that manufacturing can proceed without ambiguity. CDR is critical because 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.

Configuration Management and Design Baselines

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

Handling Uncertainty: TBD and TBC

Not all design details can be determined simultaneously. Two documentation markers manage uncertainty during design:

To Be Decided (TBD) flags items where the decision-making process itself is still pending and the outcome is uncertain ^{[to-be-decided-tbd]}. 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.

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 maintains traceability and ensures stakeholders understand which items are provisional versus firm commitments.

Worked Example: Requirement Traceability Through the V-Diagram

Consider a hypothetical Earth observation spacecraft with a mission requirement: "The spacecraft shall acquire panchromatic imagery with 1-meter ground resolution over a 100-kilometer swath."

Left side (decomposition):

1. Mission need is stated at the top
2. System requirement is derived: "The optical payload shall achieve 1-meter ground resolution"
3. This decomposes into subsystem requirements: "The telescope shall have focal length $f$ and aperture diameter $D$ such that the diffraction-limited resolution meets 1-meter GSD at nominal altitude"
4. Further decomposition yields component specifications for the primary mirror, secondary optics, and detector array

Design reviews validate each level:

• SRR confirms the system requirement correctly captures the mission need
• SDR allocates the optical requirement to the payload subsystem and confirms the spacecraft bus can support it
• PDR demonstrates that preliminary optical designs (e.g., Ritchey-Chrétien telescope configuration) can meet the requirement
• CDR locks down final specifications: exact focal length, mirror coatings, detector model, and interface definitions

Right side (integration/verification):

1. Unit testing validates individual components (mirror surface finish, detector responsivity)
2. Subsystem verification tests the integrated optical payload (point spread function, modulation transfer function)
3. System verification tests the spacecraft in orbit or through end-to-end simulation
4. Validation confirms the 1-meter GSD is achieved over the 100-kilometer swath in operational conditions

This traceability ensures that no requirement is lost and that every design decision is justified by a corresponding requirement.

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 and methodological claims are cited to source notes. The worked example is original and illustrative. The author reviewed all citations for accuracy and technical honesty.