Defense Business Systems (DBS) Model
DBS Pathway (BCAC)
Capability Need ID Phase
Solution Analysis ATP
Solution Analysis Phase
Functional Requirements ATP
Functional Req and Acq Planning Phase
Acquisition, Testing, and Deployment Phase
Capability Support ATP
Capability Support Phase
Capability Needs Identification Phase
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.75, Section 4.2.a
The functional sponsor leads this phase with guidance and support from the appropriate CMO decision authority. The objective is to establish a clear understanding of needed business capabilities so that the functional sponsor and acquisition officials can decide to invest time and resources into investigating business solutions.
- The capability need is based on the desired end state in a business mission area, the problem(s) preventing it, and the future capabilities required to achieve it.
- Definition of the future capabilities will include analysis of other organizations with similar capability needs.
Reference Source: Based on DAG CH 6-188.8.131.52 content, Jan 2020
Generation of capability requirements, which may occur in the form of a Capability Requirements Document (CRD) but may take on other formats depending on how each Service / Component has chosen to implement the DoDI 5000.75. These artifacts will replace the Problem Statement for business systems. The intent is that the documented requirements will be the outcome of a thorough analytical process during which the business need and end state are identified and business processes and performance measures are clearly defined; this process will also include analysis of other organizations with similar capability needs. The business need is based on the desired end state, the problem(s) preventing it, and the future capabilities required to achieve it. These types of initial requirements documents are not intended to be IT solutions documents.
DBS generally do not use the JCIDS process for defining requirements unless the requirement is deemed joint interest. At that point, the Joint Staff will provide guidance for any additional processes or documentation needed.
Business systems practitioners can visit the Business Community of Practice (DoD CAC Required) – Requirements Community for example requirements documents and capability requirements-related discussion.
Developing Relevant Outcomes
Reference Source: Based on DAG CH 6-3.5.4 content, Jan 2020
Successful capability delivery in IT programs relies upon the ability to track progress toward completion. Generally, Performance Measures/Attributes are used to determine the degree to which a DOTMLPF-P capability has been successfully implemented. Measures and Attributes are tied to each Capability in order to answer the question: how will we know if this Capability has been fulfilled? The Performance Measures are defined at a mission or business level and can be broken down into process or system metrics later in the transformation effort. Outcomes define “what good looks like” to indicate when success has been achieved at varying levels (strategic, business, program, KPPs, KSAs, etc.) – and, to indicate when failure may be on the horizon.
Performance measures identify the performance-based metrics that provide visibility to the outcomes progress towards completion. IT programs should initiate a top-down decomposition process of outcomes and performance measures development, where high-level outcomes are developed early on and then decomposed further into business and program outcomes as more detail is learned throughout.
Any outcome should explicitly state the business value of the resources to be invested and to allow leadership to prioritize and weigh investments. The outcome provides strategic alignment and clear criterion against which to evaluate potential approaches. It always starts with the desired result and is used to focus behaviors and results by answering the “what’s in it for me?” question. Corresponding measures must be specific, actionable, measureable, relevant, and timely operational capabilities that can be achieved against their corresponding outcomes.
It is important to note that the Functional Sponsor (who represents the needs of the user[s] that originally identified the problem, need, or requirement) is ultimately responsible for declaring whether the needed capability has been delivered.
Integrated teams should develop measures and metrics – while the exercise may be led by a Functional Sponsor or representative, it requires involvement from the Program Manager or key representatives from the program office, as well as SMEs from the test and engineering communities to ensure that measures are realistic, relevant, and testable from the beginning.