Chapter 6 Use Cases. What is a Use Case? A Use Case is a text story of some actor using a system to...

Chapter 6

Use Cases

What is a Use Case?

A Use Case is a text story of some actor using a system to meet one or more goals (or not).

Basic Use Case Components:

• Use Case Diagrams are light on detail• Text Use Cases contain most of the requirements• Use Case Diagrams show only high-level goals• Text Use Cases flesh out the details• Use Cases focus on what user needs are to be fulfilled

Fig. 6.1

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

Domain Model

Use-Case Model

Design Model: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

objects, attributes, associations

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

: System

enterItem(id, quantity)

Use Case Text

System Sequence Diagrams

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

Vision

SupplementarySpecification

Glossary

scope, goals, actors, features

terms, attributes, validation

non-functional reqs, quality attributes

requirements

Process Sale

1. Customer arrives ...2. Cashier makes new sale.3. ...

A sale consists of sellingone or more items

Use Case Tools

?

Example: (POS)

Process Sale:

A customer arrives at a checkout with items to purchase.

The cashier uses the POS system to record each purchased item.

The system presents a running total and line-item details.

The customer provides payment information, which the system validates and records.

The system updates inventory.

The customer receives a receipt and leaves the store.

brief format use case

Definitions:

• Actor: Something with behaviour; person (playing role), computer system or organization

• Scenario: Sequence of actions and interactions between actors and system. Also called use case instance. Just one story of usage, among many.

• Use Case: Collection of related success and failure scenarios.

Use Case (Casual Format):

• Handle Returns:

– Success: • Customer arrives at POS with item to return. Cashier uses

POS system to record return.

– Alternative Scenarios: • Unreturnable: Item was unreturnable due to special sale

conditions.• Failed Credit: Customer paid with credit card but card won’t

accept return so pay in cash.• Unknown Item: Computer can’t find item code, enter by hand• System Down: Use receipt book to hand-return item.

typical situation where main scenariois easy but exceptions make all the work

Use-Case Model (UP def’n):

• Collection of Use Cases within the Requirements discipline.

• Not the only UP Requirements artifact: Supplementary Specification, Glossary, Vision, Business Rules (p 101)

• Use Case Diagrams just for added context.

• Nothing OO about Use Cases.

Why Bother?

• Focusing on user goals early on keeps you looking at “what” and not “how” too soon.

• Customers understand their goals more than how a computer system may help meet them.

• Domain experts can contribute.

• User-centric; this is good since this is a document a user may very well see.

• Use Case strength is its ability to scale up or down in terms of level of detail.

Are Use Cases Functional Requirements?

• Yes, they describe what a system is supposed to do.

• A Use Case is a contract on how a system should behave.

• FURPS+ (p56)

• Use Cases are not a “features list”.

Three Kinds of Actors:

• Primary: Has goals fulfilled by using the system. Generally drives the Use Case definition

• Supporting: Provides a service to a system. Example, credit card check for POS. Often a computer system.

• Offstage: Has an interest but only indirectly (NYSTax)

Three Use Case Formats:

• Brief: One-paragraph summary (with title). We will use WikiTitles (AllOneWordWithCapitals) since these are also Wiki links.

• Casual: Multiple, short paragraphs describing various scenarios.

• Fully Dressed: All steps and variations in detail.

NOTE: After first Requirements Workshop only 10% of Use Cases are “fully dressed”. Other Use Cases are briefly or casuallydescribed.

Fully Dressed Use Case Format

Use Case Name WikiName, start with verbScope System boundaries (corp, prog)Level Summary, subfunction, etcPrimary Actor Primary system userStakeholders Who cares and what they wantPreconditions Must be true to startPostconditions What is guaranteed by successMain Success Scenario Typical, unconditional path scenarioExtensions Alternative success or failure scenariosSpecial Requirements Related non-functional requirements (RAM)Technology & Data Variations List

Varying IO methods and data formats

Frequency of Occurrence Is this system used oftenMiscellaneous Open issues; eg unmanageable failure scenarios

Fully Dressed Use Case (1):

• Scope: NextGenPOSApplication

• Level: User Goal

• PrimaryActor: Cashier

• StakeholdersAndInterests:

– cashier wants: …– customer wants: …– company wants: …– manager wants: …– government wants: …– CC company wants: …


• Preconditions: Cashier identified and authenticated• Postcondtions: Sale completed, tax calculated, inventory

updated, commission recorded, cc approval recorded• MainSuccessScenario:

