Inspecting Requirements

[article]
Summary:

Errors in requirements specifications translate into poor designs, code that does the wrong thing, and unhappy customers. Requirements documentation should be inspected early and often. Anything you can do to prevent requirements errors from propagating downstream will save you time and money. Karl Wiegers shows you how.

If I were limited to performing just one quality practice on a software project-and thank goodness I'm not-I would formally inspect every requirements document. Industry data suggests that approximately 50 percent of product defects originate in the requirements. Perhaps 80 percent of the rework effort on a development project can be traced to requirements defects. Anything you can do to prevent requirements errors from propagating downstream will save you time and money.

What Is Inspection?
Inspection is a well-defined formal peer review process, very different from simply distributing several copies of the requirements specification and inviting comments. The inspection process includes several stages: planning, overview, individual preparation, inspection meeting, rework, and follow-up to verify the changes made during rework.

In addition to the author of the work product being inspected, the inspection team includes individuals performing several roles. The moderator plans and leads the inspection, the reader presents the product to the other team members, and the recorder logs defects found and issues raised.

Inspection Participants
Appropriate inspectors of a requirements document include its author (typically a requirements analyst), another skilled requirements analyst, the project manager, and actual users or marketing representatives. Anyone who has to do work based on the document also brings a vital perspective. These downstream "victims" of the requirements include architects, designers, system test engineers, documentation writers, and support representatives.

The user viewpoint is critical. Inspectors who are not users cannot accurately judge whether the specification correctly addresses the users' needs. Non-user inspectors often guess at what the users need and add extra requirements.

To keep the team to a maximum of about eight people, selectively choose participants from among the many candidates. Favor people who can actually find problems with the requirements. Avoid including people for managerial or political reasons or those who just wish to learn about the project and its requirements.

The Preparation Stage
During preparation, inspectors examine the requirements document to understand it and to find possible defects. As well as simply reading the document from front to back, inspectors use checklists of typical requirements defects to help focus their attention. See www.processimpact.com/pr_goodies.shtml for defect checklists for requirements documents and several other software deliverables.

Inspectors can also use other analysis methods during preparation. Evaluating requirements for testability reveals incomplete, ambiguous, and inconsistent requirements (see Rodger Drabick's article "On-Track Requirements" in the May/June 1999 issue of STQE magazine). Walking through test cases or usage scenarios will show whether the necessary functional requirements are present.

Another approach involves identifying all output data items for each requirement and listing at least one other requirement that uses each output item. Look for unnecessary requirements-reducing the project's development effort will more than pay for the inspection. Ambiguities, omissions, incomplete or flawed logic, and redundancies should also catch your eye.

Missing requirements are among the hardest errors to detect. They're invisible. Inspectors don't see them during preparation and the reader doesn't describe them during the inspection meeting. Use the following techniques to look for missing requirements:

  • See if you have received requirements from all of your product's user classes.
  • Check whether nonfunctional requirements, such as quality attributes, performance goals, constraints, and external interface requirements, have been specified.
  • Ensure that the specification conforms to all pertinent business rules.
  • Represent requirements information in multiple ways. Models such as the classical structured analysis diagrams and newer UML models provide a high-level view. Decision tables and trees help you catch missing cases and undefined "else" conditions.
  • Build tables of similar requirements that fit a pattern to avoid duplications or oversights.
  • Check whether requirements are present in all pertinent functional categories for your

About the author

Karl E. Wiegers's picture Karl E. Wiegers

Karl Wiegers, Ph.D., is the Principal Consultant at Process Impact in Portland, Oregon, and the author of Software Requirements (Microsoft Press, 1999) and Creating a Software Engineering Culture (Dorset House, 1996). You can reach him at www.processimpact.com. You can find more than 35 of Karl's articles at www.processimpact.com/pubs.shtml

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01