Apsi Chapter 3

Identifying User Stories
and Use Cases

CHAPTER three
Learning Objectives
After reading this chapter, you should be able to:
Explain why identifying user stories and

use cases is the key to defining functional
requirements
Chapter Outline Write user stories with acceptance criteria

Describe the two techniques for identifying
User Stories and Use Cases
use cases
Use Cases and the User Goal Technique
Apply the user goal technique to identify use
Use Cases and Event Decomposition cases
Use Cases in the Ridgeline Mountain Apply the event decomposition technique to
Outfitters Case identify use cases
Describe the notation and purpose for the use
case diagram
Draw use case diagrams by actor and by
subsystem
Copyright 2016 Cengage Learning. All Rights Reserved. May not be copied, scanned, or duplicated, in whole or in part. Due to electronic rights, some third party content may be suppressed from the eBook and/or eChapter(s).
Editorial review has deemed that any suppressed content does not materially affect the overall learning experience. Cengage Learning reserves the right to remove additional content at any time if subsequent rights restrictions require it.
70 PART 2 ■ Systems Analysis Activities
Opening case W aiters on Call Meal-Delivery System
Waiters on Call is a restaurant meal-delivery service add up the money they have and compare it with the
started in 2010 by Sue and Tom Bickford. The Bick- records we have. After all drivers report in, we need to
fords worked for restaurants while in college and always create a deposit slip for the bank for the day’s total re-
dreamed of opening their own restaurant; unfortunately, ceipts. At the end of each week, we calculate what we
the initial investment was always out of reach. The Bick- owe each restaurant at the agreed-to wholesale price
fords noticed that many restaurants offer takeout food, and send them a statement and check.”
and that some restaurants—primarily pizzerias—offer “What other information do you need to get from
home-delivery service. However, many people they the system?” continued Sam.
met seemed to want home delivery with a wider food “It would be great to have some information at the
selection. end of each week about orders by restaurant and or-
Sue and Tom conceived Waiters on Call as the best ders by area of town—things like that,” Sue said. “That
of both worlds: a restaurant service without the high would help us decide about advertising and restaurant
initial investment. They contracted with a variety of contracts. Then, we need monthly statements for our
well-known restaurants in town to accept orders from accountant.”
customers and to deliver the complete meals. After pre- Sam made some notes and sketched some dia-
paring the meal to order, the restaurant charges Waiters grams as Sue and Tom talked. Then, after spending
on Call a wholesale price, and the customer pays retail some time thinking about it, he summarized the situa-
plus a service charge and tip when the meals are deliv- tion for Waiters on Call. “It sounds to me like you need a
ered. Waiters on Call started modestly, with only two system to use whenever these events occur”:
restaurants and one delivery driver working the dinner
■■ A customer calls in to place an order, so you need to
shift. Business rapidly expanded, until the Bickfords real-
Record an order.
ized they needed a custom computer system to support
■■ A driver is finished with a delivery, so you need to
their operations. They hired a consultant, Sam Wells, to
Record delivery completion.
help them define what sort of system they needed.
■■ A customer calls back to change an order, so you
“What events happen when you are running your
need to Update an order.
business that make you want to reach for a computer?”
■■ A driver reports for work, so you need to Sign in the
asked Sam. “Tell me about what usually goes on.”
driver.
“Well,” answered Sue, “when a customer calls in
■■ A driver submits the day’s receipts, so you need to
wanting to order, I need to record it and get the informa-
Reconcile driver receipts.
tion to the right restaurant. I need to know which drivers
are available to pick up the order, so I need drivers to call Sam continues, “Then, you need the system to
in and tell me when they are free. Perhaps this could produce information at specific points in time—for
be included as a smartphone or iPad app. Sometimes, example, when it is time to,”
customers call back wanting to change their orders, so I
need to find the original order and notify the restaurant ■■ Produce an end-of-day deposit slip.
to make the change.” ■■ Produce end-of-week restaurant payments.
“Okay, that’s great. Now, how do you handle the ■■ Produce weekly sales reports.
money?” queried Sam. ■■ Produce monthly financial reports.
Tom jumped in. “The drivers get a copy of the bill “Am I on the right track?”
showing the retail price directly from the restaurant Sue and Tom quickly agreed that Sam was talking
when they pick up the meal. The bill should agree with about the system in a way they could understand. They
our calculations. The drivers collect that amount plus a were confident that they had found the right consultant
service charge. When drivers report in at closing, we for the job.
■■ 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
CHAPTER 3 ■ Identifying User Stories and Use Cases 71
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.
user story one short sentence in the every- A user story is usually one short sentence in the everyday language of
day language of the end user that states what the end user that states what a user does as part of his or her work. In other
a user does as part of his or her work 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.”
acceptance criteria features that must A final part of a user story is the acceptance criteria. These indicate the
be present in the final system for the user to features that must be present for the user to be satisfied with the resulting imple-
be satisfied
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.
Figure 3-1 Two user stories with

