Table of Contents | Appendix C-8 | Appendix C-10
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