1. Customer arrives with goods2. Cashier starts new sale3. Cashier enters item identifier4. Systems records sale and presents description and

running total (repeat 3-4 many times)1. System presents total2. …


• Extensions:

…

– 2-4a: Customer tells Cashier of tax-exempt status1. Cashier verifies, enters tax-exempt code

2. System records tax-exempt status of sale.

…

• SpecialRequirements:

– touch screen– cc authorization in 30 seconds or less– robustness of remote system (inventory) fails– internationalizable– …


• TechnologyAndDataVariations:

– manager override is card swipe or keyed entry– item ID is bar coded or keyed in– cc uses card reader or keyboard– signature on paper receipt

• Frequency:

– All the time.• OpenIssues:

– tax law variations– remote service recovery issue– business customization

Section Meanings:

• Scope: system boundary; two broad types of scope – system and business.

• Level: level of detail; user or sub-function.

– User level corresponds to elementary business process (EBP).

– Sub-function level supports some user level goal and factors out otherwise redundant description.

• Actor: Who asks the system to fulfil this goal?

• Stakeholders: Those interested in the system. System implements a contract with stakeholders.

What should be in a use case?That which satisfies all stakeholders’ interests

Section Meanings (2):

• Preconditions and Success Guarantees: Keep to the non-obvious. Otherwise, it is just “noise”.

– preconditions: what is true before each instance of the use case

– postconditions: always true on success.• Main Success Scenario: The “happy path”. This often has

no branches. Put conditions in Extension section. Bullets in this section record:

– an interaction between actors (system also an actor) that gets the scenario started

– a validation– a state change


• Extensions:

– Most of the text. – All the special cases. – Failure situations put here. – “Most” stakeholder concerns either here or in Main.

(Non-functional requirements elsewhere)– Be direct in your expression; not inferential or vague– Complex extensions can become separate use cases.– Notation:

• 4a is an exception for main scenario 4. • 3-6a extension can happen in main scenario steps 3-6. • *a can happen in every main scenario step.• Subsections of an extension section are “mini”-use cases.


• Special Requirements: This is the place for non-functional requirements, quality attributes or constraints. Include performance, reliability, usability, etc.

• Technology and Data Variations:

– Specify alternatives such as “print to file or printer”.– Specify the data formats, for example “data

exchanged in XML”. – Can express future plans for the system.

Use Cases: Written and Wrong!!

• Because of the iterative, evolutionary, time-boxed versus waterfall approach, initial use case are always “wrong” because they are always “incomplete”.

• Fill out your understanding when coding.

• Good reason for not using Waterfall.

Questions of Style (Essential Use Cases):

• The user says she needs to “log in”, meaning userID and password; you describe this as “authentication and authorization”. Don’t be more specific than you need to be.

• Results on use cases at right level of abstraction.

• Use cases should express “goals” not “means”.

• Use cases should express user “intentions” and system “responsibilities”, not concrete actions.

• Use cases are a “design” document; too early to get bogged down in details.

• This style results in black-box use cases – use cases that describe what but not how.

• “How” includes UI details; to be avoided.

An Actor-Goal Approach:

• Use cases should always perform an action that results in something useful for the primary actor.

• This guarantees that your write the use case at the appropriate level.

• Compare this to the “feature and function” list of the 1970s.

• Does it ever hurt to focus on what the customer values?

• Remember we are still early and still talking to the customer a lot; shouldn't get into implementation strategies.

How to Find Use Cases:

• Remember, use cases satisfy goals of primary actors so:

– choose a system boundary and identify the primary actors (often brainstorming the actors highlights the system boundaries)

– identify their goals vis-à-vis this system– define the use cases that achieve those goals

system actors, both primaryand secondary

Questions to Ask Yourself When Looking for Actors/Goals:

• Who starts and stops the system?

• Who does user and security management?

• Who does system administration?

• Is “time” an actor? Is the system event driven?

• Is the system monitored (cron job)?

• How about updates?

• Are their non-human primary actors (other systems)?

• Who evaluates performance and activity?

• Who looks at the logs?

• Who gets notified on error?

Organizing Actors and Goals

• Draw a little picture (Use-Case Diagram) for each (Actor,Goal) pair or make a list of actors and goals

• What goes in the picture? system boundary, primary and secondary actors, their goals; ie, the essence of a Use-Case.

Why focus on Actors and Goals?

• Don’t ask an actor “What do you do?”, ask “What are your goals?”

• “What do you do?” will illicit answers that

