Major Capability Acquisition (MCA)

AAF  >  MCA  >  Requirements


How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.



Reference Source: CJCSI 5123.01H

JCIDS provides the baseline for documentation, review, and validation of capability requirements across the Department. Validated capability requirements documents facilitate DOTmLPF-P changes, guide the DAS, and inform PPBE processes.


Typical sources for entry into JCIDS for identifying requirements.

  1. Combatant Command (CCMD) in current operations. Most capabilities should be provided via a request for forces via GFM or from the assigned component commands. In cases where there are urgent requirements for capabilities which do not exist in the joint force, the CCMD may generate a JUON or, via a component command, a DoD component UON for review and validation. Urgent capability acquisition and procurement activities may follow if there are applicable solutions to the urgent capability requirements.
  2. CCMD in planning for future operations. Most capabilities should be provided via a request for forces via GFM or from the assigned component commands. In cases where there are anticipated emergent requirements for capabilities which do not exist in the joint force, the CCMD may generate a JEON or, via a component command, a DoD component UON for review and validation. Urgent capability acquisition and procurement activities may follow if there are applicable solutions to the emergent capability requirements.
  3. DoD Services and CCMDs conducting long term planning. Completing a CBA and generating an ICD is the normal starting point for long term planning. Following validation of the ICD, an AoA, or like study, will be
    completed and consideration of materiel and non-materiel solutions may lead to acquisition and procurement activities on a timeline appropriate to the materiel need. However, a validated JUON, JEON, or DoD component UON may substitute for an ICD and the Course of Action analysis conducted by the component solution sponsors can meet the requirements for an AoA.
  4. Science and Technology (S&T) and Innovative Approaches. Once proven at the appropriate technology level an S&T effort, prototype, and/or other innovative approach must align with existing capability requirements or
    be supported by an analysis that makes a defendable case for a new capability. In both cases, the technology developer is best served by partnering with one or more warfighter communities who are likely beneficiaries of the new technology, both to ensure robust warfighter inputs to the CBA and to have sponsorship for the follow-on capability requirements documents if the value case is positive.

DoD Process Interactions

Reference Source: CJCSI 5123.01H

The capability requirements portfolios managed under JCIDS inform and are informed by other processes and activities across the department as shown in Figure 3.


Figure 3. Process Interactions

Figure 3. Process Interactions


Of the interacting processes and activities, requirements (JCIDS),acquisition (DAS), and resources (PPBE) are the most tightly interactive and must work in concert to ensure consistent decision making while delivering timely and cost-effective capability solutions to the Warfighter. JCIDS is documented in this instruction and in reference y; DAS is documented in references hhh and iii; and PPBE is documented in references jjj and kkk. Together, the three processes provide a means to determine, validate, and prioritize capability requirements and associated capability gaps and risks, and then fund, develop, field, and sustain capability solutions for the Warfighter in a timely manner. In order to support robust decision-making and reduce the likelihood of conflicting recommendations, these three processes must also have consistent alignment with the other related processes shown in Figure 3.

JCIDS Interaction with DAS

Reference Source: CJCSI 5123.01H

USD(A&S) manages DAS as the primary process for transforming validated capability requirements into capability solutions.


Capability requirements documents provide the critical link between validated capability requirements and the acquisition of capability solutions through the five major DAS phases shown in Figure 4: Materiel
Solution Analysis (MSA), Technology Maturation and Risk Reduction (TMRR), Engineering and Manufacturing Development (EMD), Production and Deployment (P&D), and Operations and Support. Close collaboration between requirements and acquisition communities is a key aspect of ensuring that knowledge gained early in the acquisition process is leveraged to enable the setting of achievable risk informed capability requirements, and the making of effective cost, performance, schedule, and quantity trade-offs.

  • In most cases, validated ICDs drive the early part of the acquisition process, which then informs updates to capability requirements documents related to materiel and non-materiel capability solutions to be pursued.
  • The subsequent validated capability requirements documents then drive the development, procurement, and fielding of materiel and nonmateriel solutions that satisfy the validated capability requirements and close or mitigate associated capability gaps.
Figure 4. JCIDS and DAS Interactions (Deliberate Process)

Figure 4. JCIDS and DAS Interactions (Deliberate Process)

Capability Requirements

Reference Source: DAG CH 1-3.2.1 Capability Requirements

JCIDS plays a key role in identifying the capabilities needed by warfighters to support the National Security Strategy (NSS), the National Defense Strategy (NDS), and the National Military Strategy (NMS). Successful delivery of those capabilities relies on the JCIDS working in concert with the resourcing and acquisition decision support systems. JCIDS supports the Chairman and JROC in advising the Secretary of Defense (SECDEF) on identifying, assessing, and prioritizing joint military capability needs. JCIDS is a Joint Concepts-centric capabilities identification and requirements development process that enables joint forces to meet short-, mid-, and long-term future military challenges. The JCIDS process assesses existing and proposed capabilities in light of their contribution to future joint concepts and warfighting needs. The DoD created the JCIDS to support the statutory JROC responsibility of validating joint warfighting requirements.

The primary objective of the JCIDS process is to ensure the capabilities needed by joint warfighters to successfully execute their missions are consistent with their associated operational performance attributes. This is accomplished through an open process that provides the JROC with the information needed to make decisions on needed capabilities. The requirements development process then provides validated capability needs and associated performance attributes used by the materiel provider as the basis for acquiring the appropriate weapon systems. Additionally, the PPBE process informs the JCIDS with affordability information and goals through the Capabilities-Based Assessment (CBA), which identifies needed capabilities, capability gaps, and potential non-materiel (DOTmLPF-P) and materiel solution options.

JCIDS is reciprocal to the DoDD 5000.01 direction for early and continuous collaboration throughout the DoD. The system uses a capabilities-based approach that leverages the expertise of government agencies, industry, and academia by encouraging collaboration between operators and materiel providers early in the process. It is imperative that the Combat Developer and the Materiel Developer collaborate throughout the JCIDS process to ensure development of a requirement document that is stable, technologically feasible, and affordable. JCIDS defines interoperable, joint capabilities that should best meet future needs. The DoD acquisition community then delivers a technologically sound, sustainable, affordable “materiel solution” of militarily useful capability to the Joint warfighters.

The role of the JROC in requirements is described in CJCSI 5123.01. The JCIDS Manual (note: requires CAC access) provides the details necessary for identifying, describing, and justifying joint warfighting capabilities. The manual also includes the formats that describe the content required for each JCIDS document.

For Major Defense Acquisition Programs (MDAPs) subject to OSD oversight, the products of the JCIDS process directly support the Defense Acquisition Board (DAB) in advising the Milestone Decision Authority (MDA) for Acquisition Category (ACAT) ID programs. While the JCIDS process does not apply to all six acquisition pathways, the JROC seeks insight into all to ensure operation in the joint fight and support capability development, regardless of the MDA or DA.

Figure 3: JCIDS and Defense Acquisition

Figure 3: JCIDS and Defense Acquisition

Figure 3 depicts the following key points:

  • JCIDS uses a variety of approaches to determine capability requirements. The JCIDS Manual identifies some of these approaches, to include the conduct of a Capabilities-Based Assessment or other study. The key JCIDS intent is to identify the high-level operational capability requirements, establish quantifiable attributes and metrics, and articulate the traceability from those capability requirements to the tasks, conditions, standards, missions, threats, and overall strategic guidance.

  • JCIDS analysis compares capability requirements to current and programmed force capabilities to determine if there are any capability gaps that present an unacceptable level of risk and warrant development of capability solutions to mitigate or eliminate the gaps in capability. The DoD may then address these gaps using a combination of materiel and/or non-materiel solutions (non-materiel solutions would be changes to DOTmLPF-P).

  • The Initial Capabilities Document (ICD) documents the results JCIDS analysis (commonly a CBA or other study) that the appropriate authority validates prior to the Materiel Development Decision (MDD). The operational attributes identified in the ICD are mission, not system specific, and also inform the Analysis of Alternatives (AoA) conducted during the MSA phase. Refer to DoDI 5000.84 for more information on AoAs.

  • The results of the AoA then inform the development of a draft Capabilities Development Document (CDD) to support Milestone A and inform the RFP for the TMRR phase contract. This draft CDD contains performance attributes, to include KPPs, KSAs and APAs that reflect the capability requirements for the solution selected at Milestone A. Toward the end of the TMRR phase, the prototyping and other activities (to include an AoA update, when appropriate) provide information to update the draft CDD that ultimately results in a validated CDD prior to the Development RFP Release Decision. This validated CDD in-turn informs the RFP for the EMD phase. Also, the KPPs from this validated CDD are inserted verbatim into the APB approved by the MDA at Milestone B.

  • The validated CDD then drives EMD phase activities. After the system-level critical design review (CDR), this CDD is updated, which is then validated prior to Milestone C. For an incremental acquisition program, the CDD may contain performance attributes for more than one increment. CDD’s may also contain annexes for variants of a base system, where the base CDD includes the common requirements and the variations of the Family of Systems (FoS) are contained in the annexes.

