Spacecraft Design II: Requirements, Reviews, and the Path to Manufacturing

Abstract

Spacecraft development is a high-stakes, irreversible process where early decisions propagate through years of work and billions in cost. This article examines the structured framework that governs modern spacecraft design: the System Engineering V Diagram and its associated design review gates. We explore how requirements flow from mission needs through decomposition, how architectural decisions are validated, and how the design is progressively locked down through formal checkpoints. Understanding these mechanisms is essential for anyone involved in spacecraft development, as they represent the difference between a mission that succeeds and one that fails catastrophically.

Background

The development of a spacecraft is fundamentally a problem of translation: converting abstract mission objectives into concrete, verifiable hardware and software specifications. This translation must occur without loss of fidelity, and every step must be traceable back to the original need.

The System Engineering V Diagram provides the conceptual framework for this process ^{[system-engineering-v-diagram]}. Rather than a linear waterfall, the V-shape captures a bidirectional flow. The left side represents decomposition: breaking down mission needs into progressively more detailed requirements and design specifications. The right side represents integration and verification: assembling components back together and confirming that each level of assembly meets its corresponding requirements. The bottom of the V contains the actual development work—manufacturing, assembly, and testing.

The key insight is that every requirement defined on the left must have a matching verification activity on the right. This ensures traceability and prevents requirements from being lost or misinterpreted during implementation. Without this discipline, teams risk building a spacecraft that is technically sound but fails to accomplish its mission.

Key Results

The Requirement-to-Verification Chain

The V Diagram is not merely a diagram; it is a commitment to bidirectional traceability. Each level of the left side (system → subsystem → unit) must have a corresponding level on the right side (unit test → subsystem verification → system verification). This prevents the common pitfall of building something that works in isolation but fails when integrated.

Design Review Gates as Risk Reduction

Spacecraft development is gated by formal design reviews, each serving a specific risk-reduction function:

System Requirement Review (SRR) ^{[system-requirement-review]} occurs near the top of the V, before significant design investment. Its purpose is to validate that derived requirements properly decompose the high-level mission objectives. By catching misinterpretations early, SRR prevents downstream rework when changes are least costly.

System Design Review (SDR) ^{[system-design-review]} evaluates how system requirements have been allocated across configuration items (subsystems and components). It ensures the proposed decomposition is sound and that manufacturing constraints have been considered. SDR bridges the gap between requirements and detailed design by examining high-level architectural decisions.

Preliminary Design Review (PDR) ^{[preliminary-design-review]} represents a major commitment point. By this stage, trade studies are complete, technologies are selected, and preliminary designs exist for all major subsystems. PDR confirms that the chosen approach is feasible before investing in detailed specifications and procurement. It is the last major review before the design is "locked down."

Critical Design Review (CDR) ^{[critical-design-review]} is the final design review. It certifies that the detailed design is complete, correct, and ready for manufacturing. CDR ensures that every requirement has a corresponding design specification, that all interfaces are properly defined, and that the design is producible. After CDR approval, the design becomes the "build-to baseline" and is frozen ^{[build-to-baseline]}.

The Build-to Baseline as Ground Truth

Once approved at CDR, the build-to baseline becomes the single source of truth for manufacturing and assembly ^{[build-to-baseline]}. All drawings, specifications, and interface definitions are locked and controlled through formal change management. This baseline prevents ambiguity and ensures consistency across all manufacturing activities.

Managing Uncertainty: TBD and TBC

Not all details can be determined simultaneously. Two markers are used to track uncertainty:

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

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

The distinction is important: TBD means "we haven't decided yet," while TBC means "we have a provisional answer that we will confirm." Design reviews, particularly CDR, require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline.

Worked Example: Requirement Traceability Through the V

Consider a hypothetical Earth observation spacecraft with the mission objective: "Provide 5-meter ground resolution imagery of the continental United States with 95% cloud-free coverage per month."

On the left side of the V, this decomposes into:

1. System requirement: "Spacecraft shall achieve 5-meter ground resolution at nadir."

2. Subsystem requirements:

   • Optical subsystem: "Focal length and detector pitch shall support 5-meter GSD at 500 km altitude."
   • Attitude control: "Pointing stability shall be ±0.1 degrees to maintain resolution."
   • Power: "Optical subsystem shall consume no more than 150 W during imaging."

3. Unit specifications:

   • Detector: "Pixel pitch = 5 μm, array size = 4096 × 4096."
   • Lens: "Focal length = 1.2 m, aperture = f/4."
   • Reaction wheels: "Momentum capacity ≥ 50 N·m·s, control accuracy ±0.01 degrees."

On the right side, each unit specification has a corresponding test:

• Detector is tested for pixel pitch and responsivity in the lab.
• Lens is tested for focal length and optical aberrations.
• Reaction wheels are tested for momentum capacity and control accuracy.
• Subsystems are integrated and tested together (optical + attitude control tested for pointing stability during imaging).
• The full spacecraft is tested to confirm 5-meter resolution is achieved end-to-end.

This chain ensures that if the spacecraft achieves 5-meter resolution in the final test, we can trace that success back through every intermediate requirement and test. Conversely, if a test fails, we know exactly which requirement is not being met.

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 personal class notes from Spacecraft Design II (ASE 4543). The AI was used to organize, paraphrase, and structure the notes into a coherent scholarly format. All factual claims are cited to the original notes. The worked example was generated by the AI to illustrate the concepts but is not drawn from the course materials. The author is responsible for the accuracy and integrity of all claims.