Capability in Systems Engineering: Definitions, Frameworks and Practice

In everyday speech a capability is simply something you are able to do. In systems engineering, and especially in defense planning where the term took on its technical sense, a capability is defined more carefully: it is the ability to execute a specified course of action, or to achieve a desired effect under stated conditions and standards. The key move is that a capability is described by what needs to be achieved, not by the equipment that achieves it. A navy does not, in this vocabulary, need "a new frigate." It needs the ability to protect shipping in a given sea area against a given threat to a given standard. A frigate might be part of the answer. So might aircraft, new training, a change in doctrine, or a partnership with another navy.

That shift in framing, from products to abilities, reshaped how large organizations plan and buy complex systems. It produced formal processes such as the United States Joint Capabilities Integration and Development System (JCIDS), checklists of what goes into a capability such as the U.S. DOTMLPF, the British "Defence Lines of Development" and the Australian "Fundamental Inputs to Capability," and whole viewpoints within architecture frameworks such as DoDAF. It has also spread beyond defense, into rail, healthcare and business architecture.

This article explains what capability means in systems engineering, where the concept came from, how capability-based processes work, the main frameworks, and the criticisms and limits that practitioners have identified.

Defining capability

The formal definitions

Several authoritative definitions are in use. They are close but not identical, and the differences are instructive.

All of these are collected in the SEBoK glossary entry for capability. The short JP 1-02 definition is the one quoted in the Wikipedia article on the topic.

What the definitions have in common

Three ideas run through all of them.

First, a capability is an ability, not an object. It exists only when people, equipment, information and processes come together and actually work.

Second, a capability is described in operational or outcome terms. MODAF's wording is explicit: it is "expressed in non-equipment based operational terms." DoDAF ties it to "a desired effect." SEBoK speaks of "an outcome or effect."

Third, a capability is specified. It comes with conditions (where, against what, in what environment) and standards (how fast, how reliably, to what level). An unspecified ability to "do air defense" is not a capability in this technical sense; an ability to defend a named area against a defined set of threats with a stated probability of success is.

"May or may not be accompanied by an intention"

The JP 1-02 phrase that a capability "may or may not be accompanied by an intention" comes from intelligence and threat assessment. An adversary's capability is what they could do; their intention is what they mean to do. Military planning has long distinguished the two, because intentions can change quickly while capabilities take years to build. The phrase has carried over into the systems engineering definition, reminding analysts that having an ability and choosing to use it are separate questions.

Capability versus related terms

The SEBoK glossary notes that "system capability" is sometimes used to distinguish what a technical system provides from "organizational capability," which is what an enterprise as a whole can do.

Where the concept came from

From threat-based to capabilities-based planning

The SEBoK article on capability engineering states that the term "capability" was used in defense in the early 2000s, though the underlying concepts are older; it cites Peter Checkland's 1997 work in systems thinking for the earlier roots.

The trigger in the United States was a change in how the Department of Defense planned its forces. Through much of the Cold War and after, planning tended to be threat-based: analysts identified specific adversaries and scenarios and sized forces to defeat them. By the late 1990s many critics argued that this approach did not cope well with uncertainty about who future adversaries would be and how they would fight.

The 2001 Quadrennial Defense Review endorsed what it called capabilities-based planning. In a 2002 RAND monograph, "Analytic Architecture for Capabilities-Based Planning, Mission-System Analysis, and Transformation" (MR-1513), Paul K. Davis defined capabilities-based planning as "planning, under uncertainty, to provide capabilities suitable for a wide range of modern-day challenges and circumstances while working within an economic framework that necessitates choice." Davis noted that the 2001 review defined the concept only in broad terms and that opinions differed about its details.

A 2005 National Research Council report, "Naval Analytical Capabilities: Improving Capabilities-Based Planning," adopted Davis's definition, observing that there was no official government definition. It described capabilities-based planning as substantially different from the DoD's recent "threat-based or requirements-based" analysis focused on individual point scenarios, while noting that in some respects it "harkens back to principles espoused in the 1960s." The report emphasized the need to "deal with massive uncertainty" about both scenarios and assumptions.

The creation of JCIDS

The bureaucratic consequence was the Joint Capabilities Integration and Development System. According to the Wikipedia article on JCIDS, a March 2002 memo from the Secretary of Defense, then Donald Rumsfeld, asked the Vice Chairman of the Joint Chiefs of Staff to study alternative ways to evaluate requirements. The resulting system was approved by the Chairman of the Joint Chiefs on 24 June 2003, according to the Association of the United States Army, and was promulgated through CJCSI 3170.01C and CJCSM 3170.01 that month.

The Congressional Research Service states that "in 2003, DOD released guidance creating JCIDS, which updated and replaced its predecessor, the Requirements Generation System." A Naval Postgraduate School paper described the change as one that "literally turned the legacy Service-initiated Requirements Generation System (RGS) upside down," moving from a bottom-up, threat-driven process run by each military service to a top-down, capabilities-driven process with joint oversight.

The problems JCIDS was meant to fix, according to the Wikipedia summary, were that programs were not considered in the context of other programs, combined needs and joint prioritization were weak, and analysis was insufficient. The old service-specific system had produced redundant capabilities and did not meet the combined needs of the services.

What a capability is made of

If a capability is not just equipment, what else is in it? Each major defense establishment has produced a checklist. They differ in wording but share a common message: equipment alone never delivers a capability.

United States: DOTMLPF and DOTMLPF-P

JCIDS uses the acronym DOTMLPF, which stands for Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities. A later variant adds Policy, giving DOTMLPF-P. The acronym defines the solution space for closing a capability gap: a gap can be closed by changing any combination of these, not just by buying a new system. Materiel (with a capital M, meaning a new acquisition program) is only one of the letters. In JCIDS documents, proposals with "nonmateriel DOTMLPF implications" require approval by the Joint Requirements Oversight Council, as CJCSI 3170.01D (March 2004) stated.

United Kingdom: the Defence Lines of Development

The UK Ministry of Defence uses the Defence Lines of Development (DLODs). A 2009 MOD document on MODAF and the DLODs lists eight: Training, Equipment, Personnel, Information, Concepts and Doctrine, Organisation, Infrastructure, and Logistics. The memorable acronym is TEPID OIL, which drops the C from Concepts and Doctrine. Some sources render that line as Policy and Doctrine instead. Interoperability is treated as an overarching theme across all the lines rather than as a ninth line.

The MOD document explains that the DLODs "provide a mechanism for co-ordinating the parallel development of different aspects of capability," and calls the coordination of the lines Capability Integration. A former MOD requirements manager, writing on a systems safety mailing list in 2017, summarized the principle: a capability is only delivered when all of the requirements under each of the lines of development are met.

Australia: the Fundamental Inputs to Capability

Australia's Department of Defence uses the Fundamental Inputs to Capability (FIC). The glossary to the Defence Strategic Review lists nine: organisation, command and management, personnel, collective training, major systems, facilities and training areas, supplies, support, and industry. Industry was formally added as a discrete input in the 2016 Defence Industry Policy Statement, which recognized "Australian industry as a discrete Fundamental Input to Capability." A 2024 paper by an Australian Defence Force officer, David Hood, compared the original and current lists, noting renamings such as "People" to "Personnel" and "Capability Systems" to "Major Systems," and argued that the list should also include society, a proposal that is not official policy.

Comparing the checklists

The mapping is approximate, since the categories do not align one to one. The broad point is that all three treat a capability as a bundle of interdependent inputs that must be planned together.

How capability-based processes work: the JCIDS example

JCIDS is the most documented capability-based process and the one referred to in the Wikipedia article. Although the U.S. began dismantling it in 2025 (see below), its structure shows how capability thinking was turned into procedure, and many of its ideas survive in successor processes and in other countries.

Where JCIDS sat

The Congressional Research Service describes JCIDS as one of three main acquisition-related systems in the DoD, alongside the Planning, Programming, Budgeting and Execution (PPBE) process, which allocates resources, and the Defense Acquisition System, which manages programs. JCIDS identified and validated capability needs; the acquisition system bought solutions; PPBE paid for them. The JCIDS Manual described the process as "assessing joint military capabilities, and identifying, approving, and prioritizing gaps in these capabilities, to meet applicable requirements in the National Defense Strategy."

The Capabilities-Based Assessment

The analytical heart of JCIDS was the Capabilities-Based Assessment (CBA), which identifies capability requirements in a mission area and assesses whether gaps exist. The Wikipedia article describes its phases:

The sequence is the capability idea in procedural form. First define what must be achieved, independent of any solution. Then measure the shortfall. Only then consider solutions, and consider all of DOTMLPF, not just new equipment.

Capability gap analysis and architecture models

