Applying Use Case Templates

1
Applying Use Case Templates

• Paul Grabow - Baylor University
• Stephen Frezza Gannon University

2
Introduction

• Who is the audience for this presentation?
• Students who have
• Read about use cases
• Discussed use cases in class
• What is the purpose of this presentation?
• To learn how to apply a use case template
• Not to give a comprehensive intro to use cases

3
Some References

• 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 Use-Driven approach,
  Addison-Wesley, 1992.
• Larman, C., Applying UML and Patterns (3rd ed.),
  Prentice-Hall, 2005.

4
Use Case Purpose

• 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

5
Use Case Vantage Point

• From outside the system
• As an observer of the system
• System viewed as black box

6
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 begins
• Success/Failure End Conditions Must be true (or
  false) after the UC finishes
• Primary Actor Who (or what) initiates the UC
• Stakeholders Interests Who why they care

7
Use Case Pieces, cont.

• Triggers, Guarantees What event starts UC, what
  system promises to provide/do
• Main Success Scenario Sequence of goal-achieving
  actions
• Extensions/Variations Conditions plus
  actions/steps to handle branching conditions with
  respect to any step in main success scenario
• Related Information Performance target, open
  issues, schedule, super-use cases, sub use cases

8
Use Case Template

• From Alistair Cockburn
• See
• http//alistair.cockburn.us/usecases/usecases.html

9
Constructing a Use Case

• Identify Actors Goals
• List the actors and the goals that the system
  will support
• Identify System Success (and Failure)
• Identify main goal (that adds value for the
  stakeholders)
• Success equivalent to the main goal failure
  inverse of success
• Define Main Success Scenario
• Describe ordered series of actions that achieve
  main goal for typical actor (with no branching)

10
Constructing a Use Case, cont.

• Identify Extensions and Sub-variations
• To cover branching and I/O alternatives
• And superordinate and subordinate use cases
• Identify Related information
• Performance target
• Open issues
• Schedule

11
System Success Failure

• Success
• Defined with respect to the stakeholders
• Often broader than the goal of the primary actor
• System
• Directly responsible for success (or failure)
• Cannot be responsible for what it cannot control
• Actor(s)
• Not directly responsible for success (or failure)
  because not part of system

12
Example Create Bank Account
Goal in Context Existing customer requests new bank account
Scope A single bank
Level Primary
Pre-condition None
Success End Condition If customer ID is valid, then Bank account established
Failed End Condition Bank account not established when customer ID valid or bank account established when ID invalid
13
Example, cont.
Primary Actor Teller
Stakeholders Bank employees and customers
Trigger Event Teller asks system for new account
14
Example, cont.
Main Success Scenario
Actor Action System Action
1. Request new account
2. Determine if ID valid
3. Generate new account
4. Return new account number
5. Reads new account number
15
Example, cont.
Extensions
Condition Action
3a. Invalid ID Notify user Invalid ID

16
Example, cont.

• Sub-variations
• Teller may enter ID by
• Typing on a keyboard
• Speaking into a microphone
• Scanning a written form
• Teller may read account number on
• Computer screen
• Paper printed by the system

17
Example, cont.

• Superordinate use case
• None
• Subordinate use case
• IsIDValid
• GenerateNewAccount

18
Example, cont.

• What would be some possible
• Performance targets?
• Open issues?
• Schedule

19
Suggestions

• Iterate For each UC
• 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

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

21
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 ltoptional, name of use
  case that includes this onegt
• Subordinate Use Cases ltoptional, depending on
  tools, links to sub.use casesgt

22
Suggestions, cont.

• After completing extensions and sub-variations
  fill in
• Performance Target ltthe amount of time this use
  case should takegt
• OPEN ISSUES
• SCHEDULE

23
Summary

• Use case
• Purpose
• To identify functional requirements
• To server as vehicle of communication
• Vantage point
• From outside system
• System as a black box
• Use case template provides
• Check list
• Uniform format