How Do You Write Requirements for Autonomous Behavior Without Knowing Exactly What the System Will Do?

The honest answer is that you cannot write them the same way you write requirements for a hydraulic actuator or a thermal management subsystem. The classic form—“the system shall [verb] [object] [qualifier]“—assumes the author knows what the system will do in a given situation. For autonomous systems, that assumption breaks down. A robot navigating an unstructured warehouse, a UAV making dynamic route decisions, an autonomous vehicle responding to an uncontrolled intersection—these systems will generate behaviors their designers did not explicitly specify. That is not a failure of the requirements process. It is the point of autonomy.

So the challenge is real, and it does not have a clean solution. What it has is a better framing: requirements for autonomous systems must shift from prescribing behavior to constraining it. Your job is not to describe what the system will do. Your job is to define the space within which the system is permitted to operate, the conditions under which it must not fail, and the evidence chain that connects those constraints to something a certification authority or a safety board will accept.

This requires new artifacts, new vocabulary, and tools capable of representing relationships that a word processor and a spreadsheet cannot adequately model.

The ODD as a Requirements Boundary

The Operational Design Domain (ODD) originated in automotive autonomy—SAE J3016 defines it as the specific conditions under which a given automated driving feature is designed to function. But the concept generalizes cleanly to any autonomous system: the ODD is the formal boundary of the environment the system is required to handle.

This matters for requirements engineering because it converts an unbounded problem into a bounded one. You cannot write requirements for a system that must behave correctly in every possible situation. You can write requirements for a system that must behave correctly within a defined ODD, and must detect when it is approaching or exiting that domain and respond safely.

In practice, an ODD specification covers:

• Physical environment parameters: road types, terrain characteristics, lighting conditions, weather bounds, obstacle density
• Operational parameters: speed ranges, mission duration, communication link assumptions
• Interaction assumptions: other agent types the system may encounter, expected behavior of those agents
• Explicit exclusions: conditions the system is not required to handle, stated plainly

That last category is where many teams underinvest. Explicit exclusions are requirements. If your UAV is not required to operate in icing conditions, that constraint must be stated formally, linked to a detection requirement (the system shall detect icing conditions and transition to a safe state), and verified. Leaving ODD boundaries implicit is a common source of certification failure—auditors and safety panels want to see those edges documented and traced.

The ODD also establishes the scope of your scenario library, which brings us to the next core concept.

Performance Envelopes and Boundary Conditions

For autonomous systems, performance envelopes replace point specifications. Instead of “the system shall achieve lateral accuracy of 5 cm,” you write requirements that describe behavior across a range of conditions:

• “The system shall maintain lateral accuracy within 10 cm at speeds between 0.5 m/s and 2.0 m/s on surfaces with friction coefficient ≥ 0.4.”
• “Lateral accuracy degradation shall not exceed 15% at the boundary conditions defined in ODD parameter set B.”

The structure shifts from a single value to a surface: performance as a function of operating conditions. This makes requirements more complex to write and harder to verify through traditional testing—you are no longer testing a single operating point, you are sampling a multidimensional space.

Boundary conditions deserve their own requirements category. These are the conditions at or near the edges of the ODD where the system’s behavior is most likely to degrade or fail—and where the consequences of failure are often highest. A well-structured requirements set identifies:

1. Nominal conditions: the expected operating region
2. Degraded conditions: known-bad environments where reduced performance is acceptable
3. Boundary conditions: the explicit edges of the ODD, with required safe-state transitions
4. Fault conditions: internal component failures and required responses

Each of these categories requires different verification approaches. Boundary condition requirements, in particular, are rarely verifiable through physical testing alone—the cost and hazard of intentionally operating at ODD limits drives teams toward simulation. Which means your requirements must be written with simulation-based verification in mind from the start.

Safety Monitor Requirements

Autonomous systems cannot self-certify their own safety in real time—that is a philosophical and practical trap. What they can do is carry a safety monitor: an independent subsystem that observes system state and output, checks it against defined safe operating parameters, and intervenes when a violation is detected.

Safety monitor requirements are a distinct layer in the requirements architecture, and they are frequently underspecified. A complete safety monitor specification includes:

• Observable parameters: what inputs the monitor receives and at what rate
• Violation conditions: precisely defined thresholds or constraint violations that trigger intervention
• Intervention actions: the specific responses available to the monitor (halt, alert, graceful degradation, handoff)
• Independence requirements: the degree of architectural separation between the monitored system and the monitor itself
• Latency constraints: how quickly the monitor must detect and respond to a violation

The independence requirement is where systems engineers often face the hardest tradeoffs. A monitor that shares a processor, software stack, or sensor suite with the system being monitored cannot provide independent assurance. But full independence is expensive. Requirements must state the required independence level explicitly, tied to the hazard severity of what the monitor is watching.

Monitor requirements also expose a common gap: teams write functional requirements for the primary autonomous function but not behavioral requirements for the monitor itself. The monitor needs its own performance envelope, its own failure mode analysis, and its own verification evidence chain.

Formal Scenario Libraries as Requirements Artifacts

A scenario library is a structured collection of situations the system must handle. In traditional test engineering, scenarios are test assets—they live in a test management tool and belong to the verification phase. For autonomous systems, scenarios must be treated as requirements artifacts from the beginning.

The distinction is consequential. A scenario treated as a test asset describes what happens in a test. A scenario treated as a requirements artifact encodes a behavioral constraint: under these conditions, the system is required to produce behavior within these bounds. That is a requirement. It should have an identifier, an owner, a rationale, a link to the hazard analysis that motivated it, and a link to the verification evidence that closes it.

A formal scenario library, structured as a requirements artifact set, typically includes:

