Peer Reviews: Two Eyes Aren’t Enough, Part 2

Reviews

Peer Reviews: Two Eyes Aren’t Enough, Part 2

By |

Here are some additional recommendations about how to make peer reviews of your requirements documents as effective as possible.

Don’t Overwhelm the Reviewers

Many BAs wait until their requirements specification is complete before they present it to some reviewers. Busy developers, testers, project managers, and users have difficulty finding the time to scrutinize a large document on short notice. It’s far more effective to review an evolving document incrementally. Give reviewers just a few pages at a time, preferably soon after an elicitation activity. Nearly anyone should be able to find thirty minutes to review a small quantity of information once in a while.

Incremental, informal reviews will uncover a lot of problems. Expect to make multiple review passes through the requirements over time. Each review cycle will reveal errors that the reviewers didn’t spot the first time. As the requirements continue to change and grow, people might need to revisit portions of the requirements documentation that they examined in an earlier draft.

You don’t need to hold a meeting for each peer review. Sometimes it works fine just to ask one or a few reviewers to look something over and tell you what they see. Combine these sorts of informal individual reviews, which I call peer deskchecks, with formal inspections of documents that are nearly done.

Build a Collaborative Partnership with Project Stakeholders

Explain to users why their input is so critical to ensuring the quality of the requirements and how it contributes to the quality of the ultimate software product. Make them understand that their review effort is a vital contribution, not an idle exercise. Begin forging this collaboration early in the project so these participants realize they’re valued members of the team.

On many projects, my software development teams at Kodak identified product champions, key customer representatives who worked closely with the business analysts. We negotiated the exact responsibilities with each product champion. But one responsibility was not optional: to review requirements specifications and evaluate prototypes. Without user review, we couldn’t tell whether we’d accurately captured the voice of the customer. We were pleased that all of our product champions accepted this responsibility. They provided great value through their reviews.

Invite the Right Reviewers

Determine early in the project what perspectives you need represented in your requirements reviews and who can provide these perspectives. Figure 1 illustrates the essential points of view a requirements review should take into account. Particularly consider getting the participation of the following:

• Customers who provided requirements input.

• Developers who will have to design and implement the requirements.

• Testers who will have to verify that the requirements were properly implemented.

Work products must be reviewed in a context, not in isolation. The reviewers must ascertain whether the work product meets its own specification. The top-level requirements documentation has no specification or reference document, so you need customers or others who provided requirements input to review the deliverable. Also, you might invite another BA to participate who’s adroit at spotting poorly written or missing requirements. The downstream “victims” of the requirements specification can check to see whether it will satisfy their needs. And if your product connects in some way to any other products, have representatives of those other components make sure the pieces will fit together properly.

Rather than having all these different reviewers just read through the document, consider using perspective-based reading, in which each reviewer examines the deliverable from the point of view of a specific document consumer. For example, a user seeks to determine whether the documented requirements would in fact let him achieve his business objectives. A developer checks to see whether the document contains the information he needs to design and implement a solution. A tester considers whether the requirements are precise and detailed enough to be verifiable. These different points of view will reveal different types of problems.

Have Reviewers Examine Appropriate Deliverables

It might not be reasonable to expect all your user representatives to effectively review a detailed software requirements specification. They should certainly understand use cases, though, as use cases ought to be written from the user’s point of view. Make sure your reviewers can comprehend the requirements documents and diagrams well enough to validate them. If the requirements documents are too technical for the reviewers to follow, you’re wasting their time.

Design for Reviewability

Present the information in a specification in forms that make it easy for reviewers to understand it and to 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 would be an effective alternative. Remember that a requirements specification is a communication tool. If your requirements deliverables don’t speak to their intended audiences, the deliverables need further work.

Inspect All Requirements Deliverables

Informal reviews certainly are helpful, but more systematic inspections will find more defects. Inspections and other group reviews also are a way to force the issue of getting reviewers to actually look at the work product. Inspections are a powerful technique for spotting ambiguous requirements. During an inspection, one inspector (not the author) serves as the reader. The reader presents his interpretation of each requirement to the other inspectors. If his interpretation doesn’t match their own understanding, perhaps the team has detected an ambiguity, a statement that can be interpreted in more than one way. Individual informal reviews often overlook ambiguities because an ambiguous requirement can make sense to each reader, even if it means something different to each of them.

Emphasize Finding Major Errors

The greatest leverage from a review comes from finding major errors of commission and omission. These are the defects that can help you avoid extensive—and expensive—rework much later in the project. Ambiguous and erroneous requirements send developers and testers in the wrong direction. Missing requirements are among the hardest errors to detect. They’re invisible, so inspectors don’t see them during their individual preparation. Because they don’t exist, the inspection reader won’t describe them.

Fixing typographical and grammatical errors is useful because any changes that enhance effective communication are valuable. However, this should be done before sending out the document out for broad review, perhaps by having a single skilled editor go through it initially. Otherwise, reviewers can trip on these superficial errors and fail to spot the big defects that lie underneath. When I see an issues log from a review that contains mostly cosmetic and spelling mistakes, I worry that perhaps the reviewers overlooked major problems.

No business analyst can get the requirements right on his own. Get a little help from your friends to make sure that what you’ve written will satisfy customer needs and will let the rest of the development team do a first-class job.

Check out Peer Reviews: Two Eyes Aren’t Enough, Part 1.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

 

Karl Wiegers
Latest posts by Karl Wiegers (see all)