Spacecraft Design II: Requirements, Reviews, and the V-Diagram Framework

Abstract

Spacecraft design is a complex, multi-phase endeavor that demands rigorous traceability between mission objectives and final hardware. This article examines the System Engineering V-Diagram and the formal review checkpoints that structure spacecraft development, from concept through manufacturing. We discuss how requirements flow through decomposition and integration phases, and how design reviews serve as quality gates to prevent costly rework. The framework presented here is foundational to modern spacecraft projects and reflects industry best practices in systems engineering.

Background

Spacecraft projects operate under severe constraints: cost, schedule, and performance margins are typically tight, and failures are often catastrophic and irreversible. Unlike terrestrial systems where iteration and field upgrades are feasible, a spacecraft must be right before launch. This reality has driven the aerospace industry to adopt formal, structured development processes that enforce traceability and verification at every stage.

The System Engineering V-Diagram ^{[system-engineering-v-diagram]} provides the conceptual backbone for this approach. Rather than a linear waterfall or a purely iterative cycle, the V-shape captures a fundamental principle: every requirement defined during the left-side (decomposition) phase must have a corresponding verification activity on the right side (integration and validation). This bidirectional structure ensures that nothing is built without a clear link back to mission needs, and nothing is verified without a clear link forward to the actual system.

Key Results

The V-Diagram Structure

The V-Diagram decomposes spacecraft development into three major phases:

1. Left side (decomposition): Mission needs flow downward through feasibility studies and concept of operations into system requirements. These are then progressively decomposed into subsystem requirements, component specifications, and unit designs. Each level of decomposition represents a finer granularity of detail.

2. Bottom (development): At the lowest point of the V, individual units and components are designed, manufactured, and tested in isolation.

3. Right side (integration and verification): Units are tested and integrated into subsystems; subsystems are verified against their requirements; the full system is validated against the original mission needs. This upward flow mirrors the downward decomposition, ensuring completeness.

The intuition is powerful: the V-shape prevents requirements from being lost or forgotten. If a requirement is defined on the left but has no corresponding verification activity on the right, the diagram makes this gap visible ^{[system-engineering-v-diagram]}.

Design Review Checkpoints

Formal design reviews serve as quality gates within the V-Diagram. Each review is a structured assessment that the project is ready to proceed to the next phase.

System Requirement Review (SRR) occurs near the top of the V, after mission needs have been translated into derived system requirements. SRR validates that lower-level requirements properly capture and decompose the original mission objectives ^{[system-requirement-review]}. By catching misinterpretations early, when changes are least costly, SRR prevents downstream rework.

System Design Review (SDR) follows SRR and evaluates how system requirements have been allocated across configuration items (subsystems and components). SDR assesses manufacturing feasibility and confirms the architectural decomposition is sound ^{[system-design-review]}. This review bridges the gap between requirements and detailed design.

Preliminary Design Review (PDR) is a major commitment point. By this stage, trade studies are complete, technologies are selected, and preliminary designs exist for all major subsystems. PDR demonstrates that the chosen approach is feasible and mature enough to justify proceeding to final detailed design ^{[preliminary-design-review]}. It is the last major review before the design is locked down.

Critical Design Review (CDR) is the final design review, occurring after detailed design is complete but before manufacturing begins. CDR certifies that the "build-to" baseline contains complete hardware and software specifications capable of meeting all functional and performance requirements ^{[critical-design-review]}. After CDR approval, the design is frozen and becomes the authoritative baseline for manufacturing ^{[build-to-baseline]}. Changes after CDR are exponentially more expensive, making this review critical.

Documentation and Baselines

Throughout design, two markers are used to flag unresolved items:

• To Be Decided (TBD): Indicates that a decision has not yet been made and the outcome is uncertain ^{[to-be-decided-tbd]}. TBDs represent active decision points that must be resolved before the design is complete.

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

Design reviews, particularly CDR, require that TBDs be minimized and justified. The goal is to move toward a locked baseline with minimal provisional items.

The build-to baseline is the approved, detailed set of specifications established at CDR ^{[build-to-baseline]}. Once approved, it becomes the single source of truth for manufacturing and assembly. All changes to the baseline must go through formal change management to assess impacts and maintain configuration integrity.

Worked Example: Requirement Traceability in a Cubesat Project

Consider a small satellite (cubesat) project with a mission to image Earth at 10-meter ground resolution. The V-Diagram would structure development as follows:

Left side (decomposition):

• Mission need: "Provide 10-meter ground resolution imagery of Earth."
• System requirement: "Optical payload shall achieve 10-meter ground resolution from 400 km altitude."
• Subsystem requirement (payload): "Camera focal length shall be 50 mm; sensor shall have pixel pitch of 5 micrometers."
• Component specification (sensor): "5-megapixel CMOS imager, 5 μm pixel pitch, 2048 × 2560 resolution."

Bottom (development):

• The sensor is procured, tested in isolation, and verified to meet its specification.

Right side (integration and verification):

• The sensor is integrated into the camera assembly; the camera is tested to verify it achieves the required focal length and optical performance.
• The camera is integrated into the payload subsystem; the payload is tested to verify it achieves 10-meter ground resolution in simulated orbital conditions.
• The payload is integrated into the spacecraft; the full system is validated in end-to-end testing to confirm the mission objective is met.

At each review gate (SRR, SDR, PDR, CDR), the team confirms that the decomposition is sound, that no requirements have been lost, and that the next phase can proceed with confidence. If a requirement cannot be traced from mission need to final component specification, the review identifies the gap and requires resolution before proceeding.

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. The AI was used to organize, paraphrase, and structure the material for clarity and coherence. All factual claims are grounded in the source notes and cited accordingly. The author remains responsible for the accuracy and interpretation of the content.