© 2010 bennett, mcrobb and farmer1 use case description supplementary material to support bennett,...

© 2010 Bennett, McRobb and Farmer 1

Use Case Description

Supplementary material to support Bennett, McRobb and Farmer:

Object Oriented Systems Analysis and Design Using UML, (4th Edition),

McGraw Hill, 2010.

2

© 2010 Bennett, McRobb and Farmer

In This Presentation You Will Learn:

• What is a Use Case Description

• The difference between essential and real use cases

• How to describe Use Cases informally as a step-by-step sequence of actions

• How to apply Cockburn’s template for formal Use Case Descriptions

3


What is a Use Case Description?

• A Use Case Diagram gives an overall view:– Of a system’s functionality (use cases)– How functions relate to each other at run-time

(«extends» and «includes» relationships)– How user roles (actors) interact with functions

• Use Case Diagrams do not show:– Sequence or iteration of inputs and outputs while a

use case executes– Alternative courses of action dependent on conditions– Pre-conditions for a use case to commence execution– Other meta-data about the use case

4


What is a Use Case Description?

• A Use Case Description addresses these limitations of the diagram

• There are several ways to document a Use Case Description, ranging from very informal to very formal

• Most organizations will have their own style and standard, often based on Cockburn’s (2001) template

5


Essential and Real Use Cases• Some authors distinguish between

essential and real use cases• An essential use case is quite abstract, and

makes no reference to design or technology aspects

• A real use case is implementation-oriented, referring to specific technologies (e.g. interface widgets, hardware devices, etc)

• For this presentation, we will focus mainly on essential use case descriptions

6


Informal Step by Step Descriptions

• It is often useful to describe a use case simply as a sequence of I/O:– User inputs something– System outputs something– User inputs something else– System outputs something else

• Very easy to confirm with users• Also gives developers lots of clues about

data, processing and screen content

7


Example #1: ‘Buy product’

Customer

Buy productonline

(this example is adapted from Fowler, 2003)

8


Imagine the Scenario

• If you buy something from a website, you probably:– Browse through several products– Choose one– Go to the checkout– Fill in some information– Get confirmation of the sale

9


Main Scenario: ‘Buy product’• Informal description:

Buy product online1. Customer browses catalogue2. System displays product details3. Customer selects item to buy, goes to check-out4. System displays shopping cart page5. Customer fills in delivery information6. System shows full pricing, including shipping7. Customer fills in credit card details8. System authorizes card, confirms sale on screen and

sends email to customer

(Note that ‘Shopping cart’ and ‘email’ are real aspects of this use case, while the rest of the description is essential)

10


Optional Steps

• Description also covers any alternative courses, and the triggers that initiate their execution:

Alternative course: Card fails to authorize• At step 8, system fails to authorize credit purchase.

• Return to step 7, allow customer to re-enter credit card

information, retry authorization.

11


What the Description tells us:

• Even an informal description gives a lot of information that is useful to the developer:– Sequence and any iteration of steps – what

order things should happen– I/O – fields, text boxes, buttons, etc needed

on the screen– Data – what must be stored or retrieved– Process – calculations, other steps that will

need coding– Alternatives – branch points in the sequence

12


Example #2: Training Administration System

Admin clerk

Book course

place

(this example is adapted from Skidmore and Eva, 2004)

13


Main scenario: ‘Book course place’

Book course place

1. Admin clerk retrieves scheduled course details

2. System displays number of places free

3. Admin clerk chooses ‘add delegate to a course’

4. System requests delegate details

5. Admin clerk enters delegate details

6. System stores details and confirms

14


Alternate course: no free places1. Admin clerk retrieves scheduled course

details

2a. System displays ‘no places free’

2a1. Admin clerk selects ‘search for dates with free places’

2a2. Systems displays dates with free places

2a3. Admin clerk selects date

(back to main course, step 4)

15


Alternate course: details missing4. System requests delegate details

5a. Admin clerk enters details that are known

5a1. Systems displays ‘reservation is conditional on full details – OK?’

5a2. Admin clerk clicks OK

(back to main course, step 6)

16


Formal Descriptions: Cockburn’s Template

• The usual basis for formal use case descriptions, this is divided into five main sections:– Characteristic Information: a summary of the

purpose and context of the use case– Description: Main Success Scenario, Extensions and

‘Technology and Data Variations List’ – (Optional) Related Information: non-functional

aspects, links to other use cases, etc.– (Optional) Open Issues: unresolved issues still to be

addressed– Schedule (for development)

17


Characteristic Information in detail• Goal in Context: what is this use case for?• Scope: the system (or systems) within which this use

case applies• Level: is this use case primary - called directly by the

actor?• Preconditions: what should be true for the use case to

execute?• Success End Condition: what should have changed

after it has executed?• Minimal Guarantee: what should minimally occur even if

the use case fails to achieve its main goal• Primary Actor: self explanatory• Trigger: what event causes execution to begin?

18


Description in detail

• Main Success Scenario: the steps of the scenario from trigger to success, including any final closing down (e.g. interfaces or database connections)

• Extensions: alternate courses are described here, also any calls to other «includes» or «extends» use cases

• Technology and Data Variations List: describes alternative ways that the use case might be implemented, e.g. to allow for different UI devices (say, touch screen vs keyboard and mouse interface)

19


Related Information (optional)

• Priority: how important is this use case to the project?• Performance Target: how quickly must the system

respond to input or complete execution?• Frequency: how often will it need to execute?• Subordinate Use Cases: other use cases on which this

one depends for its success• Channel to primary actor: how will the actor

communicate with the use case?• Secondary Actors: other actors who can initiate and

execute the use case• Channel to Secondary Actors: as above

20


Open Issues and Schedule

• Any unresolved questions should be described in enough detail for another developer to work on them later

• If the development schedule for this use case has been decided, it should be documented

21


Summary

In this presentation you have learned :• What a Use Case Description is • What is the difference between essential

and real use cases• How to describe Use Cases informally as

a step-by-step sequence of actions• How to apply Cockburn’s template for

formal Use Case Descriptions

22


References

• Fowler (2003)

• Skidmore and Eva (2004)

• Cockburn (2001)

(For full bibliographic details, see Bennett, McRobb and Farmer)

© 2010 bennett, mcrobb and farmer1 use case description supplementary material to support bennett,...

Documents

use case slide

formal use case descriptions

real use cases

functions use case diagrams

farmer essential

essential slide

farmer example

template slide