ConOps vs OpsCon - What's the Difference?
We hear this question over and over again, as this topic comes up a lot in our classes where, as part of scope definition, we stress the need to develop and have at least one feasible system concept prior to writing the technical requirements.
There are several “standards” (note 1) that profess to define what a Concept of Operations (ConOps) is and what an Operations Concepts (OpsCon) is, and the differences between the two. The problem is that there is often confusion surrounding the differences in focus and content between the two documents. In my research, I find the two terms are often interchanged. Furthermore, there seems to be little agreement as to what a ConOps is and an OpsCon is between the various “standards”, from one organization to another, and even from within an organization. Clearly, the lack of an agreement concerning the meaning of these two terms can become a source of misunderstanding and confusion in discussions between different organizations.
Because of this, we recommend that you don’t focus your attention on the distinction between a ConOps and an OpsCon. What really matters is what your focus is and the intended use of the outcome. Your focus may be on how people will interact and use the system to accomplish the mission with the intent of developing integrated operations plans. Your focus may be on an individual system – what functionality, performance, and quality does the system need to have to accomplish the mission with the intent of helping you gain the knowledge needed to develop your system requirements.
An Intro to System Concepts
Rather than getting sucked into the “is it a ConOps or an OpsCon” debate, I have started using the term “Systems Concepts”. Methods to define System Concepts include stories, scenarios, use cases, OpsCons, ConOps, Design Reference Missions (DRMs), Operations Plans, or other methods of uncovering gaps in knowledge and scope. By using phrase “System Concepts” the discussion can focus on what is really important – developing the System Concepts rather than arguing what you call them or what the differences in focus and content are.
System Concepts bridge the gap between product scope and technical requirements. System Concepts are plain-language descriptions of user-product/system interactions throughout the life of your system from the perspective of all the key stakeholders- how it will be manufactured, tested, installed, used, maintained, stored, and decommissioned.
Defining System Concepts
The practice of defining and documenting System Concepts is a non-obtrusive, cost-effective way to build consensus among all stakeholders and discover which questions need to be addressed prior to writing your system requirements. There are many benefits to developing System Concepts.
System Concepts...
- are intuitive and easy to integrate
- are in a language that everyone understands
- facilitate coplete and consistent requirements
- reduce the debate
- identify user interface issues
- offer inexpensive opportunities for early validation
- form a foundation for testing scenarios in product verification
- are an essential part of gaining the knowledge needed to write requirements
Why These Concepts Matter
When developing the System Concepts, you are asking stakeholders to describe a day in the life of the product, for all life-cycle stages, and addressing both nominal as well as off-nominal situations. These descriptions are told from the stakeholder perspective describing their expectations for the system’s functionality, performance, capabilities, and quality.
These expectations are in the context of meeting the agreed-to need, goals, and objectives within the context of the defined drivers and constraints. By including all the key stakeholders, covering all of the life cycles of your system, and addressing both nominal and off-nominal conditions you will help prevent both missing and incorrect requirements. System Concepts will help you establish a shared vision for your system and gain the knowledge you need to define a clear, complete, correct, and concise set of requirements.
System Concepts Are a Communication Tool
Using System Concepts as a communication vehicle, you can avoid many of the fiery debates that often ensue during the average requirement definition process.
Why? Most people have an internal non-documented “System Concept” in their mind as they formulate, write, or review product requirements that are typically the source of disagreement. Unless these System Concepts are documented and shared, people involved may not be able to recognize these differences. It’s easier to resolve these differences in perspective and reach consensus while developing System Concepts than waiting until you are writing requirements. Attempting to define requirements before developing System Concepts often results in conflicting requirements because stakeholders submit requirements based on their own internal concepts, rather than a shared concept.
You can take System Concepts to a wide variety of stakeholders to get feedback on what is feasible. This feedback will help fill in holes, find inconsistencies, and correct your course. System Concepts can also be used as quick validation simulations. In the end, this information gives a foundation from which to model the system as well as develop the technical requirements.
ConOps or OpsCon?
Whether you are developing a ConOps or an OpsCon, both are developed in exactly the same way! The general methodology applies equally to both. The only difference is the “focus”.
- OpsCons focus on the system under development from a stakeholder perspective.
- ConOps focus on how the system fits into the bigger system of which it is a part and will be developed, tested, and operated.
For both, you need to involve the stakeholders and address all the lifecycles, for nominal and off-nominal situations. Both ConOps and OpsCons involve the telling of stories, scenarios, or use cases. Both align the stakeholders to a common vision, are used to define a feasible approach to meeting the overall need, goals, and objectives, and both are used to further define the various segments involved in the program.
Invest the Time to Prepare BOTH!
Why? Most organizations typically develop either a ConOps OR an OpsCon, but not both. The problem is that both define capabilities, functionality, performance, and quality needed in the system – just from a different perspective.
In Reality, BOTH Perspectives Are Needed
Documenting both perspectives as “System Concepts” results in addressing the traditional benefits and outcomes of both a ConOps and an OpsCon, thereby helping eliminate any confusion in having to distinguish between whether it is a ConOps or an OpsCon.
So, What's The Takeaway?
Rather than waste your time arguing what the difference is between ConOps and Ops Cons, focus on the benefits of developing System Concepts that include both perspectives, no matter what they are called.
Note 1: Standards include EE Std 1362-1998 “IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document”, ISO/IEC/IEEE 29148 “Systems and software engineering. Life cycle processes. Requirements engineering”, and ANSI/AIAA G-043A-2012 “Guide to the Preparation of Operational Concept Documents”. NASA has recently released NPR 7123.1B, “NASA Systems Engineering Processes and Requirements” where the definitions of ConOps and OpsCon are closely aligned with G-043A.