– describe how they do things, not what they do. – describe current practices not long-term needs

• “What are your goals?” will illicit answers that

– offer the opportunity to think of new and improved solutions

– focus on business value, not business function– get to the heart of what stakeholders want– give more opportunity for developer creativity

Example: Worker Punch Clock System ReplacementActor What do you do? What is your goal?

worker Punch my card when I get to work, go to and return from lunch, go home

Accurately record the time I am on the job

Book-keeper Transfer worker daily “on-site” hours to book-keeping system,calculate hours.

Know how many hours each worker has worked

boss Sign off on book-keeper Hours and Wages Report, resolve disagreements

Pay only for hours worked. Keep workers from “punching in” for one another

Potential Solutions

• Computerized login/passwd screen.

• Employee ID card magnetic strip reader

• Biometric palm reader

Only the “goals” approach directly lead us to the third solution.

Fig. 6.2

Goal: Process sales

Cashier

Customer

POS System

Checkout Service

Goal: Buy items

Enterprise Selling Things

Sales TaxAgency

Goal: Collect taxes on sales Sales Activity

System

Goal: Analyze sales and performance data

Why is the customer not the primary actor for the POS system?Depends on system boundary.

system boundary

some actors areother systems

some actors are“offstage”

Alternatives for Finding Actors/Goals/Use Cases:

• Start with an External Event Analysis. Responding to external events is what systems do.

• One use case per user goal

• Use Case names should be wiki names starting with a verb

• Exception: insert/update/delete are grouped as one use case – manage().

Use Case Tests:

• Boss Test: Especially for the “architecturally significant” use cases, your boss should think this is essential to the business.

• EBP Test: An Elementary Business Process is defined as

• Size Test: Use cases that you can express in less than a page are often not significant. Fully-dressed use cases take 3-10 pages to explain.

A task performed by one person in one place at one time,in response to a business event, that adds measurable value to the business and leaves business data in a consistent state.

Exercise:

• Test the following possible use cases:

– negotiate a supplier contract– handle returns– log in– move pieces on a game board

Exercise:

• Test the following possible use cases:

– negotiate a supplier contract• broader and longer than an EBP, “business” not “system”

use case

– handle returns• Boss, EBP and Size all seem to fit

– log in• never keep boss happy

– move pieces on a game board• too big

Fig. 6.3

NextGen POS

Manage Users

. . .

Cashier

SystemAdministrator

actor

use case

communicationsystem boundary

PaymentAuthorization

Service

«actor»Tax Calculator

«actor»Accounting

System

alternatenotation for a computer system actor

«actor»HR System

Cash In

«actor»Sales Activity

System

Manage Security

Analyze Activity

Customer

Manager

Process Sale

Handle Returns

A Use Case Diagram: Actors (primary and secondary), System Boundary and Goals

Fig. 6.4

NextGen

Process Sale

. . .Cashier

Show computer system actors with an alternate notation to human actors.

primary actors on the left

supporting/offstage actors on the right

For a use case context diagram, limit the use cases to user-goal level use cases.

«actor»Payment

AuthorizationService

Fig. 6.5

NextGen

Process Sale

«system»Payment


...

«actor»Payment


Some UML alternatives to illustrate external actors that are other computer systems.

The class box style can be used for any actor, computer or human. Using it for computer actors provides visual distinction.

PaymentAuthorization

Service

Alternative Notational Systems

An explanatory note;ULM provides for these

Activity Diagrams:

• A UML diagram for visualizing workflows and business processes.

• Show the inter-relatedness of various use cases

• page 477

Fig. 28.1

Receive Video Order

Fill Order Send Invoice

Deliver Order

Receive Payment

Close Order

Fulfillment Customer Service

Finance

Order

Invoice

start

Action. It does something. There is an automatic transition on its completion.

A transition supports modeling of control flow.

Fork. One incoming transition, and multiple outgoing parallel transitions and/or object flows.

Partitions. Show different parties involved in the process

Join. Multiple incoming transitions and/or object flows; one outgoing transition.

The outgoing continuation does not happen until all the inputs arrive from all flows.

Object Node. An object produced or used by actions. This allows us to model data flows or object flows.

end of activity

Fig. 28.7

[ cash payment ]

Enter Cart Items

Calculate Taxes and Discounts

Customer Cashier NextGen POS

Receipt

Shop and Fill Cart

Cart

Submit Authorization

Request

[ else ]

Create Receipt

Hand Over Items

Authorization Service

