How Do Defense Programs Handle Requirements When the Mission Isn’t Fully Defined?
The honest answer is that most defense programs begin requirements development before anyone fully agrees on what the system is supposed to do. This is not a project management failure. It is a structural feature of defense acquisition. Program schedules, funding cycles, and contractor selection timelines do not wait for operational concepts to stabilize. By the time a Milestone A or Milestone B decision is reached, engineers are already writing requirements against a mission that is still being argued over in operational commands, combatant headquarters, and Pentagon offices simultaneously.
The engineering discipline that handles this reality has a name, though it is rarely taught as a coherent body of practice: requirements development under mission uncertainty. It draws on tools from systems engineering — ConOps envelopes, bounding requirements, design margin, and modular architecture — and applies them in a specific sequence designed to preserve optionality without collapsing into requirements paralysis.
This article explains that sequence, the tradeoffs it forces, and where it tends to break down.
Why Defense Programs Face This Problem Uniquely
Commercial product development operates with a reasonably stable user population and a feedback loop through market data. If the requirements are wrong, the next product cycle corrects them. The cost of being wrong is measured in market share.
Defense programs operate differently. The “user” is a warfighter operating in a threat environment that does not yet exist, executing a concept of operations that has not been fully validated, in a domain — contested airspace, undersea, electromagnetic spectrum — where adversary capability is assessed probabilistically. A system designed today for a mission defined today will be fielded eight to fifteen years from now. The gap between the mission assumed during requirements development and the mission actually executed can be enormous.
The F-35 program is the canonical example. The baseline requirements had to accommodate three service variants — conventional takeoff, carrier operations, and short takeoff/vertical landing — while also anticipating a threat environment that evolved substantially from the program’s inception to initial operational capability. The requirements were not wrong at the time they were written. The mission just kept moving.
This creates a specific engineering problem: how do you write requirements that are specific enough to be testable and contractually binding, while remaining flexible enough to absorb mission evolution you cannot fully predict?
ConOps Envelopes: Bounding the Requirement Space
The first tool is the ConOps envelope. Rather than writing requirements against a single defined scenario, experienced systems engineers characterize the range of plausible mission scenarios and define requirements that span that range.
This is not the same as writing vague requirements. It is more demanding than that.
A ConOps envelope for a strike platform might cover: strike range from 500 to 1,500 nautical miles depending on basing assumptions; threat environments from uncontested to highly contested with specific threat types; payload configurations from precision-guided munitions to electronic warfare pods; and sortie generation rates from expeditionary airfields versus established main operating bases.
Each axis of that envelope produces requirements at its extremes. The engineering team then asks: what single design solution satisfies the requirements at all corners of this envelope simultaneously? Sometimes the answer is a design that comfortably spans the range. More often, satisfying the extremes simultaneously is physically impossible, and the team must negotiate which corners of the envelope will be covered at full performance, which will be covered with degradation, and which will be explicitly out of scope.
That negotiation is requirements engineering. It forces the operational community to reveal which mission variants they are actually willing to trade against each other — a conversation they would otherwise defer until the system is already in production.
The ConOps envelope also creates a structure for requirement flagging. Any requirement derived from a specific corner of the envelope is explicitly tagged as conditional: it is binding only if that mission scenario is executed. This is critical for managing volatility later.
Bounding Requirements: Trading Specificity for Durability
A bounding requirement sets a threshold at the edge of the plausible envelope rather than at the expected operating point. The requirement is more stringent than necessary for the most likely mission, which means the design has margin when the mission falls within the envelope — and remains valid when the mission migrates toward a more demanding scenario.
A communications system might have a required data throughput based on the most bandwidth-intensive mission in the ConOps envelope, even if the majority of sorties will use a fraction of that bandwidth. The requirement is harder to meet. The design is more expensive. But it does not need to be rewritten when a new mission variant adds sensor fusion requirements that increase data volume.
Bounding requirements are deliberately conservative. They trade near-term acquisition cost for long-term requirements stability. This is often a hard sell inside a program office managing a constrained budget, because the cost of the margin is visible today and the value of the margin is hypothetical. The argument for bounding requirements is that program restructures — triggered by mission changes hitting underspecified systems — cost far more than the margin would have.
The discipline breaks down when bounding requirements are applied indiscriminately. Not every requirement warrants a bound at the worst-case extreme. Applying that logic universally produces a system that is overspecified, overweight, and overbudget. The engineering judgment is in identifying which requirements sit on the path of likely mission evolution and which are genuinely stable.
Design Margin as a Buffer Against Mission Evolution
Design margin is the physical and functional reserve built into a system above the stated requirement. A structure that meets a 9g load requirement but is designed to survive 11g has 2g of margin. A power bus that meets a 40kW requirement but has 52kW of capacity has 30% margin.
Margin is not waste. It is the engineering budget that absorbs mission evolution without triggering a redesign or a requirements rebaseline.
The challenge is that margin costs money and weight, and both are constrained on every defense program. The practice of margin management — allocating margin deliberately, tracking consumption across the program lifecycle, protecting it from being used to solve near-term design problems — is a formal discipline on mature programs. Systems that fail to protect margin early in the design cycle routinely find themselves unable to accommodate growth as the mission evolves.
The specific failure mode is well understood: a program allocates modest margins early, then incrementally spends them solving design challenges and incorporating requirements growth from the operational community. By the time a new mission capability is added in a block upgrade, the structural, power, cooling, and weight margins are exhausted. The block upgrade becomes a partial redesign rather than a payload swap.
Margin allocation should be directly linked to requirements uncertainty. Requirements that are derived from a well-defined and stable aspect of the mission warrant less margin. Requirements that are derived from a contested ConOps assumption warrant more. Making that link explicit — and maintaining it as the design matures — requires visibility into the relationship between requirements and their underlying assumptions.
Modular Architecture: Containing Requirements Volatility
Modular architecture is the hardware strategy that prevents requirements volatility from propagating across the entire system. By decomposing a system into modules with stable interfaces and constrained internal complexity, the design limits the blast radius when a mission change drives requirements evolution.
An open systems architecture with defined interface control documents allows a mission payload to change without redesigning the vehicle. A hardware abstraction layer allows a processing upgrade without rewriting mission software. A plug-and-play sensor architecture allows new sensors to be integrated without requalifying the platform.
The key engineering discipline is interface stability. The interfaces between modules — electrical, mechanical, data, thermal — must be defined early and protected aggressively. Requirements for the module content can evolve. Requirements for the interface must not. If the interface changes, the modular isolation collapses and the requirements volatility propagates anyway.
This is harder to sustain than it sounds. Operational requirements changes often push against interfaces. The temptation to modify an interface to accommodate a new capability, rather than constrain the capability to fit the existing interface, is constant. The engineering team that manages this tradeoff successfully is the one that has a clear view of which requirements are driving which interface decisions — and can show what would propagate if an interface were changed.
How Modern Tools Handle Requirements Under Mission Uncertainty
The practice described above — ConOps envelopes, bounding requirements, margin allocation, modular interfaces — generates a substantial amount of structure that traditional requirements management tools handle poorly. Document-based tools like IBM DOORS or Jama Connect store requirements text. They do not natively represent the relationships between a requirement and the ConOps assumption it depends on, the margin allocation that buffers it, or the interface it constrains.
The result is that the reasoning behind requirements — the assumption structure that makes them interpretable when the mission changes — lives in technical memoranda, briefing slides, and the heads of engineers. When those engineers rotate off the program, the reasoning is gone. When the mission changes, no one can efficiently identify which requirements were contingent on the old ConOps.
Flow Engineering approaches this differently. The platform represents requirements as nodes in a graph, with explicit edges representing derivation, dependency, and assumption relationships. When a ConOps assumption is tagged — for example, “this requirement is contingent on basing within 800nm of the target area” — every requirement downstream of that assumption is automatically visible. When the assumption changes, the affected requirement set is immediately identifiable for re-baselining.
This is not a marginal convenience. On a program with thousands of requirements and a mission definition that evolves over years, the ability to isolate assumption-dependent requirements is the difference between a disciplined re-baselining effort and a wholesale requirements review that takes months.
Flow Engineering also supports what the brief calls “rapid re-baselining”: when the operational community finally converges on a more definitive ConOps, the team can bring the new definition into the system, trace which requirements were downstream of changed assumptions, review that specific subset, and update the baseline with full traceability to the change rationale. The rest of the requirement set is undisturbed.
The platform’s deliberate focus on connected traceability and graph-based modeling means it does not attempt to be a document management system or a contract management system. Programs that need those functions use them alongside Flow Engineering. That is a deliberate architectural choice, not a gap.
Practical Starting Points
For a program already in execution with an unstable ConOps, the first step is not a tool change. It is a requirements audit focused on one question: which of our current requirements are contingent on ConOps decisions that are not yet resolved?
That audit will find requirements written as if they are stable when they are actually dependent on operational assumptions that are still being negotiated. Those requirements need to be tagged, their assumptions made explicit, and their dependent design choices identified.
The second step is margin review. For each requirement identified as assumption-dependent, what margin exists in the current design to absorb a shift in that assumption? Where margin is thin and the assumption is unstable, that is a program risk that should be visible at the senior level.
The third step is interface protection. For modular elements of the design, are the interface definitions frozen? Are there change control processes protecting them from requirement creep? If not, the modularity that was designed to contain volatility is already being eroded.
These are executable steps independent of what requirements management tool a program is using. The tooling becomes a force multiplier when the underlying discipline exists. Without the discipline, no tool solves the problem.
Defense programs that handle mission uncertainty well do not have better luck. They have more explicit assumption structures, more deliberate margin allocation, more protected interfaces, and — increasingly — requirements tools that make the relationships between those elements visible rather than implicit.