In the series of articles on Requirement Analysis we covered - "How to get your requirements right?" and then we also looked at "Methods and Techniques for documenting the requirements". In this article let us look at the five most frequently encountered problems during the phase of requirement analysis of software development projects.

1. Teams speak a different language

   The IT teams want to talk about technology and want answers to their "How's".

   The Project Managers want the scope so that they can fix the budget and schedule.

   The CEO talks business.

   So, where is the common ground ........Hence it is very important that the person doing the requirement analysis to cater to requirements from all stakeholders and create a common ground and tries to captures the 3 W's (What, When, Where).

2. Pushing for Development to start

It is unfortunate that sometimes people do not realize the importance of doing the requirement analysis right; the emphasis is on getting to the coding / development at the earliest.

If the requirements are done right they can save a lot of time and effort down the road in fixing and re-fixing bugs and issues. Overall the development cycle will be smaller if enough time is spent on the requirement analysis phase. The statistics are there to prove this.

“From the studies made by various software development communities, it is evident that most failures in software products are due to errors in the requirements and design phases – as high as 64 percent of total defect costs according to Crosstalk, the Journal of Defense Software Engineering .”

So do not give into the pressure and emphasize on getting the requirement phase it's due.

3. Delaying the documentation - We will document along the way
   • What if that person(s) knowing the requirements leaves or moves onto another project?
   • What if you have to stop the development and re-start it after some time?
   • On what will your testing be based on?
   • How will you know if what you wanted has actually been understood?
   • How will all concerned be in sync in terms of what is required?

Sometimes people want to cut corners and leave the documentation to be done later. If it is all in a person's head there are bound to be mistakes.

Even for small projects you need not go in for elaborate documentation but document enough to avoid issues mentioned above.

4. Keeping requirements Feasible and Relevant

You need to make sure that the requirements that are being captured and documented are relevant to the solution under consideration. There may a lot of needs but are all those needs going to be met by the software which is going to be developed.

You also need to keep the requirements are in line with the rules and regulations of the company, regulatory authorities, government etc.

Examples – You might specify a date format of mm/dd/yyyy in your requirements; it will be valid in the USA. Is your software only for use in the USA? If yes, it is fine but if it is for global use this format may not be valid in the country of use. The same applies to currency.

5. Inadequate Review, Feedback, Closure

The requirements need to be reviewed by the client and all stakeholders need to come to an agreement that the requirements reflect the needs adequately. If the requirements are properly signed off it will help in meeting expectations and having satisfied customers.