Concept of Operations (ConOps)

A concept of operations, usually shortened to ConOps or CONOPS, is a description of a proposed system from the point of view of the people who will use it. It explains what the system is for, who will use it, how they will use it day to day and when things go wrong, and what will change for the organization when it arrives. It is written before the system is designed, and it is meant to be readable by users, buyers, managers, and engineers alike.

The ConOps is one of the most useful and most misunderstood documents in systems engineering. It is not a requirements specification, not a design, and not a project plan. It is the story of the system in use, told early enough that the story can still change. When it is done well, it becomes the reference that requirements trace back to and that final validation is measured against. When it is skipped or treated as a formality, projects often build exactly what was specified and still fail to deliver what users needed.

This article covers the definition, the history of the idea and its standards, what goes into a ConOps, how it relates to requirements and validation, the military meaning of the term, a worked example, and common mistakes.

Definition

The IEEE guide on the subject, IEEE Std 1362-1998, defines a ConOps document as "a user-oriented document that describes a system's operational characteristics from the end user's viewpoint." It lists "operational concept description" (OCD) as a synonym. The same guide says the document is used to communicate overall quantitative and qualitative system characteristics to the user, buyer, developer, and other organizational elements such as training, facilities, staffing, and maintenance, and that it describes the user organizations, missions, and organizational objectives from an integrated systems point of view.

NASA's Systems Engineering Handbook gives a closely related definition. It describes the ConOps as a document, developed early in a project, that describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time-sequenced manner. It describes the system from an operational perspective and helps people understand the system's goals.

Wikipedia's article summarizes typical contents as: the goals and objectives of the system; strategies, tactics, policies, and constraints; the organizations, activities, and interactions among participants and stakeholders; responsibilities and delegated authorities; the operational processes for fielding the system; and the processes for initiating, developing, maintaining, and retiring it. It also notes that a ConOps is not meant to be an implementation or transition plan.

Several other names are used for the same or overlapping documents, depending on organization and era: operational concept description, operational concept document, business requirements specification, and stakeholder requirements specification.

Why a ConOps matters

The IEEE guide lays out the purpose clearly. A ConOps bridges the gap between the user's needs and visions and the developer's technical specifications. In particular, the guide says it provides:

• A way to describe users' operational needs without getting bogged down in technical detail that belongs in later analysis.
• A way to document the system's characteristics and the users' needs in a form the users can check without technical knowledge beyond what they use in their normal jobs.
• A place for users to state their desires, visions, and expectations without having to provide quantified, testable specifications.
• A way for users and buyers to express thoughts on possible solution strategies, record design constraints and the reasons for them, and indicate the range of acceptable solutions.

The third point is worth dwelling on. IEEE's example is a user who needs a "highly reliable" system. In a requirements specification, "highly reliable" is unacceptable because it cannot be tested. In a ConOps, it is fine: the user states the need and the reason for it, and it becomes the job of the buyer or developer to turn that into a measurable reliability requirement later. The ConOps lets users speak in their own language, and the requirements process translates.

NASA emphasizes a different benefit. As requirements become more detailed and technical, stakeholders find it harder to understand what the requirements are actually saying and harder to picture the end product. The ConOps serves as a check for missing or conflicting requirements, because walking through scenarios of the system in use reveals needs that nobody wrote down. NASA's handbook gives a concrete example: adding a requirement for communication during a particular mission phase may require an additional antenna in a location that would not be needed for the nominal mission. Only by thinking through the operations does that requirement appear.

The ConOps also anchors validation at the end of the project. NASA states that validation relates back to the ConOps document: validation testing is done under realistic conditions to determine whether the product is effective and suitable for use by typical users. If there is no ConOps, there is no agreed description of "the right system" to validate against.

History

Origins at TRW

The history section of IEEE 1362-1998 states that the use of a ConOps document was first documented in a 1980 TRW report by Robert J. Lano, "A Structured Approach for Operational Concept Formulation" (TRW SS-80-02, TRW Defense and Space Systems Group, Redondo Beach, California). Lano is the same TRW engineer credited with inventing the N2 chart, an interface-analysis matrix first published in a TRW report in 1977. Both tools grew out of the same practical problem: describing complex defense and space systems in ways that many different people could understand and check.

AIAA and the operational concept document

According to the IEEE guide, in 1992 the Software Systems Technical Committee of the American Institute of Aeronautics and Astronautics (AIAA) developed a standard for an operational concept document. That AIAA guide, G-043-1992, was later revised as ANSI/AIAA G-043A-2012, Guide to the Preparation of Operational Concept Documents.

