Mission Analysis is the first phase of the ISO 15288 systems engineering lifecycle. It answers a deceptively simple question: what operational problem needs solving, and why now? Before you draw a single architecture diagram or write a single requirement, you need to understand the operational context thoroughly enough to justify the programme.

The INCOSE Systems Engineering Handbook emphasises that mission analysis bridges the gap between a vague strategic intent and a concrete engineering problem. It's where operational concepts meet practical constraints — budget, technology maturity, regulatory environment, and timeline.

What Mission Analysis Produces

• A clear statement of the operational need
• Defined mission scenarios covering nominal, edge, and failure cases
• Identified stakeholders and their conflicting priorities
• A capability gap analysis — what exists versus what's needed
• High-level operational requirements that will drive system design
• An initial operational concept (ConOps) document

Our running example throughout this tutorial series is a Medium Altitude Long Endurance (MALE) Unmanned Aerial Vehicle designed for Intelligence, Surveillance and Reconnaissance (ISR) operations. Let's set the scene.

Why This Matters for Mission Analysis

This isn't just 'build a drone that flies for a long time.' The operational context shapes every decision that follows. Contested environments mean you need communications resilience. Mixed payloads mean you need a flexible airframe. 24-hour endurance means you need serious attention to power management and possibly airborne refuelling or very efficient propulsion. Each of these will cascade into requirements, architecture, and ultimately cost.

The first concrete step in mission analysis is defining the operational context. This means understanding the environment in which the system will operate — not just geographically, but tactically, politically, and technically.

Applying It: Our UAV Programme

For the MALE UAV ISR system, the operational context includes:

• Theatres of operation: semi-arid to temperate climates, operating from forward bases with limited infrastructure
• Threat environment: moderate electronic warfare, potential MANPADS threat at lower altitudes, airspace sharing with manned military and civilian traffic
• Regulatory constraints: civil aviation authority coordination for mixed airspace, export controls on sensor technology, data sovereignty requirements for intelligence gathering
• Force structure: operators are existing aviation personnel transitioning from manned to unmanned platforms, ground control stations will be integrated into existing command and control networks
• Support constraints: maintenance must be achievable at forward operating bases with limited specialist support; mean time between maintenance events needs to be high

Every systems engineering programme has stakeholders — people or organisations with an interest in the outcome. Mission analysis requires you to identify them all, understand what they want, and recognise where those wants conflict.

Stakeholders in Our UAV Programme

1. Programme Authority (funder): wants capability delivered on time and within budget; concerned with parliamentary scrutiny and public value
2. Operational Command (end users): wants maximum sensor flexibility, long endurance, and intuitive ground control interfaces
3. Air Traffic Management: needs predictable flight profiles and reliable communications for airspace integration
4. Maintenance Organisation: wants modular, accessible design with common spares across the fleet
5. Cyber Security Authority: requires robust data links, encrypted communications, and resistance to spoofing and jamming
6. Environmental Regulators: noise restrictions at operating bases, electromagnetic emissions limits
7. Industry Partners (suppliers): want technically feasible requirements that align with their existing capabilities and supply chains

Mission scenarios are the backbone of mission analysis. They describe how the system will be used in practice — not the idealised 'everything works perfectly' case, but the messy reality including failures, edge cases, and operator behaviour under stress.

Scenario Development Approach

The INCOSE Handbook recommends developing scenarios across three categories:

• Nominal scenarios — the primary intended use cases
• Edge cases — unusual but plausible situations the system must handle
• Failure/degradation scenarios — what happens when things go wrong

Applying It: UAV Mission Scenarios

For our MALE UAV ISR system, key scenarios include:

