What Are Operational Scenarios?
An operational scenario is a description of an imagined sequence of events in which a system interacts with its users and its environment, and in which the system’s own parts interact with each other. It is a story about use: what starts the sequence, who or what does each step, in what order, under what conditions, and what passes between them.
Systems engineering uses operational scenarios to make the operational conditions a system must meet specific enough to design to, and later specific enough to check against.
The concept of operations
Scenarios sit inside a wider description of intended use, usually called the concept of operations (ConOps) or operational concept. A ConOps describes how the system will be used, from the viewpoint of the people who will operate, maintain and depend on it, and is deliberately non-technical.
It bridges the often-vague needs that motivated a project and the specific technical requirements that follow, and the operational scenarios are the heart of it.
The two names are used interchangeably in most of the field, although some industries reserve “operational concept” for a broader, multi-organisation view and “concept of operations” for a single project, and others use them the opposite way round.
Related terms
- A mission is the purpose a system exists to serve: the “why” behind the project.
- A design reference mission is a detailed scenario for one phase of that mission, used as a reference for deriving requirements. A spacecraft might have one for launch, another for on-orbit operations and another for re-entry.
- Use case is the term favoured in model-based systems engineering.
- In design reviews of a single product, the same idea appears as the product’s mission scenario or operational profile.
This guide covers where scenarios come from, what a scenario contains, why scenarios matter to requirements and to validation, where gaps in a scenario set come from, and a short case study: the Merlin engine’s negative-g cut-out in the Battle of Britain.
Where scenarios come from
Operational scenarios are produced early, before design, as part of defining the problem.
In the life cycle process set out in ISO/IEC/IEEE 15288, the first activity of concept definition is business or mission analysis. It establishes the problem, threat or opportunity a system is meant to address; defines the mission, goals, objectives and measures of success; and captures the conditions in which the system must operate. Its questions include what the intended use is, and in what operating environment.
From mission analysis come the preliminary life cycle concepts, of which the operational concept is one.
These include operational modes and states, operational scenarios, potential use cases, misuse cases and loss scenarios. The same concepts are written for the rest of the life cycle as well: acquisition, manufacture, deployment, maintenance and retirement. The scenarios are then refined during stakeholder needs definition and used to derive requirements.
For existing systems being updated, the same analysis asks what the current system can no longer do, including changes forced by a changed operational environment or by new threats. A scenario set is therefore not fixed at the start of a programme. It is revisited whenever the way a system is used, or the world it is used in, changes.
What a scenario contains
Each scenario describes a sequence of events and activities carried out by the user, the system and the environment. A complete one states:
- what triggers the sequence;
- who or what performs each step;
- when communications or exchanges occur, and between which parties;
- what information, material or energy is exchanged;
- the environmental conditions in force during the sequence.
Coverage
A set of scenarios is judged by its coverage as much as by the quality of any single one. Guidance on writing a ConOps asks for scenarios covering normal conditions, stress conditions, failure events, maintenance, and anomalies and exceptions. NASA’s concept of operations outline frames the same coverage more generally:
- Nominal conditions: normal circumstances, with no problems or anomalies.
- Off-nominal conditions: failures, substandard performance, unexpected environmental conditions or operator errors, which should reveal any extra capabilities or safeguards the system needs.
It also asks for scenarios that include the viewpoint of every stakeholder involved and make clear who is doing what. The aim is to describe all the system’s modes, normal and failure, as each stakeholder would see them.
Coverage over the whole life cycle
Coverage has a time dimension too. A purely operational view tends to describe only the system doing its job. Scenarios for transport, installation, storage and maintenance reliably surface requirements that operational scenarios miss. Transport, handling, maintenance and storage are often more critical for reliability than the conditions during actual use: an item spends much of its life being shipped, stored, handled and taken apart, not operating.
For example, the nominal Space Shuttle mission flew to orbit and landed back at the launch site. Separate scenarios were needed for an abort during ascent: one for returning to the launch site, and another for an ascent too far downrange to glide back, which required approved runways overseas. Those scenarios produced requirements, for the vehicle and for facilities on the ground, that the nominal mission alone would never have revealed.
Why scenarios matter to requirements
Stated operational requirements commonly suffer from a predictable defect. They are broad and vague where they need to be specific, written to cover “all expected conditions” without saying what those conditions are. The standard remedy is to supplement them with a set of well-defined operational scenarios that represent the range of conditions the system must meet.
A requirement such as “the aircraft shall be manoeuvrable” says little.
A set of scenarios describing the manoeuvres expected in service, in what sequence and under what loads, gives designers something to design to.
Scenarios reveal requirements in three ways:
- They expose functions. Walking through how the system will be used shows functions and interfaces that a list of capabilities leaves implicit.
- They expose conditions. Each scenario carries an environment: loads, temperatures, attitudes, pressures, durations. The extremes of the scenario set define the envelope the design must survive.
- They expose interfaces. Wherever a scenario has two systems exchanging something, there is an interface requirement on both sides.
New uses, new scenarios
New uses produce new scenarios, and new scenarios produce new requirements. The Space Shuttle’s original reference mission was to carry cargo to orbit, deploy it and return, with a stay on orbit of two to three weeks at most.
When the International Space Station was planned, a new design reference mission was needed: a higher-inclination orbit, docking to another vehicle, and a much longer stay with most systems powered down.
Each difference raised questions the original scenarios had never asked, about thermal stresses, radiation and endurance on orbit. A system is only specified for the scenarios that have been written down.
Scenarios as the basis for validation
Scenarios are used twice. Early on, they are used to derive and evaluate requirements. Later, they are used to verify and validate the system that was built.
A ConOps is expected to provide the criteria for validating the completed system, and formal validation of a requirement set checks it against the operational scenarios and use cases, to judge whether a system built to those requirements could achieve the user’s objectives.
The scenario set therefore bounds what testing proves. Qualification testing, which is part of verification, confirms that a design meets its requirements in the anticipated environmental conditions, run at the extremes of the environmental envelope. “Anticipated” carries the weight: a condition that was never anticipated is not part of the envelope being tested.
Of the areas that operational testing should prioritise, susceptibility to severe operational environments is the one least likely to have been fully tested. Operational evaluation is sometimes the first time a system meets conditions closely resembling those it was built for. Test plans are therefore expected to state their test limitations, and what those limitations mean for any conclusion about operational effectiveness. Validation can only be as complete as the scenarios it is run against.
Where scenario gaps come from
A gap in the scenario set is a condition the system will meet in service that nobody wrote down. Gaps commonly come from:
- A changed operational environment. The conditions of use move after the scenarios were written: a new role, a new climate, a new duty cycle.
- New threats. In military systems the operating conditions are partly set by an adversary, whose tactics are chosen to exploit whatever the system cannot do.
- Missing life cycle phases. Scenarios written only for operation omit transport, storage and maintenance.
- Missing off-nominal cases. Scenarios written only for success omit stress, failure and exception conditions.
A gap of any of these kinds goes unnoticed through design and verification, because both are measured against the same scenario set. It shows itself only when service use reaches the missing condition.
Case study: the Merlin negative-g cut-out, 1940 to 1943
The setting
The Battle of Britain was fought in the air between July and October 1940 (officially 10 July to 31 October). Germany aimed to gain air superiority over Britain in preparation for an invasion, codenamed Operation Sea Lion, and the Luftwaffe set out to incapacitate RAF Fighter Command. Fighter Command defended the United Kingdom with the Hawker Hurricane and the Supermarine Spitfire.
The more numerous Hurricane flew more sorties; the Spitfires mostly fought Luftwaffe fighters, mainly the Messerschmitt Bf 109E, a close match for them. Victory in the battle was decisively gained by Fighter Command.
The design choice
The Rolls-Royce Merlin powered the RAF’s Hurricane and Spitfire fighters at the start of the Second World War. Early Merlins used a float-controlled, twin-choke updraught carburettor made by SU. Carburation rather than fuel injection was a deliberate choice, calculated to give a higher specific power output: the fuel/air mixture entered the engine cooler, and therefore denser, than it would with an injected system.
The condition the design did not handle
During the Battle of France and the Battle of Britain in 1940, a problem appeared in combat. When a Merlin-engined fighter pitched its nose sharply down, the resulting negative g disturbed the fuel in the carburettor’s float chamber.
The fuel was thrown away from the outlet, first starving the engine. If the negative g continued, the float was driven to the bottom of the chamber. Because the float controlled the needle valve that regulated fuel intake, the carburettor then flooded and delivered an over-rich mixture, and the engine cut out.
The Bf 109E was powered by the Daimler-Benz DB 601, which had used direct fuel injection since 1937. Its fuel was kept at constant pressure by injection pumps, and it did not suffer from the problem. A Bf 109 pilot could escape a pursuing Hurricane or Spitfire by pushing straight over into a high-power dive, a manoeuvre the RAF fighter could not follow without its engine cutting out. RAF pilots learned to half-roll before diving in pursuit, so that the aircraft stayed under positive g, but the half-roll took extra time, which could allow the enemy to escape.
A float carburettor could not sustain a manoeuvre that combat made necessary, and this became decisive once the aircraft were fighting an opponent whose fuel system could.
The fixes
Beatrice Shilling, an engineer at the Royal Aircraft Establishment (RAE), Farnborough, devised a flow restrictor for the carburettor’s fuel supply, sized to allow just enough fuel for full engine power while limiting flooding under negative g. It could be fitted without taking aircraft out of service, and in early 1941 she led a small team around RAF fighter stations fitting it to Merlin engines. It was a partial fix: it allowed brief negative-g manoeuvres, but not inverted flight for any length of time. The cause was removed only from 1943, when later Merlins were fitted with a Bendix-Stromberg pressure carburettor that injected fuel directly into the supercharger.
The principles it demonstrates
- A design is proven only against the operational conditions it is checked against. The condition the float carburettor could not handle, a sustained nose-down push in combat, was one that service use made necessary. A scenario set that does not contain a condition produces a design that is not shown to handle it.
- Operating conditions in a contested environment are partly set by the adversary. The negative-g push-over mattered because an opponent with a different fuel system could use it to escape. Mission analysis explicitly includes threats as a source of requirements, and a changed threat is a recognised reason to revisit an existing system’s scenarios.
- Severe operational conditions are the ones least likely to have been tested. The problem was found in service, in combat, not before it. This is the pattern operational evaluation exists to catch, and the reason test plans are expected to state what their test conditions leave out.
- A design choice optimised against one measure can leave a gap against an unexamined condition. The carburettor was chosen for power density, a legitimate performance measure. Its weakness lay in a condition that measure did not include. Candidate solutions are assessed against the life cycle concepts, operational scenarios included, so a condition missing from those scenarios carries no weight in the trade.
Summary
Operational scenarios describe how a system will be used, step by step, under stated conditions, and sit at the heart of the concept of operations. They are produced before design, from mission analysis, and should cover nominal and off-nominal conditions across the whole life cycle.
They turn vague operational requirements into specific ones, and they later provide the conditions against which the built system is validated.
Because design, verification and validation are all measured against the same scenario set, a condition missing from the set can go unnoticed until service use reaches it, as the Merlin’s float carburettor showed in 1940.
More case studies
Sources
- SEBoK, “Operational Scenario (glossary)”, citing ISO/IEC/IEEE 29148:2011.
- SEBoK, “Business or Mission Analysis” (Katz, Wheatcraft, Ryan), SEBoK v2.14, 2026.
- US Federal Highway Administration, Systems Engineering for ITS, section 6.4, “Concept of Operations Template”.
- NASA / Saylor Academy, “Concept of Operations”, Space Systems Engineering 101 (video lecture).
- A. Kossiakoff et al., Systems Engineering Principles and Practice; B. S. Blanchard, Systems Engineering Management (requirements deficiencies, qualification, operational test, life cycle environments).
- Wikipedia, “Concept of operations”.
- Imperial War Museums, “8 things you need to know about the Battle of Britain”.
- Wikipedia, “Battle of Britain”, “Supermarine Spitfire”, “Miss Shilling’s orifice”, “Beatrice Shilling” and “Rolls-Royce Merlin” (citing Price 1986, Hooker 1984, Lumsden 2003, Freudenberg 2003 and others).
- IMechE Archive and Library, “International Women’s Day 2020: highlight on Beatrice Shilling”.
- Aircraft Engine Historical Society, review by G. White of M. Freudenberg, Negative Gravity: A Life of Beatrice Shilling.
- J. Whitfield, “Beatrice Shilling”, Thrust Vector, 2010.