Understanding what needs to be developed because software projects are still failing. Sadly!
The “classical” figure below illustrates perfectly the key motivation behind this article – Understanding what is needed to be developed is an essential factor for the success of any software project. Although I really appreciate the value embedded in this figure’s message, I wish this image would be a topic of the past, and we could refer to it as museum art, but unfortunately, it isn’t!
Even nowadays, there are software projects out there, in which the customer needs are clearly available, possible to be expressed and projects are initiated and (somehow) closed without taking this topic serious enough. Searching for “Software failure Case Studies” it is not impossible to relate big failures of a project to failures that could have been solved during the requirements elicitation phase.
This article is just another one available online to highlight the importance of requirement elicitation activities. Furthermore, the information available in this article is used as references to other posts available in this blog.
According to Boehm,, if a defect is found early in the software development process it would cost much less than a defect found on later phases of the development cycle. For instance, during the requirement specification phase, a defect may cost $1 to fix, whereas during the testing activities, the same defect would cost $1000 to fix.
Different strategies can be employed to elicitate and define the project requirement specification, e.g.: Use cases, prototypes, user stories and etc. The fact is that it does not matter how it will be done, the needs of the project must be clearly understood as early as possible in the project life cycle . The same context also applies for “agile projects”, where the complete requirement specification of the projects cannot be defined at early stages but nevertheless, the need to understand the needs of the project remains  (see “Truth 8”).
Defining “good” requirements for the project helps to capture the real customer and business needs, to understand the complexity of the project and its technical challenges, and to identify or even eliminate defects at very early stages of the project.
-  Boehm, Barry W.
andPhilip N. Papaccio. ‘Understanding and Controlling Software Costs,’ IEEE Transactions on Software Engineering, v. 14, no. 10, October 1988, pp. 1462-1477
-  Beohm, Barry and Victor R. Basili. ‘Software Defect Reduction Top 10 List,’ Computer, v. 34, no. 1, January 2001, pp 135-137.
-  Robertson & Robertson, “Mastering the Requirements Process” – 2006