 |
Home > Detail: Inspecting Requirements
| A StickyMinds.com Original |
|  | |
Inspecting Requirements
By Karl E. Wiegers
   
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 http://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 products. These categories might include reporting, edit operations, security, user customization, printing, and transaction logging, or whatever functional areas your products typically include.
- Make sure that the source and usage of all data items are stated.
The Inspection Meeting
During the inspection meeting, the reader describes his interpretation of each requirement in his own words. Such paraphrasing allows the other participants to compare their understanding with that of someone other than the author. Differences in interpretation can reveal omissions and surface assumptions. Inspection is a powerful method for uncovering ambiguities, in which different readers interpret a requirement in different ways.
If the reader has difficulty describing a requirement, perhaps it is too complex, poorly expressed, or incorrect. Simply reading the specification aloud verbatim or asking the inspectors if anyone has any questions on each page fails to catch many requirements problems.
Review Early and Often
Run your requirements through a quality gauntlet of both informal reviews and formal inspections. Instead of waiting until the big honkin’ requirements specification is done, start holding informal reviews when it is perhaps 10 percent complete. Informal reviews will reveal many errors quickly and cheaply.
I recently reviewed a badly flawed 300-page specification. It had serious organizational problems, violated every rule for writing unambiguous requirements, and omitted important information. Had I examined just the first thirty pages several months ago, I could have suggested many improvements in the way it was being written. This would have saved much rework at this late stage.
I want to learn about errors in the requirements before I’ve written any code for that part of the system, not when an irate customer calls. Inspections are a powerful way to help me achieve that goal.
About the Author
Karl Wiegers, Ph.D., is the Principal Consultant at Process Impact in Portland, Oregon. He’s the author of Creating a Software Engineering Culture, Software Requirements, and the forthcoming Peer Reviews in Software: A Practical Guide. You can reach Karl at www.processimpact.com.
Back to Top
StickyMinds.com Weekly Column From 7/30/01
|
