Software Acquisition

AAF  >  Software Acquisition  >  Define Capability Needs  >  Capability Needs Statement

Capability Needs Statement (CNS)

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: DODI 5000.87 Glossary


Capability Needs Statement: A high-level capture of mission deficiencies, or enhancements to existing operational capabilities, features, interoperability needs, legacy interfaces and other attributes that provides enough information to define various software solutions as they relate to the overall threat environment.


Reference Source: DODI 5000.87 Section 3.2


The planning phase will be guided by a draft CNS developed by the operational community. The sponsor will approve the CNS before the execution phase starts.


  • The program office and related stakeholders will actively engage users throughout the software lifecycle to understand their mission deficiencies, required enhancements to existing operational capabilities, cybersecurity requirements, features, interoperability needs, legacy interfaces, intelligence needs, threat intelligence, and other desired attributes.
  • All required capabilities in the CNS should be prioritized to effectively guide the software development.
  • Periodic review of the CNS should occur at least as often as each value assessment to determine if updates are warranted.

The sponsor will oversee development of a draft CNS to support the initiation of a software acquisition and use of this pathway. The CNS should be clear and concise. Programs using the embedded path will align the CNS with the requirements documents of the system(s) the software will be embedded.


Each DoD Component will create streamlined requirements processes to develop, coordinate, and approve the CNS commensurate with the size, scope, risks, threats, and urgency of need. The Joint Staff will determine if joint equities are involved and will execute an expedited joint validation process if necessary. Insights gained during the planning phase will be incorporated into the CNS before approval. The PM will actively engage with the sponsor during the CNS development to ensure operational and technical feasibility. The sponsor will approve the CNS before entry into the execution phase. Approval of the CNS should be delegated to the lowest level practical based on the size, risk, complexity, and interdependency
of the software needs.


Current acquisition programs with approved JCIDS documents that transition to the software acquisition pathway may continue to use them as the basis of requirements or develop a CNS to capture current, software-unique needs. The sponsor will periodically update the CNS throughout development as required to reflect the current high-level operational needs for the software solution. The sponsor will submit the approved CNS document into the DoD Knowledge Management and Decision Support system for awareness and archival.

CNS Guidance

Reference Source: USD(A&S) Guidance

A CNS should be high-level while providing enough information to define the software solution, considering the threat environment. The CNS is designed to capture high-level needs, similar to an Initial Capabilities Document (ICD) from JICDS, while providing greater speed and flexibility than the Information Systems ICD (IS-ICD) as part of the JCIDS IT Box model. As noted in the software policy and FY20 NDAA Section 800, “programs using the software pathway are not subject to JCIDS, but must be prudent in capturing users’ needs, priorities, and environment.”

A Sponsor drafts a CNS to justify initiating a software acquisition. DoD Components define the level of coordination and approval of a Draft CNS. During the Planning Phase the CNS is finalized and approved via streamlined Component processes. Per the policy, it is critical that DoD Components design streamlined processes based on the unique aspects of modern software development (speed, flexible scope, smaller/frequent deliveries, continuous iteration with users) and not subject software programs to legacy processes designed for large weapon systems (slower, predefined and locked-in scope/requirements, big-bang one-time delivery, and design for long system lifespans). The CNS aligns key themes from JCIDS, TechFAR, and modern software development methods.

Key Contents of a Capability Needs Statement

  • Related Program(s) or Requirements Document(s)
  • Executive Summary
  • Document Body. The document shall be no more than 10 pages long, including any content modified or augmented by a classified Annex, if used.
  1. Operational Context – Summarize the operational environment – key missions, processes, current capabilities to provide context for the needed capabilities.
  2. Threat Summary – Typically in a classified annex, the current and projected threats to the operational environment and software/systems.
  3. Capability Discussion – Outline the software capabilities needed without overly defining the technical solution. Ideally prioritized at a high level across major functional areas. Include a brief description of how it supports the mission, and any supporting elements. This does not go into user stories and other details reserved for roadmaps and backlogs.
  4. Performance Attributes – High level performance measures to guide development over time. These are not to be confused with Key Performance Parameters for testers to measure performance against. Can be subordinate to each capability area defined above or outlined for the overarching program. The objective is to clearly articulate what is valued by the operational community and continuously improve overall user capabilities.  This will focus the acquisition and development community on how to best “move the needle” and can serve as the basis for sponsor Value Assessments
  5. Interoperability – Outline the requirements for how the needed software must interface with other systems. Describe governance process for interfaces and data for the program to include any enterprise architectures, standards, or pipelines. Outline the major systems, services, and networks the software solution must be interoperable with. Describe how interfaces (internal and external) will be identified and design patterns to be used (API, proxy, etc.). Describe the ways data will be handled in the system and plans to be used internally and if it will be accessible externally by other systems or users. Details of specific interfaces and a comprehensive list of all the interfaces will be identified in separate documents, models, architectures, and/or systems. As the CNS is intended to be a high-level overarching document, address the key known elements, and update periodically as systems and networks are added/change/ retired. DODAF architecture views are NOT required in a CNS.  The program should have a Digital Engineering strategy that should be references here to describe how these design details will be capture and formats used to communicate both internally and externally, such as through MBSE (to include UAF or DODAF views) or other methods.

