Creating a Use Case
syrethasqyrner
Satzinger_9781305117204_ch03.pdf
After reading this chapter, you should be able to:
Explain why identifying user stories and use cases is the key to defining functional requirements
Write user stories with acceptance criteria
Describe the two techniques for identifying use cases
Apply the user goal technique to identify use cases
Apply the event decomposition technique to identify use cases
Describe the notation and purpose for the use case diagram
Draw use case diagrams by actor and by subsystem
Learning Objectives
User Stories and Use Cases
Use Cases and the User Goal Technique
Use Cases and Event Decomposition
Use Cases in the Ridgeline Mountain Outfitters Case
chapter OutLine
Identifying User Stories and Use Cases
chapter three
17204_ch03_ptg01_069-092.indd 69 27/11/14 7:42 AM
NOT FOR SALE
70 PART 2 ■ Systems Analysis Activities
■ Overview Chapter 2 described the systems analysis activities used in system develop- ment and introduced the tasks and techniques involved when completing the first analysis activity—gathering information about the system, its stakehold- ers, and its requirements. An extensive amount of information is required to properly define the system’s functional and nonfunctional requirements. This chapter, with Chapter 4 and Chapter 5, presents techniques for documenting
Opening CaSe Waiters on Call Meal-Delivery systeM Waiters on Call is a restaurant meal-delivery service started in 2010 by Sue and Tom Bickford. The Bick- fords worked for restaurants while in college and always dreamed of opening their own restaurant; unfortunately, the initial investment was always out of reach. The Bick- fords noticed that many restaurants offer takeout food, and that some restaurants—primarily pizzerias—offer home-delivery service. However, many people they met seemed to want home delivery with a wider food selection.
Sue and Tom conceived Waiters on Call as the best of both worlds: a restaurant service without the high initial investment. They contracted with a variety of well-known restaurants in town to accept orders from customers and to deliver the complete meals. After pre- paring the meal to order, the restaurant charges Waiters on Call a wholesale price, and the customer pays retail plus a service charge and tip when the meals are deliv- ered. Waiters on Call started modestly, with only two restaurants and one delivery driver working the dinner shift. Business rapidly expanded, until the Bickfords real- ized they needed a custom computer system to support their operations. They hired a consultant, Sam Wells, to help them define what sort of system they needed.
“What events happen when you are running your business that make you want to reach for a computer?” asked Sam. “Tell me about what usually goes on.”
“Well,” answered Sue, “when a customer calls in wanting to order, I need to record it and get the informa- tion to the right restaurant. I need to know which drivers are available to pick up the order, so I need drivers to call in and tell me when they are free. Perhaps this could be included as a smartphone or iPad app. Sometimes, customers call back wanting to change their orders, so I need to find the original order and notify the restaurant to make the change.”
“Okay, that’s great. Now, how do you handle the money?” queried Sam.
Tom jumped in. “The drivers get a copy of the bill showing the retail price directly from the restaurant when they pick up the meal. The bill should agree with our calculations. The drivers collect that amount plus a service charge. When drivers report in at closing, we
add up the money they have and compare it with the records we have. After all drivers report in, we need to create a deposit slip for the bank for the day’s total re- ceipts. At the end of each week, we calculate what we owe each restaurant at the agreed-to wholesale price and send them a statement and check.”
“What other information do you need to get from the system?” continued Sam.
“It would be great to have some information at the end of each week about orders by restaurant and or- ders by area of town—things like that,” Sue said. “That would help us decide about advertising and restaurant contracts. Then, we need monthly statements for our accountant.”
Sam made some notes and sketched some dia- grams as Sue and Tom talked. Then, after spending some time thinking about it, he summarized the situa- tion for Waiters on Call. “It sounds to me like you need a system to use whenever these events occur”:
■ A customer calls in to place an order, so you need to Record an order.
■ A driver is finished with a delivery, so you need to Record delivery completion.
■ A customer calls back to change an order, so you need to Update an order.
■ A driver reports for work, so you need to Sign in the driver.
■ A driver submits the day’s receipts, so you need to Reconcile driver receipts.
Sam continues, “Then, you need the system to produce information at specific points in time—for example, when it is time to,”
■ Produce an end-of-day deposit slip. ■ Produce end-of-week restaurant payments. ■ Produce weekly sales reports. ■ Produce monthly financial reports.
“Am I on the right track?” Sue and Tom quickly agreed that Sam was talking
about the system in a way they could understand. They were confident that they had found the right consultant for the job.
17204_ch03_ptg01_069-092.indd 70 27/11/14 7:42 AM
NOT FOR SALE
71CHAPTER 3 ■ Identifying User Stories and Use Cases
the functional requirements by creating a variety of models. These models are created as part of the analysis activity Define requirements, although remember that the analysis activities are actually done in parallel with design and imple- mentation and in each iteration of the project.
In the Waiters on Call case, Sam Wells is working with the Bickfords to identify the functional requirements for the new system using the event decom- position technique. The sketch he was drawing was a use case diagram. You will learn about this technique and others that help identify user stories and use cases in this chapter.
■ User Stories and Use Cases As you saw in Chapter 1, identifying user stories and use cases is a key task when defining functional requirements because these form the basis for the list of functions the system needs to carry out. Virtually all recent approaches to system development begin the requirements modeling activity with the concept of a user story or a use case. These two concepts are similar in that they focus on the goals of the user, and they show the list of functions at the appropriate level of detail. But they differ in the approach taken to identify them and in the amount of detail that is captured by the analyst. User stories are favored by highly Agile system development methodologies, and they are turned over to the programmer analyst much earlier than use cases are. The programmer analyst designs and codes each user story to discover needed details. The Agile devel- opment philosophy is to work directly with users and avoid doing too much documentation. In contrast, a use case approach traditionally meant analysts complete much documentation for each use case, focusing on detailed steps car- ried out by the user and the system. In practice, use cases can also be very brief for Agile development.
A user story is usually one short sentence in the everyday language of the end user that states what a user does as part of his or her work. In other words, a user story describes a goal the user has when using the system. User stories are a basic concept in Agile development because they focus on simplicity, value added, and user collaboration. They document the functional requirements quickly and less formally than traditional requirements modeling by focusing on who, what, and why for each function. The users and stakehold- ers are responsible for identifying the user stories.
In meetings with stakeholders, analysts encourage participants to write out each user story on an index card or on a shared whiteboard app. The objective is to get a potential user to articulate what he or she wants to do with the new system. A standard template helps users think through what they want and why they want it. The standard template for a user story looks like this:
“As a <role played>, I want to <goal or desire> so that <reason or benefit>.”
For example, some user stories for a bank teller might be:
■ “As a teller, I want to make a deposit to quickly serve more customers.” ■ “As a teller, I want to balance the cash drawer to assure there were no
errors.”
As a customer of the bank using an ATM machine, some user stories might be:
■ “As a bank customer, I want to withdraw cash and feel confident the stack of cash I get is the correct amount.”
■ “As a bank customer, I want to deposit a check and feel confident the deposit is recorded correctly.”
user story one short sentence in the every- day language of the end user that states what a user does as part of his or her work
17204_ch03_ptg01_069-092.indd 71 27/11/14 7:42 AM
NOT FOR SALE
72 PART 2 ■ Systems Analysis Activities
A final part of a user story is the acceptance criteria. These indicate the features that must be present for the user to be satisfied with the resulting imple- mentation. They focus on functionality, not on features or user-interface design. For example, the following are the acceptance criteria for the user story “bank teller making a deposit”:
1. Customer lookup must be by name or by account number. 2. It would be nice to display photo and signature of customer. 3. Any check hold requirements must be indicated. 4. Current balance and new balance must be displayed.
The programmer analyst uses the acceptance criteria to clarify the expec- tations of the user and to verify the user is looking at the user story at an appropriate level of analysis. When the user story is implemented and refined, the acceptance criteria are used for testing. Some consider it much like a con- tract between the developers and the users that limits controversy later in the project. Figure 3-1 shows two user stories handwritten on index cards. The first user story is for the bank teller example just discussed. The other user story is for a shipping clerk responsible for shipping the items on a new order for RMO.
User Story
As a teller, I want to make a deposit to quickly serve more customers.
Acceptance Criteria:
1. Customer lookup must be by name or by account number. 2. Nice to display photo and signature of customer. 3. Any check hold requirements must be indicated. 4. Current balance and new balance must be displayed.
User Story
As a shipping clerk, I want to ship an order as accurately as possible as soon as the order details are available.
Acceptance Criteria:
1. Available order details must pop up on the screen when available. 2. Portable display and scan device would cut time in half. 3. Sort the items by bin location. 4. Indicate number of items in stock for each item and mark backorder for those not available. 5. Recommend shipper based on weight, size, and location. 6. Print out shipping label for selected shipper.
Figure 3-1 Two user stories with acceptance criteria
acceptance criteria features that must be present in the final system for the user to be satisfied
17204_ch03_ptg01_069-092.indd 72 11/27/14 6:18 PM
NOT FOR SALE
73CHAPTER 3 ■ Identifying User Stories and Use Cases
A use case is an activity the system performs in response to a request by a user. In Chapter 1, the RMO Tradeshow System example had a list of uses that included Look up supplier, Enter/update product information, and Look up product information. Two techniques are recommended for identifying use cases: the user goal technique and the event decomposition technique. Use case techniques place the responsibility for identifying and detailing the require- ments on the system developers. The developers typically interview all types of users and stakeholders, and then make and refine notes about each use case. Some of the more complex use cases are modeled in more detail by the develop- ers before turning the uses cases over to the programmer analysts for design and implementation.
■ Use Cases and the User Goal Technique “User stories will help analysts identify and define use cases, which are the pri- mary focus of this chapter.”
One approach to identifying use cases, called the user goal technique, is to ask users to describe their goals for using the new or updated system. The analyst first identifies all the users, categorizes them by user type, and then con- ducts a structured interview with each user. By focusing on one type of user at a time, the analyst can systematically address the problem of identifying use cases.
During the interview, the analyst guides the user to identify specific ways the computer system could help the user perform his or her assigned tasks. The overarching objective is to identify what the system could do to improve the user’s performance and productivity. Subsidiary goals might include streamlin- ing tasks the user currently performs, or enabling the user to perform new tasks that are not possible or practical with the current system. As these goals are uncovered and described, the analyst probes for specific requests from the user and desired responses from the proposed system, which the analyst documents as use cases. Although the users are the ultimate source of this information, they often require guidance from the analyst to think beyond the boundaries of the ways they currently approach their jobs.
Consider various user goals for the RMO Consolidated Sales and Marketing System (CSMS) introduced in Chapter 2. In an example like this, the analyst might talk to the people in the Shipping Department to identify their specific goals. These might include: Ship items, Track shipment, and Create item return. The Marketing Department might identify goals like Add/update product information, Add/update promotion, and Produce sales history report. When considering the goals of the prospective customer, the analyst might ask RMO users from different departments to think about the system from the customer’s viewpoint and to imagine the value-added features and functions that would make RMO appealing and useful. Additionally, focus groups of actual customers might be formed to pinpoint their wants and needs. Goals identified for potential customers might include Search for item, Fill shopping cart, and View product rating and comments. Figure 3-2 lists a few of the user goals for potential users of the CSMS. Note that for the Shipping personnel, there is a use case named Ship order, which corresponds to the same user story identified in Figure 3-1.
The user goal technique for identifying use cases includes these steps:
1. Identify all the potential users for the new system. 2. Classify the potential users in terms of their functional role (e.g., shipping,
marketing, sales). 3. Further classify potential users by organizational level (e.g., operational,
management, executive).
use case an activity that the system performs in response to a request by a user
user goal technique a technique to identify use cases by determining what specific goals or objectives must be completed by the system for the user
17204_ch03_ptg01_069-092.indd 73 27/11/14 7:42 AM
NOT FOR SALE
74 PART 2 ■ Systems Analysis Activities
4. Interview each type of user to determine the specific goals they will have when using the new system. Start with goals they currently have and then get them to imagine innovative functions they think would add value. Encourage them to state each goal in the imperative verb-noun form, such as Add customer, Update order, and Produce month-end report.
5. Create a list of preliminary use cases organized by type of user. 6. Look for duplicates with similar use case names and resolve inconsistencies. 7. Identify where different types of users need the same use cases. 8. Review the completed list with each type of user and then with interested
stakeholders.
■ Use Cases and Event Decomposition The most comprehensive technique for identifying use cases is the event decom- position technique. The event decomposition technique begins by identify- ing 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 iden- tify 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 ana- lyst 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.
The appropriate level of detail for identifying use cases is one that focuses on 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. In Figure 3-2, the RMO CSMS potential customer use cases Search for item, Fill shopping cart, and View product rating and comments are good examples of elementary business processes. Fill shopping cart is a response to the business event “Customer wants to shop.” There is one person filling the cart, and there is measurable value for the customer as items are added to the cart. When the customer stops adding items and moves to another task, the system remembers the current cart and is ready to switch to the new task.
Note that each EBP (and thus each use case) occurs in response to a busi- ness event. An event occurs at a specific time and place, can be described, and should be remembered by the system. Events drive or trigger all processing that a system does, so listing events and analyzing them makes sense when you need to define system requirements by identifying use cases.
User User goal and resulting use case
Potential customer Search for item Fill shopping cart View product rating and comments
Marketing manager Add/update product information Add/update promotion Produce sales history report
Shipping personnel Ship order Track shipment Create item return
FIgure 3-2 Identifying use cases with the user goal technique
event decomposition technique a tech- nique to identify use cases by determining the business events to which the system must respond
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 event
event something that occurs at a specific time and place, can be precisely identified, and must be remembered by the system
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 74 27/11/14 7:42 AM
NOT FOR SALE
75CHAPTER 3 ■ Identifying User Stories and Use Cases
■ Event Decomposition Technique When defining the requirements for a system, it is useful to begin by asking, “What business events occur that will require the system to respond?” By asking about the events that affect the system, you direct your attention to the external environment and look at the system as a black box. This means you don’t see the underlying functions, just the input and results. This initial perspective helps keep your focus on a high-level view of the system (looking at the scope), rather than on the inner workings of the system. It also focuses your attention on the system’s interfaces with outside people and other systems.
Some events that are important to a retail store’s charge account processing system are shown in Figure 3-3. The functional requirements are defined by use cases based on six events. A customer triggers three events: “customer pays a bill,” “customer makes a charge,” and “customer changes address.” The system responds with three use cases: Record a payment, Process a charge, or Maintain customer data. Three other events are triggered inside the system by reaching a point in time: “time to send out monthly statements,” “time to send late notices,” and “time to produce end-of-week summary reports.” The system responds with use cases that carry out what it is time to do: Produce monthly statements, Send late notices, and Produce summary reports. Describing this system in terms of events keeps the focus of the charge account system on the business requirements and the elementary business processes. The result is a list of use cases triggered by business events at the right level of analysis.
Using events to define functional requirements was first emphasized for real-time systems in the early 1980s. Real-time systems must react immediately
Charge account processing system
FIgure 3-3 Events in a charge account processing system that lead to use cases
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 75 27/11/14 7:42 AM
NOT FOR SALE
76 PART 2 ■ Systems Analysis Activities
to events in the environment. Early real-time systems include manufacturing process control systems and avionics guidance systems. For example, in process control, if a vat of chemicals is full, then the system needs to Turn off the fill valve. The relevant event is “vat is full,” and the system needs to respond to that event immediately. In an airplane guidance system, if the plane’s altitude drops below 5,000 feet, then the system needs to Turn on the low-altitude alarm.
Most information systems now being developed are so interactive that they can be thought of as real-time systems. In fact, people expect a real-time response to almost everything. Thus, use cases for business systems are often identified by using the event decomposition technique.
■ Types of Events There are three types of events to consider when using the event decomposi- tion technique to identify use cases: external events, temporal events, and state events (also called internal events). The analyst begins by trying to identify and list as many of these events as possible, refining the list while talking with system users.
❚ 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 orga- nizational 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. The customer may want to place an order for one or more products. This event is of fundamental importance to an order-processing system, such as the one needed by Ridgeline Mountain Outfitters. But other events are associ- ated with a customer. Sometimes, a customer wants to return an ordered prod- uct, or a customer needs to pay the invoice for an order. External events such as these define what the system needs to be able to do. They are events that lead to important transactions that the system must process.
When describing external events, it is important to name the event so the external agent is clearly defined. The description should also include the action that the external agent wants to pursue. Thus, the event “Customer places an order” describes the external agent (a customer) and the action that the customer wants to take (to place an order for some products) that directly affects the system.
Important external events can also result from the wants and needs of peo- ple or organizational units inside the company (e.g., management requests for information). A typical event in an order-processing system might be “Manage- ment wants to check order status.” Perhaps managers want to follow up on an order for a key customer; the system must routinely provide that information.
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.” Figure 3-4 provides a checklist to help in identifying external events.
external event an event that occurs outside the system, usually initiated by an external agent
actor an external agent; a person, group or external system that interacts with the system by supplying or receiving data
External events to look for include:
√ External agent wants something resulting in a transaction √ External agent wants some information √ Data changed and needs to be updated √ Management wants some information
FIgure 3-4 External event checklist
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 76 27/11/14 7:42 AM
NOT FOR SALE
77CHAPTER 3 ■ Identifying User Stories and Use Cases
❚ 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 excep- tion 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.
The analyst begins identifying temporal events by asking about specific deadlines that the system must accommodate. What outputs are produced at that deadline? What other processing might be required at that deadline? In a payroll system, a temporal event might be named “Time to produce biweekly payroll.” The event defining the need for a monthly summary report might be named “Time to produce monthly sales summary report.” Figure 3-5 provides a checklist to use in identifying temporal events.
Temporal events do not have to occur on a fixed date. They can occur after a defined period of time has elapsed. For example, a bill might be given to a cus- tomer when a sale has occurred. If the bill has not been paid within 15 days, the system might send a late notice. The temporal event “Time to send late notice” might be defined as a point 15 days after the billing date.
❚ State Events A third type of event is a state event—an event that occurs when something hap- pens 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 Defining the events that affect a system is not always easy, but some guidelines can help an analyst think through the process.
❚ 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 (see Figure 3-6). 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
Temporal events to look for include:
√ Internal outputs needed √ Management reports (summary or exception) √ Operational reports (detailed transactions) √ Internal statements and documents (including payroll) √ External outputs needed √ Statements, status reports, bills, reminders
FIgure 3-5 Temporal event checklist
temporal event an event that occurs as a result of reaching a point in time
state event an event that occurs when something happens inside the system that triggers some process
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 77 27/11/14 7:42 AM
NOT FOR SALE
78 PART 2 ■ Systems Analysis Activities
shirt. 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 way to determine whether an occurrence is an event or whether it is part of the interaction following the event is by asking if any long pauses or intervals occur (i.e., can the system transaction be completed without interrup- tion?). Or is the system at rest again, waiting for the next transaction? After the customer wants to buy the shirt (the event), the process continues until the trans- action is complete. There are no significant stops after the transaction begins. After the transaction is complete, the system is at rest, waiting for the next transaction to begin. The EBP concept defined earlier describes this as leaving the system and its data in a consistent state. On the other hand, separate events occur when the customer buys the shirt by using his store credit card account. When the customer pays the bill at the end of the month, is the processing part of the interaction involving the purchase? In this case, no; the system records the transaction and then does other things. It does not halt all processes to wait for the payment. A separate event occurs later that results in sending the customer a bill. (This is a temporal event: “Time to send monthly bills.”) Eventually, another external event occurs (“Customer pays the bill”).
❚ 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 (see Figure 3-7). First, the customer wants a catalog or asks for some information about item avail- ability, 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.
Customer thinks about getting a
new shirt
Customer drives to the mall
Customer tries on a shirt at Sears
Customer goes to Walmart
Customer tries on a shirt at Walmart
Customer buys a shirt
FIgure 3-6 Sequence of actions that lead up to only one event affecting the system
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 78 27/11/14 7:42 AM
NOT FOR SALE
79CHAPTER 3 ■ Identifying User Stories and Use Cases
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 sys- tem, 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.
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. 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 examples of events that can be deferred until the developer is designing in system controls.
Customer requests a catalog
Customer wants to check item availability
Customer places an order
Customer changes or cancels an order
Customer wants to check order status
Customer updates account information
Customer returns the item
FIgure 3-7 The sequence of “transactions” for one specific customer resulting in many events
system controls checks or safety proce- dures to protect the integrity of the system and the data
perfect technology assumption the assumption that a system runs under perfect operating and technological conditions
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 79 27/11/14 7:42 AM
NOT FOR SALE
80 PART 2 ■ Systems Analysis Activities
■ Steps in the Event Decomposition Technique To summarize, the event decomposition technique for identifying use cases includes these steps:
1. Consider the external events in the system environment that require a response from the system by using the checklist shown in Figure 3-4.
2. For each external event, identify and name the use case that the system requires.
3. Consider the temporal events that require a response from the system by using the checklist shown in Figure 3-5.
4. For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case.
5. Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases.
6. For each state event, identify and name the use case that the system requires and then define the state change.
7. When events and use cases are defined, check to see if they are required as part of analysis by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in as system controls.
■ Use Cases in the Ridgeline Mountain Outfitters Case
The RMO CSMS involves a variety of use cases, many of them just discussed. The analysts working on the new system have used all three techniques for identifying, validating, and refining use cases. The initial system vision (dis- cussed in Chapter 2) identified four subsystems: the Sales subsystem, the Order Fulfillment subsystem, the Customer Account subsystem, and the Marketing subsystem. As work progressed, the analysts combined reports required by each subsystem into a fifth subsystem called the Reporting subsystem. In a system this size, the analyst should organize the use cases by subsystem to help track
User wants to log on to the system
User wants to change the password
User wants to change preference settings
System crash requires database
recovery
Time to back up the database
Time to require the user to change the
password
Don’t worry much about these until you are
considering design issues
FIgure 3-8 Events deferred until designing system controls
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 80 27/11/14 7:42 AM
NOT FOR SALE
81CHAPTER 3 ■ Identifying User Stories and Use Cases
which subsystem is responsible for each use case. The analyst should also iden- tify which use cases involve more than one type of user.
It is important to recognize that this list of uses cases will continue to evolve as the project progresses. Additional use cases will be added, some might be eliminated, and some might be combined. It is helpful to immediately describe some of the details of each use case, preferably in one sentence. This brief description is usually expanded to record more of the details when the develop- ers are designing and implementing the use case (see Chapter 5). Some exam- ples of brief use case descriptions are shown in Figure 3-9. Figures 3-10a through 3-10e show the initial list of use cases for the RMO CSMS along with the users. Note that many use cases have more than one user.
Sometimes, it is useful to create diagrams that visually depict use cases and how they are organized. The use case diagram is the UML model used to illustrate use cases and their relationship to users. Recall from Chapter 2 that Unified Modeling Language (UML) is the standard set of diagrams and model constructs used in system development. You saw an example of a use case dia- gram in Chapter 1. The notation is fairly simple.
■ Use Cases, Actors, and Use Case Diagram Notation Implied in most use cases is a person who uses the system, whom we have referred to up to this point as the user. In UML, that person is called an actor. An actor is always outside the automation boundary of the system but may be part of the manual portion of the system. Sometimes, the actor for a use case is not a person; instead, it can be another system or device that receives services from the system.
Figure 3-11 shows the basic parts of a use case diagram. A simple stick figure represents an actor. The stick figure is given a name that characterizes the role the actor is playing. The use case itself is represented by an oval with the name of the use case inside. The connecting line between the actor and the use case indicates that the actor is involved with that use case. Finally, the automation boundary, which defines the border between the computerized portion of the application and the people operating the application, is shown as a rectangle containing the use case. The actor’s communication with the use case crosses the automation boundary. The example in Figure 3-11 shows the actor as a shipping clerk and the use case Ship items.
❚ Use Case Diagram Examples Figure 3-12 shows a more complete use case diagram for a subsystem of the RMO CSMS: the Customer Account subsystem. The information in Figure 3-10c is recast as a single use case diagram to visually highlight the uses cases and actors for an individual subsystem. In this example, the customer, customer service representative, and store sales representative are all allowed to access the system directly. As indicated by the relationship lines, each actor can access the use case Create/update customer account. The customer might do
Use case
Create customer account
Look up customer
Process account adjustment
Brief use case description
User/actor enters new customer account data, and the system assigns account number, creates a customer record, and creates an account record.
User/actor enters customer account number, and the system retrieves and displays customer and account data.
User/actor enters order number, and the system retrieves customer and order data; actor enters adjustment amount, and the system creates a transaction record for the adjustment.
FIgure 3-9 Use cases and brief descriptions
brief use case description an often one-sentence description that provides a quick overview of a use case
use case diagram the UML model used to illustrate use cases and their relationships to actors
automation boundary the boundary between the computerized portion of the application and the users who operate the application but are part of the total system
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 81 27/11/14 7:42 AM
NOT FOR SALE
82 PART 2 ■ Systems Analysis Activities
CSMS Sales Subsystem
Use cases Users/actors
Search for item Customer, customer service representative, store sales representative
View product comments and ratings Customer, customer service representative, store sales representative
View accessory combinations Customer, customer service representative, store sales representative
Fill shopping cart
Customer
Customer
CustomerEmpty shopping cart
Check out shopping cart
CustomerFill reserve cart
CustomerEmpty reserve cart
Convert reserve cart Customer
Store sales representative
Customer service representativeCreate phone sale
Create store sale
CSMS Order Fulfillment Subsystem
Use cases Users/actors
Ship items Shipping
Manage shippers Shipping
Create backorder Shipping
Create item return
Shipping, customer, marketing
Shipping, customer
Shipping, customer, management Look up order status
Track shipment
CustomerRate and comment on product
CustomerProvide suggestion
Review suggestions Management
FIgure 3-10a Use cases and actors for CSMS Sales Subsystem
FIgure 3-10b Use cases and actors for CSMS Order Fulfillment Subsystem
© C
en ga
ge L
ea rn
in g®
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 82 27/11/14 7:42 AM
NOT FOR SALE
83CHAPTER 3 ■ Identifying User Stories and Use Cases
CSMS Customer Account Subsystem
Use cases Users/actors
Create/update customer account Customer, customer service representative, store sales representative
Process account adjustment Management
Send message Customer
Browse messages
Customer
Customer
CustomerRequest friend linkup
Reply to linkup request
CustomerSend/receive partner credits
CustomerView “mountain bucks”
CustomerTransfer “mountain bucks”
CSMS Marketing Subsystem
Use cases Users/actors
Add/update product information Merchandising, marketing
Add/update promotion Marketing
Add/update accessory package Merchandising
Add/update business partner link Marketing
CSMS Reporting Subsystem
Use cases Users/actors
Produce daily transaction summary report
Management
Produce sales history report Management, marketing
Produce sales trends report Marketing
Produce customer usage report Marketing
Produce shipment history report Management, shipping
Produce promotion impact report Marketing
Produce promotional partner activity report
Management, marketing
FIgure 3-10e Use cases and actors for CSMS Reporting Subsystem
FIgure 3-10c Use cases and actors for CSMS Customer Account Subsystem
FIgure 3-10d Use cases and actors for CSMS Marketing Subsystem
© C
en ga
ge L
ea rn
in g®
© C
en ga
ge L
ea rn
in g®
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 83 27/11/14 7:42 AM
NOT FOR SALE
84 PART 2 ■ Systems Analysis Activities
Actor is a stick figure, usually meaning an
actual person using the system
Automation boundary
Ship items
Shipping clerk
Connecting line to show which
actors participate in use cases
FIgure 3-11 A simple use case with an actor
Create/update customer account
Customer Account Subsystem All Actors
Process account adjustment
Send message
Browse messages
Request friend linkup
Reply to friend linkup
Send/receive partner credits
View "mountain bucks"
Transfer "mountain bucks"
Customer Store sales representative
Management
Customer service representative
FIgure 3-12 A use case diagram of the Customer Account subsystem for RMO, showing all actors
© C
en ga
ge L
ea rn
in g®
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 84 27/11/14 7:42 AM
NOT FOR SALE
85CHAPTER 3 ■ Identifying User Stories and Use Cases
this when checking out online. The customer service representative might do this when talking to a customer on the phone. The store sales representative might do this when dealing with the customer in a store. Only a member of manage- ment can process an account adjustment. The other use cases are included only for the customer.
There are many ways to organize use case diagrams for communicating with users, stakeholders, and project team members. One way is to show all use cases invoked by a particular actor (i.e., from the user’s viewpoint). This approach is often used during requirements definition because the systems analyst may be working with a particular user and identifying all the functions that user per- forms with the system. Figure 3-13 illustrates this viewpoint, showing all the use cases involving the customer for the Sales subsystem. Figure 3-14 shows use cases involving the customer service representative and the store sales represen- tative for the Sales subsystem. Analysts can expand this approach to include all the use cases invoked by any department, regardless of the subsystem, or all use cases important to a specific stakeholder.
❚ «includes» Relationships Frequently during the development of a use case diagram, it becomes apparent that one use case might use the services of another use case. For example, in the Sales subsystem use case diagram shown in Figure 3-14, the customer might search
Search for item
Sales Subsystem Actor: Customer
Fill reserve cart
Empty reserve cart
Empty shopping cart
View product comments and
ratings
View accessory combinations
Check out shopping cart
Fill shopping cart
Convert reserve cart
Customer
FIgure 3-13 All use cases involving the customer actor for the Sales subsystem
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 85 27/11/14 7:42 AM
NOT FOR SALE
86 PART 2 ■ Systems Analysis Activities
for an item, view product comments and ratings, and view accessory combina- tions before beginning to fill the shopping cart. However, while filling the shop- ping cart, the customer might also search for an item, view product comments, and view accessories. Therefore, one use case uses, or “includes,” another use case. Figure 3-15 shows a use case diagram emphasizing this aspect of use cases.
Customer
Search for item
Fill shopping cart View product
comments and ratings
View accessory combinations
Sales Subsystem Fill Shopping Cart <<includes>> Relationships
«includes»
«includes»
«includes»
FIgure 3-15 A use case diagram of the Fill shopping cart «includes» relationships
Sales Subsystem Actors: Service Representative and Store Representative
Customer service representative
Store sales representative
View product comments and
ratings
View accessory combinations
Create phone sale
Search for item
Create store sale
FIgure 3-14 Use cases involving the customer service representative and store sales representative for the Sales subsystem
© C
en ga
ge L
ea rn
in g®
© C
en ga
ge L
ea rn
in g®
17204_ch03_ptg01_069-092.indd 86 27/11/14 7:42 AM
NOT FOR SALE
87CHAPTER 3 ■ Identifying User Stories and Use Cases
Fill shopping cart also includes Search for item, View product comments and ratings, and View accessory combinations. Thus, the Customer can view com- ments initially, and also while carrying out the Fill shopping cart use case. The relationship between these use cases is denoted by the dashed connecting line with the arrow that points to the use case that is included. The relationship is read Fill shopping cart includes Search for item. Sometimes, this relationship is referred to as the «includes» relationship or the «uses» relationship. Note that the word includes is enclosed within guillemets in the diagram; this is the way to refer to a stereotype in UML. It means that the relationship between one use case and another use case is a stereotypical «includes» relationship.
■ Developing a Use Case Diagram Analysts create a variety of use case diagrams to communicate with users, stakeholders, management, and team members. The steps to develop use case diagrams are:
1. Identify all the stakeholders and users who would benefit by having a use case diagram.
2. Determine what each stakeholder or user needs to review in a use case dia- gram. Typically, a use case diagram might be produced for each subsystem, for each type of user, for use cases with the «includes» relationship, and for use cases that are of interest to specific stakeholders.
3. For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams.
4. Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users.
«includes» relationship a relationship between use cases in which one use case is stereotypically included within the other use case
CHAPTER SUMMaRy This chapter is the first of three chapters that present techniques for modeling a system’s functional require- ments. A key early step in the modeling process is to identify and list the user stories or use cases that de- fine the functional requirements for the system. User stories are written by end users and stakeholders dur- ing requirements meetings with the developers. They are used with most highly Agile development meth- odologies. Use cases are very similar to user stories, but they are often modeled in more detail than user stories and are the responsibility of the developers. Use cases can be identified by using the user goal technique and the event decomposition technique. The user goal technique initially identifies types of system end us- ers, called actors. Then, users are asked to list specific user goals they have when using the system to support their work. The event decomposition technique ini- tially identifies events that require a response from the
system. An event is something that can be described, something that occurs at a specific time and place, and something worth remembering. External events occur outside the system—usually triggered by someone who interacts with the system. Temporal events occur at a defined point in time, such as the end of a work day or the end of every month. State or internal events occur based on an internal system change. For each event, a use case is identified and named. The event decom- position technique helps ensure that each use case is identified at the elementary business process (EBP) level of detail. Each use case identified by the analyst is further documented by a brief use case description and by identifying the actors. UML use case diagrams are drawn to document use cases and their actors. Many different use case diagrams are drawn based on the need to review use cases with various stakeholders, users, and team members.
17204_ch03_ptg01_069-092.indd 87 27/11/14 7:42 AM
NOT FOR SALE
88 PART 2 ■ Systems Analysis Activities
event
event decomposition technique
external event
«includes» relationship
perfect technology assumption
state event
system controls
temporal event
use case
use case diagram
user goal technique
user story
acceptance criteria
actor
automation boundary
brief use case description
elementary business process (EBP)
KEy TERMS
1. What are the five activities of systems analysis, and which activity is discussed beginning with this chapter?
2. What is a user story? What is a use case?
3. What are the two techniques used to identify use cases?
4. Describe the user goal technique for identifying use cases.
5. What are some examples of users with different functional roles and at different operational levels?
6. What are some examples of use case names that correspond to your goals as a student going through the college registration process? Be sure to use the verb-noun naming convention.
7. What is the overarching objective of asking users about their specific goals?
8. How many types of users can have the same user goals for using the system?
9. Describe the event decomposition technique for identifying use cases.
10. Why is the event decomposition technique considered more comprehensive than the user goal technique?
11. What is an elementary business process (EBP)?
12. Explain how the event decomposition technique helps identify use cases at the right level of analysis.
13. What is an event?
14. What are the three types of events?
15. Define an external event and give an example that applies to a checking account system.
16. Define a temporal event and give an example that applies to a checking account system.
17. What are system controls, and why are they not considered part of the users’ functional requirements?
18. What is the perfect technology assumption?
19. What are three examples of events that involve system controls that should not be included initial- ly because of the perfect technology assumption?
20. What is a brief use case description?
21. What is UML?
22. What is the purpose of UML use case diagrams?
23. What is another name for “actor” in UML, and how is it represented on a use case diagram?
24. What is the automation boundary on a use case diagram, and how is it represented?
25. How many actors can be related to a use case on a use case diagram?
26. Why might a systems analyst draw many differ- ent use case diagrams when reviewing use cases with end users?
27. What is the «includes» relationship between two use cases?
REvIEW QUESTiOnS
PROBlEMS AnD ExERCiSES 1. Consider the situation where a student
organization is exploring its requirements for a system that manages its membership and finances. Based on what you know about stu- dent organizations, write user stories using the
standard template for the following potential users: membership director, finance director, faculty advisor. Add acceptance criteria for each user story based on how you imagine the system might work.
17204_ch03_ptg01_069-092.indd 88 27/11/14 7:42 AM
NOT FOR SALE
89CHAPTER 3 ■ Identifying User Stories and Use Cases
2. Review the external event checklist in Figure 3-4 and then think about a university course registra- tion system. What is an example of an event of each type in the checklist? Name each event by using the guidelines for naming an external event.
3. Review the temporal event checklist in Figure 3-5. Would a student grade report be an internal or external output? Would a class list for the instruc- tor be an internal or external output? What are some other internal and external outputs for a course registration system? Using the guidelines for naming temporal events, what would you name the events that trigger these outputs?
4. Consider the following sequence of actions taken by a customer at a bank. Which action is the event the analyst should define for a bank ac- count transaction processing system? (1) Kevin gets a check from Grandma for his birthday. (2) Kevin wants a car. (3) Kevin decides to save his money. (4) Kevin goes to the bank. (5) Kevin waits in line. (6) Kevin makes a deposit in his sav- ings account. (7) Kevin grabs the deposit receipt. (8) Kevin asks for a brochure on auto loans.
5. Consider the perfect technology assumption, which states that use cases should be included during analysis only if the system would be required to respond under perfect conditions. Could any of the use cases listed for the RMO CSMS be eliminated based on this assumption? Explain. Why are such use cases as Log on to the system and Back up the database required only under imperfect conditions?
6. Visit some Web sites of car manufacturers, such as Honda, BMW, Toyota, and Acura. Many of these sites have a use case that is typically named Build and price a car. As a potential customer, you can select a car model, select features and options, and get the car’s suggested price and list of specifications. Write a brief use case descrip- tion for this use case (see Figure 3-9).
7. Again looking at a Web site for one of the car manufacturers, consider yourself a potential buyer and then identify all the use cases included on the site that correspond to your goals.
8. Set up a meeting with a librarian. During your meeting, ask the librarian to describe the situ- ations that the book checkout system needs to respond to. List these external events. Now ask about points in time, or deadlines, that require the system to produce a statement, notice, report, or other output. List these temporal events. Does it seem natural for the librarian to describe the system in this way? List each event and then name the resulting use case.
9. Again considering the library, ask some students what their goals are in using the library system. Also ask some library employees about their goals in using the system. Name these goals as use cases (verb-noun) and discuss whether student users have different goals than employee users.
10. Visit a restaurant or the college food service to talk to a server (or talk with a friend who is a food server). Ask about the external events and temporal events, as you did in exercise 8. What are the events and resulting use cases for order processing at a restaurant?
11. Review the procedures for course registration at your university and then talk with the staff in advising, in registration, and in your major department. Think about the sequence that goes on over an entire semester. What are the events that students trigger? What are the events that your own department triggers? What are the temporal events that result in information going to students? What are the temporal events that result in information going to instructors or departments? List all the events and the resulting use cases that should be included in the system.
12. Refer to the RMO CSMS Order Fulfillment subsys- tem shown in Figure 3-10. Draw a use case diagram that shows all actors and all use cases. Use a draw- ing tool such as Microsoft Visio if it is available.
13. Again for the Order Fulfillment subsystem, draw a use case diagram showing just the use cases for the Shipping Department in preparation for a meeting with them about the system require- ments. Use a drawing tool such as Microsoft Visio if it is available.
14. Refer to the RMO CSMS Marketing subsystem shown in Figure 3-10. Draw a use case diagram that shows all actors and all use cases. Use a draw- ing tool such as Microsoft Visio if it is available.
15. Refer to the RMO CSMS Reporting subsystem shown in Figure 3-10. These reports were iden- tified by asking users about temporal events, meaning points in time that require the system to produce information of value. In most actual systems today, an actor is assigned responsibil- ity for producing the reports or other outputs when they are due. Recall that the actor is part of the system—the manual, nonautomated part. Thus, this is one way the “system” can be responsible for producing an output at a point in time. In the future, more outputs will be pro- duced automatically. Draw a use case diagram that shows the use cases and actors, as shown in Figure 3-10. Use a drawing tool such as Micro- soft Visio if it is available.
17204_ch03_ptg01_069-092.indd 89 27/11/14 7:42 AM
NOT FOR SALE
90 PART 2 ■ Systems Analysis Activities
The State Patrol Ticket-Processing System The purpose of the State Patrol ticket-processing system is to record moving violations, keep records of the fines paid by drivers when they plead guilty or are found guilty of moving violations, and notify the court that a warrant for arrest should be issued when such fines are not paid in a timely manner. A separate State Patrol system records accidents and the verification of financial responsibility (insurance). But a third system uses ticket and accident records to produce driving record reports for insurance companies. Finally, a fourth sys- tem issues, renews, or suspends driver’s licenses. These four systems are obviously integrated, in that they share ac- cess to the same database; otherwise, they are operated separately by different departments of the State Patrol.
When an officer gives a ticket to a driver, a copy of the ticket is turned in and entered into the system. A new ticket record is created, and relationships to the correct driver, officer, and court are established in the database. If the driver pleads guilty, he or she mails in the fine in a preprinted envelope with the ticket number on it. In some cases, the driver claims innocence and wants a court date. When the envelope is returned without a check and the trial request box has an “X” in it, the system does the following: notes the plea on the ticket record; looks up driver, ticket, and officer information; and sends a ticket details report to the appropriate court. A trial date questionnaire form is also produced at the same time and is mailed to the driver. The instructions on the questionnaire tell the driver to fill in convenient dates and mail the questionnaire directly to the court. Upon receiving this information, the court schedules a trial date and notifies the driver of the date and time.
When the trial is completed, the court sends the verdict to the ticketing system. The verdict and trial date are recorded for the ticket. If the verdict is innocent, the system that produces driving record reports for insurance companies will ignore the ticket. If the verdict is guilty, the court gives the driver another envelope with the ticket number on it for mailing in the fine.
If the driver fails to pay the fine within the required period, the ticket-processing system produces a warrant request notice and sends it to the court. This happens if the driver does not return the original envelope within two weeks, or does not return the court-supplied envelope within two weeks of the trial date. What happens next is in the hands of the court. Sometimes, the court requests that the driver’s license be suspended, and the system that processes driver’s licenses handles the suspension.
1. To what events must the ticket-processing system respond? List each event, the type of event, the resulting use case, and the actor(s). Think carefully about who the actors are. Does the officer directly enter the ticket into the system? Or does a state pa- trol clerk do it when the paper ticket is received from the officer? The existing system uses paper forms, so for now assume the state patrol clerk enters all of the information. A new system would use the same use cases, but opportunities for efficiency and accuracy would lead to changes in who the actors are.
2. Write a brief use case description for each use case. 3. Draw a use case diagram for the ticket-processing
system assuming the actors are based on your answers in question 1 (the existing system as described).
CASE STUDY
Community Board of Realtors®
One of the functions of the Board of Realtors intro- duced in Chapter 2 is to provide a Multiple Listing Service (MLS) system that supplies information that local real estate agents use to help them sell houses to their customers. Agents list houses for sale (listings) by contracting with homeowners. The agent works for a real estate office, which sends information on the
listing to the MLS. Therefore, any agent in the com- munity can get information on the listing.
The MLS systems include lots of information on a listing. It is now common to include dozens of pho- tos, video tours, Google map information, prior sales, and so forth. For now, let’s keep it simple and assume a listing includes the address, year built, square feet,
Running CaSe STudieS
17204_ch03_ptg01_069-092.indd 90 11/27/14 6:18 PM
NOT FOR SALE
91CHAPTER 3 ■ Identifying User Stories and Use Cases
number of bedrooms, number of bathrooms, owner name, owner phone number, asking price, and status code. An agent will directly request information from the MLS system on listings that match customer re- quirements. Information is provided on the house, on the agent who listed the house, and on the real estate office for which the agent works. This information is needed because an agent might want to call the listing agent to ask additional questions or call the homeowner directly to make an appointment to show the house. Although it seems dated, once each week, the MLS produces a listing booklet that contains information on all listings. These booklets are sent to some real es- tate agents because many think they are easier to flip
through and write on. Sometimes, agents and owners decide to change information about a listing, such as re- ducing the price, correcting previous information on the house, or indicating that the house is sold. The agent updates the information directly on the MLS system.
1. To what events must the MLS system respond based on the description above? List each event, the type of event, and the resulting use case. Be sure to consider all the use cases that would be needed to maintain the data in the MLS system.
2. Draw a use case diagram based on the use cases you identified in question 1. Include appropriate actors based on the case description.
The Spring Breaks ‘R’ Us Travel Service Spring Breaks ‘R’ Us (SBRU), introduced in Chapter 2, includes many use cases that make up the functional requirements. Consider the following description of the Booking subsystem. A few weeks before Thanksgiving break, it is time to open the system to new bookings. Students usually want to browse through the resorts and do some planning. When a student or group of students wants to book a trip, the system allows it. Sometimes, a student needs to be added or dropped from the group or a group changes size and needs a different type of room. One month before the actual trip, it is time for the system to send out final payment requirement notices. Students cancel the booking or they pay their final bills. Students often want to look up their booking status and check on resort details. When they arrive at the resort, they need to check in; and when they leave, they need to check out.
1. Using the event decomposition technique for each event you identify in the description here, name the event, state the type of event, and name the resulting use case. Draw a use case diagram for these use cases.
2. Consider the new Social Networking subsystem that SBRU is researching that was described in Chapter 2. Think in terms of the user goal technique to identify as many use cases as you can think of that you would like to have in the system. SBRU is guessing you might want to join, send messages, and so forth, but there must be many interesting and useful things the system could do before, during, and after the trip. Draw a use case diagram for these use cases.
On the Spot Courier Services Recall the On the Spot courier service introduced in Chapter 2. The details of the package pickup and delivery process are described here.
When Bill got an order, only on his phone at first, he recorded when he received the call and when the shipment would be ready for pickup. Sometimes, cus- tomers wanted immediate pickup; sometimes, they were calling to schedule a later time in the day for pickup.
Once he arrived at the pickup location, Bill collected the packages. It was not uncommon for the customer to have several packages for delivery. In addition to the name and address of the delivery location, he also recorded the time of pickup. He noted the desired delivery time, the location of the delivery, and the weight of the package to determine the courier cost. When he picked up the package, he
printed out a label with his portable printer that he kept in the delivery van.
At first, Bill required customers to pay at the time of pickup, but he soon discovered that there were some regular customers who preferred to receive a monthly bill for all their shipments. He wanted to be able to ac- commodate those customers. Bills were due and pay- able upon receipt.
To help keep track of all the packages, Bill de- cided that he needed to scan each package as it was sorted in the warehouse. This would enable him to keep good control of his packages and avoid loss or delays.
The delivery of a package was fairly simple. Upon delivery, he would record information about when the delivery was made and who received it. Because some of the packages were valuable, it was necessary in
17204_ch03_ptg01_069-092.indd 91 27/11/14 7:42 AM
NOT FOR SALE
92 PART 2 ■ Systems Analysis Activities
those instances to have someone sign for the package upon delivery.
1. From this description as well as the information from Chapter 2, identify all the actors who will be using the system.
2. Using the actors who you identified in question 1, develop a list of use cases based on the user goal
technique. Draw a use case diagram for these use cases.
3. Using the event decomposition technique for each event you identify in the description here, name the event, state the type of event, and name the resulting use case. Draw a use case diagram for these use cases.
Sandia Medical Devices Recall the Sandia Medical Devices Real-Time Glucose Monitoring (RTGM) system introduced in Chapter 2. As the project began, interviews with pa- tients and physicians about potential RTGM capa- bilities and interaction modes identified several areas of concern that will need to be incorporated into the system requirements and design. The relevant patient concerns include:
■ Viewing and interpreting data and trends. Patients want to be able to view more than their current glucose level. They would like to see glucose levels over various time periods, with a specific focus on time periods during which their glucose was within and outside of acceptable ranges. A graphical view of the data is preferred, although some patients also want to be able to see actual numbers.
■ Entering additional data. Some patients want to be able to enter text notes or voice messages to supplement glucose level data. For example, patients who see a high glucose alert might record voice messages describing how they feel or what they had recently eaten. Some patients thought that sharing such information with their health-care providers might be valuable, but others only wanted such information for themselves.
Physicians expressed these concerns:
■ They do not want to be the “first line of response” to all alerts. They prefer that nurses or physician assistants be charged with that role and that physicians be notified only when frontline personnel determine that an emergency situation exists.
■ They want to be able to monitor and view past patient data and trends in much the same way as described for patients.
■ They want all their actions to be logged and for patient-specific responses to be stored as part of the patient’s electronic medical record.
Perform the following tasks by using the infor- mation here as well as the system description in Chapter 2:
1. Identify all the actors who will use RTGM. 2. Using the actors who you identified in question 1,
develop a list of use cases based on the user goal technique. Draw a use case diagram for these use cases.
3. Using the event decomposition technique for each event you identified in the description, name the event, state the type of event, and name the resulting use case. Draw a use case diagram for these use cases.
Classic and more recent texts include the following:
Grady Booch, Ivar Jacobson, and James Rumbaugh, The Unified Modeling Language User Guide. Addison-Wesley, 1999.
Mike Cohn, User Stories Applied. Addison-Wesley, 2004.
Craig Larman, Applying UML and Patterns (3rd ed.). Prentice Hall, 2005.
Stephen McMenamin and John Palmer, Essential Systems Analysis. Prentice Hall, 1984.
Ed Yourdon, Modern Structured Analysis. Prentice Hall, 1989.
FURTHER RESOURCES
17204_ch03_ptg01_069-092.indd 92 27/11/14 7:42 AM
NOT FOR SALE