acceptance criteria 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.
use case an activity that the system A use case is an activity the system performs in response to a request by
performs in response to a request by a user 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.”
user goal technique a technique to One approach to identifying use cases, called the user goal technique, is
identify use cases by determining what to ask users to describe their goals for using the new or updated system. The
specific goals or objectives must be
analyst first identifies all the users, categorizes them by user type, and then con-
completed by the system for the user
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 R MO Consolidated Sales and
M arketing 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
C reate 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).
Figure 3-2 Identifying use cases User User goal and resulting use case
with the user goal technique
Potential customer Search for item
Fill shopping cart
View product rating and comments
Marketing manager Add/update product information

Add/update promotion
© Cengage Learning ®
Produce sales history report
Shipping personnel Ship order

Track shipment
Create item return
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-
event decomposition technique a tech- position technique. The event decomposition technique begins by identify-
nique to identify use cases by determining the ing all the business events the information system responds to, with each event
business events to which the system must leading to a use case. Starting with business events helps the analyst define each
respond
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 (EBP) elementary business processes (EBPs). An EBP is a task that is performed
the most fundamental task in a business by one person in one place in response to a business event, adds measurable
process, which leaves the system and data in business value, and leaves the system and its data in a stable and consistent state.
a quiescent state; usually performed by one
person in response to a business event
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-
event something that occurs at a specific ness event. An event occurs at a specific time and place, can be described, and
time and place, can be precisely identified, should be remembered by the system. Events drive or trigger all processing that
and must be remembered by the system
a system does, so listing events and analyzing them makes sense when you need
to define system requirements by identifying 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 p ayment,
Process a charge, or Maintain customer data. Three other events are t riggered
inside the system by reaching a point in time: “time to send out monthly
s tatements,” “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
Figure 3-3 Events in a charge account processing system that lead to use cases
Charge account processing system

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
external event an event that occurs An external event is an event that occurs outside the system—usually initiated
outside the system, usually initiated by an by an external agent or actor. An external agent (or actor) is a person or orga-
external agent nizational unit that supplies or receives data from the system. To identify the
actor an external agent; a person, group key external events, the analyst first tries to identify all the external agents that
or external system that interacts with the might want something from the system. A classic example of an external agent is
system by supplying or receiving data 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.
Figure 3-4 External event

checklist 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-5 Temporal event

checklist 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
❚❚ Temporal Events
temporal event an event that occurs as a A second type of event is a temporal event—an event that occurs as a result
result of reaching a point in time 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
state event an event that occurs when A third type of event is a state event—an event that occurs when something hap-
something happens inside the system that pens inside the system that triggers the need for processing. State events are also
triggers some process
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
Figure 3-6 Sequence of actions

that lead up to only one event
affecting the system
Customer thinks Customer drives to Customer tries on a

about getting a the mall shirt at Sears
new shirt
Customer goes to Customer tries on a Customer buys
Walmart shirt at Walmart a shirt
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.
Figure 3-7 The sequence of “transactions” for one specific customer resulting in many events
Customer requests a Customer wants to check Customer places Customer changes or

