G&W Chapter 20: Technical Reviews Software Specification Lecture 27 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

Part V: Greatly Improving the Odds of Success Ambiguity Metrics Technical Reviews Measuring Satisfaction Test Cases Studying Existing Products Making Agreements Ending

Rationale Most of G&W’s book emphasizes requirements adequacy – generating a sufficient quantity of requirements information. This chapter provides an overview of the principal tools for ensuring sufficient quality of requirements information.

Rationale (cont’d) Without these tools, there are no consistently reliable methods for measuring progress of requirements work.

Formal vs. Informal Reviews Formal reviews include people who were not involved in producing the document. Results go to both producers and others – project managers, possibly customers, etc. There is formal follow-up. Informal reviews involve producers reviewing their work critically within their own group. Results go to producers only. There is no formal follow-up.

Technical vs. Project Reviews Technical reviews include only experts on the subject matter and are concerned solely with the quality of the document. In Project reviews, managers consider quality info together with cost, schedule, and resource info in order to make informed decisions about what actions to take.

Review Reports: Issues List & Summary Reports Issues List: records issues with the requirements document; it tells the producers why their work was not totally acceptable. Need not be “translated” for non-technical readers. Should only raise issues – not attempt to resolve them. A review committee is generally no better at resolving issues than a producing unit is at raising them.

Review Reports (cont'd) Summary Report: intended for management and possibly customers, it carries the committee’s assessment of the work. Always generated after a formal review. Must identify what was reviewed, who did the reviewing, and what the conclusion was. The Summary Report is the fundamental link between the review process and the project management system.

Types of Reviews Vanilla: conducted with no particular meeting discipline decided in advance; structure is adjusted according to product under review. Extremely adaptable, but Requires skilled facilitation.

Types of Reviews (cont'd) Inspections: focuses on a narrow, sharply defined set of questions driven by a checklist. Walkthroughs: the product is “presented” by someone very familiar with it. Similar in spirit to a lecture, but focus is not educational (unless made clear in advance). Does not normally require participant preparation.

Types of Reviews (cont'd) Round Robin Reviews: participants take an equal and similar portion of the entire reviewing task in a cyclical pattern. Useful when participants have roughly the same level of knowledge. Ensures that nobody will shrink from participation. Useful, for example, when users with many different perspectives are involved.

Hints and Variations Chapter 8 guidelines for making all meetings effective also apply to reviews (e.g., keeping a related issues list). Analyzing review reports can reveal insights into ways to improve tools and processes. If people are reluctant to have their work reviewed or attend reviews, look at the rules you use, the leaders you use, and the reviewers you invite.

G&W Chapter 20: Technical Reviews Software Specification Lecture 27 Prepared by Stephen M. Thebaut, Ph.D. University of Florida