Software Acquisition

AAF  >  Software Acquisition

Software Acquisition


This pathway is to facilitate rapid and iterative delivery of software capability to the user.

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.02 Section 4.2


This pathway is designed for software-intensive systems. The pathway objective is to facilitate rapid and iterative delivery of software capability to the user. This pathway integrates modern software development practice such as Agile Software Development, DevSecOps, and Lean Practices. Capitalizing on active user engagement and leveraging enterprise services, working software is rapidly and iteratively delivered to meet the highest priority user needs. Tightly coupled mission-focused government-industry software teams leverage automated tools for development, integration, testing and certification to iteratively deploy software capabilities to the operational environment.

Lifecycle View of Software Acquisition

Planning Phase Execution Phase User Engagement Design and Architecture Test and Infrastructure Program Management Budgeting and Performance Management

Purpose and Applicability

Reference Source: Software Acquisition Pathway Interim Policy and Procedures, 3 Jan 2020


This interim policy establishes direction, responsibilities, and procedures for the management of the Software Acquisition Pathway pursuant to the authorities outlined in DoD Directive 5134.01 and the July 13, 2018, Deputy Secretary of Defense Memorandum, and Section 800 of the National Defense Authorization Act for FY2020. Further, this interim policy:


  • Simplifies the acquisition model to enable continuous integration and delivery of software capability on timelines relevant to the Warfighter/end user.
  • Establishes the Software Acquisition Pathway as the preferred path for acquisition and development of software-intensive systems.
  • Establishes business decision artifacts to manage risk and enable successful software acquisition and development.

This interim policy will be replaced by issuance of a DoD Instruction within a year of signature of this memo.


This interim policy applies to:


The Office of the Secretary of Defense (OSD), the Military Departments, the Office of the Chairman of the Joint Chiefs of Staff and the Joint Staff, the Combatant Commands, the Office of the Inspector General of the Department of Defense (DoD), the Defense Agencies, the DoD Field Activities, and all other organizational entities within the DoD (referred to collectively in this interim policy as the “DoD Components”).


Acquisition, development, operations, and sustainment of all DoD software-intensive system approved to use this pathway in order to demonstrate the viability and effectiveness of capabilities for operational use not later than one year after the date on which funds are first obligated to acquire or develop new software capability. Software-intensive systems include software-only systems, such as Command & Control (C2) software or applications; weapon system software, such as Intelligence, Surveillance, and Reconnaissance (ISR) software, embedded mission planning software or embedded Situational Awareness software; and any other custom-developed software running on commercial or modified commercial hardware. Software programs that meet the definition of a Defense Business System (DBS) and primarily acquire Commercial-Off-The-Shelf (COTS) components will follow DODI 5000.75 procedures but may elect to use this pathway for custom developed software. 

Overarching Policy Direction

Reference Source: Software Acquisition Pathway Interim Policy and Procedures, 3 Jan 2020


The overarching management principles that govern the Defense Acquisition System (DAS) are described in DoD Directive 5000.01 and DoDI 5000.02. The purpose of the DAS is to deliver effective and affordable solutions to the end user while enabling execution at the speed of relevance. To achieve that objective, the DoD will employ an adaptive acquisition framework composed of acquisition pathways, each tailored for the unique characteristics and risk profile of the capability being acquired. A general listing of statutory requirements associated with each of the pathways is located in the Milestone Document Identification (MDID). This interim policy describes the responsibilities of acquisition officials and the purpose and key characteristics of the software acquisition pathway.


The Component Acquisition Executive (CAE) may elect to use this pathway for acquisition of software-intensive systems or sub-systems. The decision authority shall document the decision in an Acquisition Decision Memorandum, which includes the rationale for using the software pathway, and submit to Office of the Under Secretary of Defense for Acquisition and Sustainment (OUSD (A&S)) to provide notification of use of this pathway.


