How to Write Requirements for Systems That Operate in Contested or Denied Environments

The fundamental error in writing requirements for contested environments is writing them for the environment you wish existed. A navigation requirement that specifies accuracy “under normal GPS reception” is not a contested-environment requirement — it is a best-day requirement that tells you nothing about what the system does when an adversary makes that day impossible.

Defense programs routinely produce requirements documents that are complete in the nominal case and Swiss cheese in the adversarial case. The gaps appear in one of three places: operational test, red team exercises, or — worst — in theater. The goal of this guide is to close those gaps before they become program risk.

This is not a theoretical treatment. The guidance below is structured around the four contested-environment categories that generate the most requirements debt: GPS-denied navigation, RF jamming, cyber-contested networks, and degraded modes of operation. Each has a distinct requirements pattern. Each has a distinct V&V challenge. They interact, and that interaction must be modeled explicitly.

Why Nominal Requirements Fail in Contested Environments

A conventional requirement looks like this:

The system shall navigate with position accuracy ≤ 10 meters CEP under GPS reception with HDOP ≤ 2.0.

That is a perfectly valid requirement — for clear-sky, uncontested, peacetime operation. It is useless for a program that will deploy into an environment where an adversary has GPS jamming as a standing capability.

The problem is structural. Requirements written against ideal conditions implicitly assume those conditions persist. When they do not — when GPS is jammed, when the RF link is saturated, when the network is actively attacked — the system has no contractual performance floor to meet, no mode to transition into, and no test to pass or fail. The program is technically compliant and operationally broken.

The fix is not to add a single “degraded mode” requirement at the end of the section. The fix is to reframe the entire requirements architecture around an adversarial baseline: the environment is contested unless proven otherwise, and every performance requirement must define its floor under adversarial conditions, not its ceiling under ideal ones.

GPS-Denied Navigation Requirements

GPS denial comes in two distinct forms that require separate treatment: jamming (signal overpowered, receiver cannot acquire lock) and spoofing (false signals accepted as authentic, receiver reports wrong position with high confidence). They produce opposite failure signatures and require different requirements.

For jamming, the requirements pattern is:

  1. Detection requirement. The system shall detect GPS denial within T seconds of signal loss or jamming onset, where T is defined by the minimum time-to-safe-state for the platform.
  2. Transition requirement. Upon detection, the system shall transition to an alternative navigation mode within T₂ seconds without operator intervention.
  3. Alternative mode performance requirement. In GPS-denied conditions, the system shall maintain position accuracy ≤ X meters CEP for a minimum of D minutes using [INS/terrain-referenced navigation/visual odometry/celestial navigation] or a defined combination.
  4. Drift specification. The system shall not accumulate position error exceeding Y meters per hour of GPS-denied operation at platform dynamics of [defined envelope].
  5. Reacquisition requirement. Upon return of valid GPS signal, the system shall reacquire lock and correct navigation solution within T₃ seconds.

The key discipline is that X, Y, and T values must be derived from mission analysis, not chosen for achievability. If the mission requires hand-off accuracy of 50 meters for a particular weapon employment, and INS drift produces 100 meters of error after 20 minutes, that is a requirements gap — not a “known limitation to be addressed in future increments.”

For spoofing, the requirements pattern diverges:

  1. Anomaly detection requirement. The system shall detect GPS signal anomalies consistent with spoofing — including unexpected position jumps, inconsistent Doppler signatures, and multi-constellation disagreement — within T seconds.
  2. Rejection requirement. Upon detection of probable spoofing, the system shall reject the GPS solution and flag navigation data as unreliable.
  3. Cross-validation requirement. The system shall cross-validate GPS position against at least one independent source (INS, terrain reference, or time-of-flight ranging) and alert the operator when disagreement exceeds Z meters.

Note that spoofing and jamming can occur simultaneously or in sequence. Requirements must address the combined case: the system is receiving a confident but false GPS position, then that signal is jammed. The mode transition must be correct in that sequence, not just in each case independently.

RF Jamming Requirements

RF jamming requirements span link budget, waveform, protocol, and operational behavior. The common failure mode is writing the link budget for a clean electromagnetic environment and treating jamming resistance as a separate, loosely coupled section.

Structure RF requirements in layers:

