Use Case Tutorial
Introduction
The Use Case model is about describing WHAT (as opposed to How) the system will do at a
high-level and with a user focus for the purpose of capturing system requirements.
Use cases document user-system interactions required to perform tasks and define the user and
system actions for each "user visible" task performed by the information system. As such they
effectively define all user interfaces and the sequence of interactions within them. Use cases
focus on "typical" interactions first, describing the case when, "everything goes right” and
separately describe exception processing as necessary to accomplish the task.
Use cases name the major "processes" and show the actors with which they interact. The
process of developing use cases is iterative and begins by identifying the actors involved in the
activity.
Actors
An actor may be a person or an external system. A single person may play a number of different
roles in any given activity. It is important to identify what tasks the different roles are trying to
accomplish and their contribution to the activity. These dictate what the information system must
do and what the actor must do. There are typically different levels of roles within a business
activity supported by an information system. These include, data entry role, monitoring role,
analysis role, and decision-making role. The actors and tasks are organized into a use case
diagram, which shows the actors as named stick figures, tasks as named ovals, and interactions
as lines. In particular it is important to document when different actors interact with the same task
to insure that each is consulted when developing the use case for the task.
Fig 1. an Actor
It can be said that a use case is a collection of possible sequences of interactions between the
system under discussion and its Users (or Actors), relating to a particular goal. The collection of
Use Cases should define all system behavior relevant to the actors to assure them that their
goals will be carried out properly. Any system behavior that is irrelevant to the actors should not
be included in the use cases.
Use cases are developed by interviewing system stakeholders. The first task, is to design or redesign the business system and identify what activities will be supported by the information
system. The role of an information system with respect to a business activity can vary from
simply recording data to monitoring and alerting to suggesting actions to automatically taking
actions.
After identifying the actors and naming the task, an analyst must document what the actors are
trying to accomplish and define how the system will support them. To accomplish this the analyst
Joseph Lewis Aguirre
Page 1
Use Case Tutorial
asks the user to "walk through" the steps normally taken to accomplish the task. From these the
system scope is determined by specifying the (user input-system response) pairs for each of
these steps otherwise known as transaction sequences because they are sequences of
interactions that constitute a complete transaction with the system. They specify what the user
does and what the system does in each step. These define the look and feel of the GUI needed
when actors are people or the protocols for interface programs when actors are other systems.
Once the use case for the normal or typical situation has been documented, the analyst simply
asks, "what can go wrong" at each step in the process. These can be documented as
"exception" use cases that "extend" the original use case.
Again, identical or similar sets of steps are organized into their own use cases. This eliminates
the need to duplicate the description of the use case each place it is needed. It also documents
the fact that this use case should be implemented only once but used in several places, thus
reducing the amount of duplicate code produced within the system. These use cases are added
to the use case diagram and connected to the original use case by a "used by" relationship.
Used by relationships are represented by an arrow from the original use case to the use cases
that it uses.
Consider the use case in Figure 2 for the activity, Process Customer Order. This is as course a
grain as possible for this activity. It has only one use case! It identifies a number of actors, each
of which play different roles with respect to this use case.
Attempting to document the detailed steps and user interactions for such a complex use case is
quite difficult, hence the first set of steps identified would likely be use cases as illustrated in
Figure 1.
Normal processing for a customer order requires:
1.
2.
3.
4.
5.
6.
7.
8.
Finance to Determine Credit Limits for the customer
Marketing to Define Prices
Then a Salesperson interacts with the information system to Determine Pricing for a
particular customer order
Next either the Salesperson or an Order Entry Clerk Enters the Order into the information
system.
On demand, the Order Entry Clerk Prints Orders and sends them to the Warehouse for
picking.
The Warehouse Enters The Date And Quantities Picked.
Next, the picked orders are delivered to customers and Shipping Enters The Date
Shipped. Finally
Accounting Produces Invoices and sends them to customers. Note the similarity
between this set of steps and a process description.
Notice also that each component use case has a small number of actors. Typically a use case of
a reasonable level of complexity has one or possibly two main actors that are responsible for
initiating it. Other actors involved typically play a role in exception use cases or receive the
results of a use case. Determine Credit Limits, for example, might be identified as an exception,
executed only if an order is for a new customer or if an existing customer has exceeded his credit
limit.
It is necessary to further analyze these use cases to clarify the role of the information system and
to identify additional use cases. For example, to analyze the use case, Define Prices, a
representative from Marketing is asked to describe the process of determining prices and,
together with the analyst to determine the role of the information system in this task. The
information system may take a minimal role and simple record prices determined by marketing. It
may take a more active role and provide information to Marketing such as competitor's prices or
manufacturing costs. To do so, it may need to access other internal systems or search external
databases. It may take an even more active role and, through some modeling mechanism
suggest prices or specific promotions. The basic question the analyst asks is, "How are prices
determined?" After listening to the description the analyst may ask, "What information would be
useful in performing this task?" or "What type of support would you like from the information
Joseph Lewis Aguirre
Page 2
Use Case Tutorial
system?" In addition, the analyst may suggest alternative ways in which the information system
could support this task. At this point it is important to manage user expectations and to balance
functionality provided by the information system with the feasibility of providing such functionality
at a reasonable cost and within a reasonable timeframe.
Suppose Marketing describes this process as follows: Each customer is assigned a customer
type based on their business category. Currently five categories are differentiated, Industrial,
Commercial, Public Utility, Contractor or Other. Each category is given a percent discount from
list price for each type of product, Industrial being the largest discount and Other being the least.
However, a customer could be given pricing from a different category for a specific order. For
example, a Contractor could be given Commercial or Industrial pricing for a specific order if the
salesperson must offer such pricing to get the order and it is approved by Marketing. In addition,
a salesperson could be forced to give extra discounts, specified as a percent off list price for
specific products for specific orders. Again, these must be approved by Marketing.
The question that the analyst must answer is, "What role will the information system play in this
activity?" Typically, an analyst will offer multiple alternatives beginning with the simplest,
requiring minimal functionality from the information system and moving to the more complex.
The simplest alternative would have the information system record the decisions made but would
provide no support for making those decisions. It would input customer type, product type and
percent discount for each combination. It would also input customer type for each customer and
product type for each product. During order entry it would allow a different customer type to be
specified for the order and calculate prices based on that customer type. It would also allow the
entry of specific discounts for each product on an order. More complex alternatives could include
tracking approvals for specific prices on specific orders. Others could produce profit projections
based on specific pricing decisions. Still others could enable a salesperson to enter a quote with
proposed pricing that would be sent to Marketing for approval or modification, again tracking the
person making the decision and supporting him with different reports or analyses.
If the simplest alternative is selected, then, the use case for Define Prices is,
1.
User
Select Define Prices from main menu
1.
System Display Define Prices screen with combo box for Product Type.
2.
2.
User
System
Selects Product Type from combo box.
Displays discount for each Customer Type for that Product Type.
3.
3.
User
System
Enters new discounts. Click Save button.
Saves changes to discount percents.
Exceptions:
2.a. User
2.a. System
Clicks Maintain Product Types button
Open Maintain Product Type screen (see Maintain Product Type use case)
2.b.
2.b.
User
System
Clicks Maintain Customer Types button
Open Maintain Customer Types screen (see Maintain Customer Type use case)
3.a.
System
If any business rules are violated, and error message is displayed and no
discounts are saved. Business rules are:
1.
no discount exceeds a specified maximum (system parameter)
2.
all discounts are positive
3.
discounts are non-decreasing (Industrial >= Commercial >= Public Utility
>= Contractor >= Other).
This defines a user interface to be implemented in the information system to support this use
case. The use case analysis for Define Prices has an impact on the Get Pricing use case which
now can only obtain standard pricing and the Enter Orders use case which must support entry of
a customer type for a specific order and the entry of list price discounting for specific products.
Given the limited nature of the use case, the user may decide that salespeople will not interact
with the information system to Get Pricing, instead the information system may produce printed
Joseph Lewis Aguirre
Page 3
Use Case Tutorial
price lists. Hence this use case is replaced by, Produce Price List, which simply produces price
lists for specified product types, customer types, and selected products. An actor must be
identified who has this responsibility, if salesperson is not appropriate.
The Define Prices use case implicitly assumes the existence of persistent Product data, including
its list price and product type. This data must come from somewhere. Most likely it will come
from an external system, such as Inventory Management. The above use case specifies that
product types are maintained within this system. Inventory Management may also have the
ability to maintain them. This data and interface sharing must be documented. Maintain Product
Types would become its own use case, used by Define Prices. Inventory Management would be
shown as an actor interacting with the Maintain Product Types use case. That is, part of the
responsibility of this use case is to define product types for the Inventory Management system.
Furthermore when the Inventory Management system is analyzed if it includes a use case for
Maintain Product Types, the same interface should be used.
Each use case must be similarly analyzed and an interaction specified. Consider the following
description for the use case for Enter Orders.
1.
User
Select Enter Orders from main menu.
1.
System Display Order Entry screen with combo box for Customer.
2.
2.
User
System
Select or enter Customer.
Generate and display the next Order number. Display that customer's name and
bill-to address along with the first ship-to address, set the order date to today, the
salesperson to the customer's assigned salesperson, the customer type for order
pricing to the customer's type and the terms to the customer's terms.
3.
User
3.
System
Select or enter a ship-to address and salesperson, enter customer type, date
wanted, terms, FOB point and special instructions.
Validate customer type and salesperson.
4.
4.
User
System
Exceptions:
2.a. System
Select or enter product and enter quantity ordered.
Validate product, determine and display price, calculate and display total gross
dollar amount of the order. Price is determined multiplying the list price of the
product by the discount for the product type and customer type. If insufficient
product on hand, display message and quantity on hand. Allow user to enter.
Customer's A/R balance plus un-invoiced orders exceeds customer's credit limit.
Display message. Initiate Determine Credit Worthiness use case if requested,
otherwise refuse order.
2.b.
2.b
User
System
Selects Order by order number to modify.
Display order including all products and order gross.
4.a.
System
This order causes the customer to exceed his credit limit. Display message.
Initiate Determine Credit Worthiness use case if requested, otherwise cancel line.
Again, this use case defines a user interface for this task. In some sense it "simulates" the
operation of the proposed system without actually producing a prototype. Since this type of
interaction with users is less time consuming and less expensive than prototyping, it can be an
effective way to specify requirements. On the other hand, it may not be possible for the user to
visualize the operation of the system from such a text description. In such cases, the use case
approach provides a starting point for prototype development.
Joseph Lewis Aguirre
Page 4
Use Case Tutorial
Finance
Invoicing Clerk
Marketing
Salesperson
Process Cusatomer
Orders
Shipping
Warehouse
Order Entry Clerk
Figure 2- Process Customer Order
Joseph Lewis Aguirre
Page 5
Use Case Tutorial
Invoicing Clerk
Finance
Determine
Credit Limits
Produce
Invoices
Salesperson
Enter Ship
Date and Qty
Determine
Order Pricing
Shipping
Enter
Order
Warehouse
Marketing
Define
Prices
Print Orders
for Warehouse
Enter Pick
Date and Qty
Order Entry Clerk
Figure 3 - Order Processing Use Cases
A Simple Use Case Recipe
Step 1. Identify who is going to be using the system directly - e.g. hitting keys on the keyboard.
These are the Actors.
Step 2. Pick one of those Actors…for example, a sales clerk.
Step 3. Define what that Actor wants to do with the system. Each of these things that the actor
wants to do with the system become a Use Case.
Step 4. For each of those Use Cases decide on the most usual activity the Actor performs while
using the system.
Step 5. Describe that basic activity in the description for the use case.
Describe it as "Actor does something, system does something. Actor does
something, system does something." but keep it at a high level. Do not mention
any GUI specifics for example. Also you only describe things that the system
does that the actor would be aware of and conversely you only describe what the
actor does that the system would be aware of.
Step 6. Once you're happy with the basic activity now consider alternatives – these become
“extending use cases”
Step 7. Review each Use Case descriptions against the descriptions of the other Use Cases.
Notice any glaring commonality. Extract those out as your common activity (used) Use Cases.
Note that this is the only valid way of finding "used" Use Cases.
Joseph Lewis Aguirre
Page 6
Use Case Tutorial
The used, common activity, Use Cases are actually the least important of the Use Cases to find.
You would have a complete Use Case model even if you did no analysis of the Uses Cases to
find these common courses. This is important to remember. Of course if you did not extract these
common courses then you would not identify any commonality.
Step 8. Repeat steps 2 - 7 for each Actor.
Once you've got started and are comfortable with this process the next step is to begin to
understand the trade-offs that can be made. Simplicity versus "completeness" for example.
What Not To Put In
In developing the use case model one my have more formal or detailed information than is
needed. For example the fact that a Sales Order contains one or more Sales Order Lines or that
a Customer has an address or that a Customer has a name then this can be captured on a class
diagram. If one needs to capture the fact that the Actor selects an address from a list on a GUI
dialog then capture that either in an Object Sequence Diagram or in some GUI prototypes or both
if appropriate.
Only decompose as far as is useful in achieving the aims of Use Case modeling: capturing the
high-level user functional requirements for the purpose of scoping the project and serving as the
basic unit of estimation and deliverable.
Trade Offs
The rule of thumb: "if it's not useful to model it then don't". The converse is also true: "if it is
useful then you must model it." But remember you do not model everything in the Use Case
model - there are other modeling techniques !
Joseph Lewis Aguirre
Page 7
Use Case Tutorial