MIL-STD-498 and the IEEE guide

The IEEE guide traces its own origin to a Master of Science thesis at California State University, Sacramento, in October 1993. That work was accepted, with few changes, as a Data Item Description under MIL-STD-498, the U.S. Department of Defense software development and documentation standard, by the working group harmonizing DOD-STD-2167A. MIL-STD-498 later became IEEE Std 1498-1995, which was redesignated J-STD-016-1995. The IEEE Standards Board approved the project to develop the ConOps guide in June 1993. The first draft went to IEEE's Software Engineering Standards Committee on 8 August 1995, was returned on 1 November 1995 for harmonization with other standards, and a second draft was submitted on 28 February 1996 and balloted on 21 August 1996. IEEE Std 1362-1998 was approved on 19 March 1998 and published on 31 December 1998. Its authors are listed as Richard H. Thayer, Richard E. Fairley, and Per Bjorke.

The guide explicitly states that users who formerly applied MIL-STD-498 would find its ConOps document very similar to that standard's operational concept description, and that it is substantively identical to the OCD in J-STD-016-1995.

Fairley and Thayer also wrote about the idea in academic venues. Their paper "The Concept of Operations: The Bridge from Operational Requirements to Technical Specifications" appeared at the IEEE International Conference on Requirements Engineering in 1994 (with Per Bjorke as co-author), and a paper of the same title by Fairley and Thayer appeared in Annals of Software Engineering in 1997.

ISO/IEC/IEEE 29148 and 15288

IEEE 1362 was superseded by ISO/IEC/IEEE 29148:2011, the international standard for requirements engineering in system and software life cycles, which was itself revised in 2018. Wikipedia also lists ISO/IEC/IEEE 15288:2015, the standard for system life cycle processes, as relevant current guidance. The newer standards fold the ConOps into a broader requirements-engineering framework rather than treating it as a standalone document type.

Summary timeline

ConOps versus OpsCon

Two terms cause constant confusion: concept of operations (ConOps) and operational concept or operations concept (OpsCon). Different organizations draw the line differently, and some use the terms interchangeably.

The ISO/IEC/IEEE 29148 view. The standard distinguishes the two by level. As quoted in secondary sources, it describes the ConOps, at the organization level, as addressing leadership's intended way of operating the organization, possibly referring to one or more systems treated as black boxes. The OpsCon, by contrast, is at the system level and describes what a particular system will do (not how it will do it) and why. The SEBoK (Systems Engineering Body of Knowledge) glossary similarly describes a concept of operations as an organization's broad statement of intent for an operation or series of operations, and notes that it differs slightly from an operational concept.

The NASA view. NASA's handbook makes a different distinction. The concept of operations is developed early, in Pre-Phase A, by the technical team, and describes at a high level how the system will be used to meet stakeholder expectations. The operations concept is a description of how the flight system and the ground system are used together to ensure that the concept of operations is reasonable, such as how mission data are captured, returned to Earth, processed, made available to users, and archived. NASA says the operations concept is typically developed by the operations team.

The practical takeaway. If you are working on a project, find out which definitions your organization or customer uses and stick to them. Practitioners have pointed out that there is no single standard definition of what makes a ConOps or an OpsCon document, and that different organizations define the two differently, sometimes in contradictory ways. Checking the definition at the start of a project avoids a surprisingly common argument later.

What goes into a ConOps

There is no single required format. Two widely used outlines are those of IEEE 1362 and NASA.

The IEEE 1362 outline

IEEE 1362 lists these main clauses:

1. Scope: identification, document overview, system overview
2. Referenced documents
3. Current system or situation: background, objectives, and scope; operational policies and constraints; description of the current system or situation; modes of operation; user classes and other involved personnel; support environment
4. Justification for and nature of changes: justification for changes; description of desired changes; priorities among changes; changes considered but not included; assumptions and constraints
5. Concepts for the proposed system: background, objectives, and scope; operational policies and constraints; description of the proposed system; modes of operation; user classes and other involved personnel; support environment
6. Operational scenarios
7. Summary of impacts: operational impacts; organizational impacts; impacts during development
8. Analysis of the proposed system: summary of improvements; disadvantages and limitations; alternatives and trade-offs considered
9. Notes, followed by appendices and a glossary

