Issues with software requirements

A Software Development Lifecycle (SDLC) usually starts with requirements. The aims of the requirements elicitation process are to understand the work that stakeholders do and how they might use a new system to help support that work [1].

Unfortunately, the elicitation process frequently goes wrong. Industry surveys over decades consistently find requirements ambiguity, incompleteness, weak traceability, and missed validation errors to be widespread [2] [3] [4]. Incomplete and/or hidden requirements, communication flaws between development team and customer, and moving targets are the most cited issues and also the ones mostly related to project failure [3].

Moving targets, aka requirements volatility, is a serious problem for many organizations [5]. It’s also something that Agile methodologies expect and explicitly work with rather than against [6]. Agile approaches improve project outcomes in the face of requirements volatility compared to plan-driven approaches [5] [7] [8].

The other two major issues are incomplete/hidden requirements and communication flaws. Both have as the underlying cause that they use natural language. Natural language is ambiguous, because that’s more efficient [9]. In everyday life, that’s fine, since speaker and listener share a lot of context that resolves the ambiguity. But when software development teams work to elicit requirements, this isn’t always the case. Just trying to gain access to the domain experts needed can be a big hurdle, and even when access is granted, assumptions about the meanings of words are still prevalent.

Ambiguous natural language therefore remains an important source of requirements issues. To be clear, communication is essential and there is no way to completely remove ambiguity from the process. However, there are ways to significantly reduce it, and using Domain Driven Design (DDD) and its focus on Ubiquitous Language can greatly improve the requirements gathering process.

References

1. Sommerville, I. Software Engineering, 2016, Pearson.
2. Leffingwell, D. Calculating Your Return on Investment from More Effective Requirements Management, 1996, Rational Software Corporation.
3. Méndez Fernández, D. et al. Naming the Pain in Requirements Engineering, 2016.
4. Franch, X. et al. The state‑of‑practice in requirements specification: an extended interview study at 12 companies, 2023.
5. Mohammad, A. et al. Causes and Mitigation Practices of Requirement Volatility in Agile Software Development, Informatics, 2024.
6. Beck, K. et al. Manifesto for Agile Software Development, 2001.
7. Sillitti, A. et al. Managing uncertainty in requirements: a survey in documentation-driven and agile companies, 11th IEEE International Software Metrics Symposium, 2005.
8. Krancher, O. Agile Software Development Practices and Success in Outsourced Projects: The Moderating Role of Requirements Risk, 2020.
9. Piantadosi, T. et al. The communicative function of ambiguity in language, 2012.