After reading this chapter, you should be able toExplain .docx

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 PA R T 2 ■ S y s t ems A naly sis A c tivities
■ 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
71C H A P T E R 3 ■ Identif ying User S tories and Use C ases
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

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
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 R MO 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
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
e
n
g
ag

e
L
e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 74 27/11/14 7:42 AM
NOT FOR SALE
■ 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.
S ome events t hat a re i mpor ta nt to a retail store’s cha rge
accou nt
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
e
n
g
ag
e
L
e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 75 27/11/14 7:42 AM
NOT FOR SALE
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

e
n
g
ag
e
L
e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 76 27/11/14 7:42 AM
NOT FOR SALE
❚ 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
e
n
g
ag
e
L
e
ar

n
in
g
®
17204_ch03_ptg01_069-092.indd 77 27/11/14 7:42 AM
NOT FOR SALE
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
e
n
g
ag
e
L
e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 78 27/11/14 7:42 AM
NOT FOR SALE
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
e
n
g
ag
e
L

e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 79 27/11/14 7:42 AM
NOT FOR SALE
■ 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
e
n
g
ag
e
L
e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 80 27/11/14 7:42 AM
NOT FOR SALE
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 R MO 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
e
n
g
ag
e
L
e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 81 27/11/14 7:42 AM
NOT FOR SALE
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
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
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

e
n
g
ag
e
L
e
ar
n
in
g
®
©
C
e
n
g
ag
e
L
e
ar
n
in

g
®
17204_ch03_ptg01_069-092.indd 82 27/11/14 7:42 AM
NOT FOR SALE
CSMS Customer Account Subsystem
Create/update customer account Customer, customer service
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
Add/update product information Merchandising, marketing
Add/update promotion Marketing
Add/update accessory package Merchandising
Add/update business partner link Marketing
CSMS Reporting Subsystem
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
e
n
g
ag
e
L
e
ar
n
in
g
®

©
C
e
n
g
ag
e
L
e
ar
n
in
g
®
©
C
e
n
g
ag
e
L
e
ar

n
in
g
®
17204_ch03_ptg01_069-092.indd 83 27/11/14 7:42 AM
NOT FOR SALE
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
e
n
g
ag
e
L
e
ar
n
in
g
®
©
C
e
n
g

ag
e
L
e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 84 27/11/14 7:42 AM
NOT FOR SALE
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
e
n
g
ag
e
L

e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 85 27/11/14 7:42 AM
NOT FOR SALE
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
e
n
g
ag
e
L
e
ar
n
in
g
®
©
C
e
n

g
ag
e
L
e
ar
n
in
g
®
17204_ch03_ptg01_069-092.indd 86 27/11/14 7:42 AM
NOT FOR SALE
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
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
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

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
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

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.
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
R e c a l l t he S a nd i a Me d ic a l D ev ic e s R e a l-Ti me
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.
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
CIS 510 Assignment 2: Creating a Use Case
Due Week 4 and worth 130 points
In the textbook, refer to the RMO CSMS marketing subsystem
Figure 3-10d on page 83.
Write a paper in which you research use case diagrams:
1. Create a diagram using Visio, Word, or your choice of
program that can create a use case graphic rendering.
a. Use figure 3-12 on page 84 and figure 3-14 on page 86 as
exemplars.
b. Remember to paste a copy of the diagram in the paper.
c. YOU NEED TO CREATE THE DIAGRAM, NOT TAKE ONE
FROM THE INTERNET.
2. Write an analysis of the use case drawing that you created.
Analyze the actors and how they relate to the use cases in the
diagram. (Your answer should show the purpose and
importance of use case diagrams.)
3. Use at least 2 quality resources. NOTE: Wikipedia and
similar websites do not qualify as quality resources.
The specific course learning outcomes associated with this
assignment are:
· Identify system stakeholders and formulate their needs.
· Create a use case based on relating functional requirements.

After reading this chapter, you should be able toExplain .docx

After reading this chapter, you should be able toExplain .docx

More Related Content

Similar to After reading this chapter, you should be able toExplain .docx (20)

More from daniahendric (20)

Recently uploaded (20)

After reading this chapter, you should be able toExplain .docx