A capability gap analysis determines which needed capabilities do not yet exist or fall short of the required standard. The Wikipedia article notes that the DoD Architecture Framework suggests using the Operational Activity Model (OV-5) for capability gap analysis. An OV-5 decomposes the operational activities needed to accomplish a mission. If you can map each activity to the systems, people and processes that perform it, any activity with no adequate performer is a gap. The article cites work by Sidney Antommarchi presented at the Interservice/Industry Training, Simulation and Education Conference in 2008 on a process for modeling and simulation capability gap analysis.

The key documents

JCIDS produced a chain of documents, each tied to an acquisition milestone:

The CRS notes that if the capability solution identified in an ICD is materiel, the process then develops a CDD, which "further defines the military requirements for a materiel capability" and "the specific measures of performance that such a capability would require."

Governance

The Joint Requirements Oversight Council (JROC), chaired by the Vice Chairman of the Joint Chiefs and including the service vice chiefs, managed JCIDS. Its statutory basis is Title 10 of the U.S. Code, section 181, which describes its mission as "identifying, assessing, and approving joint military requirements ... to meet the national military strategy" and "ensuring that appropriate trade-offs are made." The JROC maintained six Functional Capability Boards; the CRS lists them as cyber, battlespace awareness, force application, protection, force development and design, and logistics and sustainment. A "gatekeeper" on the Joint Staff assigned each proposal a designation and routed it to the relevant boards.

Deliberate and urgent tracks

JCIDS had two broad categories of requirement, according to the CRS. Deliberate requirements went through the formal, consensus-based staffing process aligned with major acquisition. Urgent or emergent requirements, defined as those that "if unmitigated would result in unacceptable loss of life or critical mission failure," received expedited review to allow a capability to be fielded within two years.

Revisions over time

JCIDS was revised repeatedly. The Wikipedia article records that the instruction CJCSI 3170.01I was approved on 23 January 2015 with a manual following on 12 February 2015. AcqNotes reports that a later instruction, CJCSI 5123.01I of October 2021, replaced the 3170.01 series as the governing charter. The CRS notes that the JCIDS manual was last publicly updated in 2021.

Congress also intervened. Section 925 of the FY2017 National Defense Authorization Act amended 10 U.S.C. 181 to refocus the JROC on joint programs rather than service-specific ones. Section 811 of the FY2024 act required the DoD to modernize its requirements process, including JCIDS, "to improve alignment between modern warfare concepts, technologies, and system development and reduce the time to deliver needed capabilities to warfighters." Congress received an interim report on 1 October 2024, with a final report due by 1 October 2025.

Criticisms

The CRS primer, published in November 2024, summarized criticisms of JCIDS:

• Speed. "Critics of JCIDS cite the process's long time frame as a hindrance to rapid and flexible capability development." A 2021 Government Accountability Office study found that the Joint Staff could not measure "the actual length of time that documents take to go through the JCIDS process."
• Consensus. Because the deliberate process was consensus-based, advantageous solutions "could be delayed or not developed due to lack of consensus."
• Innovation. JCIDS analysis addressed reported gaps rather than anticipating them, and some critics argued that sponsors' incentives favored predetermined solutions.
• Duplication. Narrowing the JROC's focus to joint programs after 2017 might allow services to duplicate one another's efforts.
• Materiel bias. Congress might ask whether JCIDS "overemphasizes materiel solutions" over non-materiel changes such as doctrine, which would undercut the whole point of capability thinking.

The 2025 disestablishment

On 20 August 2025, Secretary of Defense Pete Hegseth and Deputy Secretary Steve Feinberg signed a memo titled "Reforming the Joint Requirements Process to Accelerate Fielding of Warfighting Capabilities." As reported by Breaking Defense, it directed that JCIDS be disestablished and that the JROC stop validating component-level requirement documents. It created a Requirements and Resourcing Alignment Board, co-chaired by the Vice Chairman of the Joint Chiefs and the Deputy Secretary, to select topics each budget cycle from the top-ranked "key operational problems," issue programming guidance and recommend funding. It also created a Mission Engineering and Integration Activity to engage industry, conduct mission engineering analysis and run experimentation campaigns, to be established within 120 days. Trade press coverage described this as the end of a roughly 22-year system. Breaking Defense quoted former Air Force Secretary Frank Kendall's criticism of the old JROC: "They never met a military service requirement they didn't like."

The change moved the U.S. away from JCIDS's document-heavy validation chain. It did not abandon capability language; the new structures still talk about operational problems and the capabilities needed to solve them. Whether the new arrangement delivers faster results is, at the time of writing, an open question.

