BSR/AIAA

G-043A-201X
(Revision of G-043-1992)

Proposed American National Standard

Guide to the Preparation of Operational

Concept Documents

Warning

This document is not an approved AIAA Standard. It is distributed for review and comment. It is subject to
change without notice.

Recipients of this draft are invited to submit, with their comments, notification of
any relevant patent rights of which they are aware and to provide supporting
documentation

Sponsored by
American Institute of Aeronautics and Astronautics
Approved XX Month 200X

American National Standards Institute

ANSI
i
This page is intentionally blank.

ii
 BSR/AIAA G-043A-201X
(Revision of G-043-1992)

BSR/AIAA
G-043A-201X
(Revision of G-043-1992)

Proposed American National Standard

Guide to the Preparation of Operational

Concept Documents

Warning

This document is not an approved AIAA Standard. It is distributed for review and comment. It is subject to
change without notice.

Recipients of this draft are invited to submit, with their comments, notification of
any relevant patent rights of which they are aware and to provide supporting
documentation

Sponsored by
American Institute of Aeronautics and Astronautics

In cooperation with the International Council on Systems Engineering

Approved Month 200X

American National Standards Institute

Abstract
A recognized systems engineering best practice is early development of operational concepts during
system development and documentation of those operational concepts in one or more operational
concept documents. Recognizing this best practice, U. S. Department of Defense (DoD) and NASA
standard procedures have required that information relating to system operational concepts is prepared in
support of the specification and development of systems. In the past, the DoD has published Data Item
Descriptions (DIDs), and NASA has published Data Requirements Documents (DRDs), which describe
the format and content of the information to be provided.

This AIAA Guide describes which types of information are most relevant, their purpose, and who should
participate in the operational concept development effort. It also provides advice regarding effective
procedures for generation of the information and how to document it.

iii
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

American Approval of an American National Standard requires verification by ANSI that the
National requirements for due process, consensus, and other criteria have been met by the
standards developer.
Standard
Consensus is established when, in the judgment of the ANSI Board of Standards
Review, substantial agreement has been reached by directly and materially affected interests.
Substantial agreement means much more than a simple majority, but not necessarily unanimity.
Consensus requires that all views and objections be considered, and that a concerted effort be made
toward their resolution.

The use of American National Standards is completely voluntary; their existence does not in any respect
preclude anyone, whether he has approved the standards or not, from manufacturing, marketing,
purchasing, or using products, processes, or procedures not conforming to the standards.

The American National Standards Institute does not develop standards and will in no circumstances give
an interpretation of any American National Standard. Moreover, no person shall have the right or
authority to issue an interpretation of an American National Standard in the name of the American
National Standards Institute. Requests for interpretations should be addressed to the secretariat or
sponsor whose name appears on the title page of this standard.

CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The
procedures of the American National Standards Institute require that action be taken to affirm, revise, or
withdraw this standard no later than five years from the data of approval. Purchasers of American
National Standards may receive current information on all standards by calling or writing the American
National Standards Institute.

Published by
American Institute of Aeronautics and Astronautics
1801 Alexander Bell Drive, Reston, VA 20191

Copyright © 201X American Institute of Aeronautics and

Astronautics
All rights reserved
No part of this publication may be reproduced in any form, in an electronic retrieval system
or otherwise, without prior written permission of the publisher.

Printed in the United States of America

iv
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Contents

1 Introduction ....................................................................................................................................... 1
1.1 Purpose ...................................................................................................................................... 1
1.2 System ........................................................................................................................................ 1
1.3 Operational Concept Document Versus Concept of Operations Document ......... 1
1.3.1 Concept of Operations ................................................................................................... 1
1.3.2 Operational Concept....................................................................................................... 2
1.3.3 Concept of Operations Document .............................................................................. 3
1.3.4 Operational Concept Document.................................................................................. 3
1.3.5 Relationship Between Concept of Operations and Operational Concept ...... 3
1.3.6 Summary of Concept of Operations and Operational Concept ......................... 3
1.4 Other Sources .......................................................................................................................... 4
1.5 Structure of the Guide ............................................................................................................ 7
2 Scope ................................................................................................................................................. 7
3 Tailoring ............................................................................................................................................. 7
4 Applicable Documents .................................................................................................................. 7
5 Vocabulary ........................................................................................................................................ 8
5.1 Acronyms and Abbreviated Terms ..................................................................................... 8
5.2 Terms and Definitions ............................................................................................................ 9
6 Operational Concepts.................................................................................................................. 11
6.1 Purpose of the OCD ............................................................................................................. 12
6.2 Operational Concept Document in the Development Process ................................ 14
6.3 Perspectives on Operational Concept Analysis ........................................................... 16
6.3.1 A Bridge ............................................................................................................................ 16
6.3.2 Life Cycle Phases .......................................................................................................... 17
6.3.3 Who, What, When, Where, How, and Why ........................................................... 17
6.3.4 System and Context Views......................................................................................... 18
6.4 Operational Concept Documents and Use Cases ...................................................... 20
6.5 Intended Audience ................................................................................................................ 20
6.6 When to Generate an OCD ................................................................................................ 22
6.7 OCD Maintenance................................................................................................................. 22
7 Operational Concept Development Guidance ..................................................................... 23
7.1 Establish OCD Development Team ................................................................................. 23
7.2 Participants .............................................................................................................................. 23
7.3 Generating OCD Content.................................................................................................... 24
7.3.1 Overview .......................................................................................................................... 24
7.3.2 Defining the System Scope ........................................................................................ 24
7.3.3 Defining the System Context and Boundaries ...................................................... 24
7.3.4 Defining Useful Operational Scenarios ................................................................... 26
7.3.5 Developing the Scenarios ........................................................................................... 27
7.3.6 Validating the Scenarios.............................................................................................. 28
7.4 Agreed Format and Style .................................................................................................... 29
8 Bibliography .................................................................................................................................... 30
Annex A Recommended OCD Content (Informative) .............................................................. 34
A.1 Scope ........................................................................................................................................ 35

v
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

A.1.1 Identification .................................................................................................................... 35

A.1.2 System Purpose............................................................................................................. 35
A.1.3 Document Overview ..................................................................................................... 35
A.2 Referenced Documents ....................................................................................................... 35
A.3 Background Information ...................................................................................................... 35
A.4 Existing Systems and Operations .................................................................................... 36
A.5 Proposed System Operational Overview ....................................................................... 36
A.5.1 Missions............................................................................................................................ 36
A.5.2 Operational Policies and Constraints ...................................................................... 37
A.5.3 Operational Environment ............................................................................................ 37
A.5.4 Personnel ......................................................................................................................... 37
A.5.5 Support Concept and Environment .......................................................................... 37
A.5.6 Justification for and Nature of Changes ................................................................. 38
A.5.7 Impact Summary............................................................................................................ 39
A.6 System Overview................................................................................................................... 39
A.6.1 System Scope ................................................................................................................ 39
A.6.2 System Goals and Objectives ................................................................................... 40
A.6.3 Users and Operators .................................................................................................... 40
A.6.4 System Interfaces and Boundaries .......................................................................... 40
A.6.5 System States and Modes .......................................................................................... 40
A.6.6 System Capabilities ...................................................................................................... 40
A.6.7 System Architecture...................................................................................................... 40
A.7 Operational Processes ........................................................................................................ 40
A.8 Other Operational Needs .................................................................................................... 41
A.8.1 Mission Needs ................................................................................................................ 42
A.8.2 Personnel Needs ........................................................................................................... 42
A.8.3 Quality Factors ............................................................................................................... 42
A.9 Analysis of the Proposed System ..................................................................................... 42
A.9.1 Summary of Advantages ............................................................................................. 42
A.9.2 Summary of Disadvantages/Limitations ................................................................. 42
A.9.3 Alternatives and Tradeoffs Considered .................................................................. 42
A.9.4 Summary of Impact by Classes of Users ............................................................... 43
A.9.5 Regulatory Impacts ....................................................................................................... 43
A.9.6 Other Impacts ................................................................................................................. 43
A.10 Appendix A: Acronyms, Abbreviations and Glossary ............................................ 43
A.11 Appendix B: System Operational Scenarios ............................................................ 43
A.11.1 Appendix B.1 Operational Processes ................................................................. 43
A.11.2 Appendix B.2 Common Scenarios and Conditions ......................................... 44
Annex B Background to this Guide (Informative) ...................................................................... 45

Figures
Figure 1.1 Single Organization-Wide Concept of Operations May Lead to Many Operational
Concepts. .................................................................................................................................... 4
Figure 1.2 Operational Concept Grows Through the Product Life Cycle. ................................................... 5
Figure 6.1 Strategy-to-Task-to-Need Links Organization (Enterprise) Policies to Operational
Concepts. .................................................................................................................................. 15

vi
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Figure 6.2 An Operational Concept Document Describes the System and Its Context With Both
Text and Graphics in the User’s Terminology. .......................................................................... 16
Figure 6.3 An Effective Operational Concept Document Will “Tell a Story” From the Operators’
Users’ Point of View to a Wide and Varied Audience. .............................................................. 18
Figure 7.1 EIA 632 “Building Block” Model Provides Guidance in Determining System Scope and
Boundaries. ............................................................................................................................... 25
Figure 7.2 The Key to a Successful Operations Concept Document Is the Development of
Operational Scenarios. .............................................................................................................. 26
Figure 7.3 Outline for Operations Concept Document. .............................................................................. 30

Tables
Table A-1. Mapping of Annex Clauses to OCD Sections .......................................................................... 34

vii
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Change History

Change Change Date Comments

Number
1 14 December 2010 Ballot Draft 2

2 26 March 2011 Ballot Draft 3

viii
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Foreword
This Guide for the Preparation of Operational Concept Documents (OCD) has been sponsored by the
American Institute of Aeronautics and Astronautics (AIAA) as a part of its Standards Program. It is an
update and extension of the original ANSI/AIAA Guide (ANSI/AIAA G-043-1992), incorporating new
insights, knowledge, and experience that have been recognized since the Guide’s original publication.
The original guide was developed by the AIAA Software Systems Committee on Standards and formed a
sound foundation for this updated version. This edition of the Guide has been prepared by the AIAA
Systems Engineering Committee on Standards, the AIAA Software Engineering Technical Committee,
and the Requirements Working Group of the International Council on Systems Engineering.

At the time that the original Guide was published, various government standards required the generation
of operations concept information. The U.S. Department of Defense (DoD) had developed Data Item
Descriptions (DIDs), but little information was provided describing the manner in which an Operational
Concept Document should be used in support of a system development. No guidelines were provided
regarding which information was most useful, how to develop that information, which developer and
customer personnel should participate, or how to document it.

Subsequent to the publication of the original Guide, the DoD embarked on a substantial acquisition
reform activity, which resulted in the cancellation of many standards that had guided the development of
systems and software in favor of comparable commercial standards. In the same time period, guides to
the preparation of Operational Concept Documents were published by the Institute of Electrical and
Electronic Engineers (IEEE 1362) and by ISO (ISO 14711:2002 (E)). Lastly, many advances have been
made in the last decade in methods used in systems and software development, not the least of which
has been the expansion of object orientation and the development of the Unified Modeling Language
(UML) and the Systems Modeling Language (SysML).

The original Guide, ANSI/AIAA G-043-1992, was subject to review and revision in 1997. At
approximately that time, members of the International Council on Systems Engineering Requirements
Working Group (INCOSE RWG) had recognized a need for such a Guide and had begun work on their
own document. After discussion between both organizations, the INCOSE RWG and the AIAA Systems
Engineering Committee on Standards (SECoS) decided to work jointly on the revision of the ANSI Guide.
In addition, the INCOSE Net-Centric Operations (NCO) Working Group has worked jointly with the AIAA
SETC in reviewing the G-043 document. The NCO Working Group has concurred with the contents.
Although the review and revision process was begun in 1997, it was not completed until 2011.

The current Guide for the Preparation of Operational Concept Documents, in addition to including new
information, has been broadened to encompass the development of all system types, including software-
intensive systems, and to reflect technological advances of the last decade. Development of the current
Guide has benefited from the cooperative effort between the AIAA and INCOSE by providing a broad
systems-level viewpoint and inclusion of international knowledge, information and experience.

The AIAA Standards Program Procedures provides that all approved Standards, Recommended
Practices, and Guides are advisory only. Their use by anyone engaged in industry or trade is entirely
voluntary. There is no agreement to adhere to any AIAA standards publication and no commitment to
conform to or be guided by any standards report. In formulating, revising, and approving standards
publications, the Committees on Standards will not consider patents which may apply to the subject
matter. Prospective users of the publications are responsible for protecting themselves against liability for
infringement of patents or copyrights, or both.

This publication is a Guide and contains no normative material. It is informative only.

At the time of approval, the members of the AIAA Systems Engineering Committee on Standards were as
follows:

ix
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Satoshi Nagano, Chair The Aerospace Corporation

James R. van Gaasbeek, Co-Chair Northrop Grumman Corporation

Michelle Bailey Defense Acquisition University South

Dexter Lee Blackstock NASA Langley Research Center

Shirley Brandt Jacobs Engineering

John W. Dahlgren MITRE

John Eiler Stellar Solutions

Howard Estes DRS Technologies

Mahantesh Hiremath Space Systems Loral

John C. Hsu California State University, Long Beach

Stephen Jensen NASA Dryden Flight Research Center

John C. Muehlbauer Lockheed Martin Aeronautics Company

Eric E. Nichols Orbital Sciences Corporation

Brian Selvy Pratt and Whitney Rocketdyne

William W. Vaughan University of Alabama, Huntsville

Tony Williams Jacobs Engineering (NASA/JSC)

The following individuals made particular contributions to the preparation of the document:

Kurt Dittmer Northrop Grumman Corporation

Andrew Gagg Consultant

Alvaro Gracia Northrop Grumman Corporation

Raymond Jorgensen Rockwell Collins

Jérôme Loubersac Integrate Systems Engineering

George Strengers BAE Systems, Australia

John Tiehen Northrop Grumman Corporation

x
 BSR/AIAA G-043A-201X
(Revision of G-043-1992)

1 Introduction
1.1 Purpose
The purpose of this Guide is twofold. First, the Guide describes a time-tested process for operational
concept development. Second, it is intended to recommend how to compile the information developed
during operational concept development into one or more Operational Concept Documents (OCDs)
encompassing the full range of the product lifecycle (Haskins, 2010): concept, development, production,
utilization, support, and retirement stages.

1.2 System
The Operational Concept is prepared initially to support the concept and development stages of the
system life cycle. The Operational Concept is then maintained throughout the Program to support the
production, utilization, support, and retirement stages of the system life cycle. As the concept of “system”
is central to the Operational Concept and its preparation and maintenance, for the purposes of this Guide,
a system is defined as:
A combination of interacting elements organized to achieve one or more stated purposes.
A system may be considered as a product or as the services it provides. In practice, the
interpretation of its meaning is frequently clarified by the use of an associative noun (e.g.,
aircraft system). Alternatively, the word “system” may be substituted simply by a context-
dependent synonym (e.g., aircraft), though this may then obscure the system principles
perspective. [after ISO, 2008].

