Tuesday, 2 September 2008

Requirements

It always amazes me that requirements always seem to be left out and classic statements of project issues are:

"The requirements were defined incorrectly."
"The requirements changed late in the project."
"We delivered what you wanted and this differs from your expectations."

I know this is ideal world stuff but surely with formal review and a little extra time spent at the beginning of a project a great deal of issues would be solved at the end. This would stop the developers guessing what the system should do. This would also stop the testers having little as a basis for testing and mean that anything produced would likely be acceptable.

The other main thing to consider is to produce a workable product early where possible and continually get this reviewed with the potential users and stakeholders to ensure that they know exactly what is being produced and that it is acceptable.

I think in the real world the best way to help with requirements is to pick up the phone, make a meeting, send an email and chase, chase, chase. If you dont have the information that you need make a list of what is missing and then talk to the person that has been charged with the responsability of producing this information. This will both enable you to say that you have done everything that you could and if you obtain what you need it will let you do your job more effectively.

No comments: