Importance of Requirements
Have you ever wondered or even thought about that how many defects are being produced by requirements? If your answer is no, then read on, you should read even if your answer is yes 🙂
Here we go, more than two third defects are produced just because of requirements. Developer produced errors account for a small fraction only. But we tend to put more efforts on coding instead of requirements.
As a reference, do read this journal article:
For managers, see what is the value of poor requirements analysis with respect to cost (managers would definitely be attracted when shown something associated with cost 🙂
Requirements analysis on basis of ROI
As per Fred Brookes:
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part of the system is more difficult to rectify later.”
Brooks, F., “No Silver Bullet: Essence and Accidents of Software Engineering”, IEEE Computer, Vol. 20, No. 4, April 1987, p. 10-19.
Coming back to our point, who should take the action ? Of course the decision makers who decide how much time to put on requirements analysis & what methodologies to adopt for requirements gathering, analysis and management. If managment itself does not know the importance of requirements and its impact, then how the choas created by the end of the project will be overcomed.
As a first step, we need to know ourselves what impact requirements have on projects. There’s a wealth of historical information that proves that projects started without written requirements are doomed to fail. As Jones said:
“A significant and important aspect of requirements errors is that if they are not prevented or removed, they tend to flow downstream into design, code, and user manuals. Historically, errors which originate in requirements tend to be the most expensive and troublesome to eliminate later.”
Jones, C., Software Quality: Analysis and Guidelines for Success, International Thomson Computer Press, 1997
The next step is to get Management to understand the importance of requirements and to require that requirements are a mandatory part of your development process, a step that can’t be skipped no matter how intense the pressure is. Management commitment to having well-written requirements is essential.
The most neglected part is our lack to learn from our past mistakes. We do not do post mortem of past projects to learn from them and not to repeat the same mistakes. Offshore companies are always eager to find short cuts to reduce time and in turn cost. The first approach they adopt is to spend as little time on requirement gathering, analysis and management as possible that in turn produces problems by the end of the project.
To conclude, getting the requirements right is the key to getting the software right. With poorly written, incomplete, and ambiguous requirements, it’s difficult for software guys to know what to build & for QA guys to know what to test.