Early in the system development activity, a system is conceptual in nature. As the development effort
continues, the system becomes realized in hardware, software, materials, personnel, facilities, and
processes.

A system may consist of several levels where each element at each lower level may by this definition
itself be considered a system (i.e., a subsystem of a large system may itself possess all of the attributes
of a system).

1.3 Operational Concept Document Versus Concept of Operations Document

The terms “operational concept” and “concept of operations”, and the terms “operational concept
document” and “concept of operations document”, are often used interchangeably in system
development. Although there are similarities between the two terms in each set, there are also significant
differences. It is important to understand the term “concept of operations” and “operational concept”
before trying to understand the terms describing the documents.

For the purposes of this Guide, a distinction shall be made between the terms “Concept of Operations”
and “Operational Concept”. Each has a separate purpose and is prepared and used to meet separate
ends. It is imperative that the system and software engineering communities within a given Program
agree on the usage of the two terms, and use this Guide in accordance with the Program-specific
meanings. The terms “concept of operations” and “operational concept” will be used as defined below
throughout this Guide.
1.3.1 Concept of Operations

A concept of operations is an abstract model created by an organization or enterprise 1 to describe how it

intends to operate to achieve its goals and objectives. The concept of operations may be very high level
and independent of the particular systems to be used in the organization or enterprise operations or it

1 See Section 5.2, Definitions, for the distinction between “organization” and “enterprise.”

1
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

may be developed as part of the process for acquisition of a new, upgraded, or modified system. A
detailed definition of the concept of operations has been provided in the Department of Defense
Dictionary of Military and Associated Terms, JP 1-02 (DoD, 2010):
concept of operations — A verbal or graphic statement that clearly and concisely
expresses what the joint force commander intends to accomplish and how it will be done
using available resources. The concept is designed to give an overall picture of the
operation. Also called commander’s concept or CONOPS.

The INCOSE Systems Engineering Handbook, Version 3.2 (Haskins, 2010), defines the Concept of
Operations as follows:
Concept of Operations (ConOps) – Describes the way the system works from the
operator’s perspective. The ConOps includes the user description and summarizes the
needs, goals, and characteristics of the system’s user community. This includes
operation, maintenance, and support personnel.

For the purposes of this Guide, the concept of operations is defined as follows:

A verbal and graphic statement, in broad outline, of an organization’s (enterprise’s)

assumptions or intent in regard to an operation or series of operations of new, modified or
existing organizational (enterprise) systems. The concept of operations frequently is
embodied in long-range strategic plans and annual operational plans. In the latter case,
the concept of operations in the plan covers a series of connected operations to be
carried out simultaneously or in succession to achieve an organizational (enterprise)
performance objective. The concept is designed to give an overall picture of the
organization’s (enterprise’s) operations. It is also called the CONOPS.
1.3.2 Operational Concept

A definition of “operational concept” has not been found. For the purposes of this document, it will be
taken to mean an abstract model of the operations of a specific system or group of systems, usually
developed as part of the acquisition process and used throughout the system life cycle. The definition of
the Operational Concept for this Guide is as follows:

A verbal and graphic statement of an organization’s (enterprise’s) assumptions or intent

in regard to an operation or series of operations of a specific system or a related set of
specific new, existing or modified systems. The operational concept is frequently
developed as part of a system development or acquisition program. The operational
concept is designed to give an overall picture of the operations using one or more
specific systems, or set of related systems, in the organization’s (enterprise’s) operational
environment from the users’ and operators’ perspective. It is also called the OpsCon.

A single Operational Concept can be used as the basis for defining the behavior and requirements to be
allocated to two or more systems. In some cases, this is the only way that the operations can be
comprehensively described. The target systems may or may not be acquired from the same supplier. This
applies to Family of Systems/System of Systems (FoS/SoS), but it also applies to systems that are not
necessarily in the same family.

The initial Operational Concept should be developed by the users and operators at the inception of the
acquisition Program. Alternatively, an Operational Concept may be developed by the system customer 2
at the beginning of the concept and development phases of the Program. The Operational Concept is
then maintained through the production, utilization, support and retirement phases of the system life cycle
jointly by the developer and the customer.

2 See Section 5.2, Definitions, for the distinction between customer, operator, and user.

2
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

1.3.3 Concept of Operations Document

The term “Concept of Operations Document” has not been universally or consistently defined in the
literature. IEEE 1362 (IEEE, 1998a) provides the following definition:

"concept of operations (ConOps) document: A user-oriented document that describes a

system’s operational characteristics from the end-users’ viewpoint."

The definition appears to describe a document containing the “operational concept.”

For the purposes of this Guide, a Concept of Operations Document is defined as follows:

A document for recording a Concept of Operations. It is developed at the organization

(enterprise) level, independent of any specific system solution, to describe how the
organization (enterprise) will operate to execute strategy and doctrine. The Concept of
Operations Document is not a requirements document. It describes the organization
(enterprise) operational intent and context, and is used to derive needs and
requirements.
1.3.4 Operational Concept Document

No definition has been found in the literature or in general use for an Operational Concept Document.
For the purposes of this Guide, the Operational Concept Document is defined as follows:

A document for recording an Operational Concept. It is prepared at the acquisition

organization and developer level to describe how a particular system (new, modified or
existing) will be operated to satisfy its user and operator needs. The description is
independent of specific design solutions, although it will make reference to a possible
design solution at the highest level of abstraction. The Operational Concept Document is
not a requirements document. It describes the system operational intent and context,
and is used to derive needs and requirements.
1.3.5 Relationship Between Concept of Operations and Operational Concept

The Operational Concept Document must always reflect the organization (enterprise) information in the
Concept of Operations document. Preparation of the Operational Concept Document during the
development cycle is discussed in Section 6. One Concept of Operations can lead to the generation of
multiple Operational Concepts, as shown in Figure 1.1.

In order to avoid inclusion of solution-specific information in the initial Operational Concept Document,
system operational behavior should be described in the form of capabilities and outcomes. Initially, any
reference to an architectural or detailed solution should be minimized. As the system is realized and the
Operational Concept Document is revised throughout the product life cycle, references to the specific
architectural features of the solution are incorporated.
1.3.6 Summary of Concept of Operations and Operational Concept

The Concept of Operations is a high-level model of the operations of an organization (enterprise) and is
used in conjunction with an inventory assessment and gap analysis to identify organization (enterprise)
operational shortfalls and needs. This latter analysis, identifying organization (enterprise) needs, can
lead to changes in organization (enterprise) doctrine, organization, training, leadership and education,
personnel or facilities (DOTMLPF), or some combination of such changes. It can also lead to modification
or upgrade of one or more systems, or to acquisition of one or more new systems, or a combination of
such actions.

An organization (enterprise) will review and update its Concept of Operations on a regular basis. It may
be documented as a stand-alone document, or it may constitute sections of the organization’s
(enterprise’s) long-range strategic plan and annual operating plan.

3
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Figure 1.1 — Single Organization-Wide Concept of Operations May Lead to Many Operational Concepts

Operational Concepts are prepared to support the development of a new or modified/upgraded system.
They may be prepared by the customer as part of the request for proposal. (In this case, they are often
called the concept of operations.) The Operational Concept is also prepared after the commencement of
the product development activity and is maintained throughout the product life cycle. See Figure 1.2.

1.4 Other Sources

Other documents have been published providing guidance in the development of operational concepts.

IEEE Standard 1362 (IEEE, 1998a) provides a template for the preparation of a “Concept of Operations”
(ConOps) document for use in the development or modification of software-intensive systems. The IEEE
Guide was not intended for application in the development of hardware-only systems, and, in fact, states
that it is intended for use in development and modification of the software portions of software-intensive
systems. It does not discuss the procedures, methods or techniques to be used in creating the ConOps.
The IEEE Guide takes an opportunity-driven approach (we can do it) rather than a customer-needs-driven
approach (what the customer needs). In the context of this AIAA Guide, the IEEE Guide describes an
Operational Concept Document.

ISO 14711:2002(E) (ISO, 2002) provides guidance in the preparation of a document defining the space
system mission operations concept, including both the development of the space system, and all
operations subsequent to the boost phase of the mission. The Guide also expects that the operations
concept will include information on the pre-launch and launch-phase ground support operations. The
operations concept guidance covers mainly the payload operations, with a focus on the data handling
aspects of the mission.

IEEE/EIA 12207.1-1997 (IEEE, 1998b) provides a description of the contents of a “concept of operations”
document in Clause 6.3. The description gives a brief statement of the purpose of the document, a
reference to the clause in the base standard (IEEE, 1998c) invoking the document, a short outline of the
content and the characteristics of the document. It is sufficiently general to support any system
development activity. No guidance is given on the process or method to be used in developing the
document. Again, the Concept of Operations document discussed in IEEE/EIA 12207 is an Operational
Concept Document in the context of this Guide. A more recent version, IEEE Standard 12207-2008
(IEEE, 2008), merely relates IEEE Standard 1362 (IEEE, 1998a) to the section on stakeholder
requirements definition without discussing the document, its creation, or its use.

4
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Pre-Proposal •Prepared by customer / users / operators

•User’s / Operator’s viewpoint
Problem description Operational •Basis for the selection of MoEs
Concept •Basis for selection of standards of acceptance

Development •Prepared by customer / users / operators and

Problem description Operational developer
•User’s / Operator’s viewpoint
Concept
•Describes intended behaviors
•Basis for verification and validation planning
Solution description Production
•Basis for design of End Products and Enabling
Products
Concept •Basis for number of units, availability,
deployment location decisions
•Basis for evaluation for future change requests
Deployment
Concept

Support
Concept

Disposal
Concept

Figure 1.2 — Operational Concept Grows Through the Product Life Cycle

U.S. Air Force Air Combat Command Instruction (ACCI) 10-650, Development and Use of Concepts of
Operations (USAF, 1998), provides an outline for a concept of operations document that can be applied
to the development of any type of system. It provides increased focus on security issues, integration and
interoperability, and communications and computer system support, and includes explicitly sections on
training and logistics. The development process provided is at a very high level, concentrating on the
document-development process flow without any discussion of techniques or methods. In the context of
this Guide, the ACCI 10-650 concept of operations document is an operational concept document.

The U.S. Air Force has more recently implemented policies and instructions to support development of
concepts in preparation of the Joint Staff’s Joint Operating Concept (USAF, 2003; USAF, 2004; USAF,
2005). In the context of this Guide, the concept in the Policy and Instructions is a concept of operations,
written at the organizational (enterprise) level.
A high-level Operational Concept Graphic is part of the DoD Architect Framework (DoDAF)
documentation set (DoD, 2009b; document OV-1). It is a free-form document consisting of a
nonprescriptive, illustrative single-page graphic depicting a “mission, class of mission, or scenario. It
shows the main operational concepts and interesting or unique aspects of operations. It describes the
interactions between the subject architecture and its environment, and between the architecture and
external systems.” The document also includes UML use case diagrams and a text component defining
the data elements. In the context of this Guide, the OV-1 Operational Concept Graphic is a Concept of
Operations Document.

ISO/IEC 15288 (ISO, 2008) discusses the definition of a “context of use” during the definition of the
stakeholder requirements. This context definition is discussed in more detail in Clause 6.4.1.3 b) 2):

5
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Scenarios are used to analyze the operation of the system in its intended environment in
order to identify requirements that may not have been formally specified by any of the
stakeholders, e.g., legal, regulatory and social obligations. The context of use of the
system is identified and analyzed. Include in the context analysis the activities that users
perform to achieve system objectives, the relevant characteristics of the end users of the
system (e.g., expected training, degree of fatigue), the physical environment (e.g.,
available light, temperature) and any equipment to be used (e.g., protective or
communication equipment). The social and organizational influences on users that could
affect system use or constrain its design are analyzed when applicable.

ISO/IEC TR 19760 (ISO, 2003), the guide to ISO/IEC 15288, discusses the “context of use” as:

The context of use statement…is a collection of information about the physical, technical,
social and cultural elements surrounding a system and an analysis of how these affect (or
will affect) how the system is used. The context of use statement is a useful collection of
supporting information when preparing the system user and operational requirements. It
provides guidance on how and where a system will be used to the designers of the
system in considering design alternatives. It is a reference document for the design of
validation activities for a system. It is the most detailed source of information about the
users of the system and their working environment and is used as the primary guide
when selecting users for trials and tests.

As will be seen in Sections 6 and 7 of this Guide, the combined definition of the “context of use”
statement of ISO/IEC 15288 and ISO/IEC TR 19760 is very similar to an operational concept in this
Guide.

The U.S. Department of Transportation Federal Highway Administration recommends preparation and
use of a Concept of Operations in the development of transportation management systems (FHWA-HOP-
07-001). The FHA has adopted the IEEE definition of Concept of Operations given above. Therefore, the
Concept of Operations discussed in the FHA literature is an Operational Concept in the context of this
Guide.

Several papers discussing operational concepts have appeared in the literature. Some (Dusting, 2001;
Feerrar, 1996; Kays, 1992; LaMonica, 1994; Rindskopf, 1996; Verma, 2004) show the application of the
operational concept in the development of systems. The various case studies cover a wide range of
business domains:

• business systems definition

• development of oceanic air traffic management systems
• implementation of an undergraduate engineering program
• development of an automated systems engineering tool suite
• development of the nuclear waste disposal site at Yucca Mountain
• development of network-centric systems

The papers provide insight into the preparation of a concept and its documentation, and show the value of
the operational concept in a development Program, particularly when prepared at the beginning of the
Program and maintained throughout the Program life cycle.

Other papers (Anderegg, 1996; Buede,1995; Cropley, 2002; Fairley, 1994; Gabb, 2001b; Gambhir, 1996;
Jorgensen, 2002; Rogers, 1995) discuss the use of the operational concept in the systems engineering
process and its creation. Again, the value of the operational concept in reducing risk and promoting
understanding of the operators needs are stressed, as is the importance of creating the operational
concept early in the development and maintaining it throughout the Program life cycle.

6
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

In its commercial business, Intel has used “[a] combination of the use case and concept-of-operations
approaches...with use cases either translated or extended into a concept of operations model” (Simmons,
2005, 2006). The approach is based on the usage model, which “…describes the interaction between the
user and the system at a level that identifies the system’s benefits to the user.” (Again, while calling the
artifact a concept of operations, in the sense of this paper, the author is describing an operational
concept.)

1.5 Structure of the Guide

Section 1 provides the definition of a system, addresses the differences between a Concept of Operations
and an Operational Concept, and reviews other sources of information on the topic.

Section 2 defines the scope of the Guide and its use.

Section 3 provides guidance for tailoring of this Guide to specific Program needs.

Section 4 of this Guide identifies the applicable documents.

Section 5 contains definitions of acronyms, abbreviations, and terms used in this document.

Section 6 of this guide describes the purposes of the operational concept process and methods, provides
an overview of their role in the system development process, and identifies various perspectives from
which they may be applied. It also contains a description of the types of information that an OCD should
contain.

