Since the early 1970’s, two bodies of information have been distinguished:
An Operational Concept Description (OCD) for any system is a system-centric description of the intended users, uses, how the system is intended to be used, and the external conditions expected during use of the system. As such, it is the definitive reference for fitness of the system for intended use. An OCD may also identify other stakeholders and the interest in the system of each stakeholder. If so, the OCD becomes a reference for stakeholder satisfaction.
A Concept of Operations (CONOPS) for a given system (limited to an enterprise or business or capability system) is a description of the concept of how human and technical resources within the system solution are to interact to result in the enterprise or business or capability outcome. That is, a CONOPS is a conceptual description of the operational part of the system solution. The operational part of the system solution is that part of the solution which is intended to meet the requirements on the system which serve an end-use purpose.
This is all very good, until the IEEE came along and issued in 1998 IEEE 1362-1998 – IEEE Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document, which in content is a standard for an Operational Concept Description (OCD). The resulting confusion is now history, and also current reality.
More recently, the International Council on Systems Engineering (INCOSE) has managed to increase the confusion, with one part of INCOSE participating in a joint project with the AIAA to update ANSI/AIAA G-043-1992 Guide for the Preparation of Operational Concept Documents, January 1993, and in so doing, describing the confusion and the clear distinction between OCD and CONOPS, in ANSI/AIAA G-043-200x Draft 2.0 29 August 2006. In the meantime, another part of INCOSE publishes a Systems Engineering Handbook that uses the term CONOPS to mean an Operational Concept Description (OCD)!