Authorize Payment

actors

actions

objects

control flow

data flow

Motivation:

• Focusing on user goals:

– keeps the user happy.– keeps you from writing a long features list.

• Writing a use case in a context of a typical scenario

– keeps you working at the right level– aids in cohesion and reduces coupling

Example: In an Inventory System we have Product and Inventory objects and the job of adding a product to inventory.

Where to we put the responsibility of adding the Product? Does a Product add itself? Is the Inventory system responsible for adding things to itself?

An Aside:

A highly cohesive, lowly coupled system

Train-RailCar Example:add() method; where does it go?This is a “responsibility” question.

An Aside (continued):

An uncohesive, highly coupled system

One Final Note:

• The author says that some times a Use Case point-of-view is not always easy to come up with. In particular, for application servers, database back-ends and other middleware.

• This is unfortunate since a lot of work being done today is done on these kinds of back-end systems.

• However, many back-end activities are in support of front-end activities and so the front-end use cases can be an indirect guide to how these back-ends should evolve.

• As well, even back-end systems benefit from being developed, first from a point-of-view of “what” needs to be accomplished and only later, “how” to do that.

Fig. 6.6Monopoly Use Case Diagram

Monopoly Use Case Text:

• Scope: Monopoly Application

• Level: User Goal

• Primary Actor: Observer

• Stakeholders: Observer; easily observe game simulation output

• Main Scenario:

1. Observer requests new simulation, enters num players

2. Observer starts play.

3. System displays game trace after each play

4. Repeat 3. until game over or Observer cancels

Monopoly Use Case Text:

• Extensions:

– *a: At any time, system fails(System logs each move)

1. Observer restarts system

2. System detects failure and reconstructs correct state, continues

3. Observer chooses to continue• Special Requirements:

– Provide graphical and text trace modes

Use Cases and Iterative Methods:

• Functional requirements recorded in Use Cases

• In each iteration some Use Cases are developed, partially or completely.

• Use Case realizations drive the design and development.

• Use Cases influence documentation design

• Functional and system testing corresponds to Use Case Scenarios

• Development environment UIs are created to manage the most important Use Case scenarios

Use Case Evolution across Iterations:

Discipline Artifact Inception 1 week

Elab 14 weeks

Elab 24 weeks

Elab 33 weeks

Elab 43 weeks

Require-ments

Use CaseModel

2-day ReqWS, most UCs named, summarized10% in detail

Near end, 2-day ReqWSInsight from devel’ment30% in detail

Near end, 2-day ReqWSInsight from devel’ment50% in detail

Repeat, complete 70% of Use Cases in detail

Repeat, complete 90% of Use Cases in detail

Design DesignModel

none Design small set of high risk Reqs

repeat repeat Repeat, most things stable

Implemen-tation

Code, etc none Implement these

Repeat, 5% of final system built.



ProjectManage-ment

SW Devel Plan

Vague estimates

Estimates take shape

A little better A little better Most estimates reationally committed to.

Two more phases: Construction and Transition

UP Artifacts and their Timing:

Disciplne Artifact Incep

I1

Elab.

E1..En

Const.

C1..Cn

Trans.

T1..Tn

Business Modeling

Domain Model s

Require-ments

Use Case

Vision

Sup Specs

Glossary

s

s

s

s

r

r

r

r

Design Design ModelSW Architecture Document

ss

r

s – start r - refine

Fig. 6.7

January February

Use Case: Capture a Sale. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

Use Case: Handle Returns. . .Main Success Scenario:1. ...2. ...3. ...Extensions:

WhenOnce during inception. Short; do not try to define or polish all requirements.

Several times during elaboration iterations.

WhereAt a requirements workshop.

WhoMany, including end users and developers, will play the role of requirements specifier, helping to write use cases.

Led by system analyst who is responsible for requirements definition.

How: ToolsSoftware: For use case text, use a web-enabled requirements tool

that integrates with a popular word processor.For use case diagrams, a UML CASE tool.Hyperlink the use cases; present them on the project website.

Hardware: Use two projectors attached to dual video cards and set the display width double to improve the spaciousness of the drawing area or display 2 adjacent word processor windows .

Developer

CustomerSystemAnalyst

End User

Two adjacent projections.

SoftwareArchitect

Chapter 6 Use Cases. What is a Use Case? A Use Case is a text story of some actor using a system to...

Documents

Transcript of Chapter 6 Use Cases. What is a Use Case? A Use Case is a text story of some actor using a system to...