G&W Chapter 19: Ambiguity Metrics Software Specification Lecture 26 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

Where are we in G&W? Negotiating a Common Understanding Ways to Get Started Exploring the Possibilities Clarifying Expectations Greatly Improving the Odds of Success

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

What’s the Theme of Part V? Requirements need to be tested.

Rationale Design can be thought of as an iterative process of removing ambiguity: 1. Creating an approximate design 2. Testing for ambiguity 3. Removing the ambiguity found 4. Retesting the new approximation

Rationale (cont'd) We can measure ambiguity as the diversity of interpretation. This indicates how much work there is to do, and perhaps directs attention to where that work should be done.

An Ambiguity Poll Gather a diverse group of people to answer questions about a document whose ambiguity is to be measured. Be sure there is no pressure to conform, and no influence of any sort by one participant on another. (Responses to questions must be independent.)

An Ambiguity Poll Propose a set of questions, each of which can be answered with a number, such as: How fast? How big? How expensive? What capacity? Estimate ambiguity by comparing highest and lowest answers. (Other approaches?) Interview high and low estimators (at least) to help locate sources of ambiguity.

Three Sources of Ambiguity Problem-statement ambiguity – diversity of interpretation in the requirements for the design Create a means for protecting a small group of human beings from the hostile elements of their environment.

Three Sources of Ambiguity (cont'd) Design-process ambiguity – variation in the process that will produce a design (as in a picture of the solution) Final-product ambiguity – variation in the process that will create the physical solution

Hints and Variations Clustering of responses may indicate common assumptions. Lack of diversity in estimates => lack of ambiguity. Thus, it’s a good idea to use several questions in a poll. Whenever a piece of requirements work is said to be “finished,” subject it to an ambiguity poll to see if it really is finished.

G&W Chapter 19: Ambiguity Metrics Software Specification Lecture 26 Prepared by Stephen M. Thebaut, Ph.D. University of Florida