The Concept of Operations, or ConOps, is the document that answers a deceptively simple question: how will this system actually be used? It describes the system from the perspective of the operators, users, and stakeholders — in their language, framed around their scenarios — before the engineering team locks in formal requirements. It is the bridge between a stakeholder need and a specification, and it is the artifact most often skipped in the rush to start writing "shall" statements. Programs that skip it tend to discover, late and expensively, that the requirements they so carefully traced and verified describe a system nobody wanted to operate.
A ConOps is not a requirements document, and confusing the two is the first mistake. Requirements are testable, atomic, and written in the constrained language of verification — each one a claim you can later prove or disprove. A ConOps is narrative. It tells the story of the system in operation: who uses it, in what situations, to accomplish what, with what surrounding systems, under what constraints, and what happens when things go wrong. The requirements are derived from the ConOps, not the other way around. If you write requirements first and a ConOps later to rationalize them, you have inverted the flow and lost the point.
The core content of a strong ConOps is the set of operational scenarios. A scenario walks through a specific use of the system end to end: the trigger, the actors involved, the sequence of actions, the information exchanged, the decisions made, and the outcome. Good scenarios cover the nominal case, the important off-nominal cases, and the degraded and contingency cases. For a spacecraft, a scenario might trace a ground pass from acquisition of signal through command upload, telemetry downlink, and loss of signal — and a separate scenario traces what the operators do when a pass is missed. For a medical device, a scenario traces a clinician through setup, normal use, an alarm condition, and recovery. Scenarios are where latent requirements hide: the contingency step nobody thought about until they wrote it down becomes a requirement that would otherwise have been missed.
The operational environment section grounds the scenarios in reality. It captures the physical, organizational, and technical context: who the operators are and what training they have, what other systems the system must interoperate with, what the communications and data constraints are, what the physical conditions are, and what policies and regulations bound operations. This is where interface expectations first surface — long before an Interface Control Document exists, the ConOps establishes that the system will exchange data with a particular ground network or clinical information system, and that expectation flows into the interface requirements.
A ConOps also captures the operational timeline and the modes of operation. Most non-trivial systems have distinct modes — startup, nominal, safe or degraded, maintenance, shutdown — and the transitions between them are often where the hardest requirements live. Describing when the system is in each mode, what triggers a transition, and what is and is not permitted in each mode gives the requirements team a scaffold. Many mode-transition requirements and many of the trickiest verification cases trace directly back to a mode diagram first sketched in the ConOps.
The most valuable thing a ConOps does is expose stakeholder disagreement early, while it is still cheap to resolve. Written narratively and reviewed by operators, users, and engineers together, a ConOps surfaces the places where two stakeholders assumed different things about how the system would be used. The operations team assumed the system would run autonomously overnight; the safety team assumed a human would always be in the loop. That disagreement, discovered in a ConOps review, is a conversation. Discovered after the requirements are baselined and the design is underway, it is a change request, a schedule slip, and a budget hit. The ConOps is the cheapest place in the entire lifecycle to find out that people mean different things.
A ConOps is a living document, not a one-time gate artifact. As the design matures, operational understanding deepens, and the ConOps should be revisited at the major reviews — at the System Requirements Review to confirm the requirements still reflect it, and again as the design decisions in later phases feed back operational implications. When the ConOps changes, the requirements derived from it may need to change too, which is exactly why the link between operational scenarios and formal requirements should be explicit and maintained. A ConOps that is written once, filed, and never touched again quietly becomes fiction, and the requirements that claim to derive from it lose their pedigree.
The common failure modes are worth naming. A ConOps written by engineers for engineers, in requirements language, is not a ConOps — it is a premature specification. A ConOps with only the happy path and no contingency scenarios leaves the hardest requirements undiscovered. A ConOps that never gets reviewed by actual operators reflects what the engineers imagine the operators do, not what they do. And a ConOps disconnected from the requirements — where nobody can say which requirement traces to which scenario — provides no leverage when things change, because you cannot tell what a shift in operations means for the specification.
Hitt Hosting SE treats the ConOps as connected to the requirements it spawns rather than as a standalone document. Operational scenarios and modes described in the concept phase can be linked to the requirements derived from them, so the pedigree from "how the system is used" to "what the system shall do" is explicit and queryable. When the ConOps evolves at a review, the requirements that trace to the changed scenarios are flagged for reassessment, and the reviewers can see at a glance which specifications rest on a piece of operational understanding that just shifted. The point is not the document — it is that the story of the system in operation stays wired to the requirements that claim to serve it, all the way through the program.