Friday, September 7, 2007

Reality of requirements

All of us recognize very well that requirement origins the project, it’s a construction project or an ERP implementation Defining accurate requirements and meeting them makes a project successful. It’s not too much to say, solid requirement are solid foundation of a project. Reality is that still most projects fails due to poor requirement and meeting customer expectations. Reality is that we don’t do a good job in getting requirements out of customer’s stomach. Reality is that customer doesn’t have much time to spend...

Most big projects follow best practices and we do get requirement documents called business requirement document or BRD. But just like everything else requirement doesn’t remain stagnant during life of a project, new users, better knowledge, new technology can change the requirement and expectations of users. Customer often doesn’t understand the necessity of working hard on gathering requirements and assuring its quality while the project team finds it difficult to work with customer and users. Yes, customer and users are busy and they don’t want to get involved in documenting and reviewing requirements. The onus is on project manager to keep users involved in project during life of project, we need to make them understand they are biggest stakeholder in the project. A strong commitment from users is very necessary to keep the project on right track. The time and money spent on understanding and refining requirement is most pragmatic investment in a projects life cycle. Project Managers neglect the requirement do so at their own risk. Getting lucid requirement on small projects or enhancement gets tricky. Beware of second hand requirement, little addition or deletion of words can change the meaning of product.

Inadequate requirements can lead to:

Unacceptable product and dissatisfied customer.
Project overruns and poor product quality.
Poor project planning
Unnecessary Rework and iterations.

Quality of requirement is most neglected area in a project, causing disaster. Ambiguous requirement leads to vague expectations among stakeholders. Most of them will be astonished by looking at the product once delivered. Ambiguous requirement creates confusion in testers and leads to a poor quality product. Rework is unavoidable at this stage.

How to avoid this vague trap? One way is to get requirements reviewed by a team representing different perspectives. Simply forwarding requirement document doesn’t add much value to its quality. It’s much better to have joint discussion session with customer and users. If a project can afford QAing requirement can be very useful.
It’s not a bad idea to test requirements against these parameters


Who can be finest tester of requirements? Customer? I guess so... A format commitment from project sponsor about user involvement pays off very well.

Creeping requirement is a challenge to most new projects. Huge changes during development of a product can crumble the structure of product. Reality is changes can not be prevented completely. A strongly defined and enforced change control process will help the project team and stakeholder to take informed decision about accepting or rejecting changes. This helps project manager in budgeting and planning project timelines.

Those projects do a good job in requirement gathering has a big chance of success with satisfied customer and returned business.
Written By : Ajay Khandelwal
Also available at localindya on