The guide says the heart of the ConOps is in clauses 3 through 5. Clause 3 describes the existing system, manual or automated, that the users want to replace. Clause 4 justifies a new or modified system and any restrictions on it. Clause 5 describes the proposed system. The outlines for clauses 3 and 5 are almost identical on purpose, not because the contents should be the same, but to remind writers of the items to cover for both the old and new situations. Putting the two side by side makes the change visible.

Two subclauses are especially valuable and often skipped. "Changes considered but not included" records ideas that were discussed and rejected, which saves time when the same ideas come up again. "Disadvantages and limitations" forces honesty about what the proposed system will not do well.

The NASA outline

NASA's Appendix S gives an annotated outline organized a little differently:

1. Introduction: project description, background, assumptions and constraints; overview of the envisioned system and its scope
2. Documents: applicable and reference documents
3. Description of envisioned system: needs, goals, and objectives; overview of system and key elements, described in implementation-free terms; interfaces; modes of operations; proposed capabilities
4. Physical environment: the conditions the system must work in, tolerate with degraded performance, or merely survive, throughout its life cycle, including integration, test, and transportation
5. Support environment: how the system will be supported after fielding, including maintenance, repair, sparing, and upgrades
6. Operational scenarios, use cases, and/or design reference missions: nominal and off-nominal conditions
7. Impact considerations: environmental, organizational, and scientific or technical impacts
8. Risks and potential issues

NASA's main text adds a list of typical ConOps content: a description of the major phases; operation timelines; operational scenarios or design reference missions; fault management strategies; human interaction and required training; end-to-end communications strategy; command and data architecture; operational facilities; integrated logistics support such as resupply, maintenance, and assembly; staffing levels and skills; and critical events.

Comparing the two

The IEEE outline reflects its roots in information systems, where a new system usually replaces an existing process. The NASA outline reflects space missions, where there often is no current system and the physical environment is a dominant design driver. Both put operational scenarios at the center.

Operational scenarios: the core of the document

If a ConOps contains only one thing, it should be scenarios. IEEE 1362 defines a scenario as a step-by-step description of how the proposed system should operate and interact with its users and external interfaces under a given set of circumstances. The guide says scenarios should be written so readers can walk through them and understand how all the parts of the system function and interact.

What scenarios are for

IEEE lists several roles:

• They bind the individual parts of a system into a comprehensible whole.
• They give readers operational details: users' roles, how the system should operate, and its features.
• They can support simulation models that help define and allocate derived requirements and identify prototypes needed for key issues.
• They can serve as the basis for the first draft of the user manual and for acceptance test plans.
• They help the buyer and developer check that the design will meet users' needs.

How many scenarios

IEEE recommends describing scenarios for all operational modes and all user classes, and says it will usually be necessary to write several variations of each: one for normal operation, one for stress load, one for exception handling, one for degraded-mode operation, and so on. It adds that the number and detail of scenarios should be proportional to the project's perceived risk and criticality.

NASA makes the same point with more urgency: the operational concept must include scenarios for all significant operational situations, including known off-nominal ones, and important malfunctions and degraded modes must be considered to develop a useful and complete set. NASA's outline recommends labeling each scenario, for example [DRM-0100] and [DRM-0200], so requirements can trace back to specific scenarios.

How to organize scenarios

IEEE describes several approaches:

• By function: one subclause per major processing function, with lower-level subclauses for each scenario the function supports.
• By thread: each scenario follows one type of transaction through the whole system, plus scenarios for degraded, stress-loaded, and backup modes.
• By information flow, control flow, or objects and events in the system.

Thread-based scenarios are often the most revealing, because a single thread crosses organizational and technical boundaries where problems hide.

Scenarios do not need to be text only. IEEE says prototypes, storyboards, video, and other media can provide part of the information, and NASA allows pictorials, graphics, videos, and models.

Where the ConOps fits in the life cycle

Early, and then maintained

IEEE says developing the initial version of the ConOps should be one of the first activities on a project, and that it should be updated as the project evolves and placed under configuration control. NASA places the first ConOps in Pre-Phase A, when concept studies define the initial concepts, the roles of humans, hardware, and software, and a draft set of key requirements. During Phase A, the ConOps is fleshed out alongside the baseline system requirements. In Phase C, NASA's handbook calls for finalizing the ConOps validation along with the final design.

Driver of requirements

