Spacecraft Design II: Step-by-Step Derivations of the Design Review Process

Abstract

The spacecraft design process is structured around a series of formal reviews that translate mission needs into a locked, manufacturable design. This article derives the logical flow of the System Engineering V-diagram and traces how requirements propagate through four critical design reviews—System Requirement Review (SRR), System Design Review (SDR), Preliminary Design Review (PDR), and Critical Design Review (CDR)—each serving as a quality gate that reduces risk and prevents costly rework. We show how each review builds on the previous one and establish the role of the build-to baseline as the final authoritative reference for manufacturing.

Background

Spacecraft development is inherently complex: a single mission may involve hundreds of requirements, dozens of subsystems, and thousands of components distributed across multiple organizations. Without a structured process, requirements can be lost, design decisions can conflict, and manufacturing can proceed without clear direction. The aerospace industry addresses this through the System Engineering V-diagram ^{[system-engineering-v-diagram]}, a bidirectional framework that ensures every requirement defined during the left-side decomposition phase has a corresponding verification activity during the right-side integration and testing phase.

The V-diagram's power lies in its symmetry: it enforces traceability by requiring that each level of system decomposition (system → subsystem → unit) has a matching level of integration and verification. This prevents the common pitfall of building something that technically works but fails to meet the original mission needs.

Within this broader framework sit four major design reviews, each occurring at a specific point in the development lifecycle. These reviews are not bureaucratic checkpoints; they are risk-reduction gates that catch errors when they are cheapest to fix.

Key Results

The Decomposition Phase: Left Side of the V

Development begins with high-level mission needs and flows downward through increasingly detailed requirements and design specifications. The first major review in this phase is the System Requirement Review (SRR) ^{[system-requirement-review]}.

SRR validates that derived requirements—the detailed, measurable specifications extracted from mission objectives—actually capture what the stakeholders need. This review occurs early, before significant design effort is invested. Its purpose is to catch misinterpretations or gaps in requirements translation when changes are least costly. By verifying that lower-level derived requirements properly decompose the original mission objectives, SRR prevents downstream rework and ensures the entire development effort remains aligned with stakeholder intent.

Following SRR, the System Design Review (SDR) ^{[system-design-review]} bridges requirements and detailed design by examining high-level architectural decisions. SDR assesses how system requirements have been allocated across configuration items (subsystems and components) and evaluates manufacturing feasibility. This review ensures that the proposed system decomposition is sound, that each requirement has been assigned to a responsible subsystem, and that manufacturing constraints have been considered early. SDR prevents architectural mistakes that would be expensive to correct later.

The next major milestone is the Preliminary Design Review (PDR) ^{[preliminary-design-review]}. By this stage, the design team has completed trade studies, selected candidate technologies, and developed preliminary designs for all major subsystems. PDR demonstrates that the proposed design approach is expected to meet all functional and performance requirements and has achieved sufficient maturity to justify proceeding to detailed design. PDR is a significant commitment point: it "locks down" the design approach, meaning subsequent reviews focus on implementation details rather than major architectural changes.

The Integration Phase: Right Side of the V

After PDR, the team proceeds to detailed design. The final design review is the Critical Design Review (CDR) ^{[critical-design-review]}, which certifies that the detailed design is complete, correct, and ready for manufacturing and assembly.

CDR ensures that the "build-to" baseline contains detailed hardware and software specifications capable of meeting all functional and performance requirements, and that the final design fulfills all specifications and commitments established at PDR. At this stage, all design decisions must be locked down with sufficient detail that manufacturing can proceed without ambiguity. CDR is the last opportunity to catch design errors before incurring manufacturing costs.

The Build-to Baseline: The Frozen Design

Once CDR is approved, the design transitions into the build-to baseline ^{[build-to-baseline]}, the locked, approved set of complete hardware and software specifications that serves as the authoritative reference for all manufacturing, assembly, integration, and testing activities. The build-to baseline contains all detailed specifications—drawings, interface definitions, performance parameters, and acceptance criteria—necessary to manufacture and assemble the spacecraft in compliance with functional and performance requirements.

Once approved, the build-to baseline becomes the single source of truth for manufacturing and assembly teams. It eliminates ambiguity by locking all design decisions with sufficient detail that production can proceed without interpretation. All subsequent changes are controlled through formal change management processes, ensuring configuration integrity and traceability from original requirements through the final product.

Handling Uncertainty: 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) ^{[to-be-decided-tbd]} indicates that the decision-making process itself is still pending and the outcome is uncertain. TBD flags areas where active decision-making is required before the design can be considered complete.

To Be Confirmed (TBC) ^{[to-be-confirmed-tbc]} indicates an item that is not yet finalized but is expected to be confirmed during development. TBC allows teams to proceed with design work while acknowledging that certain parameters, component selections, or performance values will be confirmed later through analysis, testing, or vendor feedback.

Design reviews like CDR require that TBDs be minimized and justified, ensuring the project moves toward a locked baseline. TBCs are acceptable at CDR if the confirmation process is well-defined and scheduled before manufacturing begins.

Worked Example: Requirement Flow Through Reviews

Consider a hypothetical requirement: "The spacecraft attitude determination system shall provide pointing accuracy of ±0.1° in all three axes."

At SRR: The derived requirement is validated against the mission objective (e.g., "The spacecraft shall acquire and track a target with sufficient precision for scientific observation"). The review confirms that ±0.1° is the correct translation of the mission need, not an over-specification or under-specification.

At SDR: The requirement is allocated to the Attitude Determination and Control Subsystem (ADCS). The review confirms that the ADCS architecture—including sensors, processors, and actuators—is capable of meeting this requirement and that manufacturing can produce components to the necessary tolerance.

At PDR: The ADCS team presents preliminary designs for the star tracker, gyroscopes, and control algorithms. The review confirms that the selected components and algorithms are expected to achieve ±0.1° accuracy and that the design approach is mature enough to proceed to detailed design.

At CDR: The ADCS team presents detailed specifications for every component, including sensor calibration procedures, algorithm parameters, and acceptance test criteria. The review confirms that the detailed design will actually achieve ±0.1° accuracy and that the design is producible with available manufacturing processes.

In the build-to baseline: The detailed specifications become the authoritative reference. Manufacturing teams use these specifications to procure components, assemble the ADCS, and verify that the final system meets the ±0.1° requirement.

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. All factual and mathematical claims are cited to source notes. The article has been reviewed for technical accuracy and consistency with the source material.