TORONTO

Chapter

Use Case Fundamentals for Business Analysts

Jason Questor
President
IIBA Toronto Chapter

Topics
1.
1.What
Whatis
isUse
UseCase
CaseTechnology?
Technology?
2.
2.Value
ValueProposition
Propositionfor
forthe
theITBA
ITBA
3.
3.Use
UseCase
CaseDiagrams
Diagrams
4.
4.Use
UseCase
CaseSpecifications
Specifications
5.
5.Next
NextSteps
Steps

TORONTO
Chapter

What is Use Case Technology?

Formalized process modeling focusing on areas of
the business selected for automation
Comprised of graphical diagrams and text-based
specifications
Included as part of the Unified Modeling Language,
currently in release 2
Governed by the Object Management Group
www.omg.org/uml

TORONTO
Chapter

Value Proposition for the ITBA

Establishment and management of product scope
Identification of interface points with humans and other
systems
Foundation documentation for:
User Acceptance Test Scenarios
System documentation
User Support
User Guides
Training Material

TORONTO
Chapter

Use Case Diagrams

A labeled box is used to indicate the functional boundaries of the
system in question. In UML 2.0 this box is known as the subject
Functional requirements are represented by ovals containing verbnoun phrases. These are the actual use cases
Outside the box, stick people are used to indicate humans and
other systems. These connect to the use cases with lines known
as associations
Video Rental System

Use Case
Sales
Clerk

TORONTO
Chapter

Step by Step Diagramming

2.
Actors

1.
The
Subject

3.
Use
Cases

Creating Use Case

Diagrams
4.
Associations

5.
Directed
Relationships

TORONTO
Chapter

Step 1: The Subject

The Subject is drawn as a rectangle, and is provided
with a functional label representing the role of the
system within the business
Anything drawn inside this rectangle is considered to be
within product scope
Anything outside the
rectangle is, by
Video Rental System
definition, out of scope
Use Case
Sales
Clerk

TORONTO
Chapter

The Subject: Nuances

Avoid naming the Subject with a project code name that
is not descriptive, such as Taurus System or Project
Ariel
Use business language that is meaningful to project
stakeholders and users
Child Diagrams and Code Names can be indicated as
follows:
Video Rental System
Name (codename) / Child
Use Case
Sales
Clerk

TORONTO
Chapter

Step 2: Actors
Anyone or anything that directly interacts with the
system is considered an Actor
People
Other automated systems, which may serve as Subjects
in their own diagrams
Time

The Stick Person icon is

used for all types

Video Rental System

Use Case
Sales
Clerk

TORONTO
Chapter

Actors: Nuances
The label applied to an actor represents their current
role as it relates to the interaction with the system
The same actual person, interacting variously as an
author, editor and publisher, would be shown as three
separate actor symbols
Avoid using proper
names of people
Video Rental System
Use Case
Sales
Clerk

TORONTO
Chapter

10

Step 3: Use Cases

Enclosed within ovals, use cases are labeled with
business language verb-noun phrases
The phrase represents a system behaviour that
accomplishes a business objective that is of value to at
least one actor
Generate Invoice
Register New User

Video Rental System

Use Case
Sales
Clerk

TORONTO
Chapter

11

Use Cases: Nuances

A Use Case Diagram is not a flowchart!
No ability to show sequence of steps, branches in logic
or loops
Use Cases simply represent a shopping list of
behaviours that may (or may not) be called upon by one
or more actors at some point in time
The system has no
Video Rental System
control over an actor
Rent Video

Sales
Clerk

TORONTO
Chapter

12

Step 4: Associations
A line drawn between an actor and a use case indicates
that they communicate with each other in some fashion
The diagram does not have the ability to indicate the
nature of this communication
Use cases may associate with multiple actors
remember that
no sequence is implied
Video Rental System
Rent Video
Sales
Clerk

TORONTO
Chapter

13

Associations: Nuances
When a use case is associated with multiple actors, at
least one of them must serve as a Primary Actor who
starts up the use case
Comments can be used to indicate that an actor is
considered primary for a given use case
Video Rental System