catalog item availability an order cancels an order
Customer wants to Customer updates Customer returns
check order status account information the item
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.
system controls checks or safety proce- Most of these physical system events involve system controls, which are
dures to protect the integrity of the system checks or safety procedures put in place to protect the integrity of the system. For
and the data 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
perfect technology assumption the that technology is perfect. The perfect technology assumption states that
assumption that a system runs under perfect events should be included during analysis only if the system would be required
operating and technological conditions 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.
Figure 3-8 Events deferred until designing system controls
User wants to log on User wants to change the User wants to change
Don’t worry much
to the system password preference settings
about these until you are
considering design issues
System crash Time to back up the Time to require the
requires database database user to change the
recovery password
■■ 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
Figure 3-9 Use cases and brief Use case Brief use case description
descriptions
Create customer account User/actor enters new customer account data, and the system
assigns account number, creates a customer record, and
creates an account record.
Look up customer User/actor enters customer account number, and the system
retrieves and displays customer and account data.
Process account adjustment 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.
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-
brief use case description an often ples of brief use case descriptions are shown in Figure 3-9. Figures 3-10a
one-sentence description that provides a through 3-10e show the initial list of use cases for the RMO CSMS along with
quick overview of a use case 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
use case diagram the UML model used how they are organized. The use case diagram is the UML model used to
to illustrate use cases and their relationships illustrate use cases and their relationship to users. Recall from Chapter 2 that
to actors 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 the boundary automation boundary, which defines the border between the computerized
between the computerized portion of the portion of the application and the people operating the application, is shown
application and the users who operate the as a rectangle containing the use case. The actor’s communication with the use
application but are part of the total system
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
Figure 3-10a Use cases

CSMS Sales Subsystem
and actors for 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
View accessory combinations Customer, customer service representative, store

Fill shopping cart Customer
Empty shopping cart Customer
Check out shopping cart Customer
Fill reserve cart Customer
Empty reserve cart Customer
Convert reserve cart Customer
Create phone sale Customer service representative
Create store sale Store sales representative
Figure 3-10b Use cases

CSMS Order Fulfillment Subsystem
and actors for CSMS Order
Fulfillment Subsystem Use cases Users/actors
Ship items Shipping
Manage shippers Shipping
Create backorder Shipping
Create item return Shipping, customer
Look up order status Shipping, customer, management
Track shipment Shipping, customer, marketing
Rate and comment on product Customer
Provide suggestion Customer
Review suggestions Management
Figure 3-10c Use cases and

CSMS Customer Account Subsystem
actors for CSMS Customer
Account Subsystem Use cases Users/actors
Create/update customer account Customer, customer service representative, store

Process account adjustment Management
Send message Customer
Browse messages Customer
Request friend linkup Customer
Reply to linkup request Customer
Send/receive partner credits Customer
View “mountain bucks” Customer
Transfer “mountain bucks” Customer
Figure 3-10d Use cases and

CSMS Marketing Subsystem
actors for CSMS Marketing
Add/update product information Merchandising, marketing
Add/update promotion Marketing
Add/update accessory package Merchandising
Add/update business partner link Marketing
Figure 3-10e Use cases and

CSMS Reporting Subsystem
actors for CSMS Reporting
Produce daily transaction summary Management
report
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 Management, marketing

report
Figure 3-11 A simple use case

with an actor
Actor is a stick
figure, usually Connecting line
meaning an to show which
actual person actors participate Automation
using the system in use cases boundary
Ship items
Shipping clerk
Figure 3-12 A use case diagram

of the Customer Account
Customer Account Subsystem
subsystem for RMO, showing
All Actors
all actors
Create/update
customer account
Customer service
Request friend representative
linkup
Reply to friend
linkup
View "mountain
bucks"
Browse
messages
Customer Store sales
representative
Process account
adjustment
Send message
Transfer
"mountain bucks"
Send/receive
partner credits Management
Figure 3-13 All use cases

involving the customer actor for
Sales Subsystem
the Sales subsystem Actor: Customer
Search for item
View product
comments and
ratings
View accessory
combinations
Fill shopping cart
Empty shopping
cart
Customer
Fill reserve cart
Convert reserve
cart
Check out shopping

