Question

Required information

Chapter 17 Case: Reducing Ambiguity in Business Requirements The number one reason projects fail is bad business requirements. Business requirements are considered “bad” because of ambiguity or insufficient involvement of end users during analysis and design.     A requirement is unambiguous if it has the same interpretation for all parties. Different interpretations by different participants will usually result in unmet expectations. Here is an example of an ambiguous requirement and an example of an unambiguous requirement:
•	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.
Ambiguity is impossible to prevent completely because it is introduced into requirements in natural ways. For example:
•	Requirements can contain technical implications that are obvious to the IT developers but not to the customers.
•	Requirements can contain business implications that are obvious to the customer but not to the IT developers.
•	Requirements may contain everyday words whose meanings are “obvious” to everyone, yet different for everyone.
•	Requirements are reflections of detailed explanations that may have included multiple events, multiple perspectives, verbal rephrasing, emotion, iterative refinement, selective emphasis, and body language—none of which are captured in the written statements.
Tips for Reviewing Business Requirements
When reviewing business requirements always look for the following words to help dramatically reduce ambiguity:
•	“And” and “or” have well-defined meanings and ought to be completely unambiguous, yet they are often understood only informally and interpreted inconsistently. For example, consider the statement “The alarm must ring if button T is pressed and if button F is pressed.” This statement may be intended to mean that to ring the alarm, both buttons must be pressed or it may be intended to mean that either one can be pressed. A statement like this should never appear in a requirement because the potential for misinterpretation is too great. A preferable approach is to be very explicit, for example, “The alarm must ring if both buttons T and F are pressed simultaneously. The alarm should not ring in any other circumstance.”
•	“Always” might really mean “most of the time,” in which case it should be made more explicit. For example, the statement “We always run reports A and B together” could be challenged with “In other words, there is never any circumstance where you would run A without B and B without A?” If you build a system with an “always” requirement, then you are actually building the system to never run report A without report B. If a user suddenly wants report B without report A, you will need to make significant system changes.
•	“Never” might mean “rarely,” in which case it should be made more explicit. For example, the statement “We never run reports A and B in the same month” could be challenged with, “So that means that if I see that A has been run, I can be absolutely certain that no one will want to run B.” Again, if you build a system that supports a “never” requirement then the system users can never perform that requirement. For example, the system would never allow a user to run reports A and B in the same month, no matter what the circumstances.
•	Boundary conditions are statements about the line between true and false and do and do not. These statements may or may not be meant to include end points. For example, “We want to use method X when there are up to 10 pages, but method Y otherwise.” If you were building this system, would you include page 10 in method X or in method Y? The answer to this question will vary causing an ambiguous business requirement.

Research the web and determine other reasons for “bad” business requirements.