The Quiet Crisis in Defense Systems Engineering: Requirements Instability and Program Cost Growth

Every two years, the Government Accountability Office publishes its Assessment of Selected Weapon Programs. Every two years, the findings include a variation of the same sentence: cost growth and schedule delays are driven, in significant part, by requirements instability. The programs change. The dollar figures grow. The root cause does not.

This is not a new observation. The Nunn-McCurdy legislation, passed in 1982, created mandatory breach reporting for programs that exceed cost baselines by 15 or 25 percent. The intent was accountability through transparency. What four decades of breach reports actually reveal is a pattern: programs enter development with requirements that are either underspecified, unstable, or disconnected from the technology maturation reality on the ground. The cost growth follows predictably.

The defense acquisition community has launched multiple reform initiatives since then. Some have helped at the margins. None have addressed the core problem directly: the way requirements are created, maintained, and connected to engineering decisions is fundamentally broken, and it has been for a long time.

What the GAO Data Actually Shows

The GAO’s 2024 weapon systems assessment covered 48 major defense acquisition programs with a combined estimated cost of approximately $2.1 trillion. Programs in the assessment had experienced an average cost growth of 23 percent from their original baseline estimates. Schedule delays averaged 30 months.

When GAO investigators dig into causal factors, requirements-related issues appear in three distinct forms. First, requirements instability at the system level — the operational requirements document or capability development document changes after contracts are awarded, forcing redesign. Second, requirements that were technically complete on paper but practically ambiguous — specifications written at a level of abstraction that could support multiple incompatible design choices. Third, disconnected requirements — changes made in one tier of the specification hierarchy that were never propagated through to lower-level specifications or test plans.

Each of these is a different failure mode, but they share an underlying cause: requirements in defense programs live in documents. Documents are static. The programs they describe are not.

Stakeholder Needs and the Inception Problem

The problem begins before a program is formally initiated. During the Analysis of Alternatives and Material Development Decision phases, military users and operational commanders define what they need. This process involves Joint Capabilities Integration and Development System documentation — Capability Development Documents, Initial Capabilities Documents — that are written by people focused on operational outcomes, reviewed by committees focused on joint interoperability, and eventually handed to program offices that must translate them into system specifications.

That translation step is where the first major disconnect is introduced. Operational requirements written by warfighters describe effects in the battlespace. System specifications written by engineers describe behaviors in a hardware and software context. The mapping between those two layers is rarely explicit, rarely maintained, and almost never queryable. If an operational requirement changes — because the threat environment shifts, because a joint force commander’s priorities evolve, because Congress adds a mandate — the downstream effects on system specifications have to be traced manually, by people who may or may not have been in the room when the original translation was made.

This is not a resource problem. Major defense programs have entire requirements engineering teams. It is a structural problem. The tools those teams use — MS Word, Excel, and early-generation requirements management databases designed around document storage — do not make the dependency graph between needs and specifications a first-class data structure. The graph exists in engineers’ heads. Engineers leave programs. The graph disappears.

Technology Maturation and Requirements Churn

Defense programs routinely begin development before the technologies they depend on are mature. This is sometimes unavoidable — a 15-year development timeline for a platform means some component technologies genuinely do not exist at program start. But it creates a predictable dynamic: requirements are written against assumed technology performance levels, technologies underperform or evolve differently than expected, and requirements change in response.

The F-35 program is the canonical example. Software requirements grew from approximately 8 million lines at program start to over 24 million lines at initial operational capability. That growth was not the result of poor engineering discipline alone. It reflected genuine evolution in what the aircraft needed to do, driven by changing threat assessments and the maturation (and sometimes non-maturation) of sensor and electronic warfare technologies. Each change to software requirements cascaded into interface requirements, verification requirements, and training requirements. The cascade was real. The tooling to manage it was inadequate.

The response to this dynamic in recent programs has been to stage requirements more aggressively — to hold higher-level capability requirements stable while allowing lower-level implementation requirements to evolve within bounds. This is sound systems engineering practice. It requires tooling that can enforce and make visible the boundary between what is stable and what is variable. Most programs do not have that tooling. They have document hierarchies, manually maintained, with traceability matrices that are updated when someone remembers to update them.

Better Buying Power: What It Got Right and Where It Stopped

The Better Buying Power initiative, launched by Undersecretary of Defense Frank Kendall in 2010 and refined through subsequent versions, represented a serious attempt to change acquisition outcomes. It emphasized should-cost management, competition throughout the acquisition process, and tightening the link between requirements and funding realities.

Better Buying Power 3.0, released in 2015, added explicit language about technical excellence and systems engineering rigor. It called for more disciplined use of Model-Based Systems Engineering, better prototyping before commitment to production, and stronger requirements validation before Milestone B. These were meaningful improvements to incentive structures and program management expectations.

What Better Buying Power could not do was change the tools. Requirements traceability guidance improved. The underlying practice — people maintaining Word documents and Excel matrices — did not change at the same pace. A program could be fully BBP-compliant at the process level and still be managing requirements in a way that made cascade impact analysis practically impossible.