Section 7 provides guidelines for the preparation of an OCD.

Section 8 is a bibliography providing full attributions for all documents referenced in this Guide.
Annex A provides an annotated outline recommended for the OCD.

Annex B provides a brief discussion of the genesis of the process and the OCD. Background information
on the evolution of the OCD is also provided.

2 Scope
This guide outlines the operational concept definition process and how it may be applied. The main
emphasis of this document is to provide practical recommendations on how to perform an operational
concept definition activity with the focus on the OCD because that is the physical product in which the
results of the work are captured.

This guide is applicable for the procurement of systems, including ground systems, and associated
equipment/subsystems.

3 Tailoring
Owing to the diversity of the systems development process, and the systems to be developed, it is
impossible to create a guide that is applicable all projects and programs. Tailoring the guide to fit the
program is an ordinary part of the process. Tailoring of this guide shall be undertaken in consultation with
the procuring entity where applicable.

4 Applicable Documents
This guide is informative and not normative. Therefore, it contains no requirements, and there are no
documents containing provisions which, through reference in this text, constitute provisions of this guide.

Documents to which only informative reference is made are listed in the bibliography.

7
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

5 Vocabulary
5.1 Acronyms and Abbreviated Terms
ACC Air Combat Command

ACCI Air Combat Command Instruction

CDD Capability Development Document

CJCSI Chairman, Joint Chiefs of Staff Instruction

ConOps, CONOPS Concept of Operations

CPD Capabilities Production Document

DID Data Item Description

DoD Department of Defense

DoDAF Department of Defense Architecture Framework

DoDI Department of Defense Instruction

DOTMLPF Doctrine, Organization, Training, Materiel, Leadership and

Education, Personnel, Facilities
DRM Design Reference Mission

EIA Electronics Industries Alliance

FAA Federal Aviation Administration

FoS Family of Systems

ICD Initial Capabilities Document

IEEE Institute of Electrical and Electronics Engineers

INCOSE International Council on Systems Engineering

I/O Input / Output

ISO International Organization for Standardization

JCIDS Joint Capabilities Integration and Development System

JLC Joint Logistics Commanders

MCCR Mission Critical Computer Resources

NASA National Aeronautics and Space Administration

OCD Operational Concept Document

OCF Operational Concept Formulation

SoS System of Systems

TPM Technical Performance Measure

USAF United States Air Force

8
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

5.2 Terms and Definitions

For the purposes of this document, the following terms and definitions apply.

Acquirer
The stakeholder that acquires or procures a product or service from a supplier. (ISO/IEC 15288; ISO,
2008)

Campaign
A series of related operations aimed at accomplishing a strategic and operational objective within a given
time and space. (After DoD JP 1-02 [DoD, 2010])
Concept of Operations
A verbal and graphic statement, in broad outline, of an organization’s (enterprise’s) assumptions or intent
in regard to an operation or series of operations of new, modified or existing organizational (enterprise)
systems. The concept of operations frequently is embodied in long-range strategic plans and annual
operational plans. In the latter case, the concept of operations in the plan covers a series of connected
operations to be carried out simultaneously or in succession to achieve an organizational (enterprise)
performance objective. The concept is designed to give an overall picture of the organization (enterprise)
operations. It is also called the CONOPS.

Concept of Operations Document

A document for recording a Concept of Operations. It is developed at the organization (enterprise) level,
independent of any specific system solution, to describe how the organization (enterprise) will operate to
execute strategy and doctrine. The Concept of Operations Document is not a requirements document. It
describes the organization (enterprise) operational intent and context, and is used to derive needs and
requirements.

Customer
An organization or person that receives a product. Examples: Consumer, client, end user, retailer,
beneficiary, and purchaser. A customer can be internal or external to the organization. Customer is a
broader reference than acquirer, operator, or user and includes those roles as well as others. (IEEE
1220-2005; IEEE, 2005.)

Enabling system
A system that supports a system-of-interest during its life cycle stages but does not necessarily contribute
directly to its function during operation. For example, when a system-of-interest enters the production
stage, a production-enabling system is required. Each enabling system has a life cycle of its own.
(ISO/IEC 15288 [ISO, 2008].)
Enterprise
An organization chartered to provide certain knowledge, goods, and/or services as its products.

Family of systems
A set or arrangement of independent systems that can be arranged or interconnected in various ways to
provide different capability needs. The mix of systems can be tailored to provide desired capabilities,
dependent on the situation. Although these systems can independently provide useful capabilities, in
collaboration they can satisfy more fully a more complex and challenging capability.

Measure of effectiveness
A criterion used to assess changes in system behavior, capability, or operational environment that is tied
to measuring attainment of an end state, achievement of an objective, or creation of an effect.
Maintainer
Individual or organization that performs diagnostics, troubleshooting, preventative or corrective
maintenance, and repair actions to sustain the system's operational readiness and availability.

9
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Materiel
Modified or new item (including ships, tanks, self-propelled weapons, aircraft, etc., and related software,
spares, repair parts and support equipment, but excluding real property, installations and utilities) used to
equip, operate, maintain and support military activities without disruption as to its application for
administrative or combat purposes. In the case of family of systems and system of systems approaches,
an individual materiel item may not fully satisfy a necessary capability gap on its own.

Mission
1. The task, together with the purpose, that clearly indicates the action to be taken and the reason
therefore. 2. In common usage, especially when applied to lower level organizations, a duty assigned to
an individual or unit; a task. 3. The dispatching of one or more aircraft to accomplish one particular task.
(After DoD JP 1-02 [DoD, 2010].)
Mode
A subset of a state.

Operational Concept
A verbal and graphic statement of an organization’s (enterprise’s) assumptions or intent in regard to an
operation or series of operations of a specific system or a related set of specific new, existing or modified
systems. The operational concept is frequently developed as part of a system development or acquisition
program. The operational concept is designed to give an overall picture of the operations using one or
more specific systems, or set of related systems, in the organization’s (enterprise’s) operational
environment from the users’ and operators’ perspective. It is also called the OpsCon.

Operational Concept Document

A document for recording an Operational Concept. It is prepared at the acquisition organization and
developer level to describe how a particular system (new, modified or existing) will be operated to satisfy
its user and operator needs. The description is independent of specific design solutions, although it will
make reference to a possible design solution at the highest level of abstraction. The Operational Concept
Document is not a requirements document. It describes the system operational intent and context, and is
used to derive needs and requirements.
Operator
An entity that performs the operations of a system. The role of operator and the role of user may be
vested, simultaneously or sequentially, in the same individual or organization. An individual operator
combined with knowledge, skills and procedures may be considered as an element of the system. In the
context of this specific definition, the term entity means an individual or an organization. (ISO/IEC 15288
[ISO, 2008].)

Organization
A person or group of people and facilities with an arrangement of responsibilities, authorities, and
relationships. A body of persons organized for some specific purpose, such as a club, union, corporation,
or society, is an organization. An identified part of an organization (even as small as a single individual) or
an identified group of organizations can be regarded as an organization if it has responsibilities,
authorities, and relationships. (ISO/IEC 15288 [ISO, 2008].)

Regulator
A stakeholder, generally a government department or agency, that has regulatory authority to approve the
implementation, usage, or sale of the system. For example, the U.S. Environmental Protection Agency
publishes a list of those substances whose use is prohibited in the United States and those whose use is
restricted.

Stakeholder
An individual or organization having a right, share, claim, or interest in a system or in its possession of
characteristics that meet their needs and expectations (ISO/IEC 15288 [ISO, 2008]). Typically, there are
many stakeholders exhibiting conflicting goals and objectives.

10
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

State
The condition of a system defined by its current condition/configuration and the functionality provided.

Supplier
An organization or an individual that enters into an agreement with the acquirer for the supply of a product
or service. (ISO/IEC 15288 [ISO, 2008].)
System
A combination of interacting elements organized to achieve one or more stated purposes. A system may
be considered as a product or as the services it provides. In practice, the interpretation of its meaning is
frequently clarified by the use of an associative noun (e.g., aircraft system). Alternatively, the word
“system” may be substituted simply by a context-dependent synonym (e.g., aircraft), though this may then
obscure a system principles perspective. (ISO/IEC 15288 [ISO, 2008].)

System of Systems
A set or arrangement of interdependent systems that are related or connected to provide a given
capability. The loss of any part of the system will degrade the performance or capabilities of the whole. An
example of a SoS could be interdependent information systems. Although individual systems within the
SoS may be developed to satisfy the peculiar needs of a given user group (like a specific service or
agency), the information they share is so important that the loss of a single system may deprive other
systems of the data needed to achieve even minimal capabilities.

Technical Performance Measure

A measurable attribute of a system and related to a technical requirement. A TPM is a measurable
attribute (or parameter) of a system that is expected to change as requirements mature, designs are
created and, ultimately, as the product is produced. A TPM provides insight into the maturation of the
requirements and progress toward the ultimate satisfaction of the requirement upon which the TPM is
based.

User
Individual who, or group that, benefits from a system during its utilization. The role of user and the role of
operator may be vested, simultaneously or sequentially, in the same individual or organization. (ISO/IEC
15288 [ISO, 2008].)

6 Operational Concepts
Systems are developed to satisfy the users’ and operators’ operational needs. Users and operators react
to operational deficiencies resulting from the following operational situations:

• An existing system has become obsolescent and no longer satisfies all mission
requirements.
• The user and operator have been assigned a new mission and existing systems do not
satisfy the new mission requirements.

In addition, system modifications, upgrades, or replacements may be made to enhance operations as a

result of an intelligence discovery or a technology breakthrough.

The Operational Concept Document is a user-oriented document that describes the characteristics of a
system from the user’s and operator’s perspective. It is written in the user’s and operator’s language and
expresses their intent for the future operations of the system under development. It should not be written
in the form of a technical requirements specification but in a narrative style. It should be organized to tell
a story, and it should make use of graphical material as well as text.

Pure narrative, on the other hand, can lend itself to verbosity and ambiguity. The OCD should be written
with the same rigor as a requirements document, and should share characteristics, such as clarity,
conciseness, separation of concerns, nonambiguity, and so forth. When it helps readability, the OCD

11
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

should make use of forms of documentation that are more structured than just narrative, and it should
favor clarity, nonambiguity, and ease of maintenance.
The OCD can use a narrative style.

The OCD can use boxed statements to highlight key concepts, for example. The boxed statements,
written with rigorous style and approach, may make an OCD look like a requirements specification, but it
will improve its readability, usability, and maintainability without preventing it from telling a story. The
boxed-text style can also be supported by narrative text as illustrated by this paragraph and the preceding
bolded sentence.

The OCD can use a boxed-text style.

The OCD provides a bridge between the users’ and operators’ needs and the developers’ technical
requirements, and it helps the developer identify the users’ and operators’ views, wants, wishes, and
expectations. It should not be written in terms of a specific solution, but it should present the users’ and
operators’ general system goals, missions, functions, and components. It should be developed early in
the study phase of a project where operations and characteristics can be traded. Lastly, the OCD
provides a vehicle to document vague and immeasurable wants and desires (i.e., the user or operator
can express their desire for “fast response” or “reliable operation”).

6.1 Purpose of the OCD

The goals of an OCD are as follows:

1) to provide a clear vision of the intended use and the resulting benefits of the system;

2) to provide a forum to stimulate information exchange at the operational level on major

technical and programmatic issues among the system's users, operators, and
developers in order to facilitate a clear understanding of the system context and the
users' view of the completed system;

3) to provide a document which can be understood and utilized by all members of the
OCD audience (see Section 6.5);

4) to highlight differences between current operations and desired future operations;

and

5) to provide the basis for system validation.

To meet these goals, an OCD should therefore:

1) describe the desired system features and characteristics from an operational

perspective;
2) provide a description of the system’s, users’ and operators’ environment;

3) describe how the system will be used;

4) facilitate understanding of the overall system goals among users (including recipients
of the products of the system where applicable), buyers, implementers, architects,
testers, and managers;

5) form an overall basis for long-range operations planning and provide guidance for
development of subsequent system definition documents such as the system
specification and the interface specification; and

12
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

6) describe the user organization and mission from an integrated user/system point of
view.

The OCD is an important predecessor document to the system specification. It should be prepared
before the system specification. It should serve as a key input to the system requirements analysis and
design phases to provide the necessary framework within which proposed system design and
implementation alternatives can be evaluated. In particular, it provides the users’ perspective on the
needs, capabilities, constraints and interfaces for the proposed system. The OCD can also be used as
an element in evaluating the completeness and consistency of a system design or implementation. The
OCD should not be constrained to apply only at the highest system level but can and should be applied at
lower levels in a system hierarchy as well. In the event that the OCD is not prepared in advance of the
system requirements, it should be developed concurrently.

There are numerous purposes for an Operational Concept Document. A system-development activity
can benefit from separate OCDs prepared for each phase of the development life-cycle. Using the
INCOSE life cycle as the basis, these various OCDs are:

• Concept OCD
• Development OCD
• Production OCD
• Utilization OCD
• Support OCD
• Retirement OCD

The INCOSE Systems Engineering Handbook (Haskins, 2010) provides a slightly different, annotated, set
of potential OCDs:
Production Concept describes the way the system will be manufactured, including any
hazardous materials used in the process.

Deployment Concept describes the way the system will be delivered and installed.

Operations Concept describes the way the system works from the operator’s perspective. The
[OCD (Ops Con)] includes the user description and summarizes the
needs, goals, and characteristics of the system’s user community. This
includes operation, maintenance, and support personnel.

Support Concept describes the desired support infrastructure and manpower

considerations for maintaining the system after it is deployed. This
includes specifying equipment, procedures, facilities, and operator
training requirements.

Disposal Concept describes the way the system will be removed from operation and
retired, including the disposal of any hazardous materials used in or
resulting from the process.

Additional OCDs can be prepared for other life-cycle products, such as training.

Typically, an OCD is prepared describing the operations, maintenance and support phases. Such an
OCD may also include information on the initial deployment of the system. In this case, there is a
difference between a User/Operator OCD, illustrating the users’ and operators’ operational needs, and a
System OCD, which illustrates how a particular system (as postulated for development) will meet the
users’ and operators’ operational needs.

13
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

OCDs can be developed at various levels of decomposition of the system, with a System OCD and OCDs
for selected subsystems. Such OCDs will be related hierarchically. In like fashion, the OCD can be
separated into an operational OCD and a Maintenance Concept Document if appropriate.

OCDs can be developed for new systems or for systems under modification. In the latter case, the OCD
for the modification effort can be developed by modification of the existing OCD.

Gabb (2001a), writing based upon his experience developing and using Operational Concepts, has
categorized OCDs as follows:

User OCD Written by users and operators, or by the developer in collaboration

with the users and operators. Usually written prior to the
commencement of development activity, but can be prepared at any
point in the system life cycle. Defines the user’s and operator’s
expectations for the system’s operational capabilities.

System OCD Written by developer personnel during or after the design activity
defining how the system is to be used. Defines the developer’s
perception of how the system will be used.

Alternative OCDs Written during the concept exploration phase for each of the major
alternative systems examined.

