Operations Concept Document

The Operations Concept document is a technical design document derived from the customers Concept of Operations (CONOPS) and developed through systems engineering’s functional and behavioral decomposition and synthesis into a viable system architecture meeting all project requirements.

The key objective of the Operations Concept document is to capture system behavior. System behavior analysis (Use Case analysis) is the systematic application of requirements, constraints and system behavior goals (CONOPS) to derive a desired behavior. System behavior is captured in the Operations Concept document and expressed in system design implementation

The Operations Concept Document is an architecture driving document. The three components of system design; HW design, SW implementation and Operations Procedures are all equal elements of the system architecture. The Operations Concept Document defines & drives SW and HW implementation providing the context of system behavior.

Documentation reduces risk.

Good requirements specifications buy down programmatic risk. The risk of delivering the wrong thing. Or the perceived wrong thing.

Interfaces present technical risk. Two or more developer’s efforts meet at an interface. The interface must be well understood and documented, and early. A solid IRD will buy down technical risk documenting both “nuts and bolts”, and higher level design. Un- validated and undocumented interface assumptions are very dangerous.

System Behavior is documented in the Operations Concept document. The Operations Concept document buys down both programmatic AND technical risk. The Operations Concept document defines the systems behavior; as such the Operations Concept document is a design document. Its how the system MUST behave, it must be complied with by the developers.

The Operations Concept document also defines the behavior the customer and User sees. The Operations Concept document is generally the most “approachable” document to the customer and User.

Operations Concept Development

The Operations Concept document is developed in conjunction with the derivation of system design. Functional decomposition derives and allocates functions to sub- components of the overall system. But this is always done with a concept of behavior in mind. Therefore these functional allocations captured as requirements in B and C level specifications carry with them expectations of behavior. While these must also be captured as requirements in the specifications they are detailed as system behavior in the Operations Concept document.

The analysis package technique, used during system design derivation, facilitates the flow of derived requirements into the requirements documents and the scenario, captured in the Operations Concept document facilitates validation, verification and O&M procedures development.

Figure 3, Hierarchical System Architecture Elements

The Operations Concept document is a design driving document that describes the mission of the system, its operational and support environments, and the functions and characteristics of the system within an overall operational environment.

Collateral Benefits

System design derived or validated

System requirements derived or validated

Critical timelines derived or validated

Architectural design derived or validated

Integration steps & stages derived

Requirement verification groups derived

Development of verification procedures fac

Development of operations procedures facilitated

Development of System Documentation facilitated

Troubleshooting or anomaly investigation facilitated

The Operations Concept document is developed in conjunction with system design development capturing system behavior detailing the interactions between HW, SW and operators. The Operations Concept document IS NOT the operations manual, but it paves the way towards development of the Operations and Maintenance documents.

Detailing system scenarios of operations also facilitates development of verification plans and procedures as well as pre-deployment readiness activities (rehearsals and training).

I

Figure 4, System Behavior Analysis and Derivative Products

Operations Concept document Structure and Function

Operations Concept document Functions

Provides BIG picture to contractor team members.

Describes functions and interfaces to software developers.

Reassures Customer that we are all on the same page.

Quickly orients stakeholders to the new system; operators, maintainers, customer, testers, system engineers, managers....

Guides the contractor team as it develops and deploys its System.

Operations Concept document Characteristics

Written in the user’s language.

Written in narrative prose (in contrast to a technical requirements specification).

Uses visual forms (diagrams, illustrations, graphs) and story boards whenever possible.

Provides a bridge between the users needs and the developer’s technical requirements documents.

Helps bring to the surface the users’ views and expectations.

Contains a series of scenarios from different stakeholder viewpoints (customer, maintainer, operators, developers, testers, system engineers / architects, managers, etc.).

Integrates the scenarios into a composite system behavioral timeline with internal and external system inputs/outputs.

The Operations Concept document follows the AIAA and IEEE standard for Operations Concept documents typically organized as follows;

1.0 Scope

2.0 Referenced Documents

3.0 Operations

3.1 Operational Overview

3.2 Personnel

3.3 Operational Processes

4.0 Operational Needs

5.0 System Overview

5.1 System Scope

5.2 Users

5.3 System Interfaces

5.4 System States & Modes

5.5 System Capabilities

5.6 System Goals & Objectives

