1 / 12

G&W Chapter 19: Ambiguity Metrics Software Specification Lecture 26

This lecture discusses the importance of ambiguity metrics in software specification and how they greatly improve the odds of success. It covers topics such as negotiating a common understanding, ways to get started, clarifying expectations, and measuring satisfaction. Other topics include technical reviews, studying existing products, making agreements, and testing cases. The lecture highlights the iterative process of removing ambiguity in design and provides insights on how to measure ambiguity using an ambiguity poll. Three sources of ambiguity are also discussed: problem-statement ambiguity, design-process ambiguity, and final-product ambiguity.

dsteve
Download Presentation

G&W Chapter 19: Ambiguity Metrics Software Specification Lecture 26

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. G&W Chapter 19: Ambiguity MetricsSoftware SpecificationLecture 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 wherethat 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 MetricsSoftware SpecificationLecture 26 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

More Related