Spacecraft Design II: Common Mistakes and Misconceptions
Abstract
The spacecraft design process relies on a structured framework—the System Engineering V Diagram—that enforces bidirectional traceability between requirements and verification. Yet practitioners frequently misunderstand the purpose and timing of design reviews, conflate documentation markers, and lose sight of how architectural decisions propagate downstream. This article clarifies five common misconceptions about the design review process and the role of baselines in spacecraft development, drawing on systems engineering best practices.
Background
Spacecraft design is inherently complex: a single mission requirement may decompose into dozens of subsystem specifications, each with its own manufacturing constraints and verification strategy. Without a disciplined process, requirements slip through cracks, architectural flaws emerge late, and costs spiral. The System Engineering V Diagram provides the conceptual backbone for managing this complexity [system-engineering-v-diagram].
The V-diagram's left side flows downward through decomposition—from mission needs through feasibility studies, concept of operations, and progressively detailed design phases. The right side flows upward through integration and verification, ensuring every requirement defined on the left has a matching verification activity on the right [system-engineering-v-diagram]. This bidirectional structure prevents the common pitfall of building something that doesn't meet the original mission needs.
Within this framework sit five major design reviews, each serving a distinct purpose at a different stage of maturity. Understanding their roles—and their limitations—is essential to avoiding costly rework.
Key Results: Five Common Misconceptions
Misconception 1: All Design Reviews Are Equivalent
Reality: Design reviews occur at different stages of maturity and serve different purposes.
The System Requirement Review (SRR) occurs early, near the top of the V-diagram, and validates that high-level mission needs have been correctly translated into derived system requirements [system-requirement-review]. Its value lies in catching misinterpretations early, when changes are least costly. By contrast, the Critical Design Review (CDR) occurs after detailed design is complete and certifies that the "build-to" baseline contains specifications capable of meeting all functional and performance requirements [critical-design-review].
Treating these reviews as interchangeable—or worse, skipping SRR because "we'll catch it at CDR"—is a false economy. Early reviews prevent architectural mistakes; late reviews catch details. Both are necessary.
Misconception 2: System Design Review (SDR) Is Just a Formality Between SRR and PDR
Reality: SDR is the critical bridge between requirements and architecture.
SDR evaluates how system requirements have been allocated across configuration items and assesses manufacturing feasibility [system-design-review]. This is where the team commits to a high-level decomposition strategy. A poor allocation decision at SDR—assigning conflicting requirements to the same subsystem, or ignoring manufacturing constraints—will force expensive rework during detailed design or, worse, during manufacturing.
SDR is not a checkbox; it is the last moment to validate the system architecture before detailed design locks it in place.
Misconception 3: Preliminary Design Review (PDR) Means the Design Is Ready to Build
Reality: PDR demonstrates feasibility; it does not certify readiness for manufacturing.
PDR shows that the proposed design approach is expected to meet all functional and performance requirements and is mature enough to justify proceeding to final detailed design [preliminary-design-review]. At PDR, trade studies are complete, technologies are selected, and preliminary designs exist for all major subsystems. But detailed specifications, interface definitions, and manufacturing drawings do not yet exist.
Confusing PDR approval with manufacturing readiness leads teams to begin procurement or fabrication before the design is sufficiently detailed, resulting in rework when CDR reveals gaps or conflicts.
Misconception 4: TBD and TBC Are Interchangeable
Reality: They flag different types of uncertainty.
TBD (To Be Decided) indicates that the decision-making process itself is still pending and the outcome is uncertain [to-be-decided-tbd]. TBC (To Be Confirmed) indicates that an item is not yet finalized but is expected to be confirmed during development—implying a value or approach already exists and is under validation [to-be-confirmed-tbc].
Using TBD when you mean TBC obscures the actual state of the design. A TBD for a propulsion system type signals that the team has not yet chosen between chemical, electric, or nuclear options. A TBC for a thruster's specific impulse signals that the team has selected a candidate thruster and is confirming its performance through testing or vendor data.
Design reviews, especially CDR, require that TBDs be minimized and justified. Unresolved decisions cascade into schedule delays and design conflicts.
Misconception 5: The Build-to Baseline Is a Living Document
Reality: The build-to baseline is frozen at CDR and controlled through formal change management.
The build-to baseline is the approved, detailed set of hardware and software specifications established at CDR and serves as the authoritative reference for manufacturing and assembly [build-to-baseline]. Once approved, it becomes the single source of truth. All drawings, specifications, and interface definitions are locked and controlled through formal change management processes [build-to-baseline].
Teams that treat the baseline as a "living document" and allow informal changes during manufacturing invite inconsistency, rework, and loss of traceability. Every change must go through formal change control to assess impacts and maintain configuration integrity.
Worked Example: Requirement Allocation Gone Wrong
Consider a small satellite with a power requirement of 500 W average, 800 W peak. At SDR, the team allocates power generation to solar panels and power storage to a battery. This seems straightforward.
But during detailed design (post-PDR), the thermal analysis reveals that the battery generates significant heat in eclipse, and the thermal control subsystem cannot dissipate it without redesigning the radiator. The radiator redesign conflicts with the structural layout already approved at PDR. Now the team faces a choice: reduce battery capacity (violating the power requirement), redesign the structure (expensive and schedule-impacting), or add active cooling (mass and power penalty).
This conflict was latent at SDR. A more careful allocation at SDR—one that explicitly considered thermal coupling between power and thermal subsystems—would have surfaced the issue when changes were still cheap. Instead, the team discovered it during detailed design, when the cost of rework was orders of magnitude higher.
The lesson: allocation decisions at SDR must account for cross-subsystem interactions, not just functional decomposition.
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 class notes from ASE 4543 (Spacecraft Design II). The AI was used to organize, paraphrase, and structure the material for clarity and coherence. All factual claims are cited to the original notes. The author reviewed the final text for technical accuracy and relevance.