Software Acquisition

AAF  >  Software Acquisition  >  Glossary


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


Term Definition
AAF A series of acquisition pathways to enable the workforce to tailor strategies to deliver better solutions faster. The AAF acquisition pathways provide opportunities for milestone decision authorities, DAs, and PMs to develop acquisition strategies and employ acquisition processes that match the characteristics of the capability being acquired.
backlog Program backlogs that identify detailed user needs in prioritized lists. The backlogs allow for dynamic reallocation of scope and priority of current and planned software releases. Issues, errors, and defects identified during development and operations should be captured in the program’s backlogs to address in future iterations and releases.
capability Higher level solutions typically spanning multiple releases. Capabilities consist of multiple features to facilitate implementation.
cATO The core concept of cATO is to build software security into the software development methodology so that the authority to operate process (as with the testing process) is done alongside development. If done correctly, an authority to operate is nearly guaranteed once the software is release ready.
CNS 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.
DA The official responsible for oversight and key decisions of programs that use the software acquisition pathway in accordance with this issuance and related component policies. The official designates a PM and supports them in tailoring and streamlining processes, reviews, and decisions to enable speed of capability delivery. The official may be the Defense Acquisition Executive, Component Acquisition Executive, or the Program Executive Officer, or other designated official by the CAE.
DBS Defined in Section 2222 of Title 10, United States Code.
DevSecOps An organizational software engineering culture and practice that aims at unifying software development, security, and operations. The main characteristic of DevSecOps is to automate, monitor, and apply security at all phases of the software lifecycle: plan, develop, build, test, release, deliver, deploy, operate, and monitor. In DevSecOps, testing and security are shifted left through automated unit, functional, integration, and security testing – this is a key DevSecOps differentiator since security and functional capabilities are tested and built simultaneously.
embedded software Software with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints, or software applications embedded in a platform (e.g., air vehicle, ground vehicle, or ship). In the context of this issuance, embedded software does not apply to firmware or software dedicated to controlling devices.
end user Those who will ultimately use the software solution. Users convey operational concepts, requirements, and needs, participate in continuous testing activities, and provide feedback on developed capabilities.
enterprise services Services that have the proper scope to play a productive role in automating business processes in enterprise computing, networking, and data services. Enterprise services include technical services such as cloud infrastructure, software development pipeline platforms, common containers, virtual machines, monitoring tools, and test automation tools. Responsibility for these functions is generally above the program manager.
features A service or distinguishing characteristic of a software item (e.g., performance, portability, or functionality) that fulfills a stakeholder need and includes benefit and acceptance criteria within one release. Features are used to complete capabilities and are comprised of multiple stories (or tasks, use cases, etc.).
government developmental testing Testing intended to verify and demonstrate how well the system under development meets its technical compliance requirements, to provide data to assess developmental risk for decision making, and to ensure that the technical and support problems identified in previous testing have been corrected.
interoperability The ability of systems, units or forces to provide data, information, materiel, and services to, and accept the same from, other systems, units, or forces and to use the data, information, materiel and services so exchanged to enable them to operate effectively together. Interoperability includes information exchanges, systems, processes, procedures, organizations, and missions over the life cycle and must be balanced with cybersecurity
modern software development practices Practices (e.g., lean, agile, DevSecOps) that focus on rapid, iterative development and delivery of software with active user engagements. Small cross-functional software development teams integrate planning, design, development, testing, security, delivery, and operations with continuous improvement to maximize automation and user value.
MVCR The initial set of features suitable to be fielded to an operational environment that provides value to the warfighter or end user in a rapid timeline. The MVCR delivers initial warfighting capabilities to enhance some mission outcomes. The MVCR is analogous to a minimum marketable product in commercial industry.
MVP An early version of the software to deliver or field basic capabilities to users to evaluate and provide feedback on. Insights from MVPs help shape scope, requirements, and design.
operational acceptance When one or more military units decides to use the software in military operations as informed by test and evaluation
product owner A role on the program or development team that works closely with the user community to ensure that the requirements reflect the needs and priorities of the user community, and align to the mission objectives.
product roadmap A high-level visual summary that maps out the vision and direction of product offerings over time. It describes the goals and features of each software iteration and increment.
release A grouping of capabilities or features that can be used for demonstration or evaluation. A release may be internal for integration, testing, or demonstration; or external to system test or as user delivery. A release may be based on a time block or on product maturity.
software-intensive A system in which software represents the largest segment in one or more of the following criteria: system development cost, system development risk, system functionality, or development time.
sponsor The individual that holds the authority and advocates for needed end user capabilities and associated resource commitments.
task Individual activities to be completed to satisfy a user story or use case (e.g., implement code for a specific feature or complete design for a specific feature).
technical debt Consists of design or implementation constructs that are expedient in the short term but that set up a technical context that can make a future change costlier or impossible. Technical debt may result from having code issues related to architecture, structure, duplication, test coverage, comments and documentation, potential bugs, complexity, coding practices, and style which may accrue at the level of overall system design or system architecture, even in systems with great code quality.
UA A commitment between the sponsor and PM for continuous user involvement and assigned decision making authority in the development and delivery of software capability releases.
user acceptance Verification by operational users that software is capable of satisfying their stated needs in an operationally representative environment.
use case In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a user and a system (or between software elements), to achieve a goal. Use cases can be used in addition to or in lieu of user stories.
user story A small desired behavior of the system based on a user scenario that can be implemented and demonstrated in one iteration. A story is comprised of one or more tasks. In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are written from the perspective of an end user or user of a system.
value assessment An outcome-based assessment of mission improvements and efficiencies realized from the delivered software capabilities, and a determination of whether the outcomes have been worth the investment. The sponsor and user community perform value assessments at least annually, to inform DA and PM decisions.