Capability in architecture frameworks

Architecture frameworks give engineers standard ways to describe complex enterprises. Capability thinking entered them as a distinct viewpoint.

DoDAF 2.0 Capability Viewpoint

The DoD Architecture Framework version 2.0 introduced a Capability Viewpoint with seven models. The DoD Chief Information Officer's DoDAF 2.02 pages describe them as follows:

The DoDAF 2.02 metamodel page states that its capability definition is consistent with the one in the JCIDS instruction. The models connect the strategic level (what abilities are needed, when) to the operational level (what activities they support) and the service level (what services implement them), giving a traceable chain from strategy to solution.

MODAF and the NATO Architecture Framework

The UK Ministry of Defence Architecture Framework was released as version 1.0 in August 2005, followed by version 1.1 in April 2007, 1.2.003 in April 2008 and 1.2.004 in May 2010, according to the UK government's version history. MODAF defined capability in its own terms (quoted in the definitions table above), and the 2009 MOD analysis document linked its models to the DLODs.

The NATO Architecture Framework built on MODAF; one NATO paper notes that version 3.1 of the NATO metamodel was identical to MODAF metamodel version 1.2.003. The UK government page now states that MODAF "has been replaced with the NATO Architecture Framework (NAF) V4." Vendor documentation describes NAF v4 as adopting commercial metamodels and including a Concepts viewpoint similar to the earlier capability viewpoint.

Capability systems engineering as a discipline

Beyond the defense processes, systems engineers have tried to articulate what is distinctive about engineering capabilities rather than products. The SEBoK article on capability engineering, led by Duncan Kemp, Judith Dahmann and Mike Henshaw, is the main reference.

Core characteristics

SEBoK describes capability as a combination of people, processes, information and equipment. Capability systems engineering applies standard systems engineering tools from the viewpoint of the asset owner-operator, such as a military user or a rail transport provider, rather than from the viewpoint of a supplier building a product. Two characteristics stand out:

• Capabilities deliver outcomes rather than outputs.
• Capabilities are enduring. They are upgraded rather than replaced. A national air defense capability has existed in some form for decades, while its radars, aircraft and missiles have been replaced many times.

The aim of capability systems engineering, according to SEBoK, "is to ensure that the upgraded capability meets stakeholder needs," with good practice providing "a clear line of sight from the purpose of the capability, through the operational concept and whole system design, down to specific requirements and interfaces."

How it differs from product systems engineering

The INCOSE UK Capability Systems Engineering Guide by Kemp and Daw (2014), summarized in SEBoK, identifies several differences from traditional product systems engineering:

Lifecycle

SEBoK describes the capability lifecycle in three parts: a "fuzzy" front end of capability trade-offs, a development phase that follows the conventional V-model product lifecycle, and a "messy" in-service phase of support, adaptation and upgrade. The capability engineer is responsible for the whole of it, not just the middle.

Many worldviews

A 2011 paper by Henshaw and colleagues, presented at the 21st INCOSE International Symposium in Denver, identified at least eight different worldviews of capability and concluded that the task of capability engineering is not consistently defined across communities. Some practitioners treat a capability as a kind of system or system of systems. Others treat it as what a system or system of systems does. SEBoK notes that capability engineering is strongly related to systems-of-systems engineering in either case.

Beyond defense

SEBoK cites applications in rail (a 2012 paper by Dogan and colleagues at the 22nd INCOSE Symposium in Rome) and in healthcare (a 2017 Royal Academy of Engineering report). In both sectors the owner-operator faces similar problems: an enduring service that must be maintained and improved while in use, delivered by a mix of people, infrastructure, rolling stock or equipment, information and procedures.

Capability in private industry and business architecture

The Wikipedia article notes that the term capability is also used in private industry, for example in gap analysis. In business architecture, a capability describes what an organization does, independent of how, by whom or with what systems.

The Open Group's Open Business Architecture standard defines a business capability as "a particular ability or capacity that a business may possess or exchange to achieve a specific purpose." Version 9.2 of the TOGAF standard distinguishes a higher-level Capability, described as a business-focused outcome delivered by completing one or more work packages, from the more granular Business Capability.

Business architects often draw capability maps: hierarchical diagrams of everything a business must be able to do, such as "manage customer relationships," "fulfill orders" or "manage workforce," broken down into finer levels. Because capabilities are more stable than organization charts or software systems, the map provides a fixed reference against which to plan changes. Each capability can be assessed for maturity, cost or strategic importance, and investment can be targeted at weak but important capabilities, which is the private-sector analogue of a capability gap analysis.

