Page 94 -

Finally, a deskcheck can be useful to review a work product that is not meant to be
inspected at all. For example, many requirements analysts will generate a discussion sum-
mary after a series of interviews and elicitation sessions (see Chapter 6). This is not a work
product that is used in later stages of the software process; rather, it is an intermediate docu-
ment used to generate the software requirements specification. A deskcheck is useful in this
case to help interviewees and other requirements analysts identify any information gathered
during the interviews that is inaccurate or unclear. No approval is needed, and the require-
ments analyst is free to ignore any of the comments. The deskcheck simply serves as a
checkpoint to ensure that mistakes are caught and addressed as early as possible.

NOTE
More information on deskchecks can be found in Peer Reviews in Software
by Karl Wiegers (Addison Wesley, 2002).

Walkthroughs
A walkthrough is an informal way of presenting a technical document in a meeting. Unlike
other kinds of reviews, the author runs the walkthrough: calling the meeting, inviting the
reviewers, soliciting comments, and ensuring that everyone present understands the work
product. It typically does not follow a rigid procedure; rather, the author presents the
work product to the audience in a manner that makes sense. Many walkthroughs present
the document using a slide presentation, where each section of a work product is shown
using a set of slides. Work products that are commonly reviewed using a walkthrough
include design specifications (see Chapter 7) and use cases (see Chapter 6).
Walkthroughs are used when the author of a work product needs to take into account the
perspective of someone who does not have the technical expertise to review the docu-
ment. For example, a requirements analyst must make sure that the use cases she builds
will provide the functionality that the users need, but the user representatives may not
have seen use cases before and would be overwhelmed by them. If these users are simply
included as part of an inspection team, it is likely that they will read the document and,
failing to find many defects, sit silently through the inspection meeting without contribut-
ing much. This is not their fault—their training is in the business of the organization, not

in reading and understanding software engineering documents. This is where a walk-
through can be a useful technique to ensure that everyone understands the document.
Before the walkthrough, the author should distribute any material that will be presented
to each person who will be attending. For example, if the walkthrough is done as a slide
presentation, copies of the slides should be emailed to the attendees. If only a portion of
that material is going to be covered, that should be indicated as well.

During the walkthrough meeting, the author should solicit feedback from the audience.
This is an opportunity to brainstorm new or alternative ideas, and to check that each per-
son understands the document that is being presented. The author should go through
parts of the document to make sure that it was presented in as clear a manner as possible.

86 CHAPTER FIVE