Remedial OCD Written to redirect a Program that displays a lack of understanding of

the overall system concept. It would typically be written at some point
during the design phase.

Operations OCDs Written toward the end of the development Program to be maintained
during the operations and support phase. It is written from the user
and operator perspective and provides a representation of the system
operations and capabilities as delivered.

A User OCD and a System OCD may exist contemporaneously. Comparison of the two OCDs is valuable
and helps identify differences to be resolved.

Should multiple OCDs be prepared across the product life-cycle, it is necessary to maintain traceability
from document to document. In like fashion, if multiple OCDs are developed at a given time in the life-
cycle to address concepts for various parts of the product (such as various end products and enabling
products), traceability across the documents should be maintained. In the early phases of the project, the
OCD is a living document. However, all OCDs should be placed under configuration management control
at an appropriate time in the life-cycle to provide reference documentation.

OCDs should also incorporate sufficient information to allow the reader to identify the sources of the
information used to seed the analysis undertaken in the development of the OCD. Additionally, where
relevant, requirements should trace to the OCD for the purpose of supporting system validation.

Note that an Operational Concept Document is not a specification. It is a precedent document, providing
the user’s and operator’s views of the system, and it provides significant amounts of ancillary information
that supplements the formal statements of requirements supporting the developer’s activities (Gabb,
2001a). The OCD supports the preparation of requirements.

6.2 Operational Concept Document in the Development Process

The use of the Concepts of Operation and Operational Concept Documents has evolved within the US
DoD processes for Design, Development, Test and Evaluation. The Operational Concept was a standard
artifact in the Requirements Generation System (RGS) of CJCSI 3170.01B (DoD, 2001). In 2003, the
DoD replaced the Requirements Generation System with the Joint Capabilities Integration and
14
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Development System (JCIDS). The most recent version is documented in CJCSI 3170.01G (DoD,
2009a). The JCIDS has been introduced to develop systems, FoS and SoS to support joint operations.
As the JCIDS has matured, the Operational Concept has been deemphasized in favor of the Initial
Capability Document (ICD), the Capability Development Document (CDD) and the Capability Production
Document (CPD). However, the United States Air Force has recently re-emphasized the need for OCDs,
specifically Enabling Concepts, to provide the type of system use descriptions recommended in this
Guide.

In a non-DoD setting, a generic system development process, the Strategy-to-Task-to-Need method

(Thaler, 1993), can be used for system development, and it employs the Operational Concept. In this
approach, an organization (enterprise) develops a set of strategies for achieving its goals and objectives
and links those strategies directly to the needs (in the form of desired system features and
characteristics). Both the Concept of Operations (at the organization (enterprise) level) and the
Operational Concept Document (at the system level) are used in this process, as shown in Figure 6.1.

Enterprise
Enterprise Enterprise
Goals and
Policies Strategies
Objectives

Concept of Operations

Gap
Analysis

Mission
Needs

New Modified or DOTLPF No

System Upgraded Changes Changes
System

Operational Operational Operational

Concept Concept Concept

Figure 6.1 — Strategy-to-Task-to-Need Links Organization (Enterprise) Policies to Operational Concepts

A generic system development process can be stated as follows:

1. New or changed mission objectives perceived or defined

2. Analyze current equipment and processes
3. Define the operational deficiency(ies) or mission need(s)
4. Prepare and release the Operational Concept Document (OCD)
5. Prepare and release operational requirements
6. Prepare and release systems requirements
7. Prepare and release a system specification
8. Prepare and release the lower level specifications

15
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

6.3 Perspectives on Operational Concept Analysis

This Section provides an overview of the depth of the analysis and subsequent description needed to
develop an OCD.
6.3.1 A Bridge

As shown in the previous Section, the OCD is drawn from Strategies and Missions. An OCD must provide
a bridge from operational goals and objectives to a system and its context, while still maintaining a strong
user’s perspective. Therefore the OCD must describe the necessary elements of the context and the
system as illustrated in Figure 6.2.

Figure 6.2 — An Operational Concept Document Describes the System and Its Context With Both Text and Graphics
in the User’s Terminology

An OCD communicates to all system stakeholders, in the user's language, the desired characteristics of a
system to be developed. Stakeholders consist of the acquisition community (customer, user, operator),
the developer community (contractors and subcontractors), and other parties (e.g., regulators, approval
authorities).

The OCD provides a mechanism to trigger questions and raise issues regarding operator-related and
user-related needs and associated design trades. The effort to develop an OCD can achieve a number of
benefits to a program, of which there are five major ways:

• act as a catalyst to stimulate the development of complete, consistent, testable

requirements and designs with emphasis upon those attributes that shape the user-
related elements of the system;
• provide guidance and clarification for the development of the subsequent system
definition documentation (e.g., operational system specifications and interface control
drawings);
• form the basis for long range operational planning activities (i.e., staffing, facilities,
training, security, safety, and logistics);

16
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

• describe the system behavior(s) that are needed (give best and worst case); and
• reduce cost overrun and schedule slips by defining more accurately the system earlier in
the development stage; and decrease the chances that stakeholder dissatisfaction will
terminate the project.

6.3.2 Life Cycle Phases

The OCD should discuss the system life cycle phases of utilization, support and retirement. The OCD
must also make reference to enabling systems and processes (in the sense of the building-block model of
ANSI/EIA632; ANSI, 1999). Other important intended system usages, such as information collection,
training exercises and buildups should be included as part of the system operations.

It is also important to include in the OCD constraints arising from user concerns in the development
phase of a system related to Verification and Validation, as it affects the deployed operations. An
example of such a user concern was the development of a military training system. The users were
adamant that they would not accept the system until they had used it to perform at least two training
rotations. The information to be included in the OCD is not that which would be in a Test and Evaluation
Management Plan, but, rather, a general, top-level description of the operational evaluations that would
be performed during the deployment phase in order to determine operational suitability of the training
system.
6.3.3 Who, What, When, Where, How, and Why

A good OCD should tell a story; that is, it should be a narrative and graphical description of the system's
intended use. The need to enhance the value of the OCD to different populations through clear, concise
information is shown conceptually in Figure 6.3. This can be accomplished by describing the What,
Where, When, Who, Why, and How of the system operations. These are summarized as follows:
Whos: These describe the interactions among the various human elements within the system including
their interfaces with people external to the system. The OCD and related scenarios should also identify
decision points to include the organizational entity with authority to make those decisions. Other systems
with which this system interoperates are also identified.

Whats: These are the known components or elements and top level capabilities required of the system,
at its highest level of abstraction, to perform the necessary functions. The components are described
from an operational point of view. Necessary mission phases or modes may also be described here.

The Whats also include descriptions of the external systems with which the system of interest interfaces,
and the external interfaces. Principal internal interfaces are also described.

Whens: These describe activities, tasks, flows, precedence, concurrencies, and other time / sequence-
related elements necessary to achieve the mission objectives in each of the various mission modes and
conditions. Whens may also include information as to system development and operational availability
dates, such as Program milestones.

Wheres: These are the environments, such as geographical and physical locations of customer's
facilities and interfacing systems, within which the capabilities are required to be performed and
supported. A description of the nature of the interfaces with other systems, organizations and the
environment is also needed.
Hows: These tie together the other elements (the what, where, when, who, and why) to describe how the
system is expected to be used, operated, maintained and, ultimately, retired in the given environment,
under all significant conditions. The emphasis should be on concepts and should avoid any system
design or implementation inferences.

17
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Whys: These provide the rationale behind any established partitioning of the mission tasks between the
system components and the operators, and the reasoning for specific sequences of activities or tasks.
For example, an important function of an OCD is to provide the rationale behind the definition of the level
of technical expertise required of the system operators. This will provide a basis for the definition of a set
of system requirements and designs with a consistent level of complexity and sophistication.

Figure 6.3 — An Effective Operational Concept Document Will “Tell a Story” From the Operators’ Users’ Point of
View to a Wide and Varied Audience

6.3.4 System and Context Views

Systems do not operate alone. They interoperate in the natural and socio-political environments as well
as with other systems external to themselves. The system context must include a definition of the system
boundaries and the interfaces across the boundary (external interfaces) 3. Details of the operational
characteristics of those interfaces are normally outside the scope of the OCD, but the operations that are
enabled for the system of interest by those interfaces and the interoperations with, and inter-
dependencies with, the external systems need to be discussed. (See CJCSI 6212.01B; DoD, 2000, for
guidance on interoperability definition.) Systems can also be collections of systems requiring the analyst
to view the internal interfaces of a system of systems that form both an “internal” and an “external”
perspective.

3 The terms "interacting environment" and "noninteracting environment" are also used.

18
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

A user’s and operator’s operational view is normally expressed as both static and dynamic descriptions of
the proposed system to elucidate delivered operational characteristics and constraints. The OCD
provides the rationale behind the proposed system and should contain at least:
• mission objectives including rationale;
• operational environment;
• support environment;
• envelope of system capabilities and constraints ( a static view of the system );
• and a set of operational scenarios (a dynamic view of the system in operation, again with
emphasis on the users' point of view).

Analysis of the system context should yield the following outcomes:

• unambiguous descriptions of missions and operations in a language understood by all
users and developers;
• a clear definition of the system boundary (where system elements are inside the boundary
and the operational environment is outside the boundary);
• a clear definition of external entities and their interfaces across the system boundary.
• operational system characteristics; and
• system constraints and limitations.

It may be appropriate to identify multiple boundaries in the same OCD. For example, OCDs for a training
system, simulators or models, in which the real-world operations and the operations of the training
system, simulator or model must be addressed, require identification of multiple boundaries, to properly
represent the two disparate operational views and boundaries.

Additionally, this technique may be applied at the segment and subsystem tiers as well, resulting,
potentially, in several related OCDs of different levels of detail within a given system (see Section 2.6).
The lower tier OCDs will need to be presented in the context of the next higher tier OCD, and describe
the operations of that lower tier system element within the operations of the next higher tier system
element. Note that a software “system” may be a lower tier system element of another system or it may
be a system in its own right.

There are many types of system development programs, based on the nature of the system to be
developed (e.g., precedented vs. unprecedented, new, modification). The development can also be of
parts or all of a System of Systems (SoS) or a Family of Systems (FoS). In each case, the OCD format
must be tailored to the needs of the system development activity.

The descriptions of System Context and System Characteristics must also address less tangible facets of
operations such as:
• overall operational philosophies;
• relevant customer/developer policies and organizations;
• external requirements (i.e., changes to existing internal elements that are necessary for
the proposed system to correctly interface and function); and
• user, operator, maintainer and disposer organization (e.g., functions, responsibilities,
capabilities, and interfaces).

And yet the OCD does not contain specific implementation or design-dependent constraints. The OCD
will make reference to the system design only in the broadest, most general, manner. Specific details of
the design should not be discussed in the OCD unless that specific design feature is a unique part of the
system providing a critical function.

19
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

6.4 Operational Concept Documents and Use Cases

The Use Case, now part of the System Modeling Language (SysML), is limited in scope relative to an
OCD. The Use Case does not discuss the operational context or environment, for example. A valuable
feature of Use Cases, which can be included in the OCD, is the Use Case scenario pre- and post-
conditions. The set of Use Case descriptions and the scenarios can be included in the OCD, but their
use should be carefully considered and balanced with the use of narrative and graphics for the remainder
of the OCD. This guide does not suggest that a collection of Use Cases and Scenarios can, in itself,
constitute an OCD.

Gabb (Gabb, 2001a) has defined the relationship between OCDs and Use Cases:

“The application of Jakobson's Use Cases [has become] popular in software

development projects, particularly since becoming part of the Unified Modeling Language
(UML). Use cases describe what the system will do, how it will be used, and interactions
between the system and the external world, including users. Each use case will also
often include 'scenarios' showing instances of how the system is used in specific
circumstances.

“While use cases are more limited in scope than an OCD, they can be used effectively in
partially describing the proposed capability and scenarios. …When used in this way the
remainder of the OCD can be viewed as providing the context which allows the use
cases to be considered as part of the overall capability.”

Jorgenson (Jorgenson, 2002) has shown a complementary relationship between Use Case and the
Operational Concept. The Use Case can provide much of the information needed for the scenarios to be
developed for the OCD.

Simmons (Simmons, 2005, 2006) has reported on a “usage model” approach used at Intel that
incorporates parts of the Use Case narrative and expands upon the description to include some materials
in the Operational Concept. It, too, may be used in the development of the OCD and provides a
mechanism for eliciting expected operational behavior from the potential system users.

6.5 Intended Audience

The information in an OCD is intended for communication and understanding between several key
stakeholders. These stakeholders and the specific uses that each will make of an OCD are as follows:
Users / Operators / Maintainers use the OCD for:
• understanding, planning, organizational, operational, and logistical support aspects,
including available resources;
• understanding technical attributes concerned with human–machine interfaces and
interactions, inter- and intrasystem hardware and software interfaces, components,
locations, sequences, functions, and requirements;
• understanding philosophies and policies regarding local and depot maintenance levels,
user and operational constraints related to maintenance, accessibility of the system, and
maximum acceptable downtimes; and
• understanding early definition of operator and user constraints, capabilities, operating
procedures, resources, responsibilities, and user/system integration for use by the
development community.

Users, operators and maintainers may not be different persons, but merely different roles performed by
the same person. For example, a person who has purchased and operates an automobile for his or her
own use is both the user and the operator (and the customer, as well). Should the person also perform
maintenance activities on that automobile, then he or she is also the maintainer.

20
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

It is important to also understand the difference between the external and internal use of a system, and
the external and internal users and operators. In the case of an aircraft system, external use is use of the
system as a whole (e.g., the aircraft), and external users would be maintenance personnel, for example.
The pilot would be seen as an internal user. This is not just a matter of definition, but of decision
regarding who are the users and what scenarios are developed. Separation of these views (in discussion
scope, contexts, boundaries, users, etc.) assists in not missing important operational aspects of the
system. For some systems, the ‘external’ users can be unclear or the analysis is not useful (e.g.
information systems, word processor, rifle). For some systems the ‘external’ users are operators (word
processor, rifle). For some systems the internal users are easy to overlook, e.g., for information systems
the administrators, maintainers and some information providers. Deciding the level at which to determine
external users is critical to understanding the level of description (and scenarios) in the OCD.

System Engineers and Architects use the OCD as a framework to:

• facilitate development team understanding of the mission needs and as a basis for
comparing alternative system designs;
• establish the system context, as defined above, to include a description of interfacing
system structure;
• enable understanding of mission objectives and priorities with the rationale behind them;
• determine relationships of relevant development, operator and user organizational
structures; and
• provides key inputs for requirements analysis, including project scope, interfaces,
functions, capabilities, and constraints.

System Implementers use the OCD to provide:

• a brief overview of the system context with emphasis on the objectives and constraints
along with operational issues such as logistics, facilities, standards, timelines, and end-to-
end information operational flows;
• understanding of the rationale for system objectives; and
• insight into the role of the proposed system with respect to interfacing systems and its
place in the overall environment.

Acquirers use the OCD to:

• facilitate understanding of mission objectives, system goals, constraints, and external
interface agreements;
• form a basis for system acceptance criteria; and
• place into proper context the influence of relevant funding and schedule constraints.

Testers use the OCD to:

• plan test and evaluation organizational, operational, and logistical support aspects,
including available test resources.
• facilitate understanding of mission objectives and system goals to ensure correct
prioritization of test time and focus;
• understand operational and acceptance philosophies to facilitate appropriate test focus
(e.g., effective use of operational sequences and data); and
• understand the operational attributes of external interfaces to ensure thorough testing of
the associated system elements.

21
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Acquirer and Supplier Organization Management use the OCD to:

• focus on the system context with emphasis on mission objectives and system goals,
policies and philosophies, and constraints; and
• facilitate the understanding of the effect of the envisioned system upon the elements and
activities external to the system.

Regulators use the OCD to:

• understand usage and technical capabilities to determine if the user capabilities,
underlying technologies, or intended usage raise regulatory issues.

6.6 When to Generate an OCD

The best time to initially generate an OCD is during the study/concept definition phase for a given system.
This activity should begin prior to the initiation of the system requirements analysis phase and, in fact,
should support the activities of that phase. See Clause 6.2 for placement of the OCD development in the
generic development process. However, if an OCD was not developed at the beginning of the program,
one can be developed at a later point in the Program as a remedial OCD to help refocus the development
effort.

Systems are often structured in a hierarchical manner and consist of two or more levels of systems. For
example, given an hierarchy of System, Segment, Subsystem, and Component, an OCD could be used to
great advantage early in the process of defining the system at each of these levels (i.e., one OCD for the
system and one for each segment and subsystem). For a given level, the generation of an OCD should
begin during the earliest stages of the conceptual definition of each system at that level. In this guide, no
distinction is intended regarding the hierarchical level of the system and there may be several OCDs for
various levels in a system hierarchy. At some level in the hierarchy, the value added by generation of an
OCD will not justify the cost. At this level, OCD generation is therefore not recommended.

6.7 OCD Maintenance

Since OCDs are used to aid communications throughout the system development phases, they should be
considered living documents and updated throughout the system life cycle. The latest OCD update should
be available to support formal reviews such as system requirements or preliminary design reviews.

The OCD should also be revised when its parent information sources are changed owing to revisions of
the strategic and operational context that sourced the original OCD, such as strategic rationale,
Integration Support Plans (ISP) or Capstone Requirements.

This updating should be done via the configuration management process with change approval authority
placed at the lowest practical level. For systems expected to be in place for many years after being put
into service, and particularly those that are planned to evolve during their lifetimes, an OCD should be
used after initial system deployment to support the development of enhancements or new system
capabilities. This practice will enable developers to understand better the operational impacts of
proposed modifications. Maintaining the OCD consistent with the current system implementation
provides a very useful source of information to help familiarize new personnel with the system.

One way to achieve OCD maintenance effectively is to keep the OCD in the database or repository used
for managing requirements. The OCD is exported from the repository, and the information maintained
systematically as part of the requirement management activities, using the traceability established
between requirements and operational concepts.

22
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

7 Operational Concept Development Guidance

This section of the Guide describes techniques for generation of an OCD.

7.1 Establish OCD Development Team

Although not a part of generating an OCD per se, it may be necessary to motivate the appropriate
management and personnel of the benefits of such an activity. Providing guidance on such a motivational
activity is beyond the scope of this document. However, if schedule, staff, and budget are not specifically
allocated for development of an OCD, at each appropriate level in the proposed system hierarchy, and an
OCD is not listed among the deliverables, chances are high that this internal sales step will be necessary
before the steps described below can be accomplished. If no budget can be obtained, the production and
maintenance of an OCD can be incorporated in the Requirements Development activity. The justification
for inclusion is that the OCD provides essential domain information to support the development of
requirements.

Engagement of user participants with the right experience, skills, and attitude is critically important,
considering the need for accurate operational information in an OCD. These stakeholders would normally
already be engaged as part of the requirement elicitation process. Such participants and their
management also need to be motivated so that the OCD development task provides the user community
with a unique opportunity to directly influence the capability and characteristics of the proposed system.

7.2 Participants
A key element in any major systems engineering endeavor is the establishment of an interdisciplinary
team. The interdisciplinary OCD team is led by a senior systems/requirements engineer and is comprised
of personnel competent in the operational domain and in all of the disciplines relevant to the system
context. If the OCD is to convey valid information to and from the users, then system engineers,
architects, system implementers, testers, customers / buyers, and customer and contractor managers, or
representatives from each of these communities, should contribute actively to the OCD. The OCD
development team should also include participants familiar with the regulatory environment affecting the
system development and deployment, and participants knowledgeable of the natural and induced
operational environments. Ideally, these stakeholders will already be engaged as part of the
requirements elicitation process.

In the event that representatives from one or more of the stakeholder communities cannot participate in
OCD development, then surrogate representatives should be found. For example, it is unlikely that
customers can participate in OCD development for a consumer product, so members of the developer’s
marketing department might act as surrogates for the potential customers. As a guide to team selection,
refer to Section 6.5, which outlines the intended audience of the OCD.

It should be noted that the OCD may be developed by the system's customer (including users, operators
and acquirers), the system supplier, or a joint customer/supplier team.