Guiding Principles of a Capability Needs Statement

  • A short, high-level document based on the size, scope, and complexity of the operational need
  • Focused on operational needs, key features and interfaces, not system specifications
  • Conveys high-level priorities, timelines, and operational constraints
  • Provides the foundation for dynamic management of capabilities (or features) throughout development

in an era of rapidly changing threats and needs, greater uncertainty, and user-driven design, nearer term needs may be conveyed while affording flexibility to deal with the uncertainty beyond a 12-18-month time horizon.  Supporting the CNS will be a program roadmap and backlogs that layout the planned features over time and detailed, prioritized user stories or related statements for the next few releases.  The CNS is expected be updated as conditions warrant – which may be in response to changing threats, mission demands, disruptive technology, etc.  Notionally, the CNS might cover a FYDP horizon, the Product Roadmap a 12-18-month horizon (with greater uncertainty outside 18 months; complexity will potentially drive longer roadmap outlooks), and the backlog with a continuously prioritized set of requirements that support nearer-term releases.

Programs with Existing JCIDS Documents

Acquisition programs with an approved JCIDS document may choose to:

  1. Continue to use that JCIDS document for software requirements
  2. Develop a CNS for the software needs to complement and align with the JCIDS document for hardware/platform requirements
  3. Transition completely to a new CNS to capture the scope for the software acquisition

Leaders from the operational, requirements, and acquisition organizations may consider the following factors to determine the best course of action for each program’s software requirements and whether to continue with legacy JCIDS documentation:

  • Currency of requirements – Does the JCIDS document reflect the current operational needs?
  • Applicability – Does the JCIDS document effectively capture the software needs at a high-level?
  • Completion – Has the program delivered capabilities to meet a small or large % of the defined requirements?
  • Flexibility – Does the JCIDS document provide sufficient flexibility to the scope, priorities, and requirements details to reflect the user’s environment and respond to operational and technical changes?
  • Is the software a standalone application or embedded in a weapon system?
  • How dependent is the software with other software or platforms to deliver capabilities?
  • Is there a logical breakpoint in development to transition? This could be based on major groupings of capabilities, user groups, retirement of legacy systems, or software upgrades post IOC/FOC of a weapon system.
  • Testing – Does the JCIDS document have KPPs that the test community expect to meet before delivering software?
  • How streamlined and effective are the DoD Components software requirements processes?

Acquisition programs, fearing an extensive coordination process of a new CNS, may decide to stay with an old JCIDS document to “check-the-box”, yet should weigh the benefits of increased flexibility via a CNS. Key program stakeholders should still have a voice in shaping lower level needs via the product roadmap and program backlogs.

There are no specific time-based requirements based on the requirements processes although the one-year clock for delivering capabilities is based on first funds obligated.  Unlike the Middle Tier of Acquisition pathway which has a 6-month statutory timeline to staff requirements, there is no related timeline for requirements in the software pathway. The statutory intent of the one-year timeline to deliver into operations, was to ensure that software pathway programs were generating momentum and delivering capability on a regular basis.  The desire of course is to deliver much more often than once a year.  Given the strategic intent of the Department to move fast, we envision programs spending 60 – 180 days in planning depending on context and acquisition complexity, with an expectation for shorter durations.

Gen Hyten, VCJCS has stressed: “I have to do everything I can to insert speed into the processes inside the Pentagon. The process that we have for building software is horrible. The JROC requirements process has to be changed to allow rapid software development.”

If an existing program has a JCIDS document, here are some scenarios to illustrate notional transitioning to a CNS:

  • An existing software-centric program has an approved JCIDS document (including IS-ICD or IS-CDD) and with many years ahead for development. The Sponsor can develop a CNS to capture the scope of software needs going forward providing the acquisition team greater flexibility to meet current priority needs.
  • Existing programs still in development, with validated JCIDS requirements for software embedded in platforms or weapon systems, should generate the CNS to identify and capture specific software requirements. The CNS will serve as the governing document for the software portion of the system. The CNS must identify software capabilities tied to system-wide Key Performance Parameters (KPPs) because those capabilities will be assessed in concert with the rest of the system during test and evaluation.
  • If a program for an existing fielded system identifies a new capability requirement (e.g., integration of a new interface with another system or new subsystem, a new application or set of applications to be added to an existing platform, new modules or services that implement new algorithms or perform new services, etc.), the CNS must capture the new required capability and guide development.
  • If an existing fielded system with validated JCIDS requirements is being modernized with significant software development, the sponsor should generate a CNS to guide the modernization effort.
  • If a program for an existing fielded system identifies a better way to achieve the objectives of the materiel solution that has been fielded (to improve performance, efficiency, interoperability, etc.), then it can develop a CNS to guide the development of the modification/upgrade.