NASA describes a recursive loop at the heart of system design. Stakeholder expectations drive the development of a straw-man architecture, the ConOps, and derived requirements, and those three products must be kept consistent with each other through iteration and design decisions. The ConOps also stimulates requirements related to the user elements of the system and provides the basis for later documents such as operations plans, launch and early orbit plans, and operations handbooks, along with long-range planning for facilities, staffing, and network scheduling.

Function allocation between people and machines

NASA notes that walking through the accomplishment of mission objectives in the ConOps should make clear where decisions are needed about what human operators contribute versus what the systems are responsible for. In other words, the ConOps is where function allocation between people and automation first becomes visible.

Baseline and commitment

Once stakeholders and the technical team agree on the expectations and the ConOps, NASA calls for obtaining signatures or other commitments, usually at a concept review, and then baselining the ConOps so that further changes go through an approval process.

The ConOps on the systems engineering "V"

Many organizations draw the systems engineering life cycle as a "V." The left side descends from needs to requirements to design; the right side climbs from components through integration, verification, and validation. The U.S. Federal Highway Administration's systems engineering guidance for intelligent transportation systems (ITS) puts "Project Planning and ConOps Development" in the first phase of the V. The ConOps at the top left of the V is matched by validation at the top right: the system is validated against the operational concept it was meant to fulfill.

For federally funded U.S. highway ITS projects, this is not optional. A systems engineering analysis is required under 23 CFR 940.11 for ITS projects using Federal-aid highway funds, and FHWA publishes guidance on ConOps development, including Developing and Using a Concept of Operations in Transportation Management Systems (FHWA-HOP-07-001). That primer explicitly notes there are no "cookbooks" for writing a ConOps; it has to be tailored to each system.

The military meaning of CONOPS

In military usage, CONOPS has a narrower, operational meaning. Wikipedia, citing U.S. joint doctrine, describes a CONOPS in joint military operations as a verbal or graphic statement that clearly and concisely expresses what the joint force commander intends to accomplish and how it will be done using available resources. In this sense a CONOPS is part of operational planning for a specific operation, not necessarily a document about a system to be built.

The two meanings are related. Both describe intended operations from the viewpoint of those who will carry them out, and both come before detailed planning or design. A military CONOPS for an operation may also generate needs for new systems, which then get their own system-level concept documents. In the Department of Defense Architecture Framework (DoDAF), a CONOPS may be summarized in the OV-1, the High-Level Operational Concept Graphic, a single picture showing the main operational elements and how they interact.

Who writes the ConOps

IEEE says the ConOps should ideally be written by representatives of the user community. In practice, the buyer, a third-party consultant, or the developer often writes it. When that happens, the guide says it is essential that user representatives be involved in reviewing, revising, and approving it, because the primary goal is to capture user needs in the users' own terminology.

NASA places the systems engineer in the leading role, describing the systems engineer as usually playing the key role in developing the ConOps and the resulting system architecture. FHWA places preparation of the ConOps with the implementing agency.

These views are compatible. The systems engineer or analyst usually holds the pen, but the content must come from, and be checked by, the people who will operate, maintain, and depend on the system.

A worked example

The following example is hypothetical. It illustrates how a ConOps is structured and how scenarios produce requirements. It is not based on any real agency or project.

Background

A mid-sized county public works department runs snow plows on about 40 routes. Supervisors currently track plows by radio calls and paper route sheets. Residents phone the department to ask whether their street has been plowed, and the phone lines overload during storms. The department proposes a plow-tracking system.

Clause 3: current situation (summary)

Clause 4: justification and desired changes

• Justification: Supervisors cannot reassign plows efficiently without knowing where they are. Phone overload delays emergency calls routed through the same switchboard.
• Desired changes, in priority order: (1) show supervisors near-real-time plow locations; (2) record which street segments have been plowed; (3) give residents a public map of plowed streets.
• Considered but not included: automatic route optimization (rejected for the first release because supervisors want to keep control of assignments); cameras on plows (rejected over privacy concerns and data cost).
• Assumptions and constraints: cellular coverage exists on most routes but not all; the system must run on the department's existing dispatch computers.

Clause 5: proposed system (user classes)

Clause 6: operational scenarios

[SCN-01] Nominal storm operations. A storm begins at 2 a.m. The supervisor activates storm mode. Each plow's onboard unit begins reporting position automatically when the plow blade is lowered. The supervisor's map shows each plow as an icon moving along its route. When a plow passes a street segment with its blade down, that segment changes color on the map. Residents viewing the public map see their street turn from "not yet plowed" to "plowed" along with a time stamp.