The stakeholder who owns the OCD (e.g., customer, with the operational knowledge but not necessarily
the appropriate resource and skills) does not have to be the producer and maintainer of the document
(e.g., a design team, who has appropriate resource, tools and skills). From a purely contractual point of view,
the customer would be expected to produce the OCD. However, the design team would be the main
beneficiary of a timely and high quality OCD, so it may be in the team’s interest to take over this responsibility
from the customer, and produce an OCD that is then simply validated and approved by the customer.

This Guide recommends that people with good experience of System Engineering should take the lead in
authoring the OCD as the document is an important step in transitioning operational knowledge to an
engineer’s or developer’s viewpoint. Although users and operators will normally have the best experience of
operations and should co-author the document, operators and users will not normally have the experience
necessary to conduct the analysis and shape the content of the OCD in terms useful to the program.

23
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

7.3 Generating OCD Content

7.3.1 Overview

The first step in generating an OCD is to establish a clear definition of the scope and boundaries of the
system, defining specifically the border between what is inside the system and what is outside of it, thus
establishing the external interfaces. Once these are established, constraints, including top-level customer
policies, operational philosophy and strategies, and negotiated external requirements (changes to existing
interfacing elements, outside of the system context, which are necessary to accommodate the proposed
system in order for it to interact and function as envisioned) can be described. These, coupled with the
top level mission or system objectives, allow the system engineer to begin to define the operational
concepts. Of course, the available budget and schedule will also influence the extent to which this work
may be accomplished.

In preparing an OCD, the authors should document and discuss their assumptions with regard to the
system. Documenting assumptions is important, particularly when the system definition is still evolving.
The assumptions should be documented near the front of the document since they help set the stage for
the operation concept description that follows. The level of detail and definition of the OCD will be quite
different between the initial OCD and one in use during the maintenance and support phase of the
product life cycle, and the number of assumptions inherent in the Operational Concept Document should
decrease as the system is realized.

The steps necessary to develop the content material of an OCD are described in the following sections.
7.3.2 Defining the System Scope

Establishing the scope of the proposed system, including its overall capabilities, context and boundaries
is critical in the OCD development. Without a clear agreed definition of scope, any subsequent effort will
be difficult and potentially wasted, because of conflicting understandings of scope among team members
and other stakeholders.

The operational scope of a system is a statement of the extent of the problem that the system must
overcome. Often the scope is expressed in terms of a number of different mission types to be performed.
To perform the missions the system must possess combinations of capabilities. With each mission there
must be a success criteria or a goal that must be attained by the system.

The initial step in establishing the system scope is normally to hold one or more meetings and workshops
with critical stakeholders (including users and operators), resulting in a relatively short but agreed
definition of system scope. Review of the scope definition by a wider stakeholder group is also often
warranted, to discover possible errors and omissions. In many cases, gaining agreement on the overall
capabilities of the system can also be difficult, and the scope definition process is likely to reveal some
differences in the understanding of the proposed capabilities for the first time. Consequently, it is
preferable that initial meetings and workshops include personnel who are capable and empowered to
discuss and agree to the proposed capabilities of the system, from operational, technical, cost, political
and regulatory viewpoints. In any case, do not underestimate the time necessary to undertake this step.

It should be noted that, except in straightforward cases, it is rare for the scope to be defined quickly or
completely, and the system scope should be reviewed regularly throughout the OCD development
process. In some cases, it may be necessary to proceed with an uncertain scope—this is where
documenting assumptions becomes important. In these cases, the alternative scope issues and the
nature of the uncertainties need to be clearly identified in the OCD.
7.3.3 Defining the System Context and Boundaries

Given the definition of the system scope, the OCD developers then need to define the system context and
the boundaries. Strengers (2000) has outlined a process for analyzing the operational context of a
system. The OCD developers (both user/operator personnel and developer technical personnel) must

24
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

evaluate the environment in which the system is to operate and all the related entities external to the system
within the environment with which the system must interact and/or interoperate. The context consists of three
components—the physical, functional and organizational contexts. The physical context includes the total
physical environment, to include entities with physical connections and radiation interfaces to the system.

The functional context includes:

• management decisions or commands, directives and orders
• standard operating procedures and regulations
• tactics and strategies
• politics
• geography
• finance
• market forces (Strengers, 2000)

Lastly, the organizational context consists of all organizations with which the user and operator
community will interact in the operation of the system. The context is typically defined graphically through
one or more context diagrams to address all aspects of the environments within which the system
operates (e.g., natural, induced, political, social, economic).

In the definition of the context, the users, operators and developers must define explicitly the boundaries
of the system in order to define what is inside the system and that which is outside the system. As
discussed in Section 6.3.4, there may be several different boundaries relevant to the OCD for the system
under development. It is often difficult to come to agreement on this issue and significant time and
resources need to be allocated to accomplish the definition of system scope, context and boundaries.

In the process of defining the system scope, context and boundaries, it is valuable to consider the
“Building Block” model first published in EIA 632 (ANSI, 1999). The building block model helps ensure the
developer considers the full life cycle of the system. In this model, the system to be developed consists of
end products to be delivered to the customer and enabling products used in the development, production,
utilization, support and retirement of the system, some of which may also be delivered to the customer.
See Figure 7.1 for a graphical depiction of this model. Note that all the end products and enabling
products are part of the system, and within its scope, context and boundaries.

System
consists of consists of

End Development Test Training Disposal

Product Products Products Products Products

consists of
Production Deployment Support
Products Products Products

Subsystem Subsystem

Figure 7.1 — EIA 632 “Building Block” Model Provides Guidance in Determining System Scope and Boundaries

25
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

7.3.4 Defining Useful Operational Scenarios

The key to a successful OCD is the development of Operational Scenarios. The information described in
a typical scenario is shown in Figure 7.2. These scenarios describe the dynamic views of the system's
operation, primarily from the users' points of view. It is this articulation of how the system is perceived to
operate through various modes and mode transitions, including its expected interactions with the external
environment, outlining all important anticipated user, operator, tester, and maintainer interactions that
provide the basis and framework for the system analysis and evaluation.

Figure 7.2 — The Key to a Successful Operations Concept Document Is the Development of Operational Scenarios

As is often the case, there may be insufficient time or budget in a program to describe comprehensively
the operational concepts associated with a system by means of all possible operational scenarios.
Therefore, some skill is needed in selecting an appropriate set of the most useful of many scenarios for
use in the OCD.

A useful scenario is one which describes how a system is to be operated and maintained during a specific
time, mission phase, operational mode, or critical sequence of activities. It enables one to establish the
What, Where, When, Why, and How for the system. For example, a scenario in which the system
operates under extreme conditions, such as being required to process the highest input data rates while
staffed with the lowest expected personnel levels, provides insight into important system aspects.
Attributes such as man–machine interface bottlenecks, which could result in an overall system failure if
the conditions persist for more than a few minutes, could be uncovered by walking through such a
scenario. In another example, a system constraint limiting pointing of a spacecraft sensor within some
number of degrees of the sun, which appears to be adequately met via rigorous operational procedures,
could be found to be violated when normal communications are interrupted by a failure mode that limits
the pointing control capability. This type of interaction would be uncovered by analysis of carefully
selected operational scenarios.

26
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

A scenario can be represented by text in conjunction with a graphical representation, such as a

functional-flow block diagram, an enhanced functional flow block diagram, an activity diagram or a
sequence diagram.

Typically, a set of scenarios will be necessary. Each should focus upon a specific area of interest or
concern and not attempt to cover all aspects at once. These should be selected such that the complete
set contains scenarios dealing with all phases of operations including installation, start up, typical
examples of normal and contingency operations, shutdown, and maintenance. Operations under typical
and stressful conditions (e.g., maximum I/O rates and loads, minimum personnel staffing, and element
failure modes) should be emphasized. One should begin with one or more typical, normal system
operational scenario(s) and later develop those scenarios which focus on stressful conditions and
operations in the presence of system element faults. The primary focus should be upon the user's and
operator’s view of the system but with some scenarios devoted to the operators’, maintainers’ and testers’
views. If the system operation includes decision points where users and operators must choose a course
of action within some limited time frame, a set of scenarios should be included covering these
interactions, particularly those under which there is stress on the personnel.

At the beginning of the design and development phase of a program, the users, operators, and
developers should consider defining end-to-end mission scenarios that are stressing on the system.
These scenarios, which are sometimes referred to as Design Reference Missions (DRMs), may never be
executed as defined, but a system developed to satisfy them will be able to execute a wide range of
missions to satisfy the customer needs.
7.3.5 Developing the Scenarios

Developing the scenarios is a matter of combining the topics listed above. That is, assembling an
interdisciplinary team with the right combination of operational and technical expertise, defining a good
set of scenarios, walking through each scenario step by step and recording the results. This effort has an
additional benefit in that all of the interdisciplinary team members will gain a thorough understanding of
the role the element with which they are associated plays in the context of the other elements, as well as
the rationale behind many of the decisions made as the process evolves. Furthermore, this greater
insight enables them to suggest better ways to apply their own expertise. Development of these
scenarios is discussed in the following sections.

Several scenarios will probably be needed. Initially, one or two that represent normal expected
operations of the system under normal environmental conditions forms a good baseline. This may not be
a simple task because there may be many opinions regarding these seemingly obvious things. To begin,
conduct a series of interviews with or presentations by the people who can authoritatively define what
normal operations are expected to be. Upon defining the normal scenario(s), create additional scenarios
that focus on specific elements of interest (e.g., system operations near boundary conditions, under peak
loads or worst case conditions; operations in the presence of failures or degraded system capabilities).

Strengers (2000) recommended analysis of operational objectives, a static behavior analysis and a
dynamic behavior analysis as part of the development of the OCD. The analysis of operational objectives
yields system goals and success criteria. The static behavior analysis describes how the elements of the
system interact with the system environment to achieve system goals. The dynamic behavior analysis is
dependent upon the static analysis and the analysis of objectives. Development of the scenarios is
central to the static and dynamic behavior analysis, and consists of identification and sequencing of
operational activities in the proper order to accomplish the operational objectives. The analyst must
include scenarios for all significant operational situations and must consider the important off-design and
degraded-mode operational situations as well, to develop a useful set of scenarios.

