Step 2 “Write & Document Requirements” official document 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.

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.

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 which 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 which 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]

AcqLinks and References:

Updated: 7/28/2017

Print Friendly, PDF & Email