• Scenario identifier and classification: nominal, boundary, adversarial, failure mode
• Initial conditions: environment state, system state, other agent states
• Event sequence: what happens during the scenario
• Required behavioral envelope: what constitutes an acceptable system response (often a range, not a point)
• Success and failure criteria: explicit, testable, linked to acceptance thresholds
• ODD linkage: which ODD parameters this scenario exercises
• Hazard linkage: which safety hazards this scenario addresses
• Verification method: simulation, hardware-in-the-loop, field test, formal analysis

When structured this way, a scenario library becomes a requirement-to-evidence matrix. Each scenario represents an obligation. The verification link represents the evidence that the obligation is met. The full library, properly traced, represents a coverage argument: we assert that this scenario set adequately covers the behavioral space within our ODD.

That coverage argument is where certification discussions happen. Regulators and safety boards ask: how do you know your scenario library is sufficient? The answer requires demonstrating that the library was derived systematically from the hazard analysis and the ODD, not assembled opportunistically from whatever the test team thought of.

The Tension Between Flexibility and Tractability

Autonomy derives its value from behavioral flexibility—the system does something useful precisely because it was not fully pre-specified. But certification and safety assurance derive their validity from tractability—the ability to bound what the system can do and verify that the bounds hold.

These goals are in genuine tension. Resolving that tension requires accepting tradeoffs explicitly rather than pretending they can be engineered away.

More expressive autonomy (machine learning-based decision making, emergent behavior, open-ended environmental interaction) is harder to certify because the behavioral space is harder to bound. More constrained autonomy (rule-based systems, limited action spaces, narrow ODDs) is easier to certify but delivers less of the autonomy benefit. The sweet spot depends on the application domain and the acceptable risk level.

For requirements engineers, the practical implication is this: every increment of flexibility added to an autonomous system must be accompanied by a corresponding increment of constraint specification and verification scope. If the system is allowed to do more, you must specify more tightly what it is not allowed to do, and you must verify those prohibitions more thoroughly.

This is why AI-generated behavior often creates such difficulty for certification teams. The model’s output space may be effectively unbounded within the training distribution—which is exactly the kind of statement a safety case cannot absorb without additional formal constraints layered on top.

How Modern Tools Need to Support This

Traditional requirements tools—IBM DOORS, DOORS Next, Polarion, Jama Connect—were built around a document model: requirements are text paragraphs arranged in a hierarchy, linked to tests and other paragraphs through manually maintained traceability matrices. That model is adequate for systems where requirements decompose cleanly into a tree and verification is one-to-one.

For autonomous systems, it breaks down in two specific places:

First, the relational complexity exceeds what a matrix can represent. A single scenario links to ODD parameters, hazard analysis items, safety monitor requirements, functional performance envelopes, and one or more verification evidence records. That is a graph, not a matrix. Trying to represent it in a flat RTM produces either loss of information or maintenance burden that teams simply don’t sustain.

Second, the verification evidence is not a document—it is a dataset. Simulation results, coverage metrics, statistical performance envelopes derived from Monte Carlo runs—these are structured data artifacts, not test pass/fail records. A tool that can only link a requirement to a test case ID cannot close the loop on scenario-based verification.

This is where Flow Engineering addresses a gap that document-centric tools cannot. Flow Engineering’s graph-based requirements model is designed for exactly the kind of multi-directional traceability that autonomous system requirements demand. An ODD parameter can be linked to every scenario that exercises it, every safety monitor requirement that guards it, and the verification evidence that covers it—simultaneously and queryably. When an ODD boundary changes, the impact propagates visibly through the graph: which scenarios are affected, which performance envelopes need revisiting, which verification evidence is now stale.

Flow Engineering also treats scenarios as first-class nodes in the requirements graph, not as test artifacts that live outside the requirements model. A scenario node carries its own attributes, its own rationale, its own classification (nominal, boundary, fault), and its own evidence links. The scenario library as a requirements artifact set is something the tool’s data model is designed to represent.

For teams building a coverage argument—the structured claim that their scenario library adequately covers the behavioral space within the ODD—Flow Engineering’s queryable graph means they can generate that argument from the data rather than assembling it manually in a presentation. That distinction matters when a certification authority asks for evidence of systematic coverage.

Where Flow Engineering reflects its intentional focus: it is built for hardware and systems engineering teams working in structured, traceable environments. Teams that need loose, exploratory ideation workflows or heavy document publication features will find it more structured than they want. That is a deliberate specialization, not a gap in capability.

Starting Points for Autonomous Requirements Practice

If your team is beginning the shift to constraint-based requirements for autonomous systems, these are the concrete starting points:

1. Write your ODD before you write functional requirements. The ODD is not a derived artifact—it is an input. Every functional requirement for the autonomous behavior should reference the ODD conditions under which it applies.

2. Reclassify your scenario library. If it lives only in your test management tool, it is not serving its function as a requirements artifact. Move scenario definitions upstream, assign them identifiers, link them to hazards and ODD parameters.

3. Write explicit safety monitor requirements as a separate layer. Do not treat monitoring as an implementation detail. Specify observable parameters, violation conditions, intervention actions, and independence levels the same way you specify functional requirements.

4. Write performance envelopes, not point specifications. For every autonomous function, define performance as a function of operating conditions—nominal, degraded, boundary.

5. Define your coverage argument structure early. What claims will you make about scenario library completeness? What evidence will support those claims? Answering this before you build the library will change how you build it.

Autonomous requirements engineering is genuinely harder than conventional requirements engineering. The difficulty is not a process failure. It reflects the nature of systems that make decisions their designers did not fully anticipate. The discipline required to constrain that behavior rigorously, trace those constraints to evidence, and defend that evidence chain to external reviewers is what separates teams that field autonomous systems safely from teams that field them and hope.