Wherein we do lots of peer reviews to find as many requirement errors as we can.
Simply documenting the requirements an analyst hears during interviews or workshops isn't sufficient to give confidence that the requirements are correct. There are so many opportunities for miscommunications and misunderstandings that validation is an essential step in the requirements development process. Peer reviews constitute one of the most powerful mechanisms for finding errors in requirements. During a peer review, someone other than the author of a work product examines that work product for possible defects and improvement opportunities.
Peer reviews are a type of static testing, a way to filter out requirement problems before writing the first line of code. Reviews provide a way for users to confirm that their input has been interpreted and recorded properly. They also provide a way to detect ambiguous requirements, which helps all stakeholders reach a common understanding of what the requirements are trying to say. If I could perform only one quality practice on a software project, that practice would be formal peer review (also called inspection) of all requirements information. Given this appreciation of the power of peer reviews, we build them into our requirements activities in two ways, informally and formally.
Following each use case elicitation workshop, the analyst supplies the documents he or she creates to the workshop participants. Such ...