[SOLVED] The number one reason projects fail is

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
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 ……

Required:
1. Why are ambiguous business requirements the leading cause of system development failures?
2. Why do the words and and or tend to lead to ambiguous requirements?
3. Research the web and determine other reasons for “bad” business requirements.
4. What is wrong with the following business requirement? “The system must support employee birthdays since every employee always has a birthday every year.”

Question: The number one reason projects fail is