5.7 System Architecture

6.0 Operational Environment

7.0 Maintenance Environment

8.0 System Operational Scenarios

While the organization and structure of the AIAA and IEEE Operations Concept document is very good the key elements from a design capture perspective are the System Overview (Sect 5) with emphasis on system interfaces, states & modes and architecture. The other key section is System Operational Scenarios (Sect 8). Section 8 captures the behaviors of the system.

System Behavior Scenarios

System Behavior scenarios are Use Cases. They are depicted as threads of behavior across the system. Not all Use Cases are equally important, during the system design process the Use Cases are prioritized based on risk and the high priority Use cases are elaborated.

Mission Success Risk- Essential Mission Functionality

Integration Risk -Complex Interfaces & Interactions

Development Risk - New technology or application

Analysis of thread path variants may indicate additional potential risk areas.

>>Warning<< - Potential for infinite path variations is possible Alternate-path Use Cases rarely warrant full elaboration during system design efforts and are generally not captured in the Operation Concept document. The typical approach is to identify significant risks with the major ones understood to the extent that contingency strategies are definable. Contingency processes and procedures are the domain of the 0&M documentation not the Operations Concept document.

Each System Behavior is introduced in the Operation Concept document with explanatory text and illustrated using several key elements from the behavior analysis process; Context Diagram, Message Sequence Chart and Event Flow Table.

Operations Concept Document Outline

Operations Concept Document based on AIAA and IEEE guidelines for OCD organization.

1.0 Scope

I Identification

1.2 System Overview

<Purpose of system>

2.0 Referenced Documents

<documents referenced from Conops>

3.0 Operations

31 Operational Overview

3.1.1 Mission

<Description of Mission(s)>

3.1.2 Operational Policies

<Description of “Rules of Engagement”)>

3.1.3 Operational Constraints

<Description of role of authority>

3.1.4 Existing Operational Environment

<Description of Existing Operational Environment in which the system will he deployed>

3.1.5 Existing Support Environment

<Description of Existing Support Environment in which the system will be deployed)>

3.2 (U) Personnel

3.2.1 Personnel Profile

<Description qf general system personnel functions>

3.2.1.1 Personnel Type

<Description of system Personnel positions)>

3.2.2 Organizational Structure

<Description of Command and Control structure and functional responsibilities in which the system will be deployed)>

3.2.3 Personnel Interactions

<Description of interactions between system personnel and Command and Control structure personnel)>

3.2.4 Personnel Activities

<Description of system personnel activities)>

3.2.4.1 Personnel Type

<Description of system personnel position requirements)>

3.3 (U) Operational Processes

< This section provides a functional overview of the principle elements of the requirements space. This is a system level allocation of responsibilities/requirements.>

4.0 Operational Needs

4.1 Essential Elements

5.0 System Overview

<Section 5 can he used to supplant an SEDD, providing the system level design including detailed theory of operations material Key elements are 5.3 system interfaces, 5.4 States and Modes, and 5.7 Architecture.>

5.1 System Scope

<Description of the scope of the system (within the context of the mission)>

5.2 Users

<Description of the Users (users of the systems product or output as distinct from operators) of the system)>

5.3 System Interfaces

<Graphic and table description of the Jinctional interfaces of the system. External and internal segment level interfaces)>

5.4 System States, & Modes

<Description of the systems modes of operation and criteria for being operational”)>

5.5 System Capabilities

<Description of the capabilities that the system provides)>

5.6 System Goals & Objectives

<Description the reliability, maintainability, transportability, flexibility and expansion capability of the system)>

5.7 System Architecture

<Overview of the system architecture describing the system components and their interfaces.)>

6.0 Operational Environment

<Description of the operational environment the system will function within.>

7.0 Support/Maintenance Environment

<Description of the Support and Maintenance environment the system will function within.>

8.0 System Operational Scenarios

<Description of typical system usage scenarios. Section 8 is the meat of the OCD detailing the behavior of the key elements of the system. Care must be taken to triage the essential and important behaviors. Material flows from Analysis Package work and is represented primarily with the Scenario Sequence Diagram © and Event Flow Table. Organization follows the essential Use Cases; Install, Initialize, Fault Detect, Fault Isolate & Maintain, and Disposal and the standard multi-level hierarchy within these sections.>

Blog	Steve’s Home Page