One under or ineffectively used tool is the specification or requirements review, which is a form of design review. In this case we are reviewing the design while it is still easy and cheap to make adjustments.  Experience suggests, if we do not just forget to do this activity, it is a hastily arranged activity with little planning.  I know of no study that shows the tangible value of reviews, however, anybody that has ever written anything likely has seen the benefit of others reviewing their work.  The concept of the design review is similar and comparable to testing in that we are looking for defects.

As the old saw goes “as you sow, so shall yea reap” – if we spend little time and effort on the review we will gain little benefit.  To be of value we will need:

• Available Talent
• Material to review
• Time to review material
• Facilitator to manage the process 
• Distribute material (with deadline)
• Schedule the review
• Have the review taking notes of changes needed
• Take actions the deemed necessary from the review

To get the most out of the meeting we need a diversity of people to review. A review by the person authoring alone is pointless and better not to waste the time.  We should include those that will use the documents to create or test the end product (or process).  To that end, a systems document, for example, should be reviewed by those that are required to produce the sub-systems requirements as well as the end customer and the test group.

Once we have identified those that should be involved in the reviews, we will distribute the material for them to critique prior to reconvening.  The actual review should be a merciless critique of the document, like piranhas to a “raw steak”.  The author must be able to separate this critique from any personal implication – in other words not be overly defensive.

For what I have seen for reviews, ill prepared participants, I suggest that the day of the meeting those that are required to perform the critique must show their marked up copy of the requirements (specification) to gain entry to the meeting. If they are unable to show this up front diligence then they are not allowed into the discussion and perhaps their manager should talk to them about the reasons for design reviews.

Once we have aggressively yet objectively reviewed the document we will set about making any necessary changes we discovered in the review, always keeping in mind the revision controls. Upon updating we will then release the specification for the next set of activities.

Reviews are beneficial anytime there is a transition point from one group to other groups.  We breakdown some of the barriers and are better able to come to some common understanding by having an open critique of the requirements.

We will share some design review stories in later blogs.