************LAST HOMEWORK ASSIGNMENT FOR THIS CLASS…. I HAVE NEW CLASSES START ING IN MAY FOR MY SUMMER SEMESTER….. I HAVE AN ACCOUNTING CLASS AND A HEALTHCARE MANAGEMENT INTERNSHIP CLASS……. DO YOU HAVE EXPERTISE IN ACCOUNTING 216? IF YOU DO, I WILL BE SENDING YOU WORK WEEKLY FOR THAT CLASS*************
LOGIN INFORMATION for CLASS BOOK for this homework assignment:
user name: firstname.lastname@example.org
BOOK NAME: Business Driven Information Systems/Chapter 9: Systems Development and Project Management: Corporate Responsibility
Business Requirements (page 380-381)
Complete the Closing Case Two on page 380-381 of the text. Answer the four questions on page 381. Underline heading each question and answer below the heading. (Cite references)
CLOSING CASE TWO
Reducing Ambiguity in Business Requirements
The main 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 reduce ambiguity dramatically:
■ 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 in which you would run A without B and B without A?” If you build a system with an “always” requirement, you are actually building the system never to 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, the system users can never perform that requirement. For example, the system w
■ 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.15
Questions (UNDERLINE HEADING FOR EACH OF THE 4 QUESTIONS WITH COMPLETE ANSWER UNDER HEADING)
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 because every employee always has a birthday every year.”