Sign In
App icon


Available Now!
Get the App
Click Here to Continue Browser Session   ❯

Stakeholder Requirements Definition


The Stakeholder Requirements Definition process translates stakeholder capability needs into a set of technical requirements. The process helps ensure each individual stakeholder’s requirements, expectations and perceived constraints are understood from the acquisition perspective.

drawing showing green circles with white exclamation points labeled capability needs going through funnel labeled stakeholder requirements definition and ending up in checklist labeled technical requirements

Failing to perform an exhaustive Stakeholder Requirements Definition process could result in significant requirements creep, rework due to misunderstanding of end-user needs, unexpected contract modifications, cost growth and schedule slip. The objective of this process is to help ensure that stakeholder requirements are feasible, balanced and fully integrated as more information is learned through requirements analysis.

Stakeholder Requirements Definition bridges the gap between the identification of a materiel need, described in the Joint Capabilities Integration and Development System (JCIDS) CJCSI 3170.01, and the acquisition of a materiel solution, governed by the Defense Acquisition System, i.e., DoDD 5000.01 and DoDI 5000.02. Defense Business Systems (DBS) do not employ JCIDS procedures for the development and validation of capability requirements documents (See DoDI 5000.75).

Relationship to Requirements Analysis and Architecture Design

The Stakeholder Requirements Definition process complements Requirements Analysis and Architecture Design (see DAG CH 3–4.2.2 Requirements Analysis Process and DAG CH 3–4.2.3 Architecture Design Process, respectively).

pie chart divided into thirds with words stakeholder requirements definition, requirements analysis, and architecture design

These three processes are recursively applied at each level of the system’s specifications and then iteratively within each level throughout development.

mockup of example system specification with three levels. Pie chart applied to each of the three levels.

The DoD Architecture Framework (DoDAF) provides an approach for DoD architecture development, presentation and integration for both warfighting operations and business operations and processes. For the Net Ready Key Performance Parameter (NR-KPP), the JCIDS manual specifies the data needed to elaborate, communicate, verify and validate a system’s interoperability requirements and design. System architectural descriptions contain three primary viewpoints: Capability, Operational, and Systems. In the case of the NR-KPP, these viewpoints contain essential architecture data that describe a system’s interoperability requirements and design from multiple perspectives. DoDAF provides a standardized approach for capturing and presenting this architectural data. This standardization facilitates improved communication and sharing of technical information among various stakeholders and across organizational boundaries.

Role of the Program Manager and Systems Engineer

The Program Manager (PM) and Systems Engineer are responsible for supporting the Stakeholder Requirements Definition process and should work with the end user to establish and refine operational needs, attributes, performance parameters and constraints documented in JCIDS documents.

Stakeholder Requirements Definition activities are performed throughout the acquisition life cycle and include the following activities:

  • Elicit stakeholder capability objectives
    • Identify stakeholders who have an interest in the system and maintain relationships with the stakeholders and their organizations throughout the system’s entire life cycle.
    • Elicit capability objectives from the stakeholders about what the system will accomplish and how well.
  • Define stakeholder requirements
    • Define the perceived constraints on a system solution.
    • Define the relevant environment (including threat target and critical intelligence parameters per JCIDS Manual Page B-28) and support scenarios that can be used to analyze the operation of the system.
    • Define potential requirements that may not have been formally specified by any of the stakeholders.
  • Analyze and maintain stakeholder requirements
    • Analyze requirements for specificity, completeness, consistency, measurability, testability and feasibility.
    • Negotiate modifications with stakeholders to resolve requirement discrepancies.
    • Validate, record and maintain stakeholder requirements throughout the system life cycle.
    • Support the Requirements Analysis process to establish and maintain a traceability matrix to document how the system requirements are intended to meet the stakeholder objectives and achieve stakeholder agreements.

Requirements Source

The authoritative source for stakeholder requirements are documents produced via the JCIDS such as the Initial Capabilities Document (ICD), Capability Development Document (CDD), and the Capability Production Document (CPD). JCIDS analyzes gaps in existing and/or future warfighting operations and provides a process that allows the Joint Requirements Oversight Council to balance joint equities and make informed decisions on validation and prioritization of capability needs. In preparation for, and presentation at the CDD Validation or Requirements Decision Point, DoDI 5000.02, para 5.d.4 requires the PM to conduct a systems engineering trade-off analysis showing how cost varies as a function of the major design parameters. (Also, see DAG CH 3–4.3.2. Affordability – Systems Engineering Trade-Off Analyses.)


Key Terms

Requirements Creep
Requirements Manager
Requirements Scrub
Stakeholder Requirements Definition

Source: DAU Glossary

Statutes, Regulations, Guidance

Related ACQuipedia Articles

DAU Training Courses

DAU Tools

Products and Tasks

Product Tasks
AWQI 2-1-1: Document of baseline technical requirements
  1. Identify stakeholders who have an interest in the system.
  2. Elicit stakeholder capability objectives.
  3. Define stakeholder requirements.
  4. Given an initial capabilities document (ICD), define potential requirements that are not formally specified (i.e., derived requirements).
  5. Document defined stakeholder requirements and derived technical requirements.
  6. Inform the requirements analysis process to establish, maintain, and capture traceability between system requirements and stakeholder requirements.

Source: AWQI eWorkbook