Document Actions
Best Process and Technique to Begin Development?
We are looking at our current processes to insure that they are effective. My supervisor is interested in adding an evaluation form to be used during the review process to highlight if our requirement document meets our standards and covers all information. This form would be filled out by Development, QA, Documentation, etc. In the past I've found most developers quite reluctant to sign or fill out this type of form which ultimately stopped the whole process. They have expressed to me that they don't want to fill out the form because they feel it will be used against them in the future. Can you describe the best technique you've found to begin the process of sharing the requirements documents with development? What is the best way to evaluate if the requirements are "complete"?
The most important tool in communicating requirements is, well, communication. Sit down with your Development team, and review the requirements one by one. Answer questions, and discuss the requirement. Then, ask members of the team to explain it back to you. Ensure that what's written is updated to reflect the additional discussion. When you have a really open requirements review -- where folks are encouraged to ask questions, knowing that you will be open and patient, team members often end up clarifying their understanding by using other examples, or by drawing on a white board. About 10 years ago, I read a book, Exploring Requirements: Quality Before Design, that really helped in doing requirement reviews.
After completing the review (taking as much time as needed), I have found that the Development team is OK with signing off on them. I would ask them to sign a statement that they have had an opportunity to review the requirements and ask questions. Essentially, they're signing to say that they're clear on the requirements. The document should NOT be used to promise delivery dates, since requirements are reviewed before the design (and therefore schedule) are complete. Assure your team that this will not be used against them. If they're really nervous, you could even add a statement that says "design and scheduling are not complete. The content and scope of this release is subject to change until the design has been reviewed and the work has been scoped."
This should be part of an overall stage gate process. Early on, we're defining concepts and finalizing requirements. Design comes next, and the schedule follows. Everyone in your organization should understand how the process works -- that makes it much easier to get them to sign off on the requirements.
Answered By Stacey Weber