• Persistent surveillance of a designated area for 24 hours, with continuous data relay to ground station and periodic high-resolution spot-checks of specific targets
• Transition between multiple sensor modes during a single mission — switching from wide-area SIGINT collection to focused EO/IR tracking of a identified target
• Communications degradation: data link quality drops due to electronic warfare interference; system must maintain safe flight while reducing data throughput and alerting the operator
• Emergency landing: engine fault detected at 18,000 ft over unprepared terrain; UAV must navigate to the nearest suitable landing zone while maintaining communications
• Rapid re-tasking: intelligence priority shifts mid-mission; UAV must change surveillance area within 15 minutes while maintaining situational awareness
• Multi-UAV coordination: two UAVs operating in the same airspace, sharing sensor data and coordinating coverage to avoid gaps

Before committing to new development, you need to understand what already exists and quantify the gap. This prevents 'solutioneering' — jumping to a technical solution before properly defining the problem.

Current Capabilities vs Required Capabilities

For our UAV programme, the gap analysis looks at existing ISR assets and identifies where they fall short:

• Manned reconnaissance aircraft: high sensor quality but limited endurance (4-6 hour sorties), expensive per flight hour, crew risk in contested airspace
• Satellite-based ISR: global coverage but fixed revisit times (2-6 hours depending on orbit), weather-dependent optical sensors, limited electronic intelligence capability
• Existing tactical UAVs: responsive and cheap but limited range, altitude, and sensor payload capacity; unsuitable for persistent wide-area surveillance
• Ground-based sensors: persistent but location-fixed; cannot cover mobile targets or denied areas

The gap: no single platform provides persistent (24+ hour) wide-area ISR with high-resolution sensors, operating in contested environments at a reasonable cost per mission hour. The MALE UAV fills this gap by combining endurance, sensor flexibility, and the ability to operate from forward bases without risking crew.

The output of mission analysis is a set of high-level operational requirements. These are different from system requirements — they describe what the system must achieve operationally, not how it achieves it. The distinction matters: operational requirements give the design team freedom to find the best solution.

Sample Operational Requirements for Our UAV

1. The system shall provide continuous ISR coverage of a designated area for a minimum of 24 hours from take-off to landing
2. The system shall operate at altitudes between 5,000 ft and 25,000 ft to balance sensor resolution, coverage area, and threat avoidance
3. The system shall support interchangeable sensor payloads including EO/IR electro-optical cameras and SIGINT collection suites, with payload change achievable within 4 hours at a forward operating base
4. The system shall maintain safe and controlled flight in the event of primary data link degradation for a minimum of 60 minutes
5. The system shall operate from runways as short as 1,500 metres to accommodate forward base deployment
6. The system shall provide intelligence data to the decision-maker with a latency not exceeding 30 seconds from sensor capture
7. The system shall achieve a mean time between maintenance events of not less than 200 flight hours

At the end of mission analysis, you should have a coherent package of documents and artefacts that justify the programme and provide the input for the next phase — Stakeholder Needs Analysis. For our UAV programme, the key deliverables are:

• Operational Concept Document (ConOps) — describes how the system will be used, who uses it, and in what environment
• Mission Analysis Report — the full analysis including operational context, stakeholder interests, mission scenarios, and capability gap assessment
• Operational Requirements Document (ORD) — the high-level requirements derived from the analysis
• Stakeholder Register — identified stakeholders, their interests, influence, and any known conflicts
• Initial Risk Register — programme-level risks identified during analysis (technology maturity, schedule pressure, regulatory uncertainty)

Having delivered mission analysis for programmes both large and small, here are the mistakes we see most often:

• Skipping scenario development and jumping straight to requirements — this produces requirements that look good on paper but don't reflect how the system will actually be used
• Including solution details in operational requirements — 'the system shall have a wingspan of 20 metres' is a design decision, not an operational need
• Failing to identify conflicting stakeholder interests early — conflicts discovered during design are expensive to resolve; conflicts discovered during integration are catastrophic
• Underestimating the operational environment — assuming benign conditions when the system will operate in contested, degraded, or denied environments
• Not involving operators in scenario development — engineers writing scenarios for operators produces scenarios that sound plausible but miss the realities of operational stress, fatigue, and decision-making under uncertainty