Table of Contents | Appendix C-8 | Appendix C-10

APPENDIX C-9

CONCEPT OF OPERATIONS (CONOPS)

1.0      INTRODUCTION

The Concept of Operations (CONOPS) document is a high-level requirements document that provides a mechanism for users to describe their expectations of the system. The CONOPS is used as input to the development of formal testable system and software requirements specifications.

The objective of the CONOPS is to capture the results of the conceptual analysis process. During this process, the characteristics of the proposed system (from the user's perspective) and the operational environment in which it needs to function are identified. Both of these aspects, the system's functionality and its operational environment, are equally important.

The CONOPS has the following characteristics:

•      Describes the envisioned system

•      Identifies the various classes of users

•      Identifies the different modes of operation

•      Clarifies vague and conflicting needs among users

•      Prioritizes the desired and optional needs of the users

•      Supports the decision-making process that determines whether a system should be
       developed

•      Serves as the basis for the Functional Requirements Document (FRD)

The outline of the CONOPS is shown at the end of this appendix. The following paragraphs list the specific instructions for the subsections of the outline.

1.1      Project Description

In this section, provide a brief overview of the project.

1.1.1   Background

Summarize the conditions that created the need for the new system (or capability).

1.1.2   Assumptions and Constraints

Assumptions are future situations, beyond the control of the project, whose outcomes influence the success of a project. The following are examples of assumptions:

•      Availability of a hardware/software platform

•      Pending legislation

•      Court decisions that have not been rendered

•      Developments in technology

Constraints are conditions outside the control of the project that limit the design alternatives. The following are examples of constraints:

•      Government regulations

•      Standards imposed on the solution

•      Strategic decisions

Be careful to distinguish constraints from preferences. Constraints exist because of real business conditions. Preferences are arbitrary. For example, a delivery date is a constraint only if there are real business consequences that can happen as a result of not meeting the date. For example, if failing to have the subject application operational by the specified date places the DOJ in legal default, the date is a constraint. A date chosen arbitrarily is a preference. Preferences, if included in the CONOPS, should be noted as such.

1.2      Overview of the Envisioned System

1.2.1   Overview

Give a brief overview of the envisioned system.

1.2.2   System Scope

Give an estimate of the size and complexity of the system

1.3      Document References

List the documents that were sources of this CONOPS. Include meeting summaries, white paper analyses, and SDLC deliverables, as well as any other documents.

1.4      Glossary

Provide a glossary of terms used in the document. This may be provided as an appendix.

2.0      GOALS, OBJECTIVES, AND RATIONALE FOR THE NEW SYSTEM

2.1      Goals and Objectives of the New System (or Capability)

Define the overall goals and objectives of the new system (or capability). State the business problems that will be solved.

2.2      Rationale for the New System (or Capability)

State the justification for the new system or capability. If the need is for a new capability of an existing system, clearly identify the existing systems that must be changed.

3.0      WORK PROCESSES TO BE AUTOMATED/SUPPORTED

Describe each major process and the functions or steps performed during each work process. State the processes and functions in a manner that enables the reader to see broad concepts decomposed into layers of increasing detail. Then show, in a diagram, the sequence of the process steps described above high-level functional requirements.

4.0      HIGH-LEVEL FUNCTIONAL REQUIREMENTS

4.1      High-Level Features

In this section:

•      Describe the features, capabilities, and functions of the system.

•      Describe major system components and interactions.

•      Describe all requirements for interfaces with external systems. Describe, at a high-level,
       data that the system must send to or receive from other systems.

These must be phrased as requirements (e.g., must have definitive word "shall") and have a reference number.

4.2      Additional Features

Describe any additional features that would enhance the utility or usability of the system.

4.3      Requirements Traceability

Show the traceability to the requirements. In addition, state the "child" documents, such as FRDs, that would have requirements that trace back to this one.

5.0      HIGH-LEVEL OPERATIONAL REQUIREMENTS

5.1      Non-functional Requirements

The following should be discussed in general, not as detailed systems specifications. Add subsections accordingly.

•      Performance

•      Accessibility

•      Portability

•      Security

•      System survivability

•      Other

5.2      Deployment and Support Requirements

In this section:

•      Describe deployment considerations such as acquisition of business data to support the
       system including data cleansing and loading.

•      Describe requirements for support of the system such as maintenance organization and
       help desk.

5.3      Configuration and Implementation

•      Describe the operational policies and constraints that affect the proposed new system (or capability).

5.4      System Environment

Describe the environment in which the system will operate.

6.0      USER CLASSES AND MODES OF OPERATION

6.1      Classes/Categories of Users

Identify and describe the major classes/categories of users that will interact with the new system (or capability).

6.2      User Classes Mapped to Functional Features

This section provides an explanation of how the system will look to each user organization (or example, Regional Office, District Office, or different programs). Define variations (if any) in the user work process that correspond to the use of the system by the different classes of users.

6.3      Sample Operational Scenarios

Develop sample usage scenarios (as realistic as possible) for each major user class that show what inputs will initiate the system's functions, how the user will interact with the system, and what outputs are expected to be generated by the system.

7.0      IMPACT CONSIDERATIONS

7.1      Operational and Organizational Considerations

Describe the impacts to existing operations and organizations.

7.2      Potential Risks and Issues

Describe any potential risks and issues associated with the development of the envisioned system. Describe any other consideration, such as project schedule or staffing support and recommended implementation approach. Allocate subsections for each consideration, as necessary.

CONCEPT OF OPERATIONS (CONOPS) OUTLINE

Cover Page
Table of Contents

1.0       INTRODUCTION
            1.1       Project Description
                        1.1.1        Background
                        1.1.2        Assumptions and Constraints
            1.2       Overview of the Envisioned System
                        1.2.1        Overview
                        1.2.2        System Scope
            1.3       Document References
            1.4       Glossary

2.0       GOALS, OBJECTIVES AND RATIONAL FOR THE NEW SYSTEM
            2.1       Goals and Objectives of the New System (or Capability)
            2.2       Rationale for the New System (or Capability)

3.0       WORK PROCESSES TO BE AUTOMATED/SUPPORTED
            3.1       Major Processes and Functions
            3.2       Process Flow

4.0       HIGH-LEVEL FUNCTIONAL REQUIREMENTS
            4.1       High-Level Features
            4.2       Additional Features
            4.3       Requirements Traceability

5.0        HIGH-LEVEL OPERATIONAL REQUIREMENTS
            5.1        Non-Functional Requirements
            5.2        Deployment and Support Requirements
            5.3        Configuration and Implementation
            5.4        System Environment

6.0        USER CLASSES AND MODES OF OPERATION
            6.1        Classes/Categories of Users
            6.2        User Classes Mapped to Functional Features
            6.3        Sample Operational Scenarios

7.0        IMPACT CONSIDERATIONS
            7.1        Operational and Organizational Impacts
            7.2        Potential Risks and Issues

Table of Contents | Appendix C-8 | Appendix C-10