Upon defining the normal scenario(s), the OCD development team should create additional scenarios that
focus on specific elements of interest (e.g., system operations near boundary conditions, under peak
loads or worst case conditions, operations in the presence of failures or degraded system capabilities).
Given that industrial espionage, reverse engineering, and product piracy are common business activities,

27
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

the OCD should explicitly address one or more feasible scenarios in which the system is being attacked
or hacked (where such attacks are possible).

A list of topics that prompts the OCD developer will be helpful to ensure all necessary aspects are
addressed. This list will vary with the type of system and a sample is provided in Annex A, section A.11.

Once a relatively complete set of data is available, the interdisciplinary team developing the OCD can
begin to determine the sequencing of, and interactions between, activities necessary for the system to
execute a set of normal operations. From the interviews or presentations, it should be possible to define
a sequence of events over a period of time representing some generally complete system functions or
transactions that, once initialized, tend to run to some end. For example, in the case of a spacecraft
system for a deep space scientific mission, some typical operational scenarios would be as follows:

1) a launch through early cruise mode sequence, no spacecraft anomalies;

2) a typical scientific data collection sequence of activities in the presence of a
spacecraft anomaly;
3) a typical trajectory correction maneuver, no anomalies; and
4) response to a spacecraft power system interruption during a trajectory correction
maneuver.

Having selected a scenario, the team should then iteratively walk through all of the detailed steps the
envisioned system must execute to perform the scenario. This discovery activity is comparable to
functional decomposition in traditional systems analysis, or the elaboration of activity or sequence
diagrams from Use Cases in an object-oriented approach.

The definition activity may take some time owing to the immature definition of states, and mode
transitions, at this point in the development cycle. There may, in fact, be significant disagreements within
the team regarding these definitions. A major purpose here is to come to agreement and record clearly
the definitions and descriptions. Development of state machine diagrams may assist in achieving
understanding and agreement of the analysis results and provide documentation of the analysis.

Where there is likely to be a great deal of flexibility or variability within a scenario, the scenario should
reflect this with multiple paths indicating variants and options. Each variant may be fully fleshed out or
simply discussed in the context of other variants. Use may also be made of “common operations,” in
which certain sub-operations are common to more than one variant or scenario. In making these
decisions, it should be noted that it is important for OCD users to quickly assimilate each scenario, and
excessive detail and repetition will reduce this ability.
7.3.6 Validating the Scenarios

Scenario validation involves a number of activities aimed at providing assurance that the scenarios
provided are adequate for the purposes of the OCD. Validation begins with stakeholders checking the
scenarios for the following attributes:

Correct Each scenario is a proper representation of intended

operations, is acceptable to the user and operator community,
and includes all important operational characteristics needed
to represent those operations

Executable Each scenario provides a proper representation of the user

operations
Understandable The users and operators understand each scenario and see it
as representative of their intended operations

Clear Each scenario is unambiguous

28
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Accurate Each scenario provides an accurate representation of likely

user operations (i.e., the operations described would be
generally accepted as accurate by the user community)

Feasible Each scenario describes user operations that are feasible,

given the nature of the operations and the skills of the users

Complete The set of scenarios addresses all important nominal and

unusual events, and the users and operators can perform their
intended operations within the scope of the scenario set.

The users, operators, and maintainers are certifying that the scenarios are understandable, are correct,
and comply with policies and procedures, and that each scenario is complete. The assessment of
completeness is critical. Such user/operator/maintainer validations are particularly enhanced by use of
executable models and, possibly, real-time operational simulations.

The Operational Concept developers should also ensure that the set of scenarios is sufficient (i.e., the set
covers all important nominal and unusual events; stressors, off-design, and degraded operations) and
that users can perform their intended operations within the scope of the scenario set. The consequences
and likelihood of occurrence of the developed scenarios should be evaluated and any additional
scenarios required should be identified and defined.

Validation of the scenarios is accomplished by performing walk-throughs on the defined scenarios in

accordance with any governing policies and procedures. The scenario walk-through examines the
sequence of events, extremes of the stimuli, environmental conditions and data, and the resultant
exercising of system functions and responses. The user and development communities must be
intimately involved in validation of the scenarios, particularly in the assessment of validity.

The OCD will be one of the bases for justification of large expenditures for complex development
Programs. Therefore, it is strongly recommended that all stakeholders review all the scenarios to validate
that they represent potential solutions to user needs and to identify possible conflicts across operational
domains. In particular, potential users, operators and maintainers should walk through each scenario and
determine that it provides proper handling for all events and is acceptable, and that all important
scenarios (nominal and off-design) are represented. In addition, the users, operators, and maintainers
are certifying that the scenarios are understandable, are correct, comply with policies and procedures,
and that each scenario is complete. (Should the developer not have access to potential users, operators
and/or maintainers, then surrogates should be used.)

In performing scenario validation, the stakeholders should use historical data (where available) and
experience and comparable reference systems. Lastly, scenario validation should be performed using
simulation or modeling, where feasible, to assess the dynamic characteristics of the system. Validation
will be enhanced if the models and simulations are third-party accredited.

7.4 Agreed Format and Style

The required content and format of an OCD should be agreed and understood by all participants. Prior to
the DoD acquisition reform activity, in which many management standards were cancelled, there were
several Data Item Descriptions for the Operational Concept Document. However, these were cancelled
with the associated standards.

OCDs should be developed in accordance with an acquirer–developer agreed format. If the acquirer has
no preferred format and content, then the developer should prepare an annotated table of contents and
the acquirer and developer should agree to it prior to beginning work. A suggested content outline for an
OCD is shown in Figure 7.3 and is described in more detail in Annex A. Other formats may be
appropriate or, in some cases, imposed.

29
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Considering the intended audience of an OCD (see Section 6.5), the OCD must be somewhat all things to
all people because the intended audience has a wide range of technical and managerial backgrounds. At
the same time it must remain readable and understandable. The most practical way to achieve this goal
is to write the OCD in a narrative form describing in prose and graphics (unlike a specification) the way in
which the system is envisioned to fit and function within the proposed or expected operational
environment. The language and forms of communication, such as graphics, functional flow diagrams,
timelines, simulations, and operational mockups should be chosen predominantly to be those that the
system users will understand. Where other members of the audience may not understand these, they
should be carefully explained to reduce the possibility of misinterpretations.

Text &
s
Graphic

Oper B.
B. System
System Operational
Operational Scenarios.
Scenarios. Detailed
ati Detailed
Co n c o n a l sequences
sequences of of user,
user, system,
system, and
and environmental
environmental events:
events:
ept
•Normal
•Normal conditions
conditions
•• “Stress”
“Stress” conditions
conditions
A. Acronyms,
Acronyms, Abbreviations
A.•Failure Abbreviations and and Glossary.
Glossary.
•Failure events
events
9. •Maintenance
•Maintenance
9. Analysis
Analysis ofof the mode
mode
the Proposed
Proposed System.
System. Summary
Summary ofof
•Handling
Advantages, anomalies/exceptions
•HandlingSummary
Advantages, anomalies/exceptions
Summary of
of Disadvantages/
Disadvantages/
Limitations,
Limitations, Alternatives
Alternatives and
and Tradeoffs
Tradeoffs Considered
Considered
8.
8. Other Operational Needs. Comparison of
Other Operational Needs. Comparison of
Operational
Operational Needs
Needs and
and System
System Operational
Operational Capability
Capability
7.
7. Operational
Operational Processes.
Processes. Describe
Describe Likely
Likely Missions
Missions and
and
Operations
Operations of of Proposed
Proposed System,
System, Processes,
Processes, Operational
Operational
Describes system Flow,
Flow, Sequences,
Sequences, Inputs
Inputs and
and Outputs,
Outputs, Dependancies
Dependancies and
and
characteristics from an 6. Concurrencies
Concurrencies
6. System
System Overview.
Overview. System
System Scope,
Scope, System
System Goals
Goals and
and
operational perspective Objectives,
Objectives, Users
Users and
and Operators,
Operators, System
System Interfaces,
Interfaces,
System
System States
States and
and Modes,
Modes, System
System Capabilities,
Capabilities, System
System
5. Architecture
Architecture
5. Operational
Operational Overview.
Overview. Missions,
Missions, Operational
Operational
Policies
Policies and
and Constraints,
Constraints, Operational
Operational Environment,
Environment,
“What does it look like Personnel,
Personnel, Support
Support Concept
Concept andand Environment,
Environment,
from my point of view?” Justification
Justification for
for and
and Nature
Nature of
of Changes,
Changes, Impact
Impact Summary
Summary
4.
4. Existing
Existing Systems
Systems andand Operations.
Operations. Operational
Operational
Overview, Including Environment, Personnel,
Overview, Including Environment, Personnel,
System
System Overview,
Overview, Support
Support Environment
Environment
3.
3. Background Information.
Background Information. Details
Details and
and History
History ofof
Needed
Needed Capability,
Capability, Organizational
Organizational Infrastructure,
Infrastructure,
History
History of
of Project,
Project, Stakeholders,
Stakeholders, Related
Related Projects
Projects
2. and
and Systems
2. Referenced
ReferencedSystems
Documents.
Documents.
1.
1. Scope.
Scope. Identification,
Identification, System
System Purpose,
Purpose,
Document
Document Overview
Overview

Figure 7.3 — Outline for Operations Concept Document

8 Bibliography

Anderegg Anderegg, Alfred, A Concurrent Process for Development and Validation of

th
1996 Operational Requirements, 6 Annual International Symposium of the International
Council on Systems Engineers, Boston, Massachusetts, 1996
ANSI 1999 Processes for Engineering a System, ANSI/EIA-632-1998, American National
Standards Institute/Electronic Industries Alliance, 7 January 1999
h
Buede1995 Buede, Dennis, Risk/Decision Analysis for Trade Studies, 5 Annual International
Symposium of the National Council on Systems Engineers, St Louis, Missouri, 1995

30
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Cropley Cropley, David and Kirby, Brendan, Modeling and Simulation of Military System
th
2002 Architecture Using CORE, 12 Annual International Symposium of the International
Council on Systems Engineers, Las Vegas, Nevada, 2002
DoD 1985a Management of Computer Resources in Defense Systems, Defense Joint Logistics
Commanders (JLC), Joint Regulation, Department of Defense, June 1985
DoD 1985b Defense System Software Development, DoD-STD-2167, Department of Defense,
June 1985
DoD 1985c Configuration Management Practices for Systems, Equipment, Munitions, and
Computer Programs, MIL-STD-483A, Department of Defense, June 1985
DoD 1985d Specification Practices, MIL-STD-490A, Department of Defense, June 1985
DoD 1985e Technical Reviews and Audits for Systems, Equipments, and Computer Programs,
MIL-STD-1521B, Department of Defense, June 1985
DoD 1985f Operational Concept Documents, DID DI-MCCR-80023, SDS Documentation Set –
Data Item Descriptions for DoD-STD-2167, Department of Defense, 4 June 1985.
DoD 1988a Defense Systems Software Development, DoD-STD-2167A, Department of
Defense, February, 1988
DoD 1988b DoD Automated Information Systems (AIS) Documentation Standards, DOD-STD-
7935A, October 1988
DoD 1994a Software Development and Documentation, MIL-STD-498, Department of Defense,
December 1994,
DoD 1994b Operational Concept Description (OCD), DID DI-IPSC-81430, 5 December 1994
DoD 2000 CJCSI 6212.01B, Interoperability and Supportability of National Security Systems,
and Information Technology Systems, 8 May 2000
DoD 2001 CJCSI 3170.01B, Requirements Generation System, 15 April 2001
DoD 2009b DoD Architecture Framework, Version 2.0, Volume II: Architectural Data and
Models Architect’s Guide, 28 May 2009
DoD 2008 DoDI 5000.02, Operation of the Defense Acquisition System, December 8, 2008
DoD 2009a CJCSI 3170.01G, Joint Capabilities Integration and Development System, 1 March
2009
DoD 2010 JP 1-02, Department of Defense Dictionary of Military and Associated Terms, 12
April 2001 (as amended through 31 July 2010)
Dusting Dusting, Jeffrey, The Importance of Business Systems Definition in Requirements
th
2001 Definition – A Case Study or Two, 11 Annual International Symposium of the
International Council on Systems Engineers, Melbourne, Australia, 2001
FAA 1993 Software Development for the National Airspace System, FAA-STD-026, August
1993
Fairley 1994 Fairley, Richard E, Thayer, Ruchard H and Bjorke, Per, The Concept of Operations:
The Bridge from Operational Requirements to Technical Specifications,
Proceedings of the First International Conference on Requirements Engineering,
Colorado Springs, Colorado, 1994

31
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Feerrar Feerrar, Wallace, and Sinha, Agam, A Collaborative Systems Engineering

th
1996 Approach to an Evolutionary Oceanic System Development, 6 Annual International
Symposium of the International Council on Systems Engineers, Boston,
Massachusetts, 1996
FHWA- Federal Highway Administration, FHWA-HOP-07-001, Developing and Using a
HOP-07-001 Concept of Operations in Transportation Management Systems, August 2005
Gabb 2001a Gabb, Andrew, Operational Concepts – Variations on a Common Theme, presented
at the Sixth Australian Workshop on Requirements Engineering, Sydney, Australia,
November 2001.
th
Gabb 2001b Gabb, Andrew, Front-End Operational Concepts – Starting from the Top, 11
Annual International Symposium of the International Council on Systems Engineers,
Melbourne, Australia, 2001
Gambhir Gambhir, Sukhdeep and Scotti, Richard, A Conceptual Framework for a Customer-
th
1996 Centered Systems Development Lifecycle Model, 6 Annual International
Symposium of the International Council on Systems Engineers, Boston,
Massachusetts, 1996
Haskins Haskins, Cecilia, ed, Systems Engineering Handbook A Guide for System Life
2010 Cycle Processes and Activities, INCOSE-TP-2003-002-03.2, June 2010
IEEE 1998a IEEE Standard 1362, IEEE Guide for Information Technology – System Definition –
Concept of Operations Document, 19 March 1998
IEEE 1998b IEEE/EIA 12207.1-1997, Industry Implementation of International Standard ISO/IEC
12207:1995 (ISO/IEC 12207) Standard for Information Technology – Software life
cycle processes—Life cycle data, April 1998
IEEE 1998c IEEE/EIA 12207.0-1996, Industry Implementation of International Standard ISO/IEC
12207:1995 (ISO/IEC 12207) Standard for Information Technology – Software life
cycle processes, March 1998
IEEE 2005 IEEE Standard for Application and Management of the Systems Engineering
Process, IEEE Std 1220-2005, Software and Systems Engineering Standards
Committee of the IEEE Computer Society, New York, New York, March 2005
IEEE 2008 IEEE Std 12207-2008, Systems and software engineering — Software life cycle
processes, Second edition, 2 February, 2008
ISO 2002 ISO 14711:2002(E), Space systems – Unmanned mission operations concepts –
Guidelines, 2002
ISO 2003 ISO/IEC TR 19760:2003(E), Systems engineering — A guide for the application of
ISO/IEC 15288 (System life cycle processes), 15 November 2003