Fundamental to a successful program acquisition is the ability of the Requirements Manager (RM) to identify and clearly communicate warfighter capability needs and gaps and to team with the Materiel Developer on defining what is expected, both in terms of explicit and implicit requirements. Of significance when planning a program is realism in terms of understanding not only KPPs, KSAs, and APAs, but also those requirements resulting from sound engineering and manufacturing practice, with the ultimate goal of maturing and producing a design in the necessary quantities needed by the warfighter. This teaming arrangement also requires understanding further infrastructure requirements to utilize and sustain the new capability. Failure to recognize those latter imperatives leads to rework and cost/schedule growth.

Further information on CBA, as well as the nature and role of the Initial Capabilities Document (ICD) and the Capability Development Document (CDD) can be found in the JCIDS Manual.

Joint Requirements Oversight Council

10 USC 181 (para (b)), establishes JROC responsibilities. The Vice Chairman of the Joint Chiefs of Staff chairs the JROC and is also a member of the DAB. The Vice Chiefs of each military service are statutory members of the JROC. Also, unless directed by the JROC Chairman, the various Combatant Commanders (or Deputy Commanders) are highly encouraged to participate as appropriate when matters of that command will be under consideration by the JROC. For ACAT I programs, and other programs designated as high-interest, the Joint Requirements Oversight Council (JROC) reviews and validates all JCIDS documents under its purview. For Acquisition Category ID programs, the JROC also makes recommendations to the DAB, based on such reviews. For ACAT IB or IC level programs and all other ACAT II and III programs the Service’s respective Army Requirements Oversight Council (AROC), Marine Corps Requirements Oversight Council (MROC), and Air Force Capability Development Council (AFCDC) address the capability gaps and validate the requirements documents. Other validation boards include US Special Operations Command Requirements Evaluation Board (SOCREB) and US Cyber Command Requirements Evaluation Board (CREB).

10 USC 181 (para (d)), mandates key stakeholder advisors from across the Department and inter-DoD Agencies, when appropriate, to shape decisions in support of the Joint warfighter. This same Act specifically designated the following officials of the DoD as civilian advisors to the JROC:

Other civilian officials of the DoD may be designated by the SECDEF in accordance with the statute.

Requirements Management Process

Reference Source: DAG CH 3-4.1.4 Requirements Management Process

The Requirements Management process maintains a current and approved set of requirements over the entire acquisition life cycle. This helps ensure delivery of a capability that meets the intended mission performance, as stipulated by the operational user.

The end-user needs are usually identified in operational terms at the system level during implementation of the Stakeholder Requirements Definition and Requirements Analysis processes (see CH 3–4.2.1. Stakeholder Requirements Definition Process and CH 3-4.2.2. Requirements Analysis Process, respectively). Through the Requirements Management process, the Systems Engineer tracks requirement changes and maintains traceability of end-user needs to the system performance specification and, ultimately, the delivered capability. As the system design evolves to lower levels of detail, the Systems Engineer traces the high-level requirements down to the system elements through the lowest level of the design.

Requirements Management provides bottom-up traceability from any derived lower-level requirement up to the applicable source (system-level requirement) from which it originates. This bi-directional traceability is the key to effective management of system requirements. It enables the development of an analytical understanding of any system-wide effects of changes to requirements for a given system element, updating requirements documentation with rationale and impacts for approved changes. At the same time, bi-directional traceability ensures that approved changes do not create any “orphaned” lower-level requirements (i.e., that all bottom-up relationships to applicable system-level requirements remain valid after the change). Bi-directional traceability also ensures that higher-level requirements are properly flowed to lower-level requirements and system element designs so that there are no “childless parent” higher-level requirements (i.e., each high-level requirement is ultimately being addressed by lower-level requirements and system element designs).

Robust Requirements Management, implemented in synchronization with the program’s Configuration Management process (see CH 3–4.1.6. Configuration Management Process), can help the program to avoid or mitigate unintended or unanticipated consequences of changes through rigorous documentation of the system performance specification. Thoughtful analysis and management of requirements can help lay the foundation for system affordability.