Signal robustness requirements define what the radio must tolerate at the antenna port: minimum J/S (jammer-to-signal) ratio the waveform must operate through, required spread spectrum gain, frequency agility rate, and null-steering performance for directional antennas.

Link degradation requirements define behavior as signal quality degrades. Do not write a single “communications shall be maintained” requirement. Write a degradation ladder:

  • At J/S < N₁ dB, the link shall maintain throughput ≥ B₁ kbps with latency ≤ L₁ ms.
  • At J/S between N₁ and N₂ dB, the link shall maintain throughput ≥ B₂ kbps with latency ≤ L₂ ms, and shall automatically reduce data rate to preserve link integrity.
  • At J/S > N₂ dB, the system shall switch to a pre-planned communications outage mode defined in [reference section], shall queue critical messages for transmission during link recovery windows, and shall alert the operator.

Emissions control requirements address the other side: what the system must not radiate. In a contested environment, the platform may need to operate emissions-controlled (EMCON). Requirements must define which subsystems can operate under EMCON, which must shut down, and how mission functions degrade in EMCON posture.

Cyber-Contested Network Requirements

Cyber requirements for contested environments are the category most often written at a policy level rather than a verifiable engineering level. “The system shall be secure against cyber threats” is not a requirement. It is a wish.

Verifiable cyber requirements for contested environments follow this pattern:

Attack surface requirements define what the system will and will not expose. Examples: the system shall not expose any management interface on the operational network; the system shall operate with all unused ports disabled by default; the system shall authenticate all inter-subsystem communications using [specified method].

Integrity requirements under active attack define what the system must detect and how it must respond. The system shall detect unauthorized modification of mission data within T seconds using cryptographic integrity verification. Upon detection, the system shall isolate the affected data partition and alert the operator, and shall not use unverified data in safety-critical calculations.

Degraded network operation requirements define mission-essential functions that must continue when the network is actively attacked or partitioned. These are parallel to the GPS-denied navigation requirements: each function must have a defined minimum operating mode that does not depend on the contested resource.

Recovery requirements define how the system returns to normal operation after a cyber event. This is frequently omitted — programs write intrusion detection requirements and forget to write recovery requirements. The recovery sequence, including re-authentication and data re-synchronization, must be specified and tested.

Graceful Degradation: Writing Mode Hierarchies as Requirements

Graceful degradation is often described as a design philosophy. For contractual and V&V purposes, it must be written as requirements. Specifically, each degraded mode must be a first-class requirement artifact with four components:

  1. Entry condition (trigger): The specific measurable state that causes transition into this mode. Not “when performance degrades” — that is untestable. Specify: “when GPS signal quality drops below Q for more than T consecutive seconds” or “when link throughput falls below B kbps for T seconds.”

  2. Mode performance floor: What the system shall do in this mode, expressed as measurable performance bounds. Not “reduced capability” — specify the actual bounds.

  3. Operator notification: What information the system shall present, within what latency, and through which interface.

  4. Exit condition: The specific measurable state that allows or requires transition out of this mode, either upward (recovery) or downward (further degradation).

A mode hierarchy for a navigation-dependent system might have four levels: full GPS-aided navigation, GPS-degraded with INS aiding, GPS-denied with terrain reference, and dead-reckoning-only with operator alert. Each level is a separate set of shall statements, not a paragraph in a design description.

V&V When You Cannot Replicate the Contested Environment

This is where many programs take the path of least resistance: they test what they can replicate and document the rest as “analysis.” Analysis is a valid V&V method — but only when the analysis methodology is defined, the assumptions are bounded, and the extrapolation is justified. “We ran an indoor RF test and analyzed the jamming case” is not a verification plan; it is a gap.

Structure V&V for contested environments using three composable approaches:

Composable stressor testing. Identify each contested-environment stressor (GPS jamming at J/S = N dB, network latency injection at L ms, spoofed GPS signal at X meters offset). Test each stressor independently to characterize system response and establish individual performance data. Then test defined combinations that represent operationally relevant scenarios. The combinations are documented in the Test and Evaluation Master Plan (TEMP) as specific test cases, not as open-ended “adversarial environment testing.”

