2026-06-16 · Nicholas Edwards · ACC3 International
The Growing Cost of DoD Requirements
How requirements debt is defeating government software modernization before a line of code is written.
BLUF: The DoD lost $2.5 billion in workforce productivity to underperforming software in a single fiscal year. The cause is not bad code. It is bad specifications. AI coding tools are making that problem faster, not cheaper.
Government software programs rarely fail in the code. They fail in the space between what the mission needs and what a program delivers. This gap is caused by:
- Ambiguous language.
- Inconsistent vocabulary.
- Lengthy discovery and requirements gathering.
The cost of this gap is not abstract. In a 2025 study mandated by Section 241 of the FY2023 National Defense Authorization Act and sponsored by the Department of Defense (DoD) Chief Information Officer (CIO), RAND (Triezenberg et al., 2025) put a conservative lower bound on the total: $2.5 billion in lost workforce productivity which was caused by underperforming IT and software in fiscal year 2023 alone. The same study found significant discrepancies in how the mission impact of these issues is perceived, highlighting the gap between the users who live with these problems and the developers who build the software.
In federal and defense acquisition, that disconnect exacts a toll on missions impacted. It can cause schedule slips. It may result in rework charged at the taxpayers' expense. Mission-critical capabilities arrive late and are found to be misaligned. This affects federal workers, contractors, and warfighters. The Government Accountability Office (GAO) has documented both halves of these problems repeatedly over the years (GAO-23-105867, GAO-25-107795). The result is a debilitating effect on requirements stability in defense software acquisition. All this accumulates into a repeating loop of inefficiency driving up the sustainment costs of decades-old legacy systems in desperate need of modernization.
The introduction of LLMs into development has not closed this gap. New development tools are released regularly with increased efficiency and speed. Instead of assisting with this gap, the accelerated speed of development is only widening the gap further. Resulting in faster development of software but no improvement to the quality of requirements and specifications that steer agents in the right direction. This speed to prototype or proof of concept results in the illusion of progress while compounding the cost of errors with each iteration. In a world of LLMs where context is king: clear specifications are the context that matters.
The proposition is clear. Modern software quality is not found in faster code generation but clearer specifications. Requirements are structured clearly enough that any reader, human or machine, can interpret them in the same way. This paper examines:
- Why requirements engineering remains a difficult process.
- What a "specification first" approach looks like.
- How one solution applies established citable requirements-engineering methods to overcome the problem.
1. The operational challenge
The Mechanics of upstream failure
GAO findings on software program failures tell a consistent story. It isn't the developers. It's the programs failing at scope, communication, and scheduling. The recurring fault sits upstream of the developers and only surfaces once the pieces come together, by which point it requires rework.
Semantic drift and natural language failure
A single requirement can mean different things to different readers. Requirement failures are often left until testers raise the alarm. This is corrected after effort was already expended. That effort has a cost. This impacts the program of record.
For example: The word "Account" can carry completely different meanings to different roles like mission owners, engineering teams, and financial officers, to name a few. Each one may read a requirement differently. All these roles might be involved in the development of a system. Semantic drift is not failed documentation, but it is a vulnerability of language used at scale.
Figure 1 - Foundational cost-of-change models, validated by 2024–2025 industry assessments demonstrating a 30x to 100x cost multiplier for defects caught in production versus the requirements phase. (Ref: [Consortium for Information & Software Quality CISQ, 2022]cisq; widely cited industry cost-of-change models).
Locked knowledge and compounding debt
GAO traces failures to four recurring causes:
-
Moving goalposts. Defense acquisition programs frequently experience cost overruns and schedule slippage. These systemic issues are primarily driven by requirement volatility and inadequate quality assurance. (GAO-23-105867)
-
Undocumented legacy code and poor maintainability. Legacy efforts stall or fail due to old system instructions that are hard to translate (GAO-25-107795). Foundational knowledge can be lost in a sea of documents, dead wikis, old scripts or the minds of former employees.
-
Accidental downgrades. Since historical knowledge is lost, modernization teams end up with an incomplete picture. With an incomplete picture they build systems that drop critical requirements. This includes deeply buried security controls.
-
Technical debt. When documentation is written, it only describes what the system was imagined to be, but only for day one. Over time there will be a growing gap between what the system is meant to be and the actual code. This is a textbook example of "technical debt" (Lehman & Belady, 1985).
These factors compound technical debt over time.
Figure 2 - Modernization is increasingly hindered by what Storey (2026) terms "intent debt," the degradation of static documentation and the loss of the original design rationale. (Ref: McKinsey & Company, "Tech debt: Reclaiming tech equity," 2020, for the compounding cost of technical debt; Storey, "From Technical Debt to Cognitive and Intent Debt," ACM Queue, 2026, for the intent-debt framing).
The bottleneck is not throughput speed, but the clarity of your starting position.
2. A specification-first approach
If lack of clarity is the root cause, then a program needs to be sure that what is written down before the start of development is a solid foundation to build upon. The documented knowledge, not human memory or passing conversation, needs to be thorough enough to guide the work. It needs to be the authority.
Great specifications:
-
Must be unambiguous. Specifications must leave as little room for interpretation as possible. As stated, each perspective can bring different interpretations, and that can lead to miscommunication.
-
Must stay alive. A specification needs to be a part of a deployed system. It should absorb the changes rather than being a planning tool. This ensures that a program remains audit-ready and up to date throughout its lifecycle.
-
Must carry forward. Each release should provide the baseline for the next. Constraints and context must be inherited. Legacy systems should not require rediscovery.
These may seem like obvious inclusions for any program. These are the longstanding goals for any requirements engineer. What has changed? AI has enabled foundational principles to become more accessible, faster to achieve, and cheaper to maintain.
How to reduce ambiguity in specifications
One of the most established techniques out there is the Easy Approach to Requirements Syntax (EARS). EARS constrains every requirement to fixed grammar. The best illustration of how EARS works is to provide an ordinary requirement like:
"The system needs to lock out users if they type their password wrong too many times so they can't get hacked but let them try again after a while or if an admin unlocks them."
Seems simple enough, but there are a lot of areas for misinterpretation. "Too many times" and "after a while" are unqualified. "Lock out" works but doesn't provide a state or level of rejection. The trigger, routing, and administrative override are compounded together. This requirement can lead to lack of clarity around which condition drives which behavior. Another problem, it leaves room for a developer and tester to disagree on what the definition of "done" is. This requirement also doesn't specify security controls. These gaps or the vagueness left in this requirement can lead to disagreements which can have consequences.
The same intent, expressed in EARS:
WHILE in an active login session, WHEN a user enters an incorrect password, IF the consecutive failure count reaches 5, the Authentication Service SHALL set the account status to Locked for 15 minutes.
There is a:
- Precondition (an active session)
- Trigger (an incorrect password)
- Measurable condition (five consecutive failures)
- Responsible component (the Authentication Service)
- Response with its bound (locked for 15 minutes)
These are now explicit and individually testable. What remains becomes their own EARS statements rather than trailing clauses. Nothing is tacked on. This decomposition of each requirement is the point. Every behavior is separately verifiable, hidden conditions are forced into the open, and a reviewer or auditor knows what to expect.
Section 3 will address the challenge of managing specification clarity at scale, using a proven workflow, and leveraging AI for acceleration.
3. Building strong requirements leveraging experience
Alchemist AI Pro™ is a requirements and specifications engine. The concept is to walk through 7 guided stages which follow requirements engineering best practices. There is always an analyst in the loop. The most consequential decisions are made up front then details are reserved once scope is established. Big rocks first, details last.
| Stage |
What happens |
| 1. Capture |
Starts from an initial statement, existing documentation, legacy code, domain knowledge, or web sources. This is the context that is carried throughout the stages. |
| 2. Elicit |
The high-level features list. Details are deferred until ready. |
| 3. Frameworks |
Surfaces the unstated enterprise-level components, including security, data, and access constraints. |
| 4. Elaboration |
Works through each epic until fully detailed using Socratic questioning, agrees on the definition of done, then moves to the next. |
| 5. Alchemy |
Consolidates the elaborated requirements into a single authoritative gold standard. |
| 6. Audit |
Independently reviews the Alchemy output, revealing any ambiguities, overlaps, and contradictions, then proposes solutions for a human to accept or reject. |
| 7. Export |
Produces the final deliverables: documentation, test scripts, use cases, and specifications for developers. |
Compliance gates. The framework stage provides regulatory and security requirements early in the process. This prevents them from being late-stage surprises. Security, data, and access constraints are carried out through the elaboration, audit and export stages. Compliance is traceable from the start rather than retrofitted later.
The audit stage is independent by design. This is a genuine second opinion rather than a system grading its own work by cross-checking the specifications before gaps or contradictions are committed.
Alchemist AI Pro™ is intended to be used as a closed loop to keep the specifications alive. Your repository can be used to feed the next iteration of your requirements. Next sprint, cycle, or next version. Your specifications are carried forward. Then leverage code archeology to bring the current state of development into your next iteration as well.
4. Methodology and evidence base
The methodology used by Alchemist AI Pro™ comes from decades of experience with requirements engineering. This is auditable and not just a vendor assertion. Evaluators can verify the approach used with the provided citable sources. These include independent standards and research papers that support the methodologies discussed. These include reports from GAO, publications from IEEE, and federally funded research.
This methodology has been independently assessed
The strongest indication of the platform's potential is that it has already been independently and competitively assessed. Alchemist AI Pro™, submitted as the "Accelerating the Mission" solution, has been assessed "Awardable" by the Tradewinds Solutions Marketplace, the Chief Digital and Artificial Intelligence Office (CDAO) repository of solutions addressing priority government challenges in AI, machine learning, data, and analytics.
It is worth being precise about what that status does and does not mean. "Awardable" is a procurement-readiness signal: the solution passed a structured, competitive assessment, scored against the Marketplace's published rubrics among a field of applicants, and is now available for rapid acquisition by Department of Defense (DoD) customers with a Marketplace account. It is not an award, an endorsement, or a selection, and it is not presented in this paper as one. No contract, sole-source authorization, or government preference is implied.
5. Applicability and constraints
When it comes to use cases Alchemist AI Pro™ is designed to be suited for:
- Defense and federal modernization
- Multi-vendor or multi-agency programs
- Programs with high regulatory exposure
- Agentic and AI-assisted development pipelines
- Enterprise software procurement with custom development
What you should know about the platform:
-
This is the same work, accelerated. While the platform does accelerate the process of getting detailed and complete requirements, work is still required.
-
The platform depends on a human's judgment. Users don't load information in and then press a button to get their results. A user or users need to walk through the stages, interact with the Socratic AI, and conclude what "done" really means.
-
Legacy ingestion is powerful but not magic. During the capture stage you can add old wikis, PDFs, and SOPs to surface buried constraints. The quality of this recovery effort depends on the quality of what gets recorded. Undocumented knowledge is still undocumented until elicited from actual people. New discoveries while working through the process can be added via insights and integrated with the current workstream. Then there is Grafting. The process of taking an existing requirement set in from Alchemist AI Pro™ and "versioning it" both grabbing the code that the original requirement created as the foundation and any additional documents or features that need to be added on as an enhancement to the application.
-
The application currently supports GitHub. The closed-loop mechanism currently assumes a GitHub-based workflow. While Alchemist AI Pro™ uses GitHub, other source control systems can be swapped into alchemist to fulfill the needs of the program.
A small team that shares a clear, unified understanding of a simple system might not see the value in the overhead a formal specifications tool would bring.
6. Conclusion
The discipline that produces good software has not changed in fifty years. Provide clear specifications, traceable results, repeatable solutions. That is the goal and always has been. What has changed is the cost and speed of achieving it. Rigorous, living, machine-readable specifications are attainable to a larger audience.
Alchemist AI Pro™ is one implementation of that principle. It applies established requirements-engineering methods to decrease time to development while improving the quality of specifications. It keeps the specification coupled to deployed reality, then carries context forward across future releases. The independent "Awardable" procurement-readiness assessment from CDAO's Tradewinds Solutions Marketplace reinforces that.
Programs that recognize the specification gap have a clear path forward: They must resolve the specification problem before the downstream errors in the code compound it.
References
Christel, M. G., and Kang, K. C. (1992). Issues in Requirements Elicitation. Software Engineering Institute, CMU/SEI-92-TR-012. https://apps.dtic.mil/sti/tr/pdf/ADA258932.pdf
Comella-Dorda, S., et al. (2000). A Survey of Legacy System Modernization Approaches. Software Engineering Institute, CMU/SEI-2000-TN-003. https://apps.dtic.mil/sti/tr/pdf/ADA377453.pdf
Consortium for Information & Software Quality CISQ. (2022). The Cost of Poor Software Quality in the US. IBM Systems Sciences Institute. https://www.it-cisq.org/the-cost-of-poor-quality-software-in-the-us-a-2022-report/
Ferrari, A., Donati, B., and Gnesi, S. (2018). Detecting domain-specific ambiguities: An NLP approach based on Wikipedia crawling and word embeddings. 5th International Workshop on Artificial Intelligence for Requirements Engineering (AIRE), pp. 393–399. IEEE. https://doi.org/10.1109/AIRE.2018.00011
Lehman, M. M., and Belady, L. A. (1985). Program Evolution: Processes of Software Change. Academic Press. https://gwern.net/doc/cs/1985-lehman-programevolution.pdf
Mavin, A., Wilkinson, P., Harwood, A., and Novak, M. (2009). Easy Approach to Requirements Syntax (EARS). 17th IEEE International Requirements Engineering Conference (RE'09), pp. 317–322. https://doi.org/10.1109/RE.2009.9
McKinsey & Company. (2020). Tech debt: Reclaiming tech equity. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity
Storey, M. (2026). From Technical Debt to Cognitive and Intent Debt. ACM Queue. https://queue.acm.org/detail.cfm?id=3807966
Triezenberg, B. L., Zabel, S., Steratore, R., et al. (2025). Underperforming Software and Information Technology in the Department of Defense (RR-A2927-1). RAND Corporation. Sponsored by the DoD Chief Information Officer pursuant to Section 241 of the FY2023 NDAA. https://www.rand.org/pubs/research_reports/RRA2927-1.html
U.S. Government Accountability Office. (2023). GAO-23-105867. https://www.gao.gov/products/gao-23-105867
U.S. Government Accountability Office. (2025). GAO-25-107795. https://www.gao.gov/products/gao-25-107795
About the Author
NE
Nicholas Edwards
Lead Customer Success Architect · ACC3 International
Nicholas Edwards is a Lead Customer Success Architect at ACC3 International with over 20 years of experience spanning enterprise software engineering, solution architecture, and technical sales in the DoD and federal space. He helps government clients navigate complex technology decisions, with current focus on AI adoption.
View on LinkedInContact Nicholas Edwards
Give Alchemist AI Pro™ a Try
Alchemist AI Pro™ bridges the gap between mission need and software delivery, turning operational knowledge into traceable, testable requirements your development teams can actually build from.