Transcript Example: Withdraw

Applying Use Case Templates
Paul Grabow - Baylor University
Stephen Frezza – Gannon University
SWENET.org
1
Introduction

Who is the audience for this
presentation?

Students who have



What is the purpose of this
presentation?


Version 4
Read about use cases
Discussed use cases in class
To learn how to apply a use case template
Not to give a comprehensive intro to use
cases
SWENET.org
2
Some References





Version 4
Cockburn, Alistair,“Structuring Use Cases with Goals”, Journal of
Object-Oriented Programming, Sep-Oct 1997 & Nov-Dec 1997.
Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley,
2001.
Fowler, M., UML Distilled (3rd ed.), Addison Wesley, 2004.
Jacobson, Ivar, Object-Oriented software engineering: A UseDriven approach, Addison-Wesley, 1992.
Larman, C., Applying UML and Patterns (3rd ed.), Prentice-Hall,
2005.
SWENET.org
3
Use Case: Purpose



Version 4
To uncover and record functional
requirements
To serve as vehicle of communication
between customer and contractor
during requirements definition
Not to record non-functional
requirements
SWENET.org
4
Use Case: Vantage Point

From “outside” the system

As an observer of the system

System viewed as “black box”
Version 4
SWENET.org
5
Use Case “Pieces”

Name: Verb phrase that represents the goal
Scope: {Enterprise, System, Subsystem} Named
Level: {Summary/System, User, Sub function}
Pre-condition: Assumed to be true when UC

Success/Failure End Conditions: Must be true





Version 4
begins
(or false) after the UC finishes
Primary Actor: Who (or what) initiates the UC
Stakeholders & Interests: Who & why they care
SWENET.org
6
Use Case “Pieces”, cont.

Triggers, Guarantees: What event starts UC,

Main Success Scenario: Sequence of goal-

Extensions/Variations: Conditions plus

Related Information: Performance target, open
Version 4
what system promises to provide/do
achieving actions
actions/steps to handle branching conditions with
respect to any step in main success scenario
issues, schedule, super-use cases, sub use cases
SWENET.org
7
Use Case Template


From Alistair Cockburn
See

Version 4
http://alistair.cockburn.us/usecases/usecases.html
SWENET.org
8
Constructing a Use Case
1. Identify Actors & Goals
•
List the actors and the goals that the system will support
2. Identify System Success (and Failure)
•
Identify main goal (that adds value for the stakeholders)
•
Success: equivalent to the main goal; failure: inverse of
success
3. Define Main Success Scenario
•
Version 4
Describe ordered series of actions that achieve main goal
for typical actor (with no branching)
SWENET.org
9
Constructing a Use Case, cont.
4. Identify Extensions and Sub-variations
•
•
To cover branching and I/O alternatives
And superordinate and subordinate use
cases
5. Identify Related information
•
•
•
Version 4
Performance target
Open issues
Schedule
SWENET.org
10
System Success & Failure

Success



System



Directly responsible for success (or failure)
Cannot be responsible for what it cannot control
Actor(s)

Version 4
Defined with respect to the stakeholders
Often broader than the goal of the primary actor
Not directly responsible for success (or failure)
because not part of system
SWENET.org
11
Example: Create Bank Account
Goal in Existing customer requests new
Context: bank account
Scope: A single bank
Level: Primary
Pre-condition: None
Success End
Condition:
Failed End
Condition:
Version 4
If customer ID is valid, then Bank
account established
Bank account not established when
customer ID valid or bank account
established when ID invalid
SWENET.org
12
Example, cont.
Primary Actor: Teller
Stakeholders: Bank employees and customers
Trigger Event: Teller asks system for new
account
Version 4
SWENET.org
13
Example, cont.
Main Success Scenario
Actor Action
1. Request new account
System Action
2. Determine if ID valid
3. Generate new account
4. Return new account
number
5. Reads new account
number
Version 4
SWENET.org
14
Example, cont.
Extensions
Version 4
Condition
Action
3a. Invalid ID
Notify user: “Invalid ID”
SWENET.org
15
Example, cont.
Sub-variations
1.
Teller may enter ID by
a.
b.
c.
2.
Teller may read account number on
a.
b.
Version 4
Typing on a keyboard
Speaking into a microphone
Scanning a written form
Computer screen
Paper printed by the system
SWENET.org
16
Example, cont.

Superordinate use case:


Subordinate use case:


Version 4
None
IsIDValid
GenerateNewAccount
SWENET.org
17
Example, cont.

What would be some possible



Version 4
Performance targets?
Open issues?
Schedule
SWENET.org
18
Suggestions
Iterate: For each UC






Version 4
Not all information will be known/learned
at the same time
Okay to leave some things blank
Several iterations typical
A refinement process
More detail added over time
SWENET.org
19
Suggestions, cont.

After first version of scenario, can
you …
Split some actions for clarity?
 Partition actions that should be
developed together, or written later?
 Identify a group of actions that
should be a separate use case?
 Still claim that system is a black box?

Version 4
SWENET.org
20
Suggestions, cont.

Check scope



Is scope consistent with scenario?
Should scope be expanded? Restricted?
After several iterations of defining scenario,
identify
EXTENSIONS
SUB-VARIATIONS
Superordinate Use Case: <optional, name of use case that includes
this one>
Subordinate Use Cases: <optional, depending on tools, links to
sub.use cases>
Version 4
SWENET.org
21
Suggestions, cont.

After completing extensions and subvariations fill in
Performance Target: <the amount of time this use case should take>
OPEN ISSUES
SCHEDULE
Version 4
SWENET.org
22
Summary

Use case

Purpose:



Vantage point:



From outside system
System as a black box
Use case template provides


Version 4
To identify functional requirements
To server as vehicle of communication
“Check list”
Uniform format
SWENET.org
23