Concept of Operations (ConOps)

Go up to Terms and Definitions

A Concept of Operations (ConOps) is a high-level description of how an Organization intends Actors and Resources to perform operations and use systems to achieve defined objectives within identified operational contexts.

A Concept of Operations describes operations from the perspective of the Organizations, Communities of Interest, Users, and other Actors that conduct, govern, support, or depend on those operations.

A Concept of Operations can describe:

• The operational problem or opportunity
• The mission or business purpose
• The operational objectives
• The applicable Organizations
• The applicable Communities of Interest
• The applicable Actors
• The applicable Users
• The applicable Roles
• The applicable Authorities
• The applicable operations
• The applicable operational scenarios
• The applicable operational modes
• The applicable operational activities
• The applicable interactions
• The applicable information exchanges
• The applicable Resources
• The applicable Operational Resources
• The applicable systems
• The applicable external systems
• The applicable Test Environments
• The applicable Governance Domains
• The applicable Policies
• The applicable Governance Policies
• The applicable assumptions
• The applicable constraints
• The applicable risks
• The applicable measures of effectiveness
• The applicable success conditions

A Concept of Operations can describe:

• Current operations
• Proposed operations
• Transitions from current operations to proposed operations
• Normal operations
• Degraded operations
• Exceptional operations
• Recovery operations
• Connected operations
• Disconnected operations
• Air-gapped operations
• Initial deployment
• Continuing operation
• Retirement

A Concept of Operations can use:

• Narrative descriptions
• Operational scenarios
• Use cases
• Activity descriptions
• Information-flow descriptions
• Models
• Diagrams
• Tables
• Operational timelines
• References to supporting Artifacts

high-level description of how an Organization intends Actors and Resources to perform operations and use systems to achieve defined objectives within identified operational contexts

Adapted from:

• ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering
• ANSI/AIAA G-043A-2012e, Guide for the Preparation of Operational Concept Documents
• DIDO Reference Architecture
• DIDO Reference Implementation Conceptual Model
• DIDO-TE draft Requirements Register

ISO/IEC/IEEE 29148 describes a Concept of Operations as a broad verbal and graphical statement of an Organization’s assumptions or intent concerning an operation or series of operations.

ISO/IEC/IEEE 29148 also identifies the Concept of Operations as a basis for bounding the operating space, system capabilities, interfaces, and operating environment and for describing how an enterprise or Organization intends to employ human and technological Resources to achieve outcomes.

This definition preserves that organizational and operational perspective while supporting narrative, graphical, model-based, and other governed representations.

The abbreviation for Concept of Operations is ConOps.

A Concept of Operations differs from an operational concept:

• A Concept of Operations describes how one or more Organizations intend to conduct operations and use systems to achieve objectives
• An operational concept describes how a particular system operates or supports its Users within its operational context

The Concept of Operations provides the broader organizational and mission context. The operational concept provides the system-oriented operational view.

A Concept of Operations differs from an architecture:

• A Concept of Operations describes intended operations, Actors, Roles, Resources, interactions, and outcomes
• An architecture describes the fundamental concepts, structures, relationships, principles, and decisions of a system or other subject

A Concept of Operations informs the architecture but does not prescribe every architectural element or relationship.

A Concept of Operations differs from a design:

• A Concept of Operations describes what Organizations and Actors intend to accomplish operationally
• A design specifies how a solution realizes the required capabilities and behaviors

A Concept of Operations should remain independent of implementation mechanisms unless an operational constraint requires a particular mechanism.

A Concept of Operations differs from a Requirement:

• A Concept of Operations describes operational intent and context
• A Requirement states a necessary capability, behavior, quality, or constraint that an identified subject SHALL satisfy

A Concept of Operations can provide the source and rationale for Mission Objectives, Operational Requirements, Functional Requirements, and quality Requirements.

A statement within a Concept of Operations does not automatically constitute a Requirement. The requirements process must express normative obligations as independently identifiable and objectively verifiable Requirement Statements.

A Concept of Operations differs from a procedure:

• A Concept of Operations describes the overall operational approach
• A procedure specifies activities used to perform a particular operation or task

A Concept of Operations does not need to reside in one document. Organizations can represent the Concept of Operations through a governed collection of Wiki pages, models, diagrams, scenarios, tables, and other Artifacts.

A Concept of Operations should preserve Traceability among:

• The operational problem or opportunity
• The mission and business objectives
• The Organizations and Communities of Interest
• The Actors and Roles
• The operational scenarios
• The Resources and systems
• The applicable Governance Policies
• The Mission Objectives
• The supporting Requirements
• The applicable architecture elements

The DIDO-TE Concept of Operations describes how an Organization uses DIDO-TE to test and validate a distributed system.

The Concept of Operations describes how:

• A Test Administrator establishes an approved Test Environment
• A Test Designer selects or creates a Test Definition
• A Test Operator selects the applicable Node Set
• DIDO-TE allocates the required Operational Resources
• DIDO-TE performs Test Execution
• A Test Run records the execution context
• Test Results record the observed outcomes
• Verdicts classify the Test Results
• Evidence supports review and evaluation
• An authorized Evaluator performs Validation
• An authorized Actor records the Validation Decision
• A Repository preserves retained content
• Catalogs support discovery of Test Definitions, Test Environments, Baselines, and Resources
• Registries identify authorized participants
• Inventories identify available Resources

The Concept of Operations also describes connected, disconnected, air-gapped, normal, degraded, exceptional, and recovery operations.

The DIDO-TE Mission Objectives and supporting Requirements derive from and remain traceable to this operational description.