ISO 2008 ISO/IEC 15288, Systems and software engineering – System life cycle processes,
Second edition, 2 February, 2008
Jorgensen Jorgensen, Raymond, Operational Concepts and the Case for Use Cases: Unifying
th
2002 UML with Systems Engineering, 12 Annual International Symposium of the
International Council on Systems Engineers, Las Vegas, Nevada, 2002

32
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Kays 1992 Kays, James, Systems Engineering at the US Military Academy, 2nd Annual
International Symposium of the National Council on Systems Engineers, Seattle,
Washington, 1992
LaMonica LaMonica, Frank, and Comer, Edward, Advanced System Engineering Automation
st th
1994 (ASEA): Automated System Engineering for the 21 Century, 4 Annual
International Symposium of the National Council on Systems Engineers, San Jose,
California, 1994
Lano 1990 Lano, Robert J, “A Structured Approach for Operational Concept Formulation”,
reprinted in Thayer, Richard H and Dorfman, Marlin, System and Software
Requirements Engineering, IEEE Computer Society Press Tutorial, IEEE Computer
Society Press, Los Alamitos, California, 1990.
NASA 1989 Concept Data Item Description, SMA-DID-P100, NASA Product Specification
Document Standard, Release 4.3, 28 February, 1989
th
Rindskopf Rindskopf, Sam, Mined Geologic Disposal System Concept of Operations, 6
1996 Annual International Symposium of the International Council on Systems Engineers,
Boston, Massachusetts, 1996
Rogers 1995 Rogers, Christopher, Densler, Kristina, Englert, Mary, King, Taylor and Tulloch,
Michael, The Human Factors Engineering Specialty Within the Systems
th
Engineering Process, 5 Annual International Symposium of the National Council
on Systems Engineers, St Loius, Missouri, 1995
Simmons Simmons, Erik, The Usage Model: A Structure for Richly Describing Product Usage
th
2005 During Design and Development, Proceedings of the 13 IEEE International
Conference on Requirements Engineering, 2005
Simmons Simmons, Erik, The Usage Model: Describing Product Usage During Design and
2006 Development, IEEE Software, IEEE Computer Society, 2006
Strengers Strengers, George, Development of Operational Concept Descriptions (Analyzing
2000 what the customer needs), Proceedings of the 2000 Systems Engineering / Test
and Evaluation Conference, Australia, 2000
Thaler 1993 Thaler, David E, Strategies to Tasks A Framework for Linking Means and Ends,
The RAND Corporation, 1993, ISBN 0-8330-1461-7
TRW 1980 Structured Approach for Operational Concept Formulation (OCF), TRW Defense
and Space Systems Group, T-031-979, Redondo Beach, California, January, 1980
USAF 1998 ACC Instruction 10-650, Development and Use of Concepts of Operations,
Department of the Air Force, 11 September 1998
USAF 2003 Air Force Policy Directive 10-28, Air Force Concept Development, Department of
the Air Force, 15 September 2003
USAF 2004 ACC Instruction 10-280, Air Combat Command (ACC) Concept Development, 5
January 2004
USAF 2005 Air Force Instruction 10-2801, Air Force Concept of Operations Development, 24
October 2005

33
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Annex A Recommended OCD Content (Informative)

This Annex is a description of information that is recommended for inclusion in an OCD. It should be
noted that the content is meant to be tailored and that the level of detail to be included will typically
depend on when, in the system life cycle, the OCD is prepared or updated, and the purpose for which the
OCD is being developed.

The OCD contents are organized to tell a story, describing the current, if any, operational processes in
the mission area, enumerating the user and mission needs, providing an overview of the envisioned
system capabilities and architecture, and tying it all together by detailing scenarios of how the system is
used in accomplishing the various operational processes. It provides unique information regarding the
operational use of the system, the processes followed, and typical scenarios of usage.

In this Annex, sections numbered “A.x” represent sections in the OCD numbered “x”. The following table
provides a table of contents for this Annex.
Table A-1 — Mapping of Annex Clauses to OCD Sections

Annex OCD
Section Section
Number Number OCD Section Title
A.1 1 Scope
A.1.1 1.1 Identification
A.1.2 1.2 System Purpose
A.1.3 1.3 Document Overview
A.2 2 Reference Documents
A.3 3 Background Information
A.4 4 Existing Systems and Operations
A.5 5 Operation Overview
A.5.1 5.1 Missions
A.5.2 5.2 Operational Policies and Constraints
A.5.3 5.3 Operational Environment
A.5.4 5.4 Personnel
A.5.4.1 5.4.1 Organizational Structure
A.5.4.2 5.4.2 Personnel Profile
A.5.5 5.5 Support Concept and Environment
A.5.6 5.6 Justification For and Nature of Changes
A.5.6.1 5.6.1 Justification for Change
A.5.6.2 5.6.2 Summary of Needed Changes
A.5.6.3 5.6.3 Changes Considered But Not Included
A.5.7 5.7 Impact Summary
A.6 6 System Overview
A.6.1 6.1 System Scope
A.6.2 6.2 System Goals and Objectives
A.6.3 6.3 Users and Operators
A.6.4 6.4 System Interfaces
A.6.5 6.5 System States and Modes
A.6.6 6.6 System Capabilities
A.6.7 6.7 System Architecture
A.7 7 Operational Processes
A.8 8 Other Operational Needs
A.8.1 8.1 Mission Needs
A.8.2 8.2 Personnel Needs
A.8.2.X 8.2.X Personnel Type
A.8.3 8.3 Quality Factors
34
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Annex OCD
Section Section
Number Number OCD Section Title
A.9 9 Analysis of the Proposed System
A.9.1 9.1 Summary of Advantages
A.9.2 9.2 Summary of Disadvantages/Limitations
A.9.3 9.3 Alternatives and Tradeoffs Considered
A.9.4 9.4 Summary of Impact by Classes of Users
A.9.5 9.5 Regulatory Impacts
A.9.6 9.6 Other Impacts
A.10 Appendix A Acronyms, Abbreviations and Glossary
A.11 Appendix B Detailed System Operational Scenarios
A.11.1 B.1 Operational Processes
A.11.1.x B.1.x Scenario
A.11.2 B.2 Common Scenarios and Conditions

This recommended OCD content suggests that the current and future operations are presented in
separate OCD sections (described in clauses A.4 and A.5). An alternative is to present the current, future
(and possibly interim, degraded, etc.) operational concepts for a particular topic, together in the same
OCD section, rather than in separate sections. Using this alternative OCD content list, the subsections of
OCD Sections 4 and 5 would individually address the current and future concepts (including interim
concepts, degraded concepts, and others as appropriate).

A.1 Scope
This OCD section documents the scope of the OCD.

A.1.1 Identification

This OCD subsection should contain the approved identification number, title, and abbreviation, if
applicable, of the system to which the OCD applies.
A.1.2 System Purpose

This OCD subsection should briefly state the purpose of the system to which the OCD applies.
A.1.3 Document Overview

This OCD subsection should summarize the purpose (including intended audience) and contents of the
OCD.

A.2 Referenced Documents

This OCD section should list by document number and title all documents referenced in this document. It
should also identify the source for each document.

A.3 Background Information

This OCD section contains background information that is useful in understanding the needed capability,
the existing system, the proposed system, and/or the project to provide the proposed system. Where
information is only relevant to the existing or proposed system, that information should be provided in the
appropriate sections rather than this section. Typical information which may be included in this section
includes the following:

35
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

• details and history of the needed capability;

• a description of the higher level organizational infrastructure;
• details and history of the project;
• a review of stakeholders for the system and project; and
• discussion of related projects and systems.

The section helps to define the “why” of the system.

A.4 Existing Systems and Operations

This OCD section describes the system(s) currently being used for the operations described in the OCD,
and the nature of the operations being conducted. This section is only relevant where the capability has
previously been provided by an existing system (or systems), and where discussion of that system is
useful in understanding the capability. Note that the existing operations may be manual or include
manual process components. The information provided, including the level of detail, should be
constrained to what is useful in understanding the future operations.

The structure of Section A.5 should be used as an indication of the structure and content for this OCD
section. Appropriate information may include for example:
• operational overview, including the operational environment;
• personnel;
• system overview; and
• support environment.

A.5 Proposed System Operational Overview

This OCD section provides an overview of the operations and operational context of the proposed
system, supporting the description of the operations in Section A.7. The operational overview is provided
from the users’ perspective(s) and within the system operational environment. The system operational
environment is that environment in which the user performs his tasks, and is the subject of this section of
the OpsCon. The information in this section of the OpsCon provides a static description of the
relationship of the system with the environment.

This section summarizes, in a prose style with graphics, information regarding the mission of the system,
its operational environment, and a characterization of the personnel. Where an OCD is influenced by
other operational information, such as other OCDs, ConOps documents, doctrine and/or procedures, that
information should be referenced here. In some cases, particularly where the OCD is part of a hierarchy
of operational documents, traceability should be provided to higher level documents.
A.5.1 Missions

This OCD subsection should describe the applicable primary and secondary mission(s) that the system
will address. It should state the overall purpose and intent of operations and should describe, if
applicable, such issues as threats or opportunities, geography or location of operations, strategies used
to accomplish the mission, and specific tactics, methods or techniques employed to accomplish the
mission. Where there are multiple missions, these should be prioritized where possible.

This section should describe “what” the system is intended to do, and, to some extent, “how” and “when”
it is expected to do it. It is important to explain key operational terms and operational jargon in a
language that will be clearly understood by a wider audience.

36
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

A.5.2 Operational Policies and Constraints

This OCD subsection should reference the policies and standards governing the mission and describe the
use and applicability of the system. It should also describe any other operational constraints that govern
or limit operations (e.g., personnel availability and acceptable weather).
This OCD section also helps define “where” the system will operate in a sociopolitical or economic sense.
A.5.3 Operational Environment

This OCD section should describe the physical operational environment(s). This may include discussion
of the following, for example:
• temperature, humidity, contaminants, noise, shock, vibration;
• facilities, equipment, computing hardware and software;
• interoperating systems;
• the social, geopolitical and economic environments affecting operations; and
• elements that threaten, challenge or cooperate with the system.

This section also describes any changes to the environment that are likely to occur within the lifetime of
the proposed system, including those caused by the introduction and use of the system itself. This section
defines “where” the system will operate.
A.5.4 Personnel

This OCD section defines “who” will operate the system.

A.5.4.1 Organizational Structure

This OCD subsection should identify and describe the organizational structure(s) of the personnel. It
should state the charter of each organizational element and describe any reporting and other
relationships where they are relevant to the system of interest.
A.5.4.2 Personnel Profile

This OCD subsection should identify the various types of personnel involved in the mission, including
users, operators, and maintainers. For each personnel type the following information should be provided,
as appropriate:
• title(s);
• roles and responsibilities relating to the missions;
• activities performed in fulfilling the missions;
• educational and training background required or assumed;
• physical characteristics as appropriate;
• skill levels required or assumed, including language skills; and
• relationship to the stakeholder organizations that were defined in Section A.3.

This OCD section also describes any changes to the personnel which are likely to occur within the lifetime
of the proposed system, including those caused by the introduction and use of the system itself.

This OCD section should describe the interactions of personnel, within the organizational boundaries and
between organizations. Both formal and informal interactions should be identified.
A.5.5 Support Concept and Environment

This section describes the support concept and support environment for the system (noting that the
support environment, or parts thereof, may be within the operational environment).

37
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

The support concept may include the following, for example:

• policies and constraints relevant to support of the deployed system, referring to Section
A.5.2;
• the support environment (see below);
• operational procedures relevant to the support of the deployed system, with reference to
the scenarios in Section A.11;
• the use of automated test equipment;
• repair versus replacement criteria;
• maintenance levels and cycles;
• Government versus contractor support;
• required facilities;
• requirements and/or impacts on the supply system;
• identification of organizations and personnel involved in the system's development,
support, and use, referring to Section A.5.4; and
• phases of system life cycle and related issues.

The support concept should be limited to those issues which arise directly from the proposed operational
capability defined in the OCD.

Description of the support environment(s) may include discussion of the following, for example:
• temperature, humidity, contaminants, noise, shock, vibration;
• facilities, equipment, computing hardware and software; and
• the geopolitical and economic environments affecting support.

It is not intended that this OCD section include planning or design of support for the proposed system.
Instead it should consider the features of the operations and the proposed system which will give rise to
special needs or treatment in terms of support, particularly those which are likely to incur high costs or
significant risks, and otherwise be based on the system support concept as it is defined at the time of
writing.

This section defines “what” the support concept will do, “how” it will do it (to some extent), and “when” it
will do it. It also defines “where” support will be provided.
A.5.6 Justification for and Nature of Changes

This OCD section provides reasons and rationale for the change in an existing system, such as a new
mission or obsolescence of the system or a component.
A.5.6.1 Justification for Change

This OCD section describes new or modified aspects of user needs, threats, missions, objectives,
environments, interfaces, personnel, or other factors that require a new or modified system. It also
summarizes deficiencies or limitations in the current system or situations that make it unable to respond
to these factors.

This OCD section identifies any assumptions and constraints applicable to the changes identified in this
section.

This OCD section should also include, if applicable, justification for why a new system is proposed as
opposed to the modification of an existing system.
A.5.6.2 Summary of Needed Changes

This OCD section summarizes new or modified capabilities/functions, processes, interfaces, or other
changes needed to respond to the factors identified in A.5.6.1. It should assign priorities to the needed

38
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

changes identifying, for example, each change as essential, desirable, or optional, and prioritizing the
desirable and optional changes.
A.5.6.3 Changes Considered but not Included

This OCD section should identify changes considered but not included in A.5.6.2 and rationale for not
including them.
A.5.7 Impact Summary

This OCD section summarizes the impacts on users, operators, support personnel and other involved
agencies arising from the implementation of the proposed capability. Its purpose is to provide advance
notice to elements and organizations, including those external to the system, which may need to take
action in response to the changes to be made as a result of the capability. It should also identify impacts
to the natural, operational, and support environments resulting from the implementation of the proposed
capabilities.
Impacts may include the following:
• operational impacts, including significant changes in the modes of operation under
different conditions or regulatory restrictions, procedures, interfaces with other systems,
and the source and handling of information;
• organizational impacts, including changes to responsibilities, addition or elimination of
responsibilities or positions, the need for training or retraining; and changes in number,
skill levels, position identifiers, or location of personnel in various modes of operation; and
• impacts during the development effort, including meetings/discussions regarding the new
system, development or modification of common information, training, parallel operation of
the new and existing systems, impacts during testing of the new system, technologies or
usage subject to regulatory control; and other activities needed to aid or monitor
development.

