SMAD stands for Space Mission Analysis and Design. The textbook by that name, first published in 1991 and now in its fifth edition (Space Mission Engineering: The New SMAD), is the closest thing the space industry has to a universal reference. It defines the process of taking a mission concept from initial objectives through detailed design.
The SMAD methodology breaks mission engineering into a structured sequence: define mission objectives, derive requirements, allocate budgets (mass, power, data, thermal, link), assess risks, and verify readiness at each phase gate. Each step feeds the next. Requirements drive budgets. Budgets constrain design trades. Design trades generate new requirements. The process is iterative by nature.
What makes SMAD powerful is not any single analysis. It is the integration. A mass budget without requirements context is just numbers. Requirements without budget margins are just wishes. Phase gates without risk posture are just meetings. The methodology works because it connects these elements into a coherent picture of mission readiness.
The methodology starts with mission objectives — the why. These are typically two to five short statements that define what the mission must accomplish for its sponsor or customer. "Provide global broadband internet with 50 ms latency" is a mission objective. "The system shall use Ka-band" is not — it is an implementation choice masquerading as an objective. Getting this distinction right at the start prevents months of rework later.
From mission objectives, the methodology derives system-level requirements. Each requirement should be testable, traceable to an objective, and specific enough that two engineers reading it would design the same thing. SMAD provides reference values and rules of thumb for common requirement domains: pointing accuracy, power generation, data rate, mass margins, link margins. These reference values are starting points, not final answers, but they get you to a defensible first draft in days instead of weeks.
Budget allocation is where the methodology earns its keep. SMAD defines the standard budgets every mission needs: mass (with margins by phase), power (with eclipse and contingency cases), data rate (uplink and downlink), thermal (hot case and cold case), and link (transmit through receive). Each budget has a recommended margin policy: 30% at SRR, 20% at PDR, 10-15% at CDR. These margins are not arbitrary — they come from decades of program data showing how much spacecraft mass and power tend to grow between concept and launch.
Risk management runs in parallel with the technical analysis. SMAD recommends maintaining a risk register with likelihood, consequence, and a 5x5 risk matrix. Each risk should have an owner, a mitigation plan, and a status. The discipline is not the matrix itself — it is the habit of revisiting the register at every program review and making sure new risks are captured as they emerge.
Phase gates are where the methodology converts work into decisions. SRR confirms the requirements are right. PDR confirms the design approach is feasible. CDR confirms the detailed design is ready to build. TRR confirms the test program is ready to execute. Each gate has entrance and exit criteria, and the methodology insists that the criteria are evaluated against evidence — not opinions.
Most teams implement SMAD methodology using a collection of disconnected tools: DOORS for requirements, Excel for budgets, PowerPoint for reviews, custom scripts for analysis. The methodology describes an integrated process, but the tools force a fragmented execution. Every review cycle requires manual integration of data from five different sources.
The cost of fragmentation shows up in three places. First, in time — engineers spend days every month reconciling spreadsheets that should not need reconciliation. Second, in errors — when the mass budget on one engineer's laptop disagrees with the mass budget on another's, the wrong number sometimes ends up in the review package. Third, in confidence — review boards lose trust when the same number appears with different values in different documents, and trust is hard to rebuild.
Hitt Hosting SE implements the methodology as software. Requirements, budgets, risks, phase gates, and engineering calculators live in one system. The connections the methodology describes — requirements tracing to budgets, risks linking to requirements, phase gates pulling from all of the above — are maintained automatically. The process the textbook defines becomes the workflow the tool enforces. Engineers spend their time on engineering, not on tool integration.