13th International Conference on Software Quality

Software Division of
The American Society for Quality

Home ] Up ] 13ICSQ Program ] Sponsor & Exhibitor Opportunities ] Special Needs ] Dallas Info ] Hotel/Airline/Rental Car/Driving Directions ] Paper & Tutorial Presenter Information ] Volunteers Opportunities ] ICSQ History.htm ] Contact Us ] About ASQ ]


Tuesday Concussent Sessions
Gerald Weinberg
Karl Wiegers
Robin Goldsmith
Neil Potter
Mark Paulk


Karl Wiegers - Keynote Speaker

Karl Wiegers is Principal Consultant with Process Impact, a software process consulting and education company in Portland, Oregon. His interests include requirements engineering, peer reviews, project management, risk management, and software metrics. Previously, he spent 18 years at Eastman Kodak Company, where he held positions as a photographic research scientist, software developer, software manager, and software process and quality improvement leader. Karl received a B.S. degree in chemistry from Boise State College, and M.S. and Ph.D. degrees in organic chemistry from the University of Illinois. He is a member of the IEEE, IEEE Computer Society, and ACM.

Karl’s most recent book is Software Requirements, 2nd Edition (Microsoft Press, 2003). He also wrote Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002) and Creating a Software Engineering Culture (Dorset House, 1996), which won a Productivity Award from Software Development magazine, as well as 160 articles on software development, chemistry, and military history. Karl has served on the Editorial Board for IEEE Software magazine and as a contributing editor for Software Development magazine. He is a frequent speaker at software conferences and professional society meetings.

Keynote:  The Soft Side of Peer Reviews

Peer reviews are as much a social interaction as a technical practice. Asking your colleagues to point out errors in your work is a learned - not instinctive  - behavior. This presentation describes some of the cultural and interpersonal aspects of peer reviews and inspections that must be considered when trying to install a review program in an organization. The concept of "egoless programming” is described as it relates to reviews. Suggestions are provided for how a reviewer should present issues to the author in a nonjudgmental way. Some aspects of management attitudes and behaviors are discussed, including 10 signs of management commitment to peer reviews. A case study illustrates the risks of managers using defect counts from inspections to evaluate individual authors. These risks include:

  • Developers might not submit their work for review.

  • Developers might refuse to review someone else’s work.

  • Reviewers might not point out defects they see.

  • Authors might hold unofficial “pre-reviews”.

  • Review teams might debate whether or not something is a defect.

  • The culture will have an implicit goal of finding few defects.

  • Authors might review small bits of work to avoid finding too many bugs.

Several reasons why people do not perform reviews and ways to overcome them are explored, including factors related to lack of knowledge, cultural barriers, and simple resistance to change. Some of the benefits that people performing different project roles can enjoy from a successful peer review program are itemized. The presentation also addresses some aspects of holding reviews that involve participants from different cultures. By understanding the social and cultural aspects of peer reviews, organizations can increase their benefits from this powerful quality and productivity improvement technique.

Tutorial:  In Search of Excellent Requirements

Requirements form the foundation for all the software work that follows. Arriving at a shared vision of the product to be developed is one of the greatest challenges facing the software project team, and customer involvement is among the most critical factors in software quality. The objective of this tutorial is to give attendees a tool kit of practices, reinforced with practice sessions and group discussions, that they can begin applying to improve the quality of the requirements development and requirements management processes in their organization.

Learn about tested methods that can help any organization improve the way it gathers, documents, and analyzes software requirements. Characteristics of excellent requirements statements and requirements specifications are presented and used to evaluate some sample functional requirements. The seminar emphasizes several practical techniques, including:

  • Customer involvement through a “product champion” model

  • The application of use cases for defining user needs and system functions

  • Writing software requirements specifications using a standard template

  • Construction of dialog maps to model user interfaces

  • Using prototypes to clarify and refine user needs

  • Using peer reviews to find errors in requirements

  • Using a requirements traceability matrix to connect requirements to design elements, code, and tests

The basic concepts of requirements management are described, as are practical methods for managing changes to requirements. These techniques can reduce project risk by improving the quality and control of the software requirements, thereby increasing the likelihood of a successfully completed project.

Tutorial Objectives:

  • Be able to recognize and classify different types of requirements information

  • Learn about many “good practices” for requirements elicitation, analysis, specification, validation, and management

  • Learn how to apply the use case technique for eliciting user requirements

  • Select appropriate techniques for representing requirements on your projects

  • Be able to critically evaluate requirements statements for ambiguity and other problems

Tutorial Outline:

 I.       Introduction to Requirements Engineering

A.     Introduction to seminar, objectives, participant expectations

B.     Define three levels of software requirements: business, user, and functional

C.     Describe characteristics of high-quality requirements

D.     Requirements development vs. requirements management

II.     Practice session: small group discussions on requirements problems in their projects

III.    Software Requirements Development

A.     A requirements development process

B.     The requirements analyst

C.     The vision and scope document

D.     Sources of requirements

E.      Classifying requirements into categories

F.      Customer involvement in the requirements process: the product champion model

G.     Gathering user requirements through use cases

H.     Practice session: identifying use cases for an airline reservation kiosk

I.        Documenting requirements: the software requirements specification

J.       Software quality attributes

K.    Practice session and discussion: reviewing a portion of an SRS

L.      Modeling user interfaces with dialog maps

M.   Practice session: drawing a dialog map from use cases

N.    Reducing the expectation gap through prototyping

O.    Other methods of analyzing and validating requirements

IV.    Software Requirements Management

A.     Basic requirements management practices

B.     Version and change management

C.     Requirements change impact analysis

D.     Requirements traceability

V.     Practice session: Small group discussions on how to apply solutions to the
        requirements problems from the discussion in section II

 VI.    Wrap-up