cart
Empty reserve
cart
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
Figure 3-14 Use cases involving the customer service representative and store sales representative for the Sales subsystem
Sales Subsystem
Actors: Service Representative and Store Representative
Search for item
View product
comments and
ratings
Customer service Store sales
representative representative
View accessory
combinations
Create phone sale Create store sale
Figure 3-15 A use case diagram

of the Fill shopping cart «includes»
Sales Subsystem
relationships
Fill Shopping Cart <<includes>> Relationships
Search for item
«includes»
View product
Fill shopping cart «includes» comments and
ratings
Customer
«includes»
View accessory
combinations
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.
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
«includes» relationship a relationship referred to as the «includes» relationship or the «uses» relationship. Note that
between use cases in which one use case the word includes is enclosed within guillemets in the diagram; this is the way to
is stereotypically included within the other refer to a stereotype in UML. It means that the relationship between one use case
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.
chapter Summary
This chapter is the first of three chapters that present system. An event is something that can be described,
techniques for modeling a system’s functional require- something that occurs at a specific time and place, and
ments. A key early step in the modeling process is to something worth remembering. External events occur
identify and list the user stories or use cases that de- outside the system—usually triggered by someone who
fine the functional requirements for the system. User interacts with the system. Temporal events occur at a
stories are written by end users and stakeholders dur- defined point in time, such as the end of a work day or
ing requirements meetings with the developers. They the end of every month. State or internal events occur
are used with most highly Agile development meth- based on an internal system change. For each event,
odologies. Use cases are very similar to user stories, a use case is identified and named. The event decom-
but they are often modeled in more detail than user position technique helps ensure that each use case is
stories and are the responsibility of the developers. Use identified at the elementary business process (EBP)
cases can be identified by using the user goal technique level of detail. Each use case identified by the analyst
and the event decomposition technique. The user goal is further documented by a brief use case description
technique initially identifies types of system end us- and by identifying the actors. UML use case diagrams
ers, called actors. Then, users are asked to list specific are drawn to document use cases and their actors.
user goals they have when using the system to support Many different use case diagrams are drawn based on
their work. The event decomposition technique ini- the need to review use cases with various stakeholders,
tially identifies events that require a response from the users, and team members.
Key Terms
acceptance criteria event system controls
actor event decomposition technique temporal event
automation boundary external event use case
brief use case description «includes» relationship use case diagram
elementary business perfect technology assumption user goal technique
process (EBP) state event user story
Review Questions
1. What are the five activities of systems analysis, 14. What are the three types of events?
and which activity is discussed beginning with 15. Define an external event and give an example
this chapter? that applies to a checking account system.
2. What is a user story? What is a use case? 16. Define a temporal event and give an example
3. What are the two techniques used to identify that applies to a checking account system.
use cases? 17. What are system controls, and why are they
4. Describe the user goal technique for identifying not considered part of the users’ functional
use cases. requirements?
5. What are some examples of users with different 18. What is the perfect technology assumption?
functional roles and at different operational levels? 19. What are three examples of events that involve
6. What are some examples of use case names that system controls that should not be included initial-
correspond to your goals as a student going ly because of the perfect technology assumption?
through the college registration process? Be sure 20. What is a brief use case description?
to use the verb-noun naming convention.
21. What is UML?
7. What is the overarching objective of asking users
22. What is the purpose of UML use case
about their specific goals?
diagrams?
8. How many types of users can have the same user
23. What is another name for “actor” in UML, and
goals for using the system?
how is it represented on a use case diagram?
9. Describe the event decomposition technique for
24. What is the automation boundary on a use case
identifying use cases.
diagram, and how is it represented?
10. Why is the event decomposition technique
25. How many actors can be related to a use case on
considered more comprehensive than the user
a use case diagram?
goal technique?
26. Why might a systems analyst draw many differ-
11. What is an elementary business process (EBP)?
ent use case diagrams when reviewing use cases
12. Explain how the event decomposition technique with end users?
helps identify use cases at the right level of analysis.
27. What is the «includes» relationship between two
13. What is an event? use cases?
Problems and Exercises