The parallels with defense are direct. A business capability, like a military one, is delivered by people, processes, information and technology together. A new software system alone does not create a capability for "managing customer relationships" if staff are not trained, processes are not redesigned and data are not migrated.

A worked example: describing a capability and its gaps

The following example is hypothetical, constructed to show how the concepts fit together. The numbers are illustrative, not drawn from any real program.

Step 1: State the capability in operational terms

A coastal authority wants this capability: "Locate a person in the water within a 50 nautical mile coastal zone and recover them within 2 hours of an alert, in conditions up to a stated sea state, by day or night, with 90 percent success."

Note that this says nothing about helicopters, boats or radar. It states the effect (locate and recover), the conditions (zone, sea state, day and night) and the standards (2 hours, 90 percent).

Step 2: Decompose into tasks (a functional area analysis)

Sum check: 10 + 60 + 30 + 20 = 120 minutes, which equals the 2-hour standard. The task standards are consistent with the overall capability standard.

Step 3: Assess current performance (a functional needs analysis)

Suppose analysis of past incidents shows the following (hypothetical figures):

For a night incident at the far edge: 8 + 75 + 50 + 15 = 148 minutes, which exceeds the 120-minute standard by 28 minutes.

Step 4: Consider solutions across all lines of development

The capability view makes alternatives visible. A product-centered approach might jump straight to "buy a faster aircraft." A capability approach asks whether relocating an existing aircraft, plus thermal imaging and training, might close both gaps at lower cost. It also flags dependencies: thermal imaging without trained crews or maintenance support (Logistics) delivers little.

Step 5: Phase and track

A CV-3 style phasing table would then show when each element arrives and how much of the standard is met in each period. The capability is declared delivered only when all contributing lines are in place, which is the TEPID OIL principle in action.

Limits, criticisms and open problems

Definitions remain inconsistent

Henshaw and colleagues' finding of at least eight worldviews is a warning. Teams that think they agree on "capability" may mean different things: a system, a mission effect, an organizational competence, or a portfolio of programs. SEBoK notes that terminology such as capability-based acquisition, life capability management and capability sponsor is used with varying meanings across and within sectors.

Process overhead

The JCIDS experience shows that a capability process can become a slow, document-heavy bureaucracy. The CRS and the 2025 memo both frame speed as the central problem. The capability idea itself does not require heavy process, but institutionalizing it often produces one.

Materiel bias persists

Even with DOTMLPF and TEPID OIL checklists, organizations tend to treat equipment as the main answer, because equipment programs have budgets, sponsors and industrial constituencies. The CRS raised exactly this question for Congress. The checklists exist because the bias is real; they do not eliminate it.

Measuring capability is hard

A capability is an ability under conditions and standards, which means measuring it requires realistic exercises, operational data or modeling and simulation. Many capabilities, such as deterrence or resilience, are hard to observe until they are tested, and by then it may be too late.

Complex adaptive behavior

SEBoK's point that capabilities are often complex adaptive systems matters in practice. An improved capability changes the behavior of users and adversaries. A better fraud-detection capability changes how fraudsters operate; a better air defense changes how an adversary plans attacks. The capability's effectiveness can decline even if nothing in it degrades.

Gaps versus opportunities

Gap analysis looks at shortfalls against a stated need. The CRS noted criticism that this approach reacts to identified gaps rather than identifying opportunities created by new technology. Capability thinking that only fills gaps may miss chances to do entirely new things.

Common misconceptions

"A capability is a big piece of equipment."

The whole point of the concept is that it is not. Equipment is one input. Without trained people, doctrine, logistics and information, equipment delivers no capability.

"Capability-based planning ignores threats."

It does not. It responds to uncertainty about threats by planning for a range of challenges rather than a single scenario. Davis's definition stresses "a wide range of modern-day challenges and circumstances," and the work still uses scenarios, just more of them and with more attention to uncertainty.

"JCIDS and capability-based planning are the same thing."

JCIDS was one particular U.S. process for validating requirements based on capability analysis. Capability-based planning is a broader approach, used by other countries and in other sectors, and it survives JCIDS's 2025 disestablishment.

"Capability engineering is just systems engineering with a new label."

SEBoK and the INCOSE UK guide argue that the tools are largely the same but the viewpoint differs: owner-operator rather than supplier, enduring service rather than one-time delivery, influence rather than command, and non-like-for-like trade-offs. Whether that justifies a separate discipline is debated, which is itself part of the eight-worldviews finding.

"Business capabilities and military capabilities are unrelated ideas."

They share the same logic: describe what must be achievable, independent of how, then plan people, processes, information and technology together to achieve it.

Frequently asked questions

What does DOTMLPF stand for?

Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities. DOTMLPF-P adds Policy.

What does TEPID OIL stand for?

Training, Equipment, Personnel, Information, (Concepts and) Doctrine, Organisation, Infrastructure, Logistics: the UK Defence Lines of Development. The C of Concepts and Doctrine is dropped to make the acronym.

What is a capability gap?

A shortfall between a required capability, with its conditions and standards, and what current and programmed forces or systems can actually achieve. JCIDS defined gaps as capability shortfalls identified by combatant commanders.

What is the difference between a capability and a requirement?

A capability describes an ability in operational terms. A requirement is a specific, verifiable statement that a particular solution must meet. In JCIDS, the Initial Capabilities Document described the capability need; the Capability Development Document, written only after a materiel approach was chosen, set out detailed requirements with thresholds and objectives.

Why do architecture frameworks have a capability viewpoint?

To connect strategy to solutions. DoDAF's CV models let an architect show which capabilities a vision requires, when they will be available, how they depend on one another, which organizations will use them, and which activities and services they support.

Is JCIDS still in use?

The August 2025 memo directed its disestablishment and set out replacement structures, including the Requirements and Resourcing Alignment Board and the Mission Engineering and Integration Activity. A DoD implementing document dated 10 November 2025 carries the same title as the memo. Readers needing current details should consult the latest DoD issuances.

Does capability thinking apply to small organizations?

Yes, in simplified form. Any organization can state what it needs to be able to do, under what conditions and to what standard, measure the shortfall, and consider changes to people, processes, information and tools together rather than defaulting to buying something.

Who are the key references for capability systems engineering?

The SEBoK article on capability engineering, the INCOSE UK Capability Systems Engineering Guide by Kemp and Daw (2014), Henshaw and colleagues' 2011 analysis of perspectives, Paul Davis's 2002 RAND monograph on capabilities-based planning, and, for defense processes, the JCIDS documentation and the UK and Australian capability management publications.

Summary

In systems engineering, a capability is an ability to achieve a specified effect under stated conditions and standards. It is delivered by a combination of equipment, people, training, doctrine, organization, information, infrastructure and logistics, and it is described in operational terms rather than as a product. The concept took hold in U.S. defense planning in the early 2000s with the shift to capabilities-based planning and the creation of JCIDS in 2003, and parallel frameworks developed in the United Kingdom and Australia. Architecture frameworks such as DoDAF added a capability viewpoint to trace strategy to solutions, and the systems engineering community has articulated how capability engineering differs from product engineering. The approach has real strengths, especially in forcing consideration of non-equipment solutions, but also persistent weaknesses: inconsistent definitions, process overhead, a lingering bias toward equipment, and the difficulty of measuring what an organization can actually do. The 2025 dismantling of JCIDS shows that the processes built around the concept remain contested even as the concept itself endures.

Sources

• Capability (systems engineering) (Wikipedia))
• Joint Capabilities Integration and Development System (Wikipedia)
• Congressional Research Service, Defense Primer: JCIDS (IF12817)
• SEBoK, Capability Engineering
• SEBoK, Capability (glossary))
• SEBoK, System Capability (glossary))
• Davis, Analytic Architecture for Capabilities-Based Planning, RAND MR-1513 (2002)
• National Research Council, Naval Analytical Capabilities: Improving Capabilities-Based Planning (2005)
• AUSA, A New Look at Requirements: The Joint Capabilities Integration and Development System
• DoD CIO, DoDAF 2.02 Capability Viewpoint
• UK MOD, MODAF and Defence Lines of Development analysis (2009)
• GOV.UK, MOD Architecture Framework
• Overt Defense, Capability Management and the Defence Lines of Development
• Australian Department of Defence, Defence Strategic Review glossary
• Hood, Society as a Fundamental Input to Defence Capability
• Breaking Defense, Pentagon terminating JCIDS process as part of larger acquisition reform memo (2025)
• Air and Space Forces Magazine, Hegseth Cuts JCIDS in Move to Speed Weapons Development
• Berrisford, Capabilities and competencies in O-BA and TOGAF
• AcqNotes, JCIDS overview