What Is the Concept of Operations (ConOps) and How Does It Drive Requirements?
Requirements don’t emerge from a vacuum. Before a single “shall” statement is written, someone — a customer, a program manager, a safety authority — has a mental model of how the system will be used. That mental model, when made explicit and structured, is the Concept of Operations. When it stays implicit, you get requirements that pass review but fail the field.
ConOps is defined in IEEE 1362 as a document describing “the system from an operational standpoint” — but the definition undersells it. A ConOps is a stakeholder-facing narrative: it describes who uses the system, under what conditions, with what goals, alongside what other systems, and subject to what constraints. It is written in the language of operators and users, not engineers. It answers the question, “What does this system need to do in the real world?” before asking, “How should it be built?”
This article defines ConOps precisely, separates it from three artifacts it is routinely confused with, explains exactly how it generates — and corrupts — stakeholder requirements, and describes what a rigorous ConOps actually contains across three different domains.
ConOps Is Not These Other Things
The term is overloaded. Four artifacts frequently get labeled “ConOps,” and treating them as interchangeable causes real damage downstream.
ConOps (Concept of Operations): A stakeholder-facing narrative of operational intent. The audience is the people who will use, operate, maintain, and be affected by the system. The content is qualitative and scenario-driven. It describes the world the system will live in, not the system itself.
OperCon (Operational Concept): A systems-engineering artifact describing the intended behavior of the system as a whole — how it will function to meet operational needs. OperCon is more technical than ConOps and lives closer to the architecture. Where ConOps says “a UAV operator monitors multiple aircraft from a ground station during a 6-hour patrol,” OperCon says “the system shall maintain continuous telemetry with all active airframes within the operational area.” OperCon is derived from ConOps; it is not a synonym.
CONOPS Document (military/government usage): In DoD and NATO contexts, CONOPS (all caps) refers to a high-level command document describing how a military force will employ a capability in a campaign. This is a planning document written by operational commanders. It informs system acquisition ConOps but is not itself a systems engineering artifact.
System Concept: A preliminary description of a proposed solution — what the system looks like, what major components it includes, what technologies it employs. System concepts are generated in response to ConOps; they are design artifacts, not operational narratives. Writing a system concept before a ConOps is the classic error that leads to solutions searching for problems.
The practical implication: ConOps answers “what world does this system operate in and what is expected of it?” Everything else — OperCon, system concept, architecture — comes after that question is answered.
What a Good ConOps Actually Contains
ConOps documents vary widely in quality. The difference between a ConOps that drives clean requirements and one that generates six months of ambiguity late in development comes down to whether six structural elements are present.
1. Operator and User Profiles Who physically operates the system? Who uses its outputs? What is their training level, cognitive load, and operational authority? A ConOps for a medical infusion pump that does not specify whether operators are ICU nurses, home-care patients, or both has not answered the question. Different user profiles generate different use cases, different failure mode assumptions, and fundamentally different requirements.
2. Operational Environment Where will the system function? What are the physical conditions — temperature, vibration, EMI, lighting, network connectivity? What are the regulatory and institutional conditions — FAA airspace class, FDA classification, OSHA zone? Environment constraints that appear first in ConOps become design constraints and verification conditions. Environment constraints discovered at CDR become redesigns.
3. Use Cases with Preconditions and Success Criteria Not just “the system performs inspection” but: who initiates the inspection, what state is the system in before it starts, what constitutes a successful outcome, and what constitutes a safe failure. Each use case in a ConOps should be complete enough that a stakeholder can recognize whether their real-world operation is covered.
4. Operational Scenarios Including Off-Nominal Conditions Normal operations are easy. The requirements that kill programs are the ones generated by degraded-mode scenarios, contingency operations, and handoff procedures. A ConOps that only describes nominal operations is half a ConOps. How does the operator respond when communication is lost? Who takes control when the primary operator is incapacitated? What happens when two systems with conflicting authority are both active?
5. Constraint Sources Standards bodies, regulatory agencies, customer contractual requirements, and interface partners that will impose constraints on the system — named explicitly. This is not a requirement list; it is a map of where requirements will come from, so the requirements engineering team knows where to look.
6. Measures of Effectiveness What does operational success look like, quantitatively? Coverage area surveyed per hour, time from symptom onset to diagnosis, number of cycles completed per shift without human intervention. These measures become the basis for system-level performance requirements and, eventually, acceptance criteria.
How ConOps Drives Stakeholder Requirements — And Where It Fails
The mechanism is straightforward: each use case in the ConOps generates a set of stakeholder needs. Those needs, when structured and made testable, become stakeholder requirements. Those stakeholder requirements then drive functional and performance requirements at the system level.
The failure mode is equally straightforward: incomplete ConOps generates incomplete stakeholder requirements. The gaps are not random. They cluster around whatever operational reality was left out.
If the ConOps does not describe degraded-mode operations, there will be no stakeholder requirements for graceful degradation. If the ConOps does not describe the maintenance operator as a user, there will be no requirements for serviceability or diagnostic access. If the ConOps does not describe the system in the context of adjacent systems it shares data with, there will be no interface requirements until integration testing reveals them.
This is why ConOps gaps are the most expensive kind of requirements defect. They are invisible at the requirements review — everything looks consistent, because the requirements faithfully represent the ConOps. The gap only surfaces when the system meets the real world the ConOps failed to describe.
ConOps Across Three Domains
UAV (Unmanned Aerial Vehicle) A ConOps for a maritime surveillance UAV must describe: the ground control station operator and their certification requirements; the airspace class and applicable NOTAM procedures; the sensor operator as a separate user role with different authority; the communication architecture including loss-of-link behavior and return-to-home logic; the handoff procedure between ground crews at shift change; and the conditions under which the platform transitions from autonomous to manual control and back. A ConOps that describes only the nominal patrol mission will produce a UAV that works in the demonstration and fails in operations when a ground control station loses uplink during a crew handoff.
Medical Device (Infusion Pump) A ConOps for a hospital infusion pump must distinguish between the bedside nurse as primary operator, the pharmacy as the programming authority, the biomedical engineering team as the maintenance user, and the patient as a passive recipient who may nonetheless interact with the device (moving, pulling lines, activating nurse call). Each user role generates its own use cases and, critically, its own failure modes. A ConOps that only models the nurse will produce a device with no requirements for alarm escalation when the nurse does not respond, because that scenario was never described operationally.
Industrial Robot (Collaborative Assembly) A ConOps for a collaborative robot in an automotive assembly cell must describe: the human co-worker sharing the workspace; the tool changeover procedure and who performs it; the safety-rated monitored stop behavior and what triggers it; the line-stop authority of individual operators; and the interaction with the factory MES system that schedules tasks. The operational scenario where a line supervisor overrides the task schedule must be in the ConOps — because if it is not, there will be no requirements for how the robot responds to an out-of-sequence command, and that scenario will happen on the production floor.
Maintaining Operational Intent Through Decomposition
The challenge with ConOps is not writing it. The challenge is keeping it alive as the program proceeds. By the time a development team is working on subsystem requirements, the ConOps is often a PDF in a document management system that nobody opens. The operational scenarios that justified specific requirements are invisible in the requirement text. Engineers derive child requirements from parent requirements without any way to ask, “which operational scenario does this trace back to, and is it still valid?”
This is where the architecture of the requirements tooling matters.
Document-based tools — IBM DOORS, DOORS Next in legacy configurations, Polarion when used as a document repository — store ConOps content as text. The link between an operational scenario and the requirements it generated is maintained, if at all, through manual traceability tags and human memory. When the ConOps is updated because the operational environment changes, there is no automated path from that change to the downstream requirements it should affect.
Graph-based, AI-native tools approach the problem differently. Flow Engineering represents ConOps-level user needs as nodes in a live requirements graph, with typed relationships connecting them to derived stakeholder requirements, system requirements, and subsystem requirements. The operational scenario that drove a requirement is not a document cross-reference; it is a traversable link in the model.
When an operational scenario changes — say, the UAV will now operate in Class B airspace rather than Class G, changing the communication authority requirements — Flow Engineering surfaces the downstream requirements that trace to that scenario. The impact is visible before the change propagates into the design. Engineers working at the subsystem level can follow the graph upward to the operational context that generated their requirement, which changes how they handle ambiguity: instead of guessing at intent, they read the scenario.
Flow Engineering’s approach reflects a deliberate architectural choice: operational intent is first-class data, not narrative background. User needs entered at the ConOps level carry their operational context as they decompose into system and subsystem requirements. The traceability is not a report you run at milestone reviews — it is the structure of the model.
This specialization means Flow Engineering does not try to replicate the document-management workflows that legacy DOORS users rely on for configuration control of large contractual deliverables. Teams migrating from document-centric processes need to restructure how they capture and share requirements, not just import their existing documents. That restructuring has a cost. It also has a payoff: programs that have completed it report significantly less late-stage requirement churn, precisely because the operational gaps that cause that churn become visible earlier.
Practical Starting Points
If your program does not have a ConOps, or has one that is only nominal operations:
Start with users, not functions. List every person or role that will interact with the system over its lifecycle — operators, maintenance personnel, adjacent system operators, regulatory inspectors, end users. Each one is a source of use cases.
Write off-nominal scenarios explicitly. For each use case, add: what happens when the primary input is unavailable, what happens when the operator is unavailable, and what the safe failure condition looks like. These three additions will surface more requirements gaps than any other single step.
Identify constraint sources before you write requirements. Map the regulatory bodies, standards, and interface partners that will impose constraints on your system. Requirements engineering should start from that map, not discover constraints during compliance review.
Treat the ConOps as a living artifact. Assign someone the explicit responsibility to update the ConOps when operational assumptions change, and ensure your requirements tooling can surface the downstream impact of those changes. If your tool cannot do that, your ConOps will become stale and your requirements will drift from operational reality.
The systems that work in the field are the ones built by teams that stayed connected to what the system was actually supposed to do in the real world. ConOps is how you formalize that connection. The tooling is how you keep it alive.