It should be noted that some of this information may not be available during preparation of the OCD early
in the system development. In such circumstances, it is appropriate to avoid inclusion of purely
speculative material.

A.6 System Overview

The intent of this OCD section is to provide an overview of the system, rather than a detailed description
of system architecture, functions and other characteristics. Where appropriate, detailed information may
be referenced, but should not be included here. The section should include a discussion of the system
scope, system boundaries (both physical and operational 4), personnel involved, system states and
modes, capabilities, the system architecture and external interfaces (and any significant internal
interfaces). The system overview is written from the perspective(s) of the system operators and
maintainers, in their operational environment, and is defined for the system of interest.

The system overview should only be detailed enough to provide the information needed to understand the
other sections of the Operational Concept Document. Early in the development activity, the system
overview describes the conceptual system. As development progresses, this section is updated, finally
describing the actual system operational concept at the end of the development effort.
A.6.1 System Scope

This OCD subsection should describe the scope of the system within the context of the mission. It should
describe the primary use(s) of the system within the context of the operational environment.

4 The OCD developer should refer to the discussion of boundaries in Section 6.3.4.

39
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

A.6.2 System Goals and Objectives

This OCD subsection should describe the system's goals and the objectives and expectations for it,
quantified where possible, and the key performance attributes for the system. These should include the
system quality factors (e.g., availability, reliability, maintainability, transportability, flexibility, expansion).

The goals and objectives will define “why” the system exists and should be related to the missions
described in Section A.5.1.
A.6.3 Users and Operators

This OCD subsection should identify the various users and operators of the system, relating them to the
personnel described in Section A.5.4.
It is important to clearly describe the difference between the users and the operators of the system. Both
points of view, while potentially very different, are needed to ensure a well-designed system.

The users and operators section will discuss “who” is involved in the use of the system and their
responsibilities, authorities and accountabilities.
A.6.4 System Interfaces and Boundaries

This OCD subsection should identify and describe the various internal and external interfaces of the
system. It should also identify the relationships between systems in which the organization (enterprise) is
a FoS/SoS. The system interfaces section defines, in part, “where” the system is operated and supported.
The placement of the system boundary is normally accomplished once the external interfaces are
understood and such subtle interfaces as those associated with system operators and users are also
clarified and understood. This section should complement the discussion conducted in Section A.5.3 by
relating the defined interfaces and boundaries to the Operational Environment.
A.6.5 System States and Modes

This OCD subsection should describe, at a high level, the operational states and modes and relate them
to the various operational processes and user activities. Definition of all normal operational and support
states and modes, and significant off-design states and modes, will lead to completeness in the selection
of operations defined in the OCD.

The states and modes section will help define “how” the system operates.
A.6.6 System Capabilities

This OCD subsection should identify and describe the capabilities to be supplied by the system as a
whole. It should relate system capabilities and characteristics to specific mission and personnel needs.

The capabilities section defines “what” the system will do.

A.6.7 System Architecture

This OCD subsection should provide an overview of the system architecture, identifying the various
significant system elements and their interrelationships.
The system architecture section defines “what” the system consists of.

A.7 Operational Processes

This OCD section should be written from an operations point of view, describing the missions and
operations as they are likely to exist, using the proposed system.

This OCD section summarizes, in a prose style, the operational processes, providing a process model
describing the operations which take place, the operational flow and sequence of operations, inputs and

40
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

outputs and other issues including dependencies and concurrencies. The information in this section will,
therefore, provide a dynamic description of the system characteristics and how the system will perform to
accomplish the operations. Detailed scenarios for each process should be presented in Appendix B of
the OCD. However, critical operational threads should be discussed in detail in this section of the OCD.

The processes should normally describe the following for each operation, as applicable:
• variations in the operations for different situations, including why, when, where, who, what,
and how;
• the nature and objective(s) of each operation (or activity or task);
• when an operation may occur, including the order of tasks and activities within an
operation, time sequences and the likely duration(s) of the operation;
• what tasks and activities occur, what methods and techniques are used;
• the system states and modes, and configurations, for each operational process;
• how the system is used, and how it responds to achieve the objectives of the operation;
• relationships to and interactions with other operations;
• what inputs are needed for the operation;
• what outputs or outcomes are expected;
• who is involved in the operation, and who does what, including interactions between
different personnel; and
• where the operation occurs.

Additional information that may be included in the operational process description is:
• the level of preparedness needed (i.e. the initial state of personnel, equipment, and
information) to perform the operation successfully;
• the time responses to different stimuli, especially those that stress the system; and
• why an operation may occur, including the stimulus for the operation, and rationale for
specific sequences of activities or tasks including, where appropriate, references to
business rules, strategy and/or tactics.

The scope of the operations should include all activities in which the system will be employed, including
the primary and secondary missions, various levels of maintenance, and supporting or enabling
operations (which support or enable the system to be used in its missions).

An indication should also be given of the importance of each operation, and the relative importance of
different operations.

Processes may be decomposed from high level to lower level processes.

This OCD section should be structured in accordance with the needs of the OCD audience. It could be
hierarchically structured, or it could just be a list of processes. Regardless of the structure chosen, the
contents of this section must be related to the scenarios and the operational needs.

The operations section defines “what” the system does, and, to some extent, “how” it will do it.

A.8 Other Operational Needs

This OCD section provides a comparison of the user/operator/customer needs with the operational
capability provided by the system. It is not a description of the operational requirements, as those
requirements are derived from the OCD (and other sources) subsequent to its endorsement by the
customer, and derivation of those operational requirements involves a good deal more analytical activity
than required to prepare the OCD.

For example, the identification and quantification of system performance may require extensive
operational analysis and system modeling which may only be initiated in other phases of the development
stage of the lifecycle.

41
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

This OCD section may also contain descriptions of those operational needs that complement the
operations but do not readily fit into the preceding section on Operational Processes. That is, those
needs which are operational, but are difficult to describe in terms of process activities: such needs may
relate to security and other important quality factors.

The priority of the operational needs should be documented in this section. This OCD section should
provide a transition between the description of operations (Section A.7 above) to the system overview
Section A.6, stating the mission and personnel needs that drive the requirements for the system.
A.8.1 Mission Needs

This OCD subsection should summarize the mission needs that the system will seek to satisfy. In the
event that a Mission Needs Statement or Initial Capabilities Document has already been prepared, this
section provides a brief summary of that document’s contents and refers the reader to it as a source
document.
A.8.2 Personnel Needs
A.8.2.1 C.8.2.X Personnel Type

For each type, this subsection should describe the personnel needs that the system will seek to satisfy.
A.8.3 Quality Factors

This OCD section will include a discussion of important system quality factors such as:
• Usability;
• Operability; and
• Human performance/error balance

The OCD section will also discuss additional system needs such as security and privacy attributes and
how the conceptual system addresses them.

A.9 Analysis of the Proposed System

A.9.1 Summary of Advantages

This OCD section provides a qualitative and quantitative summary of the advantages to be obtained from
the proposed system, including new capabilities, enhanced capabilities, and improved performance, as
applicable, and their relationship to any deficiencies identified in A.5.6.
A.9.2 Summary of Disadvantages/Limitations

This OCD section provides a qualitative and quantitative summary of disadvantages or limitations of the
proposed system. These disadvantages may include, as applicable, degraded or missing capabilities,
degraded or less-than-desired performance, greater-than-desired use of resources, undesirable
operational impacts, conflicts with user assumptions, and other constraints. Limitations may result from
decisions taken during development or doctrinal inputs to the development activities.

This OCD section should also discuss any adverse impacts on the environment, including the social, geo-
political and economic environment. It should anticipate the effect of those emergent characteristics that
will arise from introduction and use of the system in the environment.
A.9.3 Alternatives and Tradeoffs Considered

This OCD section identifies and describes major alternatives considered to the system or its
characteristics, the tradeoffs among them, and rationale for the decisions reached. It is not intended to

42
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

be a recapitulation of the trade studies nor a report on new trade studies, but rather a summary of the
findings.
A.9.4 Summary of Impact by Classes of Users

For each class of user, this section provides a qualitative and quantitative summary of the impact of the
system on that particular class of user.
A.9.5 Regulatory Impacts

This OCD section describes any potential regulatory issues and how the system addresses or mitigates
these issues. This section needs to provide an overview of the regulatory issues including who the
regulators are and the scope of their authority. This section should enumerate the issues a regulator may
have and how they relate to the system and its development, operation, and maintenance. For example,
in the case of a Foreign Military Sale, this section would enumerate what the critical technologies are,
where and how they are used and/or may be protected, why they are needed, who has access to them,
and when they will be exported.
A.9.6 Other Impacts

Impacts not covered in any other part of OCD Section 9 should be documented here.

A.10 Appendix A: Acronyms, Abbreviations, and Glossary

The Operational Concept Document should be written in conformance with a Program-specific list of
acronyms, abbreviations, and with definitions incorporated in a program-specific glossary. Should the
OCD use terms not incorporated in those references, or should the references not exist at the time of the
OCD creation, then document-specific acronyms, abbreviations, and a glossary should be provided here.

A.11 Appendix B: System Operational Scenarios

This OCD Appendix will provide detailed information for a number of key scenarios that best describe
how the system is used in its operational context by the users, operators, and maintainers. The scenarios
are stated in terms of, and related, to the operational elements defined in Sections A.5.1 through A.5.5
above.

The OCD section should provide typical usage scenarios for each of the operational processes served by
the system, as documented in Section 7 of the OCD. Scenarios describe typical detailed sequences of
user, system, and environment events. Based on the motivations for preparing an OCD, this section is by
far the most important and should receive substantial emphasis. Details on the development of the
scenarios are provided in Section 7.3.5 of this Guide.
A.11.1 Appendix B.1 Operational Processes

This OCD subsection should describe the scenarios for the operational process(s) described in Section 7
of the OCD.
A.11.1.1 Appendix B.1.x Scenario

This OCD subsection should provide, for each operational process, the sequence of user and system
operations/tasks. Each scenario should be related to specific users and system elements.

Several different types of scenarios should be considered, including those that address normal mission
modes, anomaly/exception handling, mission critical activities, safety critical modes/activities, and
maintenance modes. Detailed scenarios should be provided for each Design Reference Mission (DRM)
identified for the system.

Section 7.3.5 of this Guide provides direction for development of an appropriate and quality set of
scenarios. Typical content for a scenario is listed in the following outline.

43
BSR/AIAA G-043A-201X
(Revision of G-043-1992)

Overview
• Summary of what the system is (context), what it is to do in general (mission), and how it
will do it

Sequence
• Data flow
• State and mode transitions
• Decision points (particularly human interactions)

Performance
• Response time
• Delay points / times
• Throughput / turnaround times expected
• Reliability, availability, maintainability
• Survivability
• Supportability
• Key Technical Performance Measures
• Key Measures of Effectiveness

User and Organizational Issues

• User types and technical expertise
• User training constraints,
• User / operator responsibilities and decision authority
• User workload and period over which operators/users can function effectively
• Operator/user comfort and convenience
• Situational awareness

System Environment and Existing Facilities

• Environment in which system must operate, including all physical environments

• Geographical issues
• Safety, security, system integrity needs
• Interfacing systems description and data flows
• Operational aspects which will affect the needs for system growth capabilities, including
flexibility and expansion
• HAZMAT and disposal issues

A.11.2 Appendix B.2 Common Scenarios and Conditions

Various scenarios may share common sections and common conditions. It would be appropriate to
document them in this section and then reference them from the scenario descriptions.

44
 BSR/AIAA G-043-201X
(Revision of G-043-1992)

Annex B Background to this Guide (Informative)

During the 1980s, efforts to describe the need for Operational Concept information and encourage its
preparation originated on at least three different fronts. As early as January 1980, TRW Defense and
Space Systems Group, as part of its TRW Software Series, published a document entitled Structured
Approach for Operational Concept Formulation (OCF; TRW 1980). At that time, it was recognized that
operational concept formulation (i.e., defining system goals, missions, functions, and components) was
important to the success of a system development and would have an impact on the overall system
design and development process. The purpose of the document was to present a series of ideas,
concepts, tools, techniques, and procedures for more effectively accomplishing the system engineering
tasks of concept formulation, requirements analysis and definition, architecture formulation, and system
design. A later paper on the subject by Robert J. Lano (1990), was published in an IEEE document.

In June 1985, a subgroup under the Department of Defense Joint Logistics Commanders (JLC) produced
a Joint Regulation entitled, Management of Computer Resources in Defense Systems (DoD, 1985a). The
purpose of the regulation was to establish policy for the acquisition, management, and support of Mission
Critical Computer Resources (MCCR) software during all phases of the system life cycle. The Joint
Regulation included DoD-STD-2167, Defense System Software Development (DoD, 1985b); MIL-STD-
483A, Configuration Management Practices for Systems, Equipment, Munitions, and Computer Programs
(DoD, 1985c); MIL-STD-490A, Specification Practices (DoD, 1985d); and MIL-STD-1521B, Technical
Reviews and Audits for Systems, Equipments, and Computer Programs (DoD, 1985e). Within the
associated set of DIDs for DoD-STD-2167 was a DID entitled, Operational Concept Document (DoD
1985f), the purpose of which was to describe the mission of the system, its operational and support
environments, and the functions and characteristics of the computer system within the overall system.
During a revision of DoD-STD-2167 (DoD-STD-2167A, February 1988 [DoD 1988a]), the Operational
Concept Document was dropped in favor of some operational concept information appearing in a
System/Segment Design Document.

In December 1994, MIL-STD-498, Software Development and Documentation (DoD, 1994a), was
approved, which merged DOD-STD-2167A and DOD-STD-7935A, DoD Automated Information Systems
(AIS) Documentation Standards (DoD, 1988b). Within the associated set of DIDs for MIL-STD-498 was a
DID entitled Operational Concept Description (OCD; DoD, 1994b), the purpose of which was to describe
a proposed system in terms of the user needs it will fulfill, its relationship to existing systems or
procedures, and the ways the system will be used.

Also in this time frame, a Concept Data Item (NASA, 1989) was published as a National Aeronautics and
Space Administration Product Specification Document Standards. Within the Federal Aviation Agency
(FAA), DoD-STD-2167A was adopted as FAA-STD-026 (FAA, 1993). The OCD, however, was not
dropped. It is still required by the FAA and is typically developed at more than one level within a system
(e.g., system and subsystem levels).

As part of the acquisition reform efforts undertaken by the Department of Defense, the aforementioned
documents have been cancelled in deference to commercial standards. The latest DoD approach to
acquisition is defined in DoDI 5000.02 (DoD, 2008) and CJCSI 3170.01G (DoD, 2009). A generic
development approach is outlined in Section 6.2.

The Operational Concept Document is considered by the American Institute of Aeronautics and
Astronautics (AIAA) Systems Engineering Technical Committee, the AIAA Software System Committee
on Standards, and the International Council on Systems Engineering (INCOSE), to be a very important
and useful document. Development of a set of OCDs and related scenarios at each appropriate level in
the system hierarchy should become a planned activity of any development life cycle, with OCDs and
scenarios defined as specific life cycle products.

45