Mission Planning Technical Guide

Purpose:

This document outlines the process for defining mission requirements, establishing verification and validation (V&V) methods, and structuring an effective mission planning session. It also includes a worked example based on NASA’s MarCO mission to demonstrate how real missions define and verify requirements.

1. Systems Engineering Process Overview

1.1 Define Mission Objectives

Mission objectives describe the purpose of the mission in qualitative terms. They answer “why” the mission exists and what scientific or technical outcome it aims to achieve.

Example:

• Demonstrate real-time communications relay capability during an interplanetary mission.
• Quantify CO₂ concentrations above wildfire plumes using hyperspectral imaging.

1.2 Derive Mission Requirements

Mission requirements are quantitative, verifiable statements describing what must be true for the mission to succeed. Each requirement should have: 

- A measurable quantity or condition
- A direct link to a higher-level objective
- A defined verification method

Each should follow this structure: The system shall [do X / achieve Y] under [specified conditions].

Categories of Requirements:

1.3 Establish Verification and Validation (V&V)

Each requirement must be associated with a verification method that confirms it has been met. The four standard verification methods are listed below.

Each requirement statement should indicate its verification method, for example: The ADCS shall maintain pointing accuracy ≤ 2° (verified by analysis and on-orbit demonstration).

1.4 Build the Requirement Breakdown Structure (RBS)

The RBS is a hierarchical organization of requirements. It helps trace each subsystem requirement back to a top-level mission objective.

1. Mission Requirements: define the overall mission goals.
   2. System Requirements: describe satellite-level capabilities and performance.
   3. Subsystem Requirements: define what each subsystem must achieve.
   4. Component Requirements: specify measurable conditions for individual parts.

1.5 Supporting Analyses

Subsystem teams should conduct preliminary analyses to establish feasibility and support requirements definition. These include power budget, mass budget, link budget, and thermal budget.

1.6 Requirement Tracking Format

2. Worked Example: NASA MarCO (Mars Cube One)

NASA’s MarCO consisted of two 6U CubeSats that relayed telemetry from the InSight lander during its descent to Mars.

2.1 Mission Objective

Demonstrate that a CubeSat can provide a real-time UHF relay link from Mars to Earth during entry, descent, and landing.

2.2 Top-Level Requirements

2.3 Subsystem Requirements

Communications

• The X-band high-gain antenna shall provide ≥ 20 dBi gain at 8.4 GHz. (Test)
• The transponder shall maintain a bit error rate < 10⁻⁵ at 8 kbps link. (Analysis + Test)

Power

• The solar array shall generate 35 W at 1 AU. (Analysis + Test)
• The battery shall support 15 min eclipse with ≥ 90% depth of discharge. (Analysis)

ADCS

• The spacecraft shall maintain pointing within 1° during downlink. (Analysis + Test)

Thermal

• The spacecraft shall survive between −20 °C and +50 °C. (Thermal vacuum test)

3. Mission Planning Worksheet Template

Guidance

Use precise, measurable verbs in requirement statements (“shall measure,” “shall transmit,” “shall maintain”) rather than vague ones (“optimize,” “improve,” “support”). Each requirement must be independently testable and traceable to a mission objective.