1. Consider the situation where a student standard template for the following potential
organization is exploring its requirements for users: membership director, finance director,
a system that manages its membership and faculty advisor. Add acceptance criteria for each
finances. Based on what you know about stu- user story based on how you imagine the system
dent organizations, write user stories using the might work.
2. Review the external event checklist in Figure 3-4 9. Again considering the library, ask some students
and then think about a university course registra- what their goals are in using the library system.
tion system. What is an example of an event of Also ask some library employees about their
each type in the checklist? Name each event by goals in using the system. Name these goals as use
using the guidelines for naming an external event. cases (verb-noun) and discuss whether student
3. Review the temporal event checklist in Figure 3-5. users have different goals than employee users.
Would a student grade report be an internal or 10. Visit a restaurant or the college food service to
external output? Would a class list for the instruc- talk to a server (or talk with a friend who is a
tor be an internal or external output? What are food server). Ask about the external events and
some other internal and external outputs for a temporal events, as you did in exercise 8. What
course registration system? Using the guidelines are the events and resulting use cases for order
for naming temporal events, what would you processing at a restaurant?
name the events that trigger these outputs? 11. Review the procedures for course registration
4. Consider the following sequence of actions taken at your university and then talk with the staff
by a customer at a bank. Which action is the in advising, in registration, and in your major
event the analyst should define for a bank ac- department. Think about the sequence that goes
count transaction processing system? (1) Kevin on over an entire semester. What are the events
gets a check from Grandma for his birthday. that students trigger? What are the events that
(2) Kevin wants a car. (3) Kevin decides to save your own department triggers? What are the
his money. (4) Kevin goes to the bank. (5) Kevin temporal events that result in information going
waits in line. (6) Kevin makes a deposit in his sav- to students? What are the temporal events that
ings account. (7) Kevin grabs the deposit receipt. result in information going to instructors or
(8) Kevin asks for a brochure on auto loans. departments? List all the events and the resulting
5. Consider the perfect technology assumption, use cases that should be included in the system.
which states that use cases should be included 12. Refer to the RMO CSMS Order Fulfillment subsys-
during analysis only if the system would be tem shown in Figure 3-10. Draw a use case diagram
required to respond under perfect conditions. that shows all actors and all use cases. Use a draw-
Could any of the use cases listed for the RMO ing tool such as Microsoft Visio if it is available.
CSMS be eliminated based on this assumption? 13. Again for the Order Fulfillment subsystem, draw
Explain. Why are such use cases as Log on to the a use case diagram showing just the use cases
system and Back up the database required only for the Shipping Department in preparation for
under imperfect conditions? a meeting with them about the system require-
6. Visit some Web sites of car manufacturers, such ments. Use a drawing tool such as Microsoft
as Honda, BMW, Toyota, and Acura. Many of Visio if it is available.
these sites have a use case that is typically named 14. Refer to the RMO CSMS Marketing subsystem
Build and price a car. As a potential customer, shown in Figure 3-10. Draw a use case diagram
you can select a car model, select features and that shows all actors and all use cases. Use a draw-
options, and get the car’s suggested price and list ing tool such as Microsoft Visio if it is available.
of specifications. Write a brief use case descrip-
15. Refer to the RMO CSMS Reporting subsystem
tion for this use case (see Figure 3-9).
shown in Figure 3-10. These reports were iden-
7. Again looking at a Web site for one of the car tified by asking users about temporal events,
manufacturers, consider yourself a potential meaning points in time that require the system
buyer and then identify all the use cases included to produce information of value. In most actual
on the site that correspond to your goals. systems today, an actor is assigned responsibil-
8. Set up a meeting with a librarian. During your ity for producing the reports or other outputs
meeting, ask the librarian to describe the situ- when they are due. Recall that the actor is part
ations that the book checkout system needs to of the system—the manual, nonautomated
respond to. List these external events. Now ask part. Thus, this is one way the “system” can be
about points in time, or deadlines, that require responsible for producing an output at a point
the system to produce a statement, notice, report, in time. In the future, more outputs will be pro-
or other output. List these temporal events. Does duced automatically. Draw a use case diagram
it seem natural for the librarian to describe the that shows the use cases and actors, as shown in
system in this way? List each event and then Figure 3-10. Use a drawing tool such as Micro-
name the resulting use case. soft Visio if it is available.
CASE STUDY
The State Patrol Ticket-Processing When the trial is completed, the court sends the
verdict to the ticketing system. The verdict and trial date
System are recorded for the ticket. If the verdict is innocent, the
The purpose of the State Patrol ticket-processing system is system that produces driving record reports for insurance
to record moving violations, keep records of the fines paid by companies will ignore the ticket. If the verdict is guilty,
drivers when they plead guilty or are found guilty of moving the court gives the driver another envelope with the ticket
violations, and notify the court that a warrant for arrest should number on it for mailing in the fine.
be issued when such fines are not paid in a timely manner. If the driver fails to pay the fine within the required
A separate State Patrol system records accidents and the period, the ticket-processing system produces a warrant
verification of financial responsibility (insurance). But a third request notice and sends it to the court. This happens if
system uses ticket and accident records to produce driving the driver does not return the original envelope within two
record reports for insurance companies. Finally, a fourth sys- weeks, or does not return the court-supplied envelope
tem issues, renews, or suspends driver’s licenses. These within two weeks of the trial date. What happens next is
four systems are obviously integrated, in that they share ac- in the hands of the court. Sometimes, the court requests
cess to the same database; otherwise, they are operated that the driver’s license be suspended, and the system that
separately by different departments of the State Patrol. processes driver’s licenses handles the suspension.
When an officer gives a ticket to a driver, a copy of
the ticket is turned in and entered into the system. A new 1. To what events must the ticket-processing system
ticket record is created, and relationships to the correct respond? List each event, the type of event, the
driver, officer, and court are established in the database. resulting use case, and the actor(s). Think carefully
If the driver pleads guilty, he or she mails in the fine in a about who the actors are. Does the officer directly
preprinted envelope with the ticket number on it. In some enter the ticket into the system? Or does a state pa-
cases, the driver claims innocence and wants a court date. trol clerk do it when the paper ticket is received from
When the envelope is returned without a check and the trial the officer? The existing system uses paper forms, so
request box has an “X” in it, the system does the following: for now assume the state patrol clerk enters all of the
notes the plea on the ticket record; looks up driver, ticket, information. A new system would use the same use
and officer information; and sends a ticket details report cases, but opportunities for efficiency and accuracy
to the appropriate court. A trial date questionnaire form is would lead to changes in who the actors are.
also produced at the same time and is mailed to the driver. 2. Write a brief use case description for each use case.
The instructions on the questionnaire tell the driver to fill in 3. Draw a use case diagram for the ticket-processing
convenient dates and mail the questionnaire directly to the system assuming the actors are based on your
court. Upon receiving this information, the court schedules answers in question 1 (the existing system as
a trial date and notifies the driver of the date and time. described).
Running Case Studie s
Community Board of Realtors®