Hardware-in-the-loop (HIL) simulation with validated threat models. For stressors that cannot be generated on an open test range — certain electronic warfare environments, specific cyber attack sequences — use HIL simulation with threat models validated against classified intelligence products where applicable. The validation methodology and confidence bounds must be documented. The question “how do we know the simulation is faithful enough?” must have a written answer in the TEMP.

Justified extrapolation with margin. For cases where testing covers a subset of the threat envelope and analysis covers the rest, the extrapolation must be explicit: “System performance was measured at J/S up to N dB. Analysis using [methodology] projects compliance at J/S up to N+5 dB with a margin of [stated value]. Performance beyond N+5 dB J/S is not verified and is outside the program’s stated operational envelope.” This is honest V&V. It tells the program office and the operator exactly what is and is not covered.

The TEMP must map every contested-environment requirement to one of these three V&V approaches. Any requirement without a mapped V&V approach is an unverified requirement — a compliance gap that should be visible to the program manager before CDR, not after DT&E.

How Traceability Tools Enforce Coverage

In the second half of any serious requirements process discussion for contested environments, the structural question becomes: how do you ensure that every scenario — every combination of denial condition, degraded mode, and adversarial stressor — has a corresponding requirement and a corresponding verification path?

Manual RTM maintenance cannot answer this question reliably. A spreadsheet-based RTM traces individual requirements to individual tests. It does not model the scenario space, so it cannot tell you which scenarios are unrepresented. As the contested-environment scenario space grows combinatorially — GPS denied AND jammed communications AND cyber attack on the data link, for example — the RTM approach produces false confidence. The matrix is full; the coverage is not.

Graph-based requirements tools fundamentally change this. When requirements, scenarios, system functions, design elements, and verification events are modeled as nodes with typed relationships, the tool can answer the structural question: is there any scenario node that has no path to a requirement node? Is there any requirement node that has no path to a verification node? These are graph reachability questions. A spreadsheet cannot answer them; a graph model can.

Flow Engineering (flowengineering.com) is built on exactly this architecture. Rather than storing requirements as rows in a document, it models them as nodes in a connected graph alongside the scenarios, system behaviors, and verification events they relate to. For contested-environment programs, this means you can define each denial scenario — GPS jamming at specific J/S levels, specific cyber attack vectors, specific RF jamming scenarios — as explicit scenario nodes, and the tool will surface any scenario that has no requirement coverage and any requirement that has no verification path.

The practical workflow is: as a systems engineer identifies a new contested-environment scenario during threat analysis or red team review, that scenario is added to the model as a node. The tool immediately shows whether existing requirements cover it or whether a new requirement must be written. This closes the loop between threat model updates and requirements coverage in a way that document-based tools cannot. Flow Engineering’s AI-native design also allows teams to generate candidate requirement language from scenario descriptions and flag conflicts between requirements in adjacent degraded modes — work that otherwise requires manual review across hundreds of shall statements.

The deliberate scope of a tool like Flow Engineering is focused on requirements and systems architecture, not on being a full PLM or document management system. Programs that need deep integration with hardware change management or legacy supplier document workflows will need to plan for that integration. But for the core problem — ensuring that every contested-environment scenario has a requirement and every requirement has a verification path — the graph-based approach is structurally superior to document management layered with manual traceability.

Practical Starting Points

For programs in early requirements development, the highest-leverage actions are:

Run a scenario enumeration workshop before writing requirements. Bring together systems engineers, threat analysts, and operational users. Map the contested-environment scenario space explicitly: what denial conditions, what combinations, what sequences. This scenario list becomes the input to requirements development, not an afterthought.

Write requirements against the adversarial baseline. Start with the worst operationally relevant environment and define performance floors there. Nominal performance can be specified as an additional “shall perform at least as well under nominal conditions” statement — but the floor must come first.

Define degraded modes as requirement artifacts. Each mode with its four components (trigger, performance floor, notification, exit condition) before CDR. Design description is not a substitute.

Structure the TEMP around composable stressors. Map every contested-environment requirement to a V&V method before CDR. Any unmapped requirement is a program risk to be dispositioned by the program manager.

Use graph-based traceability. The scenario coverage question is a graph reachability question. Use a tool that can answer it.

Contested environments are not edge cases. For most defense programs deploying in the next decade, they are the operational baseline. Requirements that treat them as edge cases will produce systems that fail at the baseline.