Use Case Overview

7/26/2019 Use Case Overview

1/29

An Introduction to Use Cases


2/29

Copyright 2002-2004 Serlio Software Development Corporation2

Outline

Why use cases?

What are actors and use cases?

How do we write use cases?


3/29


Unstable Requirements

Leading cause of runaway projects*

Most expensive errors to fix

Hardest errors to correct

User involvement is key

*Facts and Fallacies of Software Engineering, Robert L. Glass, 2003, Addison-Wesley


4/29


Software Project Success RateSource: Standish Group 1999

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

< $750k $750k -

$1.5M

$1.5M - $3M $3M - $6M $6M - $10M > $10M

Total Cost


5/29


Requirements Specifications

Easily misunderstood

Too large to comprehend

Hard to test for completeness

Provide no context


6/29


Why Use Cases?

The hard part: Build the rightthing

Describes behavior of the system

Easily understood by

Problem-oriented stakeholders

Solution-oriented stakeholders

Focus on actual system needs


7/29


Outline

Why use cases?




8/29


What Is An Actor?

A role, not a person

Human or non-human Three essential traits

External to the system

Interactswith the systemTries to achieve a goal

Claims adjuster


9/29


Why Define Actors?

Establishes need for a requirement

Focus on how the system is used

Defines system boundaries

Determines completeness

Shows who knows requirements


10/29

Copyright 2002-2004 Serlio Software Development Corporation 10

What Is a Use Case?

Describes one way to use thesystem

Essential traits:Centered around a goal

Describes stepsto achievethat goal

Written as a series of interactions

Yields a resultto the actor


11/29


Use Case Simple Example

Name: Generate QuotePrimary Actor:Insurance QuoterBrief Description:Insurance Quoter creates an insurance quote for her automobile.

Primary Flow:The use case begins when Insurance Quoter asks the system fora quote. The system asks Insurance Quoter for her homeaddress. After Insurance Quoter gives her name and address, thesystem asks what vehicle they would like to insure. InsuranceQuoter identifies the vehicle to insure. The system then presents

a list of coverages and levels. Insurance Quoter selects herdesired coverage levels and asks for the quote. The systempresents the quote, including the premium for each coverage.


12/29


Types of Requirements

Functional

Non-Functional

Usability Reliability

Portability

Supportability

+ (legal)

Terminology

The systemshould generate

insurance quotes. The system

should handle30,000 quote

requests perhour.


13/29


Outline

Why use cases?




14/29


The Use Case Writing Process

1. Identify actors2. Identify use cases3. Prioritize use cases4. Write use case descriptions5. Review and revise6. Go to step 3

Capture non-functional requirements Capture terminology


15/29


Identify Actors

Actor Name: Customer

Description:

A customer is an individual or business that currently has arelationship with the bank. For the purposes of the loanmanagement system, a customer is someone who holds anactive loan account or has been extended credit.

Goals:

Be informed of a payment due Make a loan payment

Check loan balance


16/29


Identify Use Cases

A use case is an event

Not an information flow

Not a process flow

Use a short, verb-nouncombination

Describe theinteraction

Reflect the actors goal

Evaluate LoanApplication

Close Out Loan

Generate LateNotice


17/29


Use Case Diagrams

Insurance Quoter

Generate Quote

Buy Coverage

Accounting System


18/29


Formality Of Use Cases

Brief

PrimaryScenario

FullyDressed


19/29


Detailing a Use Case

Name andBrief Summary

Primary Flow

(Interaction)

Alternate/Extension

Alternate/Extension

Alternate/ExtensionSupplementalInformation

PreconditionsSuccess guaranteeOther requirementsOpen issues


20/29


Primary Flow

Cancel Order Use Case

Flow of Events

1. The use case begins when the customer rep asks

the system to cancel an order.2. The customer rep searches for the order by order ID.

3. The system presents the order.

4. The customer rep marks the order as cancelled.

5. The system cancels the order.

6. The system tells the accounting subsystem to creditthe customers account.


21/29


Preconditions

Defines use case scopeand place

What has already happened?

Requiredstate of the system

Written in the present tense


22/29


Precondition Examples

The broker is logged on.

The order status is

complete.

The quote is valid.

The divert location is in

service.


23/29


Postcondition

A.K.A Success Guarantee

Requiredstate of the system

Written as an assertion, past tense

Describes the satisfied interests


24/29


Postcondition Examples

The email was sent.

The file was saved.

The policy was cancelled.

The system credited the

customers account.


25/29


Extensions

We know the main successscenario

The world doesnt work this way Software is no exception

We need a way to describe:

Failure conditionsAlternative/conditional steps in the

flow


26/29


Extensions: Mechanics

Insertion point

Extension

condition

Alternate steps


27/29


Extensions: Writing the Condition

Write as an assertion

That the system can detect

Identify the insertion point

Say what was detected

Replaces the insertion point step


28/29


Extension Example

Pack Order:

5. The packing clerk scans the item and places it in the carton.

6. The system records that the item was packed and updates the

order.

Extensions:

*a. The order management system is unavailable.

1.

6a. The item does not belong on the order.1.

6b. The order was cancelled.

1.

6c. The item has been recalled.


29/29


Summary

Why use cases?



Documents

Use Case Overview