Programs executing this pathway will not be subject to the Joint Capability Integration and Development System (JCIDS), except pursuant to a modfied process specifically provided for the acquisition of development of software by the Vice Chairman of the Joint Chiefs of Staff, in consultation with the Under Secretary of Defense for Acquisition and Sustainment and each service acquisition executive (as defined in section 101(a)(10) of title 10, United States Code. The Sponsor and Program Manager (PM) shall develop a Capability Needs Statement (CNS) and a User Agreement (UA) prior to acquisition of software capabilities. CNSs identify mission deficiencies, required enhancements to existing operational capabilities, features, interoperability needs, legacy interfaces, and other attributes required for new software-intensive systems or sub-systems or upgrades to existing systems or sub-systems. Each DoD Component will develop a streamlined process that results in iteratively developed requirements documented in the CNS. UAs capture a commitment between the PM office, the sponsor, and end user(s) of the system. The CNS and UA documents are meant to be flexible products, periodically updated to reflect the capabilities baseline, and will be developed and approved via an expedited Component validation process and expedited joint process if the Joint Staff determines that there are joint implications. CAEs will ensure the approved CNS document is available in the Knowledge Management and Decision Support system.


The PM shall develop an Acquisition Strategy that outlines the program’s approach to performing software acquisition in increments consistent with the user’s requirements that results in demonstrating the viability and effectiveness of capabilities for operational use not later than one year after the date on which funds are first obligated to acquire or develop new software capability, and to continuously engineer and deliver capability updates at least annually. The Acquisition Strategy shall include a lifecycle sustainment strategy that promotes continuous engineering and delivery throughout the software lifecycle, as well as an Intellectual Property (IP) strategy (see paragraph (m)). The acquisition strategy must also clearly identify test and evaluation requirements that have been fully coordinated with the test community.


PMs shall leverage Enterprise Level Services as a first choice, if available, before creating new services. These may come from portfolio, Component, or DoD-wide services and/or commercial providers. Enterprise Services include technical services (e.g., Platform as a Service (PaaS), common containers/virtual machines, or infrastructure) and business services (e.g., contract vehicles or requirements management).


The PM shall ensure that software teams use iterative and incremental software development methodologies (such as Agile or Lean), and use modern technologies (e.g. DevSecOps pipelines) to achieve automated testing, continuous integration and continuous delivery of user capabilities, frequent user feedback/engagement (at every iteration if possible), security and authorization processes, and continuous runtime monitoring of operational software. Software development teams shall consider the program’s lifecycle objective and use sound software practices to achieve improved software quality (e.g., manage technical debt, actively refactor design and code, and create effective modular open systems approaches to support future capabilities). Embedded systems should tailor software development activities to this pathway to the greatest extent possible.


The PM shall ensure that software teams address persistent cyber security requirements starting at program inception and include a risk-based lifecycle management approach to secure development, secure capabilities, and secure lifecycle to address software vulnerabilities. The PM shall also ensure that automated test processes, tools and/or environments are certified by the test community and the automated test process includes, to the greatest extent practicable, frequent and recurring tests that address cyber and software assurance considerations throughout the software lifecycle. The automated build scripts and test results shall be available to government testers, so they can reuse/recreate any test artifact.


The PM shall ensure that software teams develop and/or leverage a Software Architecture that aligns, supports, and reflects the continuous engineering of capability over the software lifecycle. Interoperability and interfaces with legacy systems are to be addressed early in the software lifecycle. The PM shall ensure that software teams demonstrate that the architecture complies with good design principles including but not limited to modular open systems architecture, and supports frequent iterative capability releases. Periodic evaluation of the architecture should include refactoring and adopting newly available technologies when appropriate to continuously “pay down” technical debt.


The PM and the sponsor shall define and develop a Minimum Viable Product (MVP) and if appropriate, a develop a Minimum Viable Capability Release (MVCR) to deliver software products that will meet an initial set of Warfighter/end-user needs, and a Product Roadmap to guide the delivery of remaining capabilities. The MVP is an early version of the software that has just enough working features to meet basic minimum functional capabilities. The goal of an MVP is to quickly deliver basic capabilities into users’ hands for evaluation, feedback, and improvements. The MVCR is a set of features suitable to be delivered to an operational environment that provides value and capability to the Warfighter/end user on a reduced delivery timeline. The goal of the MVCR is to deliver initial warfighting capabilities that can be fielded to enhance some mission outcome(s). Subsequent capability deliveries must occur at least annually.


The PM, in collaboration with developmental and operational test organizations, shall plan, streamline, automate and integrate contractor test, Developmental Test and Evaluation (DT&E), and Operational Test (OT). The test and user communities shall participate in early program development and test planning activities. The software build and automated test process and associated data should be leveraged to enable timely satisfaction of DT and OT test criteria and user acceptance.


The PM shall identify, collect, and use management, cost, schedule, and performance metrics to enable effective program execution by the PM and other stakeholders. Metrics collection should leverage automated tools to the maximum extent practicable. The minimum set of metrics used to manage the program should include process efficiency, software quality, software development progress, cost, and capability delivery (i.e. value). Programs using this pathway shall report a minimal set of data to OUSD (A&S) on a quarterly basis as defined in the Software Acquisition Pathway Guidance located at


The Sponsor and PM shall conduct value assessments at least annually that will provide a determination of whether the operational value of the software from the end user perspective, and informed by testing, is commensurate with the resources invested. Value assessments inform future resource investment decisions.


The PM shall develop and maintain an Intellectual Property (IP) strategy in accordance with DoDI 5010.44 that is tailored to the unique circumstances of the program to achieve its supportability and cyber security requirements. The PM should be aware of and understand the rights and obligations of both the Government and industry, as well as the system architecture and life-cycle requirements, in order to negotiate for computer software deliverables and license rights. In the case of open source software and software developed in whole or in part at Government expense, the IP strategy should include, to the maximum extent practicable, negotiation for and periodic delivery of executable and source code and all associated scripts, tools, databases, libraries, other software executables, and anything else necessary to compile, test, debug, deploy, and successfully operate the software. The PM will ensure any restrictive markings on software and software documentation deliverables are consistent with the Government’s license rights prior to acceptance by the Government. The PM shall approve the use of any commercial or proprietary software prior to its insertion into the software developed for the government, and the PM will protect all IP associated with commercial or proprietary software. The PM, to the maximum extent practicable, shall require that any commercial or proprietary software used in or interoperable with software developed for the Government has documented open interfaces to allow for technology insertion, and to support the use of modular open systems approaches, as applicable.


The PM shall ensure technical manuals are developed/verified incrementally and synchronized with software deliveries throughout the software development lifecycle; and shall also ensure that receiving users and military units are trained to the appropriate level of proficiency and readiness to successfully execute the individual and collective tasks necessary to accomplish the mission supported by the software. The PM shall ensure delivery of technical operator and maintainer manuals required to operate and maintain the system.


The decision authority should formally tailor in applicable processes and documentation consistent with modern software development principles to fit the size, scope, and complexity of the development activity to achieve cost, schedule, performance, and delivery objectives.


It is the implementing components’ responsibility to ensure that the program is conducted in accordance with all applicable laws and regulations. For example, procedures for compliance with statutory requirements applicable to DoD programs that acquire information technology (including acquisition of software), such as the Clinger Cohen Act, are established in DoDI 5000.02 Change 5, and in the Acquisition of Information Technology DoDI upon cancellation of DoDI 5000.02 Change 5. A general listing of statutory requirements associated with each of the pathways is located in the Milestone Document Identification (MDID).


All safety critical software standards and guidance apply when using this pathway policy.


Reference Source: Software Acquisition Pathway Interim Policy and Procedures, 3 Jan 2020




  1. Establish policy and provide guidance for the Software Acquisition Pathway.
  2. Serve as the Approval Authority for programs that request to use the Software Acquisition Pathway or delegate authority to a Component Acquisition Executive.
  3. Act as decision authority for programs in the Software Acquisition Pathway when appropriate, or delegate decision authority to a Component Acquisition Executive.
  4. Determine when a program is not appropriate for the Software Acquisition Pathway and direct that the program be executed using another acquisition pathway.




  1. Establish a streamlined and coordinated requirements, budget, and acquisition process to support rapid fielding of software applications and of software upgrades to embedded systems for operational use.




  1. Serve as the Approval Authority for programs that request to use the Software Acquisition Pathway or delegate authority to a designated official.
  2. Act as decision authority for programs in the Software Acquisition Pathway when appropriate, or delegate decision authority to a designated official.
  3. Ensure that the procedures in this interim policy are implemented.




  1. Serve as the Decision Authority for programs that adopt the Software Acquisition Pathway and shall implement the procedures in this interim policy.
  2. Designate a PM for each Software Acquisition Pathway program.
  3. Submit sufficient program metrics data to support adequate DoD leadership insight into the operation of the pathway and support development and/or evolution of tools for modeling software acquisition cost and performance.




  1. Develop and submit an acquisition strategy, timing and scope of decision points, metrics, and required documentation to the decision authority.
  2. In conjunction with the user community representative, develop a UA that identifies the appropriate level of user involvement and expectations for a collaborative method of evolving capability delivery timelines.
  3. In conjunction with the user community, the test and evaluation community, and cost estimating community, develop an acquisition strategy and program cost estimate.




  1. In conjunction with the PM, develop a UA that identifies the user involvement strategy, any operational constraints, and expectations for a collaborative method of evolving capability delivery and/or deployment timelines.
  2. Ensure that the UA is executed to provide end-user input on capability needs, prioritization of work, and approve working software.
  3. In conjunction with the PM, develop a CNS and provide advocacy for program resources.