What Goes Into a ConOps? A Breakdown of the Most Critical Sections

A Concept of Operations (CONOPS) document provides the foundation for understanding, communicating, and aligning on how a system or operation is intended to function. It bridges the gap between high-level mission objectives and the technical details that follow, giving stakeholders a shared vision of both the current state (“as-is”) and the desired future state (“to-be”). In this breakdown, we walk through each section of a CONOPS, explaining what it covers, why it matters, and how you can use Innoslate to streamline the process with diagrams, stakeholder insights, and a ready-to-use template.

Breakdown of Each Section in the CONOPs

Version History and Executive Summary

The first part of the template is the Version History and Executive Summary sections. Documents and every entity contained in the document have a version history and baselining.  The Executive Summary provides a concise overview of the CONOPS, including essential details such as the mission, organizations' roles and responsibilities, and key capabilities and performance characteristics that stakeholders are interested in. The first part of the document's “meat” is in Section 2, Mission Description. The outline for Section 2 is shown below:

2. Mission Description

This section introduces the overarching purpose and scope of the system or operation. It provides background on why the system exists, what needs it addresses, and defines the high-level goals, context, and anticipated outcomes of the mission. The information sets the stage for more detailed descriptions in subsequent sections.

2.1 "As-Is" Mission Description

This subsection describes the current state of the system, organization, or operational environment as it exists today.

2.1.1 Goals and Objectives

Clearly state the primary goals and measurable objectives of the existing mission or system. Describe what success looks like in the current state, including:

• key metrics
• timelines
• deliverables (if available)

2.1.2 Underlying Mission and Business Rationale

The justification for the current mission or operation revolves around a comprehensive understanding of the underlying factors that influenced its inception. This includes:

• a detailed examination of the business case that supports the initiative
• the organizational drivers that motivate its implementation
• any regulatory requirements that must be adhered to

Additionally, stakeholder needs play a critical role in shaping the system or approach currently in place.

2.1.3 "As-Is" Architecture

Describe the current architecture supporting the mission. Include the main components, systems, processes, and technologies in use. Provide a high-level overview, specifying which diagrams or reference materials may support it.

2.1.4 Key Stakeholders and Expectations

Identify the main stakeholders involved in or affected by the current system. Summarize their roles, interests, and expectations. Stakeholders may include internal teams, customers, partners, regulatory bodies, or end-users.

2.1.5 "As-Is" Gaps

Highlight the current limitations, shortcomings, or gaps in the existing mission or system. These may include: operational inefficiencies,

• unmet requirements
• technology obsolescence
• stakeholder dissatisfaction

This section sets up the need for a future solution or change.

2.2 "To-Be" Architecture

This section outlines the envisioned future state after proposed changes or upgrades are implemented.

2.2.1 "To-Be" Operational Concept

Describe how the system or operation will function in the future state. Summarize the

• high-level operational workflow
• new or improved capabilities
• and user interactions

Articulate how changes will address current gaps and improve mission outcomes.

2.2.2 "To-Be" Functional Model

Describe the key functions, processes, and responsibilities that will be implemented within the envisioned system. Map out new roles, interactions, and functional workflows to optimize efficiency. This can be illustrated with diagrams that show inputs, outputs, and functions.

2.2.3 Anticipated Performance Impacts of the "To-Be" Architecture

Analyze how the proposed changes are expected to affect performance, efficiency, and outcomes. Include qualitative or quantitative measures where possible (e.g., improved speed, reduced cost, increased reliability). Highlight benefits, potential risks, and significant changes from the "as-is" state.

Understanding the "As-Is" and "To Be" Architecture

"As-Is" Operational Concept

You will want to start developing the "As-Is" architecture to fully understand the current system and identify the gaps that need to be rectified in the new system. For the "As-Is" architecture section, you can use: use-case diagrams, activity diagrams, and sequence diagrams, along with more physical operational concepts such as the SysML Block Definition Diagram and Internal Block Diagram.

If you don't want to dive into SysML models, simplify your workflow with these two models. 1) For behavioral models, you can use the Action Diagram, and 2) for physical models, you can use the Asset Diagram.

Related Reading: MBSE for Beginners

"To-Be" Operational Concept

However, the embedded table of key stakeholders, their roles, and expectations can provide critical insight into how the stakeholders see the current and resulting systems. A stakeholder diagram can be created within Innoslate and embedded in this section, as well as in the “As-Is” or current architecture. Usually, we use the Asset diagram for this (see below).

1) Add Models and Images

You can add diagrams or images directly into a CONOPS document by clicking the + icon in the rich text editor.

2) Build New Diagrams

If you do not have any previous images or diagrams to visualize the "As Is" Architecture, you can build diagrams in Innoslate Diagram View. Navigate to Diagrams View, then click +Create Diagram to get started creating your diagram.

Reusing Diagrams: All objects in the entity can then be used later to trace back to the CONOPS by adding relationships either in the entity view or in the entity side menu. You can now also add diagrams directly into a CONOPS document, and the diagrams will display the latest version.

How to Set Up a CONOP in Innoslate

To set up the document template in Innoslate: Navigate to  Menu>Documents, then click +Create Document

In the Type drop-down menu, select "Concept of Operations Document."

Now, add the number, name, and description for the document artifacts' attributes. Click Next>.

In the Template drop-down menu, choose ASSE Concept of Operations (With Guidelines). Click Finish.

You now have a template for CONOPS in a digital engineering solution that can be traced to other objects in your database. If you don't already have an Innoslate account, sign up for a free Sandbox account at cloud.innoslate.com/signup.