One of the functions of the Board of Realtors intro- listing to the MLS. Therefore, any agent in the com-
duced in Chapter 2 is to provide a Multiple Listing munity can get information on the listing.
Service (MLS) system that supplies information that The MLS systems include lots of information on
local real estate agents use to help them sell houses to a listing. It is now common to include dozens of pho-
their customers. Agents list houses for sale (listings) by tos, video tours, Google map information, prior sales,
contracting with homeowners. The agent works for and so forth. For now, let’s keep it simple and assume
a real estate office, which sends information on the a listing includes the address, year built, square feet,
number of bedrooms, number of bathrooms, owner through and write on. Sometimes, agents and owners
name, owner phone number, asking price, and status decide to change information about a listing, such as re-
code. An agent will directly request information from ducing the price, correcting previous information on the
the MLS system on listings that match customer re- house, or indicating that the house is sold. The agent
quirements. Information is provided on the house, on updates the information directly on the MLS system.
the agent who listed the house, and on the real estate
1. To what events must the MLS system respond
office for which the agent works. This information is
based on the description above? List each event,
needed because an agent might want to call the listing
the type of event, and the resulting use case. Be
agent to ask additional questions or call the homeowner
sure to consider all the use cases that would be
directly to make an appointment to show the house.
needed to maintain the data in the MLS system.
Although it seems dated, once each week, the MLS
produces a listing booklet that contains information 2. Draw a use case diagram based on the use cases
on all listings. These booklets are sent to some real es- you identified in question 1. Include appropriate
tate agents because many think they are easier to flip actors based on the case description.
The Spring Breaks ‘R’ Us Travel Service