Activities and Products

The Program Manager (PM) should keep leadership and all stakeholders informed of cost, schedule and performance impacts associated with requirement changes and requirements growth.

The Systems Engineer establishes and maintains a Requirements Traceability Matrix (RTM), which captures all the requirements in the system performance specification, their decomposition/derivation and allocation history and rationale for all entries and changes. The requirements should be:


  • Traceable to and from the stated end-user needs.
  • Correctly allocated, with potential effects of proposed changes fully investigated, understood and communicated to the PM.
  • Feasibly allocated,i.e., lower-level system elements cannot have the same or wider tolerance bands as those of the higher-level system elements into which they are incorporated.


All affected stakeholders and decision makers should fully understand the effects of proposed changes to requirements at the system or system element level before they accept any changes for incorporation into the design. The RTM provides significant benefits during trade-off analysis activities, since it captures the system-wide effects of proposed changes to established requirements.

Component Acquisition Executives (CAE) establish Configuration Steering Boards (CSB), following Capability Development Document (CDD) validation, for Acquisition Category (ACAT) I programs in development, production and sustainment. The CSB reviews all requirements changes and any significant technical configuration changes that have the potential to result in cost and schedule impacts to the program. In a continuous effort to reduce Total Ownership Cost (TOC), the PM, in consultation with the Program Executive Officer (PEO) and requirements sponsor, will identify and propose to the CSB recommended requirements changes, to include de-scoping options, that reduce the program cost and/or moderate requirements needed to respond to any threat developments. These recommended changes will be presented to the CSB with supporting rationale addressing operational implications.

CH 3–2.4. Tools, Techniques and Lessons Learned contains information about SE tools generally employed in the Requirements Management process. There are many commercial software packages specifically designed for the traceability aspect of Requirements Management, from top-level operational requirements down to the lowest-level system elements in the Work Breakdown Structure.

Stakeholder Requirements Definition

Reference Source: DAG CH 3-4.2.1 Stakeholder Requirements Definition Process

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. 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. Defense Business Systems (DBS) do not employ JCIDS procedures for the development and validation of capability requirements documents (See DoDI 5000.75).

The Stakeholder Requirements Definition process complements Requirements Analysis and Architecture Design (see CH 3–4.2.2. Requirements Analysis Process and CH 3–4.2.3. Architecture Design Process, respectively). These three processes are recursively applied at each level of the system’s specifications and then iteratively within each level throughout development.

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.

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.

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, the PM is required to conduct a systems engineering trade-off analysis showing how cost varies as a function of the major design parameters. (Also, see CH 3–4.3.2. Affordability – Systems Engineering Trade-Off Analyses.)

Requirements Analysis

Reference Source: DAG CH 3-4.2.2 Requirements Analysis Process

The Requirements Analysis process results in the decomposition of end-user needs (usually identified in operational terms at the system level during implementation of the Stakeholder Requirements Definition process; see CH 3–4.2.1. Stakeholder Requirements Definition Process) into clear, achievable and verifiable requirements. As the system design evolves, Requirements Analysis activities support allocation and derivation of requirements down to the system elements representing the lowest level of the design. The allocated requirements form the basis of contracting language and the system performance specification. The resultant system requirements are addressed at technical reviews and audits throughout the acquisition life cycle and captured in applicable program and systems engineering (SE) technical documentation.


The Requirements Analysis process objectives include:

  • Linking the needs of the end users to the system, system elements and enabling system elements to be designed and developed.
  • Defining a system that meets end-users’ operational mission requirements within specified cost and schedule constraints.
  • Providing insight into the interactions among various functions to achieve a set of balanced requirements based on user objectives.


The Requirements Analysis process provides:

  • Translation of end-user needs (usually stated in operational terms) to unambiguous, verifiable and feasible system performance specification requirements.
  • Incorporation of design considerations, including statutory and regulatory constraints (see CH 3–4.3. Design Considerations).
  • Allocation of requirements from the system-level specification to the lowest-level system elements and enabling system elements.
  • Rationale for specification requirements and their decomposition/allocation.
  • A mechanism to support trade-off analyses between related requirements to provide maximized mission assurance within cost and schedule constraints.
  • A framework for accurate assessment of system performance throughout the life cycle.


