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

2. 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

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

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

5. 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

6. 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.

7. 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.)

8. 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.

9. 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.

10. 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

11. 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.

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