[SCN-02] Plow stops unexpectedly (off-nominal). At 4:15 a.m., plow 17 stops moving for 12 minutes with its blade down. The supervisor's map highlights plow 17. The supervisor radios the driver, who reports a stuck vehicle ahead. The supervisor reassigns two street segments to plow 18.

[SCN-03] Loss of cellular coverage (degraded mode). Plow 9 enters a rural valley without cellular service. Its onboard unit stores position and blade data. The supervisor's map shows plow 9's last known position with a "no signal" indicator. When the plow regains service 20 minutes later, the stored data upload and the segments plowed during the gap are filled in.

[SCN-04] Public demand spike (stress). During a major storm, traffic on the public map rises sharply. Residents continue to see the map, possibly with slower updates, and the supervisor's internal map is unaffected.

[SCN-05] Onboard unit failure (exception). Plow 23's onboard unit fails. The supervisor's map shows the unit as offline. The driver resumes radio check-ins, and the supervisor marks segments manually.

From scenarios to requirements

Each scenario produces requirements, which trace back to it. A few examples, again hypothetical:

Three things are worth noticing. First, none of these requirements came from the original one-line request ("track the plows"). They came from walking through scenarios, especially the off-nominal ones. Second, SCN-03 and SCN-05 reveal that the system needs a degraded mode and a manual fallback, which affect both software and training. Third, SCN-04 produces an architectural decision (separating public and internal services) that would be expensive to retrofit later. This is the ConOps doing exactly what NASA and IEEE describe: revealing requirements and design functions that would otherwise be overlooked.

Clause 7: summary of impacts (excerpt)

• Operational: Drivers no longer need routine radio check-ins; radio is reserved for problems.
• Organizational: Clerks will need training to use the street lookup; call volume is expected to change, which may affect staffing.
• During development: Supervisors must spend time validating route maps; plows must be taken out of service briefly to install units, which must be done outside the storm season.

Clause 8: disadvantages and limitations (excerpt)

• The public map shows where plows have been, not when they will arrive; residents may still call to ask for arrival times.
• Coverage gaps mean some segments will appear unplowed for a time even after they are plowed.
• Drivers may be concerned about location tracking; labor relations must be addressed.

Writing these limitations down early lets the department decide whether to accept them, change the concept, or plan communication to residents and staff.

Writing a good ConOps: practical guidance

Write in the users' language

The ConOps is for users first. Avoid technical acronyms where possible, define those you must use, and describe things in terms of jobs, places, and events that users recognize.

Stay implementation-free

NASA's outline asks that system element descriptions be implementation-free, describing what the system and its elements are expected to do, not how they are built. A ConOps that says "the system will use a particular database product" has drifted into design. Real constraints, such as "must run on existing dispatch computers," belong in the constraints section with their reasons.

Describe the current situation honestly

IEEE's structure starts with the current system for good reason. Many failed projects misjudged what the old process actually did, including informal workarounds that nobody documented. The current-system section should describe what really happens, not what the procedures manual says happens.

Cover off-nominal operations

Both IEEE and NASA stress degraded, failure, stress, and exception scenarios. These are where the hard requirements come from, and they are the most likely to be missing if the authors only imagine the system working as intended.

Cover the whole life cycle

NASA's ConOps guidance covers operations from integration, test, and launch through disposal. For non-space systems, the equivalent is installation, training, cutover from the old system, normal operations, maintenance, upgrades, and retirement. Wikipedia's summary also includes processes for initiating, developing, maintaining, and retiring the system.

Label scenarios for traceability

Give each scenario an identifier so requirements and tests can reference it. This is a small habit with a large payoff when someone later asks why a requirement exists.

Keep it current and under control

A ConOps written once and filed is of limited use. IEEE says it should be updated periodically and placed under configuration control. Changes to the operational concept should trigger a review of affected requirements.

Right-size it

IEEE says small projects may need less formality than large ones but should still address every component of the guide. A ConOps for a small internal tool might be a few pages; one for a major public system might be a long document with appendices and models. Size should follow risk and complexity, not habit.

Reviewing a ConOps: questions to ask

The guidance above can be turned into a short set of review questions. These are a synthesis of the IEEE and NASA material rather than an official checklist from either.

A ConOps that passes these questions is not guaranteed to be right, but one that fails several of them is very likely to leave important requirements undiscovered.

Common pitfalls

