If you email me at the address below, I have a weighted Requirements checklist that I've used that might be of use to you.
Life should NOT be a trip to the grave with the intention of arriving safely in an cool and well preserved body, but rather to skid in, chocolate in one hand, beer in the other, body wrecked, totally worn out and screaming WOO HOO what a ride!
I have reviewed a lot of Requirements documents as part of the testing job. If the requirements document is developed in terms of what the completed software has to do and then defining inputs, processing and outputs. You have to make sure that the requirement description is what the end User wants. Then make sure that all processing requirements define the input (how the data is entered, what is its format, and the validity checks made on the data). Each Processing requirement should have an output ( data going somewhere (DB), User Screen etc.). Design starts when the requirements have been approved. The contract should contain wording that after the requirements have been approved, finding missing or incorrect requirements during design and implementation does not mean additional funding.
Does your company wait to design before the requirement is approved and finalized?
I am asking this because most companies will define high level requirements and divide the work between developers\team leaders. Now it is job of developers to get the detail requirements and they are the one who define input and output. So atleast here in my company project is divided into tracks and each team leader of the track manages his/her track.
Does requirement review happens before we divide project into tracks or after each track has finalized.
[This message has been edited by yburhani (edited 02-07-2003).]
The decision to start design without approval of requirements varies from project to project and company to company. On major efforts for the Government, design was not to start until after requirements approval. In some cases, low risk items would be started. In some companies, requirements and design are done in parallel. Another approach is have several phases of requirements and design (incremental). Major item on this aproach is to have to top structure defined.
I have also seen the requirements produced after the design (not the correct way or idea way to go, but it does happen)and no reviews.
I prefer the incremental approach to requirements, design and implementation with a full review between each ("build a little, test a little". However, this is a company management call.