Understanding Requirements

According to one of the most widely cited studies for IT project failures, the “Chaos” Report by the Standish Group, approximately 31% of all software projects are cancelled before ever being completed. Even more startling is the fact that in the 1995 study, only 16.2% of the 8,380 projects surveyed were completed on-time and within budget.

Fast-forward to Chaos statistics from 2007 and we see an improvement in these figures: 35% of all projects were successful, while 19% were failures. Fortunately these numbers have improved over the last decade or so, although the success rate of software projects in general is still unacceptably low. Why is it that such a large number of projects fail?

According to respondents in the first study above, ‘Incomplete Requirements’ is the number one reason why software projects are impaired and eventually abandoned. There are a number of other important reasons listed, including ‘Lack of User Involvement’, ‘Lack of Resources’, and ‘Unrealistic Expectations’, but generally speaking the issue of inadequate requirements has been a longstanding pain point within the software development industry. I am certain that like most software developers you too have experienced the frustration of requirements issues at some point, maybe due to those all-too-common reasons such as insufficient research during the requirements gathering phase, or misunderstandings in communication between the customer and the development team.
Oftentimes development teams fail to understand requirements because of documentation that is vague or open-ended. Unclear requirements leave a lot of room for interpretation, meaning that the customer, managers, developers, and any other parties involved may understand requirements differently from each other. As a consequence a development team’s interpretation of a system may be different to what was envisioned during requirements analysis, and again different to what the customer expected.

The truth is that requirements analysis is an inexact process, and that scope issues are going to surface in most software projects. While these types of issues cannot always be avoided we should try our best to ensure that we understand all requirements in as much detail as possible and as early on in a project’s lifecycle as possible, to minimize the likelihood of these issues jeopardizing project success.