in reply to
Re: Dealing with the QA guy ... (no, really)
in thread Dealing with the QA guy ... (no, really)
According to the procedure we have, once the requirements is documented, we don't go back to it until the user acceptance testing.
I believe this is one of the potential stumbling blocks in software development that agile and iterative methodologies attempt to address. By keeping customers close to the developers, developers can short-cut the wasted-effort cycle when requirements are vague. By developing in short timeboxes, the amount of drift to user acceptance testing is minimized.
The Extreme Perl website expresses the problem reasonably well. Heavy, plan-driven methodologies are optimizing to minimize implementation risk, whereas agile methodologies are optimizing to minimize requirements risk -- which many would agree from experience is often both more likely and of higher overall impact.
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.