The Software Acquisition Pathway: A Different Model

The Software Acquisition Pathway (SWP), codified in DoDI 5000.87 in 2020, represents a more fundamental departure. It acknowledges explicitly that software-intensive programs cannot be managed like hardware acquisition programs. It allows for continuous delivery of software capability without formal Milestone B and C events. It mandates DevSecOps adoption and requires programs to maintain a persistent delivery pipeline.

For requirements management, the SWP’s implications are significant. A program on the Software Acquisition Pathway is expected to continuously refine requirements in response to user feedback. This is agile-aligned practice — requirements as a living backlog, not a frozen baseline. But it creates a documentation challenge that the SWP guidance does not fully resolve: how do you maintain traceability between user needs and delivered capability when both are continuously evolving?

Some SWP programs have solved this by integrating requirements management directly into their development pipelines — linking user stories to system requirements to test cases to verification evidence in a single connected data structure. These programs exist, and they perform better on cost and schedule predictability. They are not yet the norm.

What Modern Requirements Management Actually Looks Like

The contrast between legacy and modern requirements management practice is not primarily about tools. It is about data model.

Legacy practice treats a requirement as a paragraph in a document. A document has sections. Sections can be numbered. Numbers can be referenced in other documents. This creates a traceability system, technically, but one that is fragile (renumbered sections break references), opaque (you cannot query it), and static (it reflects the state at last publication, not the state right now).

Modern practice treats a requirement as a node in a graph. The graph has explicit, typed edges: a system requirement derives from an operational requirement; a design element satisfies a system requirement; a test case verifies a system requirement. When a node changes, the graph makes visible which other nodes are affected. When a requirement is deleted, the graph immediately shows orphaned downstream specifications. When a new threat assessment drives a new operational requirement, the impact analysis — what specifications change, what tests need to be rewritten, what verification evidence is now invalid — can be generated rather than manually reconstructed.

This model is not theoretical. It is implemented in modern systems engineering tools that have moved beyond document storage to genuine model management. Tools like IBM DOORS Next and Jama Connect have made progress in this direction — their linked requirement objects and configurable traceability schemes are genuinely better than flat documents. Polarion and Codebeamer offer tighter integration between requirements and development workflow, which matters for SWP-aligned programs. These are real capabilities, and programs using them are better positioned than programs using pure document workflows.

The remaining gap in these tools is AI-native analysis. Requirements graphs in legacy platforms are queryable if you write the right reports. They are not yet environments where an engineer can ask “what changes if the radar cross-section threshold tightens by 15 percent” and get a reasoned impact analysis across the full specification hierarchy.

That is the capability that tools like Flow Engineering are being built to provide. Flow Engineering’s architecture treats requirements as structured, semantically queryable data from the start — not documents converted to data after the fact. When requirements are graph-native and the AI reasoning layer is designed around that structure rather than retrofitted onto it, the kind of proactive impact analysis that defense programs need becomes operationally practical. For programs managing thousands of requirements with complex interdependencies across multiple contractor tiers, that distinction — AI-native versus AI-added-on — is the difference between a useful feature and a transformative capability.

Why the Industry Is at an Inflection Point

Three forces are converging to make this a moment of genuine change rather than another cycle of process reform.

First, the threat environment is accelerating faster than acquisition timelines can accommodate. Peer adversary capability development, particularly in areas like hypersonics, electronic warfare, and autonomous systems, is requiring requirements changes mid-program that would previously have been deferred to a follow-on program. Programs have to manage more churn than they were designed to absorb.

Second, software content in defense systems has grown to the point where hardware-centric requirements management practice simply breaks. A modern combat aircraft or naval vessel has more software complexity than the hardware around it. Requirements management tools and processes designed for hardware specification cannot handle software requirements at scale without significant adaptation.

Third, AI tooling has matured to the point where it can provide genuine leverage on the hardest parts of requirements management — impact analysis, consistency checking across large requirement sets, gap identification between operational needs and system specifications. This is not speculative. The underlying model capabilities exist. The question is whether they are integrated into the requirements workflow or remain a separate analytical step that engineers have to remember to perform.

An Honest Assessment

The defense acquisition community has more self-awareness about requirements problems than it did twenty years ago. The Better Buying Power initiatives, the Software Acquisition Pathway, the DoD’s Digital Engineering Strategy — these represent genuine intellectual progress about what good systems engineering looks like and what policy levers can move programs toward it.

The implementation gap remains wide. Most programs are still managed against requirements that live in documents, with traceability maintained in spreadsheets, and impact analysis performed by walking down the hall and asking someone who has been on the program long enough to remember why a requirement was written the way it was. When that person leaves, the institutional knowledge goes with them.

The GAO will publish its next weapon systems assessment. It will note cost growth. It will note requirements instability. The question for the defense engineering community is whether that cycle is inevitable, or whether the tooling now exists to break it.

The tooling exists. The organizational will to adopt it is the variable that is harder to forecast.