PLEASE DO NOT PLAGIARIZE

ANSWER THE 4 QUESTIONS AT THE BOTTOM OF THE CASE STUDY.

Report Internal report Detailed internal report Summary internal report Exception reporting Examples Presents data that are distributed inside the organization and intended for employees within an Organization, Internal reports typically support day-to-day operations monitoring that supports managerial decision making Presents Information with little or nofiltering or restrictions of the data Organizes and categorises data for managerial perusal. A report that summarizes total sales by product for each month is an example of a summary Internal report. The data for a summary report are typically categorized and summarized to indicate trends and potential problems Highlights situations occurring outside of the normal operating range for a condition or standard These internal reports include only exceptions and might highlight accounts that are unpaid or delinquent or identify items that are low in stock Ensures the reliability of information consisting of policies and their physical implementation, access restrictions, or record keeping of actions and transactions Assesses a company's information system to determine necessary changes and to help ensure the information system's availability, confidentiality, and integrity Presents a formal report or audit of a project after it is up and running Information system control report Information systems audit report Post-implementation report FIGURE 1710 Examples of System Reports. OPENING CASE STUDY QUESTIONS Which phase in the systems development life cycle is the most critical when building a video game? Which phase in the systems development life cycle is the least critical when building a video game? Chapter Seventeen Case: Reducing Ambiguity in Business Requirements The number one reason projects fail is bad business requirements. Business requirements are consid- ered "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 interpre tations 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 320 Unit 5 Transforming Organizations Ambiguity is impossible to prevent completely because it is introduced into requirements in natu- ral 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 dif- ferent 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 it button Tis 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 elther 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 Fare pressed simultane ously. 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 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 sys- tem, would you include page 10 in method X or in method Y? The answer to this question will vary causing an ambiguous business requirement. Questions 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