Spacecraft Design II: The V-Diagram Framework and Requirements Traceability

Abstract

The System Engineering V-Diagram provides a structured lifecycle framework for spacecraft development, mapping decomposition and integration activities in parallel. This article explains the V-Diagram's architecture, the role of design reviews as quality gates, and how requirements traceability prevents costly rework. Understanding this framework is essential for spacecraft designers to ensure mission objectives flow through every development phase and that verification activities align with requirements at each level.

Background

Spacecraft development is inherently complex: a single mission objective must decompose into thousands of derived requirements, each allocated to specific subsystems and components. Without a structured approach, requirements can be lost, misinterpreted, or left unverified—leading to cost overruns, schedule delays, or mission failure.

The System Engineering V-Diagram addresses this challenge by establishing a bidirectional process that mirrors decomposition with integration and verification ^{[system-engineering-v-diagram]}. The left side of the V flows downward through progressively detailed design phases, while the right side flows upward through testing and validation. This symmetry ensures that every requirement defined during decomposition has a corresponding verification activity during integration.

Key Results

The V-Diagram Structure

The V-Diagram organizes spacecraft development into three primary flows ^{[system-engineering-v-diagram]}:

1. Decomposition (left side): Mission needs flow through feasibility studies, concept of operations, system requirements, and progressively detailed design phases.
2. Integration and verification (right side): Unit testing, subsystem verification, system verification, and validation flow back up to operational requirements.
3. Development baseline (bottom): Timelines, documentation, and configuration management activities support both flows.

The key insight is that the V-shape enforces traceability: each requirement level on the left must have a matching verification level on the right. This prevents the common pitfall of building something that does not meet the original mission needs ^{[system-engineering-v-diagram]}.

Design Reviews as Quality Gates

The V-Diagram is punctuated by formal design reviews that serve as checkpoints and commitment points. Each review validates that the current phase is complete and mature enough to proceed to the next.

System Requirement Review (SRR) occurs near the top of the V, validating that high-level mission needs have been correctly translated into derived system requirements ^{[system-requirement-review]}. By catching misinterpretations early, SRR prevents downstream rework when changes are least costly.

System Design Review (SDR) bridges requirements and detailed design by assessing how system requirements have been allocated to configuration items (subsystems and components) and evaluating manufacturing feasibility ^{[system-design-review]}. This review prevents architectural mistakes that would be expensive to correct later.

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

Critical Design Review (CDR) is the final design review, certifying that the detailed design is complete, correct, and ready for manufacturing ^{[critical-design-review]}. CDR ensures that the "build-to" baseline contains all specifications necessary to manufacture and assemble the spacecraft, and that every requirement has a corresponding design specification ^{[build-to-baseline]}. After CDR approval, the design is frozen and becomes the authoritative baseline for building the spacecraft.

Requirements Traceability and Documentation Control

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. This prevents ambiguity and ensures consistency across all manufacturing activities.

During design phases, unresolved items are flagged using standardized terminology. To Be Decided (TBD) indicates that a decision-making process is still pending and the outcome is uncertain ^{[to-be-decided-tbd]}. To Be Confirmed (TBC) indicates an item that is not yet finalized but is expected to be confirmed during development ^{[to-be-confirmed-tbc]}. Design reviews require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline.

Worked Example: Tracing a Requirement Through the V-Diagram

Consider a hypothetical Earth observation spacecraft with the mission objective: "Acquire multispectral imagery of ground targets with 10-meter spatial resolution."

1. Decomposition (left side):

   • At SRR, this mission objective is translated into system-level requirements: optical aperture diameter, detector pixel size, orbital altitude, and image processing specifications.
   • At SDR, these system requirements are allocated to subsystems: the optical payload subsystem receives the aperture and detector requirements; the attitude control subsystem receives pointing accuracy requirements; the data handling subsystem receives image processing and storage requirements.
   • At PDR, each subsystem team develops preliminary designs: the optical team selects a specific lens design and detector model; the attitude control team selects reaction wheels and star trackers; the data handling team selects processors and memory.
   • At CDR, detailed specifications are locked: exact lens drawings, detector datasheets, processor firmware specifications, and all interface definitions.

2. Integration and verification (right side):

   • Unit testing verifies that individual components (lenses, detectors, processors) meet their specifications.
   • Subsystem verification tests the optical payload as an integrated unit, confirming that the lens and detector together achieve 10-meter resolution.
   • System verification tests the entire spacecraft, confirming that attitude control, optical payload, and data handling work together to acquire and downlink imagery meeting the original mission objective.
   • Validation confirms that the spacecraft operates in the actual orbital environment and produces usable imagery.

At each level, a requirement from the left side has a corresponding verification activity on the right side. If the optical payload subsystem fails to achieve 10-meter resolution during subsystem verification, the issue is traced back to the requirement, the design, and the unit tests—ensuring root cause is identified and corrected before system integration.

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 mathematical claims are cited to source notes. The structure, synthesis, and worked example were generated by the AI based on note content, with human review and editing. The article does not contain claims beyond what is supported by the cited notes.