Use Cases and Event Decomposition

USE CASES AND EVENT DECOMPOSITION • The most comprehensive technique for identifying use cases is the event decomposition technique. The event decomposition technique begins by identifying all the business events the information system responds to, with each event leading to a use case. Starting with business events helps the analyst define each use case at the appropriate level of detail. For example, one analyst might identify a use case as typing in a customer name on a form. A second analyst might identify a use case as the entire process of adding a new customer. A third analyst might even define a use case as working with customers all day, which could include adding new customers, updating customer records, deleting customers, following up on late-paying customers, or contacting former customers. The first example is too narrow to be useful. Conversely, working with customers all day—the third example—is too broad to be useful. The second example defines a complete user goal, which is the right level of analysis for a use case. EVENT DECOMPOSITION TECHNIQUE •event decomposition technique a technique to identify use cases by determining the business events to which the system must respond. • Elementary business processes (EBPs). An EBP is a task that is performed by one person in one place in response to a business event, adds measurable business value, and leaves the system and its data in a stable and consistent state. • elementary business processes (EBP)the most fundamental task in a business process, which leaves the system and data in a quiescent state; usually performed by one person in response to a business TYPES OF EVENTS • There are three types of events to consider when using the event decomposition technique to identify use cases: external events, temporal events, and state events (also called internal events). EXTERNAL EVENTS • External Events - An external event is an event that occurs outside the system—usually initiated by an external agent or actor. An external agent (or actor) is a person or organizational unit that supplies or receives data from the system. To identify the key external events, the analyst first tries to identify all the external agents that might want something from the system. A classic example of an external agent is a customer. • Another type of external event occurs when external entities provide new information that the system simply needs to store for later use. For example, a regular customer reports a change in address, phone, or employer. Usually, one event for each type of external agent can be described to handle updates to data, such as “Customer needs to update account information.” TEMPORAL EVENTS • A second type of event is a temporal event—an event that occurs as a result of reaching a point in time. Many information systems produce outputs at defined intervals, such as payroll systems that produce a paycheck every two weeks (or each month). Sometimes, the outputs are reports that management wants to receive regularly, such as monthly or weekly performance or exception reports. These events are different from external events in that the system should automatically produce the required output without being told to do so. In other words, no external agent or actor is making demands, but the system is supposed to generate information or other outputs when they are needed. STATE EVENTS • State Events A third type of event is a state event—an event that occurs when something happens inside the system that triggers the need for processing. State events are also called internal events. For example, if the sale of a product results in an adjustment to an inventory record, and the inventory in stock drops below a reorder point, it is necessary to reorder. The state event might be named “Reorder point reached.” Often, state events occur as a consequence of external events. Sometimes, they are similar to temporal events, except the point in time cannot be defined. IDENTIFYING EVENTS • Events Versus Prior Conditions and Responses It is sometimes difficult to distinguish between an event and part of a sequence of prior conditions that leads up to the event. Consider a customer buying a shirt from a retail store. From the customer’s perspective, this purchase involves a long sequence of events. The first event might be that the customer wants to get dressed. Then, the customer wants to wear a striped shirt. Next, the striped shirt appears to be worn out. The customer decides to drive to the mall, and he decides to go into Sears. Then, he tries on a striped shirt. At this point, the customer decides to leave Sears and go to Walmart to try on a • Finally, the customer wants to purchase the shirt. The analyst has to think through such a sequence to arrive at the point where an event directly affects the system. In this case, the system is not affected until the customer is in the store, has a shirt in hand ready to purchase, and says “I want to buy this shirt.”In other situations, it is not easy to distinguish between an external event and the system’s response. For example, when the customer buys the shirt, the system requests a credit card number and then the customer supplies the credit card. Is the act of supplying the credit card an event? In this case, no; it is part of the interaction that occurs while completing the original transaction. THE SEQUENCE OF EVENTS: TRACING A TRANSACTION’S LIFE CYCLE • A useful method for identifying events is to trace the sequence of events that might occur for a specific external agent or actor. In the case of Ridgeline Mountain Outfitters’ new CSMS, the analyst can think through all the possible transactions that might result from one new customer. First, the customer wants a catalog or asks for some information about item availability, resulting in a name and address being added to the database. Then, the customer might want to place an order. Perhaps he or she will want to change the order—for example, correcting the size of the shirt or buying another shirt • Next, the customer might want to check the status of an order to find out the shipping date. Perhaps the customer has moved and wants an address change recorded for future catalog mailings. Finally, the customer might want to return an item. Thinking through this type of sequence can help identify events. TECHNOLOGY-DEPENDENT EVENTS AND SYSTEM CONTROLS Sometimes, the analyst is concerned about events that are important to the system, but do not directly concern users or transactions. Such events typically involve design choices or system controls. During analysis, the analyst should temporarily ignore these events. However, they are important later for design.Some examples of events that affect design issues include external events that refer to the physical system, such as logging on. Although important to the final operation of the system, such implementation details should be deferred. At this stage, the analyst should focus only on the functional requirements (i.e., the work that the system needs to complete). A functional requirements model does not need to indicate how the system is actually implemented, so the model should omit the implementation details. SYSTEM CONTROL • Most of these physical system events involve system controls, which are checks or safety procedures put in place to protect the integrity of the system. For example, logging on to a system is required because of system security controls. Other controls protect the integrity of the database, such as backing up the data every day. These controls are important to the system, and they will certainly be added to the system during design. But spending time on system controls during analysis only adds details to the requirements model that users are not typically very concerned about; they trust the system developers to take care of such details.One way to help decide which events apply to system controls is to assume that technology is perfect. PERFECT TECHNOLOGY ASSUMPTION • The perfect technology assumption states that events should be included during analysis only if the system would be required to respond under perfect conditions (i.e., with equipment never breaking down, capacity for processing and storage being unlimited, and people operating the system being completely honest and never making mistakes). By pretending that technology is perfect, analysts can eliminate events like “Time to back up the database” because they can assume that the disk will never crash. Again, during design, the project team adds these controls because technology is obviously not perfect. Figure 3-8 lists some ex