The most powerful quality practice available to the software industry today is inspection of software requirements documentation. An inspection is a type of formal, rigorous team peer review that can discover more subtle problems than individual reviewers might spot on their own. Less formal peer reviews are also valuable in many situations. Unfortunately, reviews of requirements documents often aren't held when intended, and those that are performed don't always go well. Here are some suggestions for holding more effective requirements reviews.
Educate the reviewers
Don't expect that reviewers will automatically know what to do. If you're an analyst who's relying on input from others to validate and verify your requirements, you need to educate your reviewers. Tell them what kind of input you're seeking so they can focus on that type of information. Give them tips on how to study and analyze a requirements specification. For example, some reviewers might start reading at some point other than the beginning of the document. After all, developers won't read the entire document sequentially during construction. This is a way to get fresh eyes looking at various sections rather than having all reviewers peter out partway through the document and miss a lot of errors in the back pages.
Give the reviewers a checklist of typical requirements errors so that they can focus their examination on those points. You can find such checklists at http://www.processimpact.com/pr_goodies.shtml. Consider asking different reviewers to use separate parts of the checklist to broaden the review coverage.
Many organizations hold ineffective reviews because participants aren't sure how to behave in a review meeting. Peer reviews are at least as much a social interaction as they are a technical practice. If you're holding inspections or team reviews that involve a meeting, make sure the participants understand how to collaborate effectively and constr
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
uctively. I can't emphasize enough the importance of training the reviewers in the peer review process.
Don't overwhelm the reviewers
Don't wait until your specification is "complete" before offering it to some reviewers. It's far more effective to review the evolving document incrementally. Give reviewers just a few pages at a time, preferably soon after an elicitation activity. Expect to make multiple review passes through the requirements documentation over time. Each review cycle will detect errors that the reviewers didn't spot the first time.
Invite the right reviewers
Determine what perspectives you need represented in your requirements reviews and who can provide those perspectives. Particularly consider engaging customers who provided requirements input, developers who will have to design and implement the requirements and testers who will have to verify the proper implementation of the requirements. Also consider inviting another analyst who's adroit at spotting requirements problems.
Design for reviewability
A requirements specification is a communication tool. Present information in ways that make it easy for reviewers to understand it and examine it for problems. There are many ways to communicate besides natural language text. If your eyes glaze over when reading a long list of textual requirements, maybe a diagram or a table is an effective alternative.
Emphasize finding major errors
The real leverage from a review comes from finding major errors of commission and omission. These are the ones that can help you avoid extensive -- and expensive -- rework much later in the project. Fixing typos is useful, but get some help with this before sending out the document out for broad review. When I see an issue list from a review that contains mostly cosmetic and spelling mistakes, I worry that perhaps the reviewers overlooked major problems.
No analyst can get the requirements right by himself. Get a little help from your friends to make sure that what you write will let the rest of the development team do a first-class job.
-----------------------------------------
About the author: Karl Wiegers is principal consultant with Process Impact in Portland, Ore. He is also the author of More About Software Requirements: Thorny Issues and Practical Advice; Software Requirements, 2nd Edition; Peer Reviews in Software: A Practical Guide; and Creating a Software Engineering Culture.