Spring Breaks ‘R’ Us (SBRU), introduced in Chapter 2, 1. Using the event decomposition technique for
includes many use cases that make up the functional each event you identify in the description here,
requirements. Consider the following description of the name the event, state the type of event, and
Booking subsystem. A few weeks before Thanksgiving name the resulting use case. Draw a use case
break, it is time to open the system to new bookings. diagram for these use cases.
Students usually want to browse through the resorts 2. Consider the new Social Networking subsystem
and do some planning. When a student or group of that SBRU is researching that was described
students wants to book a trip, the system allows it. in Chapter 2. Think in terms of the user goal
Sometimes, a student needs to be added or dropped technique to identify as many use cases as you
from the group or a group changes size and needs a can think of that you would like to have in the
different type of room. One month before the actual system. SBRU is guessing you might want to
trip, it is time for the system to send out final payment join, send messages, and so forth, but there must
requirement notices. Students cancel the booking or be many interesting and useful things the system
they pay their final bills. Students often want to look could do before, during, and after the trip. Draw
up their booking status and check on resort details. a use case diagram for these use cases.
When they arrive at the resort, they need to check in;
and when they leave, they need to check out.
On the Spot Courier Services

Recall the On the Spot courier service introduced printed out a label with his portable printer that he
in Chapter 2. The details of the package pickup and kept in the delivery van.
delivery process are described here. At first, Bill required customers to pay at the time
When Bill got an order, only on his phone at first, of pickup, but he soon discovered that there were some
he recorded when he received the call and when the regular customers who preferred to receive a monthly
shipment would be ready for pickup. Sometimes, cus- bill for all their shipments. He wanted to be able to ac-
tomers wanted immediate pickup; sometimes, they commodate those customers. Bills were due and pay-
were calling to schedule a later time in the day for able upon receipt.
pickup. To help keep track of all the packages, Bill de-
Once he arrived at the pickup location, Bill cided that he needed to scan each package as it was
c ollected the packages. It was not uncommon for sorted in the warehouse. This would enable him to
the customer to have several packages for delivery. keep good control of his packages and avoid loss or
In a ddition to the name and address of the delivery delays.
location, he also r ecorded the time of pickup. He The delivery of a package was fairly simple. Upon
noted the desired delivery time, the location of the delivery, he would record information about when the
delivery, and the weight of the package to determine delivery was made and who received it. Because some
the courier cost. When he picked up the package, he of the packages were valuable, it was necessary in
those instances to have someone sign for the package technique. Draw a use case diagram for these
upon delivery. use cases.
1. From this description as well as the information 3. Using the event decomposition technique for
from Chapter 2, identify all the actors who will each event you identify in the description
be using the system. here, name the event, state the type of event,
and name the resulting use case. Draw a use
2. Using the actors who you identified in question 1,
case diagram for these use cases.
develop a list of use cases based on the user goal
Sandia Medical Devices

Recall the Sandia Medical Devices Real-Time Physicians expressed these concerns:
G lucose Monitoring (RTGM) system introduced in
■■ They do not want to be the “first line of
Chapter 2. As the project began, interviews with pa-
response” to all alerts. They prefer that nurses
tients and physicians about potential RTGM capa-
or physician assistants be charged with that
bilities and interaction modes identified several areas
role and that physicians be notified only when
of concern that will need to be incorporated into the
frontline personnel determine that an emergency
system requirements and design. The relevant patient
situation exists.
concerns include:
■■ They want to be able to monitor and view past
■■ Viewing and interpreting data and trends. patient data and trends in much the same way as
Patients want to be able to view more than their described for patients.
current glucose level. They would like to see ■■ They want all their actions to be logged and for
glucose levels over various time periods, with a patient-specific responses to be stored as part of
specific focus on time periods during which their the patient’s electronic medical record.
glucose was within and outside of acceptable
Perform the following tasks by using the infor-
ranges. A graphical view of the data is preferred,
mation here as well as the system description in
although some patients also want to be able to
Chapter 2:
see actual numbers.
■■ Entering additional data. Some patients want 1. Identify all the actors who will use RTGM.
to be able to enter text notes or voice messages 2. Using the actors who you identified in question 1,
to supplement glucose level data. For example, develop a list of use cases based on the user goal
patients who see a high glucose alert might technique. Draw a use case diagram for these use
record voice messages describing how they feel cases.
or what they had recently eaten. Some patients 3. Using the event decomposition technique for
thought that sharing such information with each event you identified in the description, name
their health-care providers might be valuable, the event, state the type of event, and name the
but others only wanted such information for resulting use case. Draw a use case diagram for
themselves. these use cases.
Further R esources
Classic and more recent texts include the following: Craig Larman, Applying UML and Patterns (3rd ed.).
Grady Booch, Ivar Jacobson, and James Prentice Hall, 2005.
Rumbaugh, The Unified Modeling Language Stephen McMenamin and John Palmer, Essential
User Guide. Addison-Wesley, 1999. Systems Analysis. Prentice Hall, 1984.
Mike Cohn, User Stories Applied. Addison-Wesley, Ed Yourdon, Modern Structured Analysis. Prentice
2004. Hall, 1989.

Apsi Chapter 3

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apsi Chapter 3

Uploaded by

Copyright:

Available Formats

Identifying User Stories

and Use Cases

Explain why identifying user stories and

Chapter Outline Write user stories with acceptance criteria

Opening case W aiters on Call Meal-Delivery System

the functional requirements by creating a variety of models. These models are

■■ User Stories and Use Cases

Figure 3-1 Two user stories with

■■ Use Cases and the User Goal Technique

Marketing manager Add/update product information

Shipping personnel Ship order

■■ Use Cases and Event Decomposition

■■ Event Decomposition Technique

Charge account processing system

to events in the environment. Early real-time systems include manufacturing

Figure 3-4 External event

√ External agent wants something resulting in a transaction

Figure 3-5 Temporal event

❚❚ Events Versus Prior Conditions and Responses

Figure 3-6 Sequence of actions

Customer thinks Customer drives to Customer tries on a

❚❚ The Sequence of Events: Tracing a Transaction’s Life Cycle

Customer requests a Customer wants to check Customer places Customer changes or

❚❚ Technology-Dependent Events and System Controls

Figure 3-8 Events deferred until designing system controls

■■ Steps in the Event Decomposition Technique

■■ Use Cases in the Ridgeline Mountain

■■ Use Cases, Actors, and Use Case Diagram Notation

❚❚ Use Case Diagram Examples

Figure 3-10a Use cases

View accessory combinations Customer, customer service representative, store

Fill shopping cart Customer

Empty shopping cart Customer

Check out shopping cart Customer

Fill reserve cart Customer

Empty reserve cart Customer

Create phone sale Customer service representative

Create store sale Store sales representative

Figure 3-10b Use cases

Ship items Shipping

Manage shippers Shipping

Create backorder Shipping

Create item return Shipping, customer

Look up order status Shipping, customer, management

Track shipment Shipping, customer, marketing

Provide suggestion Customer

Review suggestions Management

Figure 3-10c Use cases and

Create/update customer account Customer, customer service representative, store

Process account adjustment Management

Send message Customer

Browse messages Customer

Request friend linkup Customer

Reply to linkup request Customer

View “mountain bucks” Customer

Transfer “mountain bucks” Customer

Figure 3-10d Use cases and

Add/update product information Merchandising, marketing

Add/update accessory package Merchandising

Add/update business partner link Marketing

Figure 3-10e Use cases and

Produce sales history report Management, marketing