Step 2: Write & Document Requirements

Step 2 “Write & Document Requirements” officially documents the requirements. The requirements must be documented in order to establish a requirements baseline to start building a system and manage any changes. This step focuses on writing down the functional and performance level requirements into the appropriate requirements documents. Requirements can be developed using the Capability Development Tracking and Manager (CDTM) tool for DoD programs.

Main Requirements Documents

The three (3) main requirements Documents produced under the DoD Joint Capabilities Integration and Development System (JCIDS) Process are:

Initial Capabilities Document (ICD): defines the need for a materiel approach, or an approach that is a combination of materiel and non-materiel, to a specific need.
Capability Development Document (CDD): defines the operational requirements for the system that will deliver the capability that meets operational performance criteria specified in the ICD.
Capability Production Document (CPD): defines the information necessary to support production, testing, and deployment of an affordable and supportable increment within an acquisition strategy. The CPD identifies, in threshold/objective format, the specific attributes that contribute most significantly to the desired operational capability

Besides listing requirements, the documents should explain why the product is needed, put the product in context for development, and describe what the finished product will be like. To put the product in context for development, describe the development tools that will be used, the project budget and staffing situations, and the approximate development schedule. Include details about how the finished product will be distributed or accessed and any other pertinent information that affects development.

Requirements Development Lessons Learned

Here are a few of the problems which can be avoided (or at least lessened) by having a good and well-written requirements document:

Building to requirements that do not really reflect the needs of stakeholders
Building a project from inconsistent or incomplete requirements
Making changes to requirements during development, which is costly
Misunderstandings between customers or end-users and developers result in a product that is not what was wanted
Forgetting plans for the project
Feature creep

Step 2 Checklist Items

Below is an excerpt from the Requirements Checklist that can be used in this step.

Were all stakeholder requirements documented?
Was each requirement checked to see that it met all of the following?
- Necessary [trace to a user need]
- Concise [minimal]
- Feasible [attainable]
- Testable [measurable]
- Technology Independent [avoid “HOW to” statements unless they are real constraints on the design of the system]
- Unambiguous [Clear]
- Complete [function fully defined]

Requirements Development Steps:

Overview: Requirements Development Process
Step 1: Gather & Develop Requirements
Step 2: Write & Document Requirements
Step 3: Check Completeness
Step 4: Analyze, Refine & Decompose Requirements
Step 5: Verify & Validate Requirements
Step 6: Manage Requirements

AcqNotes Tutorials

AcqLinks and References:

Updated: 6/11/2021