swenet.org1 applying use case templates paul grabow - baylor university stephen frezza – gannon...

SWENET.org 1

Applying Use Case Templates

Paul Grabow - Baylor UniversityStephen Frezza – Gannon

University

SWENET.org 2Version 4

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


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.


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


Use Case: Vantage Point From “outside” the system

As an observer of the system

System viewed as “black box”


Use Case “Pieces” NameName: Verb phrase that represents the goal ScopeScope: {Enterprise, System, Subsystem}

Named LevelLevel: {Summary/System, User, Sub function} Pre-conditionPre-condition: Assumed to be true when UC

begins Success/Failure End ConditionsSuccess/Failure End Conditions: Must be

true (or false) after the UC finishes Primary ActorPrimary Actor: Who (or what) initiates the UC Stakeholders & InterestsStakeholders & Interests: Who & why they

care


Use Case “Pieces”, cont. Triggers, GuaranteesTriggers, Guarantees: What event starts

UC, what system promises to provide/do Main Success ScenarioMain Success Scenario: Sequence of

goal-achieving actions Extensions/VariationsExtensions/Variations: Conditions plus

actions/steps to handle branching conditions with respect to any step in main success scenario

Related InformationRelated Information: Performance target, open issues, schedule, super-use cases, sub use cases


Use Case Template From Alistair Cockburn See

http://alistair.cockburn.us/usecases/usecases.html


Constructing a Use Case1.1. Identify Actors & GoalsIdentify Actors & Goals

• List the actors and the goals that the system will support

2.2. Identify System Success (and FailureIdentify System Success (and Failure)• Identify main goal (that adds value for the stakeholders)

• Success: equivalent to the main goal; failure: inverse of success

3.3. Define Main Success ScenarioDefine Main Success Scenario• Describe ordered series of actions that achieve main goal for

typical actor (with no branching)


Constructing a Use Case, cont.

4.4. Identify Extensions and Sub-Identify Extensions and Sub-variationsvariations

• To cover branching and I/O alternatives• And superordinate and subordinate use

cases

5.5. Identify Related informationIdentify Related information• Performance target• Open issues• Schedule


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


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


Example, cont.

Primary Actor:

Teller

Stakeholders:

Bank employees and customers

Trigger Event:

Teller asks system for new account


Example, cont.

Main SuccessMain Success ScenarioScenario

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


Example, cont.

ExtensionsExtensions

Condition Action

3a. Invalid IDNotify user: “Invalid ID”


Example, cont.

Sub-variationsSub-variations1. Teller may enter ID by

a. Typing on a keyboardb. Speaking into a microphonec. Scanning a written form

2. Teller may read account number ona. Computer screenb. Paper printed by the system


Example, cont. Superordinate use case:

None

Subordinate use case: IsIDValid GenerateNewAccount


Example, cont. What would be some possible

Performance targets? Open issues? Schedule


Suggestions

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


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?


Suggestions, cont. Check scope

Is scope consistent with scenario? Should scope be expanded? Restricted?

After several iterations of defining scenario, identify

EXTENSIONS

SUB-VARIATIONSSuperordinate Use Case: <optional, name of use case that

includes this one>Subordinate Use Cases: <optional, depending on tools, links

to sub.use cases>


Suggestions, cont. After completing extensions and

sub-variations fill in

Performance Target: <the amount of time this use case should take>

OPEN ISSUES

SCHEDULE


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

swenet.org1 applying use case templates paul grabow - baylor university stephen frezza – gannon...

Documents