Page 92 -

For example, a use case document for accounting software will not explain how double-
entry accounting works; it will assume that every reader is familiar with the concept.

When an inspector finds a defect, he is helping the author identify areas that need to be
explained. The author assumed that each reader fully understood a concept: it turned out
that the reader needed some clarification after all. In this way, the document can be
adjusted to the level of its specific readers.
The hesitant author will generally recognize that she has expertise that her readers do not
have. Explain that while she can make an educated guess at what context and background
needs to be included, she has no way of knowing if it is enough. The inspection process is
an efficient technique to help her fix this.

NOTE
More information on inspections can be found in Software Inspection by
Tom Gilb and Dorothy Graham (Addison Wesley, 1993) and Peer Reviews
in Software by Karl Wiegers (Addison Wesley, 2002). Information on the
effectiveness of software inspections can be found in the Software Tech-
nology Roadmap: http://www.sei.cmu.edu/str/.

Deskchecks
A deskcheck is a simple review in which the author of a work product distributes it to one
or more reviewers. In a deskcheck, the author sends a copy of the work product to
selected project team members. The team members read it, and then write up defects and
comments to send back to the author. Work products that are commonly reviewed using a
deskcheck include vision and scope documents (see Chapter 2) and discussion summaries
(see Chapter 6).

There are times when a full inspection is neither necessary nor useful. Some work prod-
ucts do not benefit enough to warrant the attention of an entire inspection team because
they do not need consensus or approval. In these cases, the author simply needs input
from others to prevent defects, but does not require that they approve the document. In
these cases, the deskcheck is a useful review practice.

Unlike an inspection, a deskcheck does not produce written logs that can be archived with
the document for later reference. There is no follow-up meeting or approval process. It is
simply a way for one team member to check another’s work. Deskchecks are not formal
reviews (where “formal” simply means that it generates a written work product that
meets a certain standard and is archived with the rest of the project documentation); there
is no standard for the results of the deskcheck. The reviewers simply review the work
product and return the results. There is no moderator, and there is not necessarily any
consensus generated.

But, despite the lack of formality, the deskcheck is a very important tool for a project
team, and there are many times when the project manager will build deskchecks into the
organization’s software process. If a work product does not need approval by a team but is

84 CHAPTER FIVE