Rent Video

Primary
Actor
Sales
Clerk

TORONTO
Chapter

14

Step 5: Directed Relationships

Describe the relationships among use cases themselves
Not always required, but provide enhanced modeling
capabilities for automated business processes
Shown with dashed
arrows with open
Rent Video
arrowheads
<<include>>
<<extend>>

Adjust
Inventory

Apply
Promotion

TORONTO
Chapter

15

Directed Relationship: <<include>>

A Use Case may call upon other use cases to provide a
subset of required functionality
Base Use Case (the one that calls)
Inclusion Use Case (the one that is called)

Inclusion use cases are activated on a mandatory basis

Rent Video
Optimal configuration for
<<include>>
shared functionality
Reusable code
Ease of maintenance

TORONTO
Chapter

Update
Inventory

Return Video

<<include>>

16

<<include>>: Nuances
If an Inclusion Use Case is considered to be only a
behaviour fragment, it cannot be directly instantiated by
Actors through associations
On the other hand, Inclusion Use Cases that are
complete behaviours may be directly instantiated by
Actors
Rent Video
<<include>>
Without the activation of
Update
its inclusions, a Base Use
Inventory
Case is considered an
<<include>>
Return Video
incomplete behaviour
TORONTO
Chapter

17

Directed Relationship: <<extend>>

An Extension Use Case inserts a new behaviour known
as an Insertion Segment into a Base Use Case
This may involve additional or even replacement
behaviour
Represents special case processing, such as adding a
special holiday greeting
to a welcoming screen
Rent Video

Apply
Promotion

TORONTO
Chapter

<<extend>>

18

<<extend>>: Nuances
Extension Use Cases are normally used only for
behaviour fragments. As such they generally may not
be directly instantiated by an Actor through an
association.
Base Use Cases are considered to be complete
behaviours without the involvement of their extensions.
Rent Video

Apply
Promotion

TORONTO
Chapter

<<extend>>

19

Use Case Specifications

Provide a step by step text based script that documents
the transactional dialog between an actor and the
system.
Despite being called Specifications, these are
requirements based, and do not describe
technologically dependent details of how the system is
designed or how it accomplishes its behavioural tasks

TORONTO
Chapter

20

Sample Use Case Specification

1. The Use Case starts when the Sales Clerk selects Rent Video.
2. The system presents the Rent Video online form0specification / constraint.
3. The Sales Clerk enters the product code printed on the empty video box
provided by the customer.
4. The system presents video details including name of video, number in stock,
studio, year of production and director.
5. The system requests confirmation from the Sales Clerk.
6. The Sales Clerk acknowledges that this is the correct video.
7. The system requests the customers membership number for the Video Rental
Club.
8. The Sales Clerk provides the membership number for the Video Rental Club.
9. The System provides a Rental Agreement Invoice, and the Use Case ends.

TORONTO
Chapter

21

Specification: Nuances
Unless required by predetermined regulations or practices, avoid
using verbs such as displays, types, swipes, or prints, as these
indicate how a solution will be designed and implemented
A complete specification set may include many flows or scenarios
Main Flow: when everything is working well
Alternative Flows: Secondary flows showing conditional or exception
processing
If flows include elaborate conditional processing, you may want to
spin these conditional paths off to their own specification descriptions

TORONTO
Chapter

22

Putting It All Together

Video Rental System

Primary
Actor

Apply
Promotion

<<extend>>

Rent Video
Sales
Clerk

Chapter

<<include>>
Update
Inventory

Return Video

TORONTO

Credit Card
Company
System

<<include>>

23

Next Steps
5. Class
Diagrams
6. State Machine
Diagrams

4.
Collaboration
Diagrams

1. Use Case
Diagrams
3. Activity
Diagrams

2. Use Case
Specifications

Note: Order and level of IT Business Analyst involvement may change based on
expertise, project and client variables

TORONTO
Chapter

24