Spacecraft Design II: System Engineering and Design Review Framework

Abstract

This article synthesizes core concepts from a Spacecraft Design II course, focusing on the system engineering V-diagram and the design review process that structures spacecraft development. The V-diagram provides a bidirectional framework linking requirements decomposition with verification and integration activities, while a sequence of formal reviews—SRR, SDR, PDR, and CDR—ensures traceability and maturity at each development phase. Together, these tools prevent costly rework and align implementation with mission objectives.

Background

Spacecraft development is inherently complex: a single system may contain thousands of components, multiple subsystems with interdependent interfaces, and requirements spanning thermal, structural, power, communications, and payload domains. Without a disciplined engineering framework, requirements can be misinterpreted, architectural decisions can propagate errors downstream, and manufacturing can proceed without clear specifications. The system engineering V-diagram and formal design reviews address these risks by imposing structure and checkpoints throughout the development lifecycle.

The System Engineering V-Diagram

The V-diagram is a conceptual model that maps the entire spacecraft lifecycle from mission conception through retirement ^{[system-engineering-v-diagram]}. The diagram is organized as two converging paths:

Left side (decomposition). Development begins with high-level mission needs and flows downward through feasibility studies, concept of operations, and system-level requirements. These are progressively decomposed into subsystem requirements, component specifications, and unit-level designs. Each level of decomposition is more detailed and specific than the one above.

Right side (integration and verification). After implementation, the process reverses. Unit-level components are tested individually, then integrated into subsystems and verified against subsystem requirements. Subsystems are integrated into the full system and verified against system requirements. Finally, the complete spacecraft is validated against the original operational requirements and mission objectives.

Bottom of the V. Development processes, timelines, and documentation activities occur throughout, supporting both decomposition and integration phases.

The key insight is traceability: every requirement defined on the left side must have a corresponding verification activity on the right side ^{[system-engineering-v-diagram]}. This ensures that no requirement is lost during implementation and that the final product actually meets the original mission needs. The V-shape prevents the common pitfall of building a system that is technically sound but does not solve the intended problem.

Key Results

Design Review Sequence

Spacecraft development is punctuated by formal design reviews that serve as quality gates and commitment points. Each review validates that the design has matured sufficiently to proceed to the next phase.

System Requirement Review (SRR). The SRR occurs early in development, near the top of the V-diagram ^{[system-requirement-review]}. Its purpose is to validate that high-level mission needs have been correctly translated into derived system requirements. By catching misinterpretations or gaps in requirements translation early, SRR prevents downstream rework when changes are least costly. The review ensures that the entire development effort remains aligned with stakeholder needs before significant design investment begins.

System Design Review (SDR). Following SRR, the SDR examines how system requirements have been allocated across the spacecraft's configuration items (subsystems and components) ^{[system-design-review]}. The review assesses the proposed system decomposition, confirms that each requirement has been assigned to responsible subsystems, and considers manufacturing feasibility. SDR bridges requirements and detailed design by validating high-level architectural decisions before they are locked down.

Preliminary Design Review (PDR). PDR is a major commitment point where the design team demonstrates that the proposed approach is feasible and mature enough to justify proceeding to final detailed design ^{[preliminary-design-review]}. By this stage, trade studies have been completed, technologies have been selected, and preliminary designs exist for all major subsystems. PDR confirms that the chosen approach is sound before investing in detailed specifications, drawings, and procurement. It reduces risk by catching fundamental design flaws before they propagate into expensive detailed work.

Critical Design Review (CDR). CDR 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 complete set of hardware and software specifications—is correct, complete, and capable of meeting all functional and performance requirements ^{[build-to-baseline]}. After CDR approval, the design is frozen and becomes the authoritative baseline for manufacturing. This review is critical because changes after CDR are exponentially more expensive than changes during design.

Configuration Management and Baselines

The build-to baseline is the approved, detailed set of specifications that serves as the single source of truth for manufacturing and assembly ^{[build-to-baseline]}. Once established at CDR, all drawings, specifications, and interface definitions are locked and controlled through formal change management. This prevents ambiguity, ensures consistency across manufacturing activities, and provides traceability from requirements through final product.

Documentation Markers: TBD and TBC

During design development, not all details can be determined simultaneously. Two documentation markers are used to flag unresolved items:

To Be Decided (TBD). A TBD indicates that 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 require that TBDs be minimized and justified before the design is locked.

To Be Confirmed (TBC). A TBC indicates an item that is not yet finalized but is 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: Traceability Through the V-Diagram

Consider a hypothetical Earth observation satellite with a mission requirement: "Acquire panchromatic imagery at 1-meter ground resolution over a 100-km swath."

Left side (decomposition):

• This mission requirement is decomposed into system requirements: optical resolution, sensor format, data rate, power budget, thermal control, and attitude stability.
• Optical resolution requirement flows down to the payload subsystem, which decomposes it into focal length, detector pitch, and optical aberration budgets.
• Attitude stability requirement flows to the attitude determination and control subsystem (ADCS), which decomposes it into pointing accuracy and jitter specifications.

Right side (integration and verification):

• The optical subsystem is tested to verify focal length and detector performance meet specifications.
• The ADCS is tested to verify pointing accuracy and jitter meet specifications.
• The integrated payload and ADCS are tested together to verify that the combined system achieves 1-meter ground resolution.
• The complete spacecraft is validated in orbit to confirm that 1-meter panchromatic imagery is actually acquired.

At each design review, traceability is confirmed: SRR validates that the mission requirement has been correctly interpreted; SDR confirms that optical and ADCS subsystems have been assigned responsibility; PDR demonstrates that preliminary designs can meet the decomposed requirements; CDR certifies that detailed designs are complete and correct.

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 notes into a coherent scholarly format. All factual claims are cited to the original notes. The author is responsible for accuracy and any errors in interpretation.