Requirements Reviews - When You Want Another Opinion - Part 1


In my view, the most powerful quality practice available to the software industry today is inspection of requirements documentation. A peer review is an activity in which someone other than the author of a work product examines that product to find defects and improvement opportunities. 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. Removing errors in the requirements saves many times the cost of the inspection because of the rapidly escalating cost of remedying defects that are found later in the project.

Unfortunately, inspections and other peer reviews of requirements documents often aren’t held when intended, and those that are performed don’t always go well. Reviewers take only a superficial look (if they look at all), and they miss many of the major defects that lurk in the specification. Conducting an ineffective review can give the team unjustified confidence in the work product’s quality.

This pair of articles, adapted from my book More about Software Requirements, presents several ways to make your requirements reviews more effective and to encourage prospective reviewers to participate in them. For an in-depth exploration of different peer review approaches and how to make them work for you, see my book Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002).

Note that, although I refer to requirements documents in these articles, the same principles also apply whether you’re storing your requirements in a spreadsheet, a database, a requirements management tool, or on note cards. No matter what their form, you really ought to have multiple pairs of eyes examine your project’s requirements for problems.

Educate the Reviewers

Educate the Requirements ReviewersSuppose someone hands you a document and asks for your input. Your instinctive approach probably is to begin reading at the top of page one and see whether any problems jump out at you as you go. Maybe you’re not too sure what to look for. As you continue reading, you begin to get tired and bored. Your own work backlog tugs at your conscience. So you flip through the rest of the pages, tell the author about the minor issues you found, and move on with your life. There’s a better way.

Don’t expect that reviewers will automatically know what to do. If you’re a business analyst who’s relying on input from others to validate and verify your requirements, you need to educate your reviewers. Ideally, you can get them to take some training on how to perform peer reviews, such as my eLearning course called “Software Inspections and Peer Reviews”. If not, at least tell them about the purpose of reviews, the various sorts of review approaches, and what you expect of the reviewers. This is particularly important if you plan to hold inspections, which involve a more structured process than do the more familiar informal reviews.

Interact Respectfully

Peer reviews are at least as much a social interaction as they are a technical practice. I believe that asking someone to tell you about mistakes in your work is a learned behavior, not an instinctive behavior. Authors need to learn how to request and accept constructive input about mistakes they’ve made. If you’re holding inspections or team reviews that involve a meeting, make sure the participants understand how to collaborate effectively and constructively. Many organizations hold ineffective reviews because participants are uncomfortable and they aren’t sure how to behave in a review meeting.

One state government agency that hired me as a consultant told me that their review participants refer to the review as “going into the shark tank”—not an appealing prospect. If you’ve been burned by a caustic review in the past, you’ll be reluctant to participate in such a stressful and ego-busting experience again. Therefore, it’s important to make reviews be constructive experiences in which all participants feel that they’re contributing to improving the team’s collective work products.

People need to be considerate when they provide feedback to the author of the work product being reviewed. I like to simply make observations about the product, rather than telling the author he did something wrong. If you’re the author, you might react differently if a reviewer accusingly says, “You forgot to fill in section 3.4 of the SRS template,” instead of simply commenting: “I didn’t see anything entered in section 3.4 here” or “Section 3.4 seems to be missing.” Be thoughtful about how you phrase your comments. Perhaps you’re a reviewer today, but you might be the author the next time.

Focus on Specific Problems

Tell the reviewers what kind of input you’re seeking in each situation so they can focus their attention on giving you useful feedback. Give them tips on how to study and analyze a requirements specification. For example, you might invite certain reviewers to 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 of the reviewers peter out partway through the document and miss a lot of errors in the latter pages. Some people suggest reading the document from back to front, section by section, to see whether the questions they come up with are all answered earlier in the document.

Give the reviewers a checklist of typical requirements errors so they can focus their examination on those points. You can find checklists for reviewing software requirements specifications and use case documents here . You might suggest that the reviewers make multiple passes through the document, perhaps during separate review cycles of a growing document. They can look for different types of problems from the checklist during each pass. Alternatively, ask different reviewers to use separate parts of the checklist to broaden the review coverage. Eventually requirements reviewers will internalize the review checklists and know what sorts of problems to look for.

In part two of this article I’ll share some additional tips for making your requirements reviews as effective as possible.

 About Author :

Karl Wiegers is Principal Consultant at Process Impact, His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons (

Like this article:
  12 members liked this article


Tony Markos posted on Wednesday, December 19, 2012 7:41 AM

Question: How are data flows documented to facilitate ease of requirements reviews?

Note: The real issue in requirements analysis is not so much identifying standalone requirements, but the essential interrelationships between them. For behavioral related requirements, these, of course, are the data flows.
Travis Barker MPA GCPM posted on Sunday, January 27, 2013 2:06 PM
Thanks for the article. It was a very interesting read.

I think you make a very valid point about the benefits that can be achieved through as structured peer review process of the requirements. Identifying the purpose, goals, and process by which the peer review will take place, in advance, insures that the effort achieves the intent of the peer review (i.e., the requirements of the peer review) and that the objectives are met.

The requirements list is identified to achieve customer, stakeholder, community, business, and product specifications. The review of these specifications supports the effective, efficient, and sustainable identification, allocation, and implementation of resources (financial, human, and technical) while minimizing duplication, error, and the escalating costs that result.

The weakness of the peer review specification checklist is that it could potentially omit other specifications that are required. As scope creep becomes increasingly inevitable as corporations expand into global markets the ability to incorporate a peer review process that accounts for escalating requirements is needed.

Thanks again for the article. I found it quite insightful.

Travis Barker, MPA GCPM
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC