Spacecraft Design II: Systems Engineering and Design Review Frameworks

Abstract

Spacecraft development is a complex, multi-phase endeavor requiring rigorous alignment between mission objectives and implementation. This article examines the foundational systems engineering framework and formal design review checkpoints that structure spacecraft projects from concept through manufacturing. We focus on the V-diagram lifecycle model and the four critical design reviews—SRR, SDR, PDR, and CDR—that serve as quality gates and ensure traceability from high-level requirements to detailed specifications.

Background

Modern spacecraft projects operate under severe constraints: cost, schedule, technical risk, and mission criticality all demand disciplined engineering processes. Ad hoc design approaches routinely fail to deliver systems that meet stakeholder needs or can be manufactured reliably. The systems engineering discipline emerged to address this challenge by imposing structure on the decomposition, verification, and integration of complex systems ^{[system-engineering-v-diagram]}.

The core insight is bidirectional traceability: every requirement defined during the early phases must have a corresponding verification activity later, and every design decision must trace back to a validated requirement. This prevents the common failure mode where teams build something technically impressive but operationally useless.

The V-Diagram Framework

The System Engineering V Diagram provides a visual and conceptual map of the entire spacecraft lifecycle ^{[system-engineering-v-diagram]}. The diagram is structured as two converging paths:

Left side (decomposition). Development flows downward from mission needs through feasibility studies, concept of operations, system requirements, and progressively detailed design phases. At each level, high-level objectives are broken into more specific, measurable requirements and allocated to subsystems and components.

Right side (integration and verification). After detailed design and manufacturing, the process reverses. Unit testing, subsystem verification, system verification, and validation flow upward, confirming that each level of the system meets its corresponding requirements. The right side is not a mirror image; it is driven by the left side's decomposition structure.

Bottom (development activities). Timelines, documentation, and project management activities support both sides of the V.

The V-shape emphasizes a critical principle: traceability and balance. Every requirement on the left must have a verification counterpart on the right. This prevents requirements from being lost or forgotten during implementation and ensures the final product actually satisfies the original mission ^{[system-engineering-v-diagram]}.

Design Review Checkpoints

Spacecraft projects employ formal design reviews at key milestones to validate progress, assess risk, and authorize advancement to the next phase. These reviews are not bureaucratic overhead; they are quality gates that catch errors before they become expensive.

System Requirement Review (SRR)

The System Requirement Review occurs near the top of the V-diagram, after mission definition but before significant design investment ^{[system-requirement-review]}. Its purpose is to validate that high-level mission needs have been correctly translated into derived system requirements.

At SRR, the team demonstrates that:

• Mission objectives are clearly stated and understood by all stakeholders
• Derived requirements properly decompose and capture those objectives
• Requirements are testable, traceable, and free of ambiguity

By catching misinterpretations early, SRR prevents downstream rework and ensures the entire development effort remains aligned with stakeholder intent ^{[system-requirement-review]}.

System Design Review (SDR)

Following SRR, the System Design Review examines how system requirements have been allocated across the spacecraft's configuration items (subsystems and components) and assesses manufacturing feasibility ^{[system-design-review]}.

SDR validates:

• Allocation of each system requirement to one or more responsible subsystems
• Architectural soundness of the proposed decomposition
• Early consideration of manufacturing constraints and producibility

This review bridges requirements and detailed design. It prevents architectural mistakes that would be expensive to correct later and confirms the team is ready to proceed with detailed subsystem design ^{[system-design-review]}.

Preliminary Design Review (PDR)

The Preliminary Design Review is a major commitment point ^{[preliminary-design-review]}. By this stage, the team has completed trade studies, selected candidate technologies, and developed preliminary designs for all major subsystems.

PDR demonstrates:

• The proposed design approach is expected to meet all functional and performance requirements
• Sufficient design maturity exists to justify proceeding to final detailed design
• Technical risks have been identified and mitigation strategies are in place

PDR is the last major review before the design is "locked down" for final implementation. Approval authorizes the team to invest in detailed specifications, drawings, and long-lead procurement ^{[preliminary-design-review]}.

Critical Design Review (CDR)

The Critical Design Review is the final design review and the last opportunity to catch errors before manufacturing begins ^{[critical-design-review]}. At CDR, the team presents the complete, detailed design ready for implementation.

CDR certifies:

• The "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements
• All interfaces are properly defined and compatible
• Every requirement has a corresponding design specification
• The design is producible and all TBDs and TBCs are resolved or justified

After CDR approval, the design is frozen and becomes the authoritative baseline for manufacturing and assembly ^{[critical-design-review]}.

The Build-to Baseline

Once CDR is complete and approved, the detailed specifications, drawings, and interface definitions are consolidated into the Build-to Baseline ^{[build-to-baseline]}. This baseline becomes the single source of truth for all manufacturing, assembly, integration, and test activities.

The build-to baseline is placed under formal configuration management. Any changes after CDR must go through formal change control processes that assess impacts on schedule, cost, and performance. This prevents ambiguity, ensures consistency across all manufacturing activities, and maintains traceability from requirements through the final product ^{[build-to-baseline]}.

Documentation and Tracking

Throughout the design process, teams use standardized notation to flag unresolved items:

TBD (To Be Decided). 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 can be considered complete.

TBC (To Be Confirmed). Indicates that a value or item is not yet finalized but is expected to be confirmed during development, typically through analysis, testing, or vendor feedback ^{[to-be-confirmed-tbc]}. TBC assumes an existing candidate value; TBD assumes the decision itself is still pending.

Design reviews, particularly CDR, require that TBDs be minimized and justified. Unresolved TBDs at CDR indicate incomplete design maturity and increase schedule risk ^{[to-be-decided-tbd]}.

Conclusion

The systems engineering V-diagram and formal design review framework provide structure and discipline to spacecraft development. By enforcing bidirectional traceability, establishing clear quality gates, and maintaining a locked baseline for manufacturing, these processes reduce technical risk and increase the probability that the final spacecraft will meet its mission objectives on schedule and within budget. While the framework requires investment in documentation and formal reviews, the cost of these activities is negligible compared to the cost of discovering design flaws during manufacturing or, worse, after launch.

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 instructed to paraphrase note content, maintain technical accuracy, and cite all factual claims. The author reviewed the output for correctness and alignment with course material before publication.