The process of defining, deriving and refining requirements proceeds as follows:

  • Analyze user requirements.
  • Translate end-user needs into basic functions.
  • Develop a quantifiable set of performance requirements by defining the functional boundaries of the system in terms of the behavior and properties to be provided.
  • Define each function that the system is required to perform.
  • Define implementation constraints (stakeholder requirements or solution limitations).
  • Translate performance requirements into specific system technical design requirements and functions.


The Requirements Analysis process is an iterative activity whereby system requirements are identified, refined, analyzed and traded to remove deficiencies and minimize the impacts of potential cost drivers to establish an agreed-to set of requirements coordinated with the appropriate stakeholders. Poorly written requirements can lead to significant problems in the areas of schedule, cost or performance, and can thus increase program risk. A well-crafted set of functional/performance requirements can then be translated into design requirements for the total system over its life cycle and can allow stakeholders to assess system performance during execution of the Verification and Validation processes (see CH 3–4.2.6. Verification Process and CH 3–4.2.7. Validation Process, respectively). Good requirements have the following attributes:

  • Necessary
  • Unique
  • Unambiguous — clear and concise
  • Complete
  • Consistent
  • Technically feasible/achievable/obtainable
  • Traceable
  • Measurable/quantifiable
  • Verifiable (e.g., Testable)
  • Able to be validated
  • Operationally effective
  • Singular


The Requirements Analysis process ensures that requirements derived from user-specified capability needs are analyzed, decomposed, and functionally detailed across the system design. Early development and definition of requirements using the attributes listed above reduces development time, enables achievement of cost and schedule objectives and increases the quality of the final system. Requirements Analysis encompasses the definition and refinement of the system, system elements, enabling system elements and associated functional and performance requirements. The development of the functional baseline is largely a product of the Requirements Analysis process. All requirements are placed under configuration control, tracked and managed as described in the Requirements Management process and Configuration Management process (see CH 3–4.1.4. Requirements Management Process and CH 3–4.1.6. Configuration Management Process, respectively).

Sustainment Considerations

Reference Source: DAG CH 4- Other Metrics and Attributes

The draft CDD ensures the other sustainment-critical metrics enable the mandatory Sustainment KPPs and KSAs.


Reference Source: DAG CH 4- Affordability


If the O&S Cost KSA exceeds the O&S Cost affordability constraint, the program’s early development starts in an O&S Cost deficit. The PM uses this information to identify resource shortfalls and to align resource demand and logistics attributes. See Section for more on O&S affordability.

At the Milestone A decision point, the DoD Component presents an affordability analysis and proposed affordability goals based on resources the resource sponsor projects to be available in the portfolio(s) of the program under consideration. From this analysis, the PM, with the resource sponsor, determines an affordability metric for these goals to be used throughout the program life. The PM tailors the O&S Cost metric to the type of program. Average annual O&S Cost per unit is the most common metric. Information systems programs with no production quantities frequently use average annual total O&S Cost over the first 10 years of fielding. Missile programs often use average annual O&S Cost per year, since most of the support costs on that type of system are not unit specific. The PM also ensures that the metric definition is clear about what it includes (i.e., the metric specifically identifies which CAPE O&S Cost Elements are included and whether or not disposal costs are included).


Reference Source: DAG CH 4- Capability Development Document

Capability Development Document

Required capabilities are refined in the TMRR phase. The sustainment strategy builds on the capability gaps and requirements highlighted in the MSA Phase and documents them as requirements in the validated Capability Development Document (CDD). The PSM partners with the systems engineer to refine the threshold and objective range value for each sustainment metric. Studies, trades, data models, and analyses executed in TMRR identify the technical capabilities, risks, and limitations of the alternative sustainment strategies and design alternatives. These results influence the final values assigned in the CDD, confirming or refining those identified in the draft CDD. Feedback from TMRR phase testing and modeling improves the realism, affordability, and testability of sustainment metrics.

The sustainment metrics identified in the CDD flow into the system specification and subsequent contract RFP. The specific values for Sustainment KPPs and KSAs in the CDD require vetting by Service and Office of the Secretary of Defense testing agencies. The PM should be aware if developmental testing, reliability modeling, or technology improvement efforts show outcomes not supporting requirements from the draft CDD. The approved CDD should reflect results from TMRR events to avoid unachievable or unaffordable capabilities. The CDD is the last opportunity to influence sustainment requirements without significant cost, schedule, or performance impacts later in program development. See CJCSI 3170.01I JCIDS Manual, Encl. D – Pages D-47-62 for additional information on the CDD.