• Treating the ConOps as a requirements document in disguise. Filling it with "shall" statements makes it unreadable to users and duplicates the requirements specification.
• Writing it after the design. A ConOps reverse-engineered from a finished design cannot do its main job of shaping requirements.
• Writing it without users. A ConOps drafted by developers and never reviewed by operators often describes how developers imagine the system will be used.
• Only nominal scenarios. The system works perfectly in every story; nobody wrote what happens when it does not.
• Skipping impacts. Organizational impacts such as training, staffing, and changes to job roles are often the biggest risks to adoption, and they are not visible in technical requirements.
• Confusing ConOps and project plan. Wikipedia notes the ConOps is not an implementation or transition plan. It may describe how the system will be fielded, but schedules and budgets belong elsewhere.
• Letting it go stale. If the concept changes but the ConOps does not, requirements and validation lose their reference point.

Misconceptions

"A ConOps is only for military or space projects." The term has strong roots in defense and aerospace, but IEEE wrote its guide for software-intensive systems of all kinds, and U.S. transportation agencies, health agencies, and others use ConOps documents routinely.

"A ConOps is the same as the military CONOPS." The military CONOPS describes a commander's intent for an operation. The systems engineering ConOps describes a proposed system in use. They share a name and a viewpoint but serve different purposes.

"Once you have requirements, you do not need the ConOps." NASA ties validation to the ConOps. Without it, there is no agreed picture of what "the right system" looks like when testing is done.

"The ConOps must be a long document." Size depends on the project. Both IEEE and NASA allow graphics, videos, models, and simulations to carry much of the content.

"Users cannot write ConOps documents." IEEE says users ideally should write it. Users may need help structuring it, but the content is fundamentally theirs.

Frequently asked questions

What is the difference between a ConOps and a requirements specification?

A ConOps describes the system in use, in users' language, and may include qualitative needs. A requirements specification states verifiable "shall" statements that the design must satisfy. The ConOps comes first and requirements trace back to it.

Is a ConOps the same as a use case document?

Use cases and scenarios are often part of a ConOps, but a ConOps also covers the current situation, justification for change, user classes, policies, support environment, impacts, and limitations. A use case document typically covers only functional interactions.

How long should a ConOps be?

As long as needed to describe the system's use and nothing more. Neither IEEE nor NASA sets a length; both say content should be tailored to the project's scope, complexity, and risk.

When should the ConOps be written?

At the very beginning, before requirements are baselined. IEEE says the initial version should be one of the first project activities, and NASA places the first ConOps in Pre-Phase A concept studies.

Who approves the ConOps?

Typically the stakeholders and the technical team, often at a concept review. NASA describes obtaining signatures or other commitments and then baselining it.

Which standard should I use?

The current international standard is ISO/IEC/IEEE 29148, which superseded IEEE 1362. Many practitioners still use the IEEE 1362 outline because it is clear and well structured. NASA's Appendix S is a good template for missions and engineered systems, and FHWA's guidance is tailored to transportation.

What is an OV-1?

In the DoD Architecture Framework, the OV-1 is the High-Level Operational Concept Graphic, a single picture summarizing the operational concept. It is often used alongside, or as a summary of, a CONOPS.

Summary

A concept of operations describes a proposed system from the users' viewpoint: what it is for, who uses it, how it works in normal and abnormal situations, and what it changes. The idea was first documented at TRW in 1980, was formalized in AIAA and MIL-STD-498 documents in the early 1990s, became IEEE Std 1362 in 1998, and is now folded into ISO/IEC/IEEE 29148. NASA, transportation agencies, and many others use it as the foundation of requirements and the reference for validation. Its most important content is a set of labeled scenarios that cover nominal and off-nominal operations, because those scenarios are where missing requirements and hidden design drivers come to light.

Sources

• Concept of operations (Wikipedia)
• IEEE Std 1362-1998, IEEE Guide for Information Technology, System Definition, Concept of Operations (ConOps) Document
• ISO/IEC/IEEE 29148 at IEEE Standards Association
• NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2
• SEBoK glossary: Concept of Operations (ConOps)(glossary))
• FHWA, Developing and Using a Concept of Operations in Transportation Management Systems: primer (FHWA-HOP-07-001)
• FHWA, Decision Support Framework for Dynamic Part-Time Shoulder Use, Chapter 3
• Fairley, Thayer and Bjorke, "The concept of operations: the bridge from operational requirements to technical specifications" (ICRE 1994)
• Joint Publication 5-0, Joint Operation Planning (archived)
• U.S. HHS / CMS, Concept of Operations (ConOps) template, archived