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.
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:
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.
This subsection describes the current state of the system, organization, or operational environment as it exists today.
Clearly state the primary goals and measurable objectives of the existing mission or system. Describe what success looks like in the current state, including:
The justification for the current mission or operation revolves around a comprehensive understanding of the underlying factors that influenced its inception. This includes:
Additionally, stakeholder needs play a critical role in shaping the system or approach currently in place.
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.
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.
Highlight the current limitations, shortcomings, or gaps in the existing mission or system. These may include: operational inefficiencies,
This section sets up the need for a future solution or change.
This section outlines the envisioned future state after proposed changes or upgrades are implemented.
Describe how the system or operation will function in the future state. Summarize the
Articulate how changes will address current gaps and improve mission outcomes.
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.
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.
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
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).
You can add diagrams or images directly into a CONOPS document by clicking the + icon in the rich text editor.
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.
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.