Built as written:
the five software requirements risks that decide a project

A project can be delivered on time, within budget and with relatively few technical defects, and still fail commercially. It simply built the wrong thing. The problem arises in the software requirements, long before the first line of code. They are also where it is cheapest to prevent.

Research points to many problems rooted in requirements. For a typical medium-to-large software project, I would prioritise five. Their relative importance depends on the project’s domain and delivery model.

Incomplete software requirements: expensive rework

What is missing from a requirement is rarely visible on the day someone writes it. It surfaces later, when someone has to build or test it. A study presented at the ASE 2026 conference analysed 8,082 requirements that a chipmaker received from car manufacturers, standards bodies and its own engineering teams. Only 0.2% were fully specified. The operational context was missing in 81.5% of them, conditional logic in 51.5% and the expected behaviour in 45%. The less context a requirement carried, the more detailed requirements the engineers had to derive from it^[1].

Interviews at a car manufacturer and a supplier explain why. Early in a project, the people writing requirements often lack knowledge of the future product, so requirements come out vague or soon outdated. Customers who do not fully understand their problem describe the solution they want instead. Short contracting times push teams to collect requirements in a hurry^[2].

Some gaps hide in plain sight. When an old system is replaced, everything it already does is a requirement too. A 2026 study of a legacy modernisation found that interviews captured new needs well, but missed what the existing system already did. That knowledge lived only in people’s heads^[3].

Ambiguous software requirements: incorrect functionality

An ambiguous requirement is worse than a missing one, because it looks complete. Two readers find two meanings, and each builds what they understood.

Practitioners rank ambiguity as the worst requirements defect. A 2025 study at a large European defence company interviewed ten experienced engineers and surveyed 58 more. Eight of the ten interviewees ranked ambiguity among the three most severe defects, and seven among the three most frequent. The survey also confirmed both rankings. The engineers described the effect plainly. An ambiguous requirement travels back and forth between analysts and developers and attracts change requests. Worse, it can stay unnoticed until integration testing or maintenance, when fixing it is most expensive^[4]. Similarly, research reflects the same priority. A review of 105 empirical studies on requirements quality found ambiguity to be the most studied quality attribute, with more sub-types than any other^[5].

AI makes the risk sharper, not smaller. A study presented at the ASE 2026 conference rewrote 1,304 programming tasks in ambiguous variants and gave them to large language models. Ambiguity lowered the share of correct solutions by 7.22 percentage points on average, and by up to 32 points. Answers also became less consistent: for GPT-4, conflicting answers to the same task rose from 14% to 28%. The models detected only between 25% and 44% of the ambiguous wordings, depending on the type^[6]. An AI model does not ask what you meant. It picks a meaning and writes the code.

Uncontrolled requirements changes: cost and schedule overruns

Requirements will change; the business does. The risk is change without control: changes that nobody assesses, prices or traces through the design.

A case study at a software product company, based on 15 interviews, traced requirements volatility mainly to uncertain requirements and a changing business environment. Architects reported scheduling problems and architectural technical debt as the result^[7]. The defence study adds a link to risk 2: ambiguous requirements are a frequent source of change requests^[4]. Many changes are not new needs at all, but old requirements finally understood.

Moreover, complexity makes this harder. In PMI’s 2026 Pulse of the Profession, 81% of project professionals said projects had become more complex. Four in five complex projects suffered negative fallout, such as strategic drift or delivery disruption^[8]. Without a managed baseline and an impact assessment for each change, every shift in priorities lands directly on budget and schedule.

Missing non-functional requirements: operational failures

Functional requirements describe what the system does. Non-functional requirements describe how well: performance, reliability, security, maintainability. They shape the architecture, and they are the ones most often left implicit.

A 2025 analysis of the international NaPiRE survey on requirements engineering found that most respondents rated maintainability, reliability, usability and performance as important. Yet some reported that requirements for these important attributes were not documented. The authors treat these gaps as technical debt^[10]. An engineer in the defence study gave an example of what follows. Nobody can properly test a task specified only as “high priority” and “fast”. The system passes its tests and then malfunctions in production, where the real constraints differ^[4].

Likewise, public-sector reviews point in the same direction. The Dutch government’s ICT review board, the Adviescollege ICT-toetsing (AcICT), reviewed 20 projects worth more than €1.1 billion in 2025. It asks for security requirements that are “concrete, applicable and testable”. It also wants maintenance planned and funded already in the project phase^[9].

Insufficient stakeholder involvement: failure to meet business needs

Requirements are only as good as the people who shape them. When the right people are absent, the system meets the specification and misses the business.

The AcICT found that the client role in government IT projects was still too often insufficiently fulfilled. Projects get stuck when clients lean too heavily on the supplier and set too few concrete, measurable requirements themselves^[9]. Similarly, the automotive interviews describe the same problem from the inside. Communication and feedback channels across levels and organisations are hard to establish, and responsibilities between teams are often unclear^[2]. In the legacy modernisation study, users from one country did not take part in prioritisation, and the developers opted out because they did not see it as their role^[3].

The people who write requirements matter as much as the people they ask. A small 2026 study among 18 practitioners in Brazil listed 17 undesirable traits of requirements engineers. Communication problems and lack of domain knowledge were among the main groups^[11]. Finally, PMI found that high performers were more likely to align sponsors on success criteria before execution: 39% against 30%. Overall, 31% of complex projects failed to deliver their full intended benefits^[8].

What this means for your software requirements

The fundamental challenge in software requirements engineering is not simply documenting what the software should do. It is ensuring a shared, validated, testable and continuously managed understanding of the business needs.

A project can be delivered on time, within budget and with relatively few technical defects, yet still fail commercially because it implements the wrong requirements. For software project governance, requirements quality should therefore be treated as a key project risk indicator, alongside budget, schedule and technical quality.

Five questions help to measure it before the next steering meeting.

1. Is each requirement complete enough to build and test without guessing? Check context, conditions and expected behaviour, including what the old system already does.
2. Could two readers understand it differently? If so, add an example or an acceptance criterion before anyone writes code, human or AI.
3. Is every change assessed before it is accepted? Name who approves it, what it costs and which parts of the design it touches.
4. Are performance, reliability, security and maintainability written down and testable? If not, the architecture is being decided by default.
5. Did the people who will use the system shape the requirements? And did the sponsor agree on what success means to them?

Whoever writes the code, an in-house team, a supplier or an AI model, builds what the requirements say.

Sources

1. Z. Wang, S. Yu, Z. Xing, T. Wenzel, C. Chen, “Bridging Stakeholder and Product Requirements: An Empirical Study of Requirement Engineering in the Automotive Industry”, ASE 2026, arXiv:2607.05632, 6 July 2026. arxiv.org
2. G. Liebel, M. Tichy, E. Knauss, O. Ljungkrantz, G. Stieglbauer, “Organisation and communication problems in automotive requirements engineering”, Requirements Engineering 23 (2018) 145–167, published online 28 October 2016. doi.org
3. R. S. Karper, D. A. Tamburri, A. Ferrari, W.-J. van den Heuvel, “When Stakeholder-centric Requirements Engineering is Not Enough: An Action Research Study on Legacy System Modernisation”, arXiv:2609.07340, 7 September 2026. arxiv.org
4. E. Gentili, D. Falessi, “Practitioners’ perceptions on requirements smells”, Information and Software Technology 187 (2025) 107823, available online 5 July 2025. doi.org
5. L. Montgomery, D. Fucci, A. Bouraffa, L. Scholz, W. Maalej, “Empirical research on requirements quality: a systematic mapping study”, Requirements Engineering 27 (2022) 183–209. doi.org
6. D. Yang et al., “Clarity Is Not Assumed: Understanding LLM-Based Code Generation under Ambiguous Requirements”, ASE 2026 (East China Normal University), arXiv:2604.21505. arxiv.org
7. S. Aaramaa, S. Dasanayake, M. Oivo, J. Markkula, S. Saukkonen, “Requirements Volatility in Software Architecture Design: An Exploratory Case Study”, arXiv:2603.17648 (posted 18 March 2026). arxiv.org
8. Project Management Institute, Pulse of the Profession 2026, “Driving Success in Complex Projects”, press release, 12 May 2026. businesswire.com
9. Adviescollege ICT-toetsing, “Jaarrapportage 2025” (Annual Report 2025), March 2026, published 9 April 2026, CC BY 4.0. adviescollegeicttoetsing.nl
10. E. Scott, G. Robiolo, S. Matalonga, M. Felderer, D. Pfahl, “A study on reported under-documented non-functional requirements as an indicator of technical debt”, Software Quality Journal 33 (2025), article 28, published online 30 June 2025. doi.org
11. L. Barbosa et al., “Understanding Undesirable Attributes of Requirements Engineers: Insights from Practitioners”, arXiv:2606.01370, 31 May 2026. arxiv.org