1 / 9

Chapter 11 Closing Case Two : Reducing Ambiguity in Business Requirements

Saurav Joshi Spring 2010. Chapter 11 Closing Case Two : Reducing Ambiguity in Business Requirements. Ambiguous Requirements…. Ambiguity in requirements means that a single reader can interpret the requirement in more than one way or that multiple readers come to different interpretations.

paulos
Télécharger la présentation

Chapter 11 Closing Case Two : Reducing Ambiguity in Business Requirements

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. Saurav Joshi Spring 2010 Chapter 11Closing Case Two:Reducing Ambiguity in Business Requirements

  2. Ambiguous Requirements… • Ambiguity in requirements means that a single reader can interpret the requirement in more than one way or that multiple readers come to different interpretations. • Lead to confusion, wasted effort, rework, and unmet expectations • Are the one of the main causes for project failures.

  3. Examples • Ambiguous requirement: The financial report must show profits in local and U.S. currencies. • Unambiguous requirement: The financial report must show profits in local and U.S. currencies using the exchange rate printed in The Wall Street Journal for the last business day of the period being reported.

  4. Why is ambiguity hard to prevent? • Technical implications used in requirements maybe obvious to IT developers but not to customers. • Business implications used in requirements maybe obvious to customers but not to IT developers. • Everyday words used in requirements may have different meanings for different people.

  5. Reduction of ambiguity Correct use of the following words can help reduce ambiguity. • And/or : “The alarm must ring if button T is pressed and if button F is pressed” vs. “The alarm must ring if both buttons T and F are pressed simultaneously. The alarm should not ring in any other circumstance. • Always: “We always run reports A and B together”. • Never: “We never run reports A and B in the same month”

  6. Questions True or False • Meanings of some words which are “obvious” to everyone can still be different for everyone. True/False ?

  7. Questions Multiple Choice Which of the following is related to ambiguous requirements? • Uncertainty • Misinterpretation • Unfulfilled expectations • 4. All of the above

  8. Discussion Question What are some other ways that we can help reduce ambiguity in business requirements?

  9. Reference • Baltzan, Paige, and Amy Phillips. Business Driven Information Systems. Boston: McGraw-Hill /Irwin, 2008. Print.

More Related