Connection Between Concept of Operations and Functional Requirements Document?

What's the connection between the Concept of Operations document and the Functional Requirements Document (FRD)?

Once the Concept of Operations document is completed—and the project gets the go-ahead—this document can be used as a starting point by the Business Analyst and those involved in capturing requirements.

Download your template here

System requirements will be derived from the user needs and converted into more formal and exact language as per the Software Requirements Specification (SRS) and the Functional Requirements Document (FRD).

The Software Requirements Specification is written for IT Architects and Software Developers and must be as precise as possible. Avoid ambiguity. Keep each requirement as precise as possible.

Ask yourself: how could the reader misunderstand this requirement?
Where is it ambiguous, vague or contradictory?

The Functional Requirements Document (FRD) is a distillation of the users’ needs, which is later converted into the Software Requirements Specification (SRS).

Technical writers convert them from high-level, user-oriented language into exact, technical statements.

What else does the use cases do?

The operation scenarios (use cases) can also be used to:

• Define the scope of work for system integration

• Determine facilities that must be provided

• Estimate the required funding

• Estimate training requirements

• Identify metrics for measuring and validating the live system

• Identify support requirements

Summary

The Concept of Operations document is a critical part of the Software Development Lifecycle.

The contents of this document must be sufficient to allow the decision-maker to evaluate, approve and assess the worthiness of the proposed system.

This document is necessary to capture all information required for the development of requirements for, and design of the system and the associated support environment.