Use Cases for Requirements

� Today’s material: Arlow and Neustadtch. 4 and 5 Larman: part of chapter 6

� What are requirements?

Use Cases for Requirements

� Today’s material: Arlow and Neustadt ch. 4 Larman: part of chapter 6

� What are requirements? � Requirements (or specifications, or requirements specifications)

� “…are capabilities…to which the system…must conform”� – Larman p. 41 (2nd), p. 54 (3rd)

� “Requirements” also names a UP discipline� See Fig. next (or L. sect. 2.4 in 2nd ed., and 2.7 in 3rd ed.)

� …it is done throughout the project� Unlike in non-iterative life cycle models

� (e.g. waterfall model, fountain model)

Disciplines in the RUP

Modified from: http://dn.codegear.com/article/images/33319/RUP.JPG

Domain diagrams

Use cases

Sequence & Design class diagrams

Use Cases - Background

� A use case is a “case of use”� …that is, (generalized) example of usage

� Precise translation from the Swedish is “usage case”

� Invented by Ivar Jacobson in 1986

� Major advance in the book:

Writing Effective Use Cases,

Alistair Cockburn (“Coburn”), 2000

What is a Use Case?

� A use case is a story about using the system

� A use case is a set of related system use scenarios

� A use case is a set of related system use instances

� As a way to communicate among humans…

� Stories are

flexible and human-friendly

Use Cases for System Needs

� Because use cases are human friendly…� …they are a good way to capture needs

� They are stories about how a system can

meet needs

� Example for POS system (what’s another?)� Customer brings items to checkout counter. Cashier records each item. System displays each item & price, and current total. Customer provides

payment somehow. System validates it, logs it, and updates inventory data. System prints receipt and customer waves a cheery goodbye.

� the “somehow” can be expanded into multiple scenarios� E.g. L. p. 46 2nd ed., p. 63 3rd ed.

Stories Can Have Titles…

� The title of that use case could be

� “Process a customer with items to buy”

� Consider a course registration system

� A title of a use case might be

� “Process a student with courses to sign up for”

� Consider a project planning, or general UML editor system, or _______ system

� Write down a title for one use case…

� (We’ll have more to say about these in the future)

Use Case – What Is It?

� Set of related scenarios� (i.e. set of related use case instances)…� …in which actor(s) use the system…� …to meet some need

� Actor: something that behaves in some way� E.g. a cashier, a computer(?), a retail store, a customer…

� Not the system itself though

� What actors exist in a _____ or UML editing system?

� Need: a goal that the system can support � Buying things� Returning things� Determining what to order to restock inventory

Use Cases are Appropriately General

� Too specific: Joe Schmoe goes to the grocery store at 11:00 a.m. on Thursday to buy stuff for breakfast. In his basket he puts beer, chips, and the book “All About Healthy Breakfasts.” Then he…

� A use case instance (specific but not too specific): � one path through a use case.

� Example: someone goes to the store, puts items into a cart, proceeds to the cash only express line…

� Another example: . . .

� (scenario: same as a use case instance)

� A use case: set of “related…scenarios”

� Use case title: Handle Returns

� There is a main use case instance (scenario)

� Main success scenario

� Customer has items to return, cashier scans in each, gets total, gives refund

� Credit card expired use case instance

� Customer paid with credit card, but now can’t refund to the credit card account, so give cash

� Bar code missing scenario

� …

The Use Case as a

Set of Use Case Instances/Scenarios

Use Case Instances in the Use Case

� Write down a use case instance (scenario) for a project planning system use case, UML editor use case, or ____ use case

� …then…we’ll put a few on the board…

A Couple of Scenarios…

� Make new SSD or use case diagram

� E.g. Create, drag, drop a stick figure

� (User, mouse, computer have behaviors)

� Load and modify previously created diagram

� Use file browser to search the right .uml file, click to bring it up, ….

� (Monitor, file system have behaviors)

Recall ‘Actor’: something that behaves in some way

� What is the actor for each of these?

� Make SSD or use case diagram

� Create, drag, drop a stick figure

� User, mouse, computer

� Load and modify previously created diagram

� Use file browser to search for diagram in a .uml file, click to bring it up, ….

� Monitor, file system

� How about some other examples?

Use Cases – One Requirements Tool

� In the FURPS+ model, use cases…

� …are primarily oriented toward one letter

� Which letter? (See next slide to figure out)

FURPS+ Model for Requirements

� F is for Functionality� Things it does: features, etc.

� U is for Usability� Things that help people use it: help, documentation, ergonomics

� R is for Reliability� MTBF, availability, fail softness, etc.

� P is for Performance� Speed, resource consumption, accuracy, response delay, etc.

� S is for Supportability� Maintenance friendly, configuration support, international issues

� + is for other stuff� Like what?

Functionality: features vs. valuable features

� “…the software industry is littered with failed projects that did not deliver what people really needed” – Larman p. 48 (2nd ed.)� “Lack of user involvement …is near the top of the list of reasons for project failure” – p. 65 (3rd ed.)

� Requirements (hence, use cases) should� …focus on reaching goals and adding value� (…not on laundry lists of features)

� Otherwise, the system could end up with:� features that don’t add much value; and� important goals that aren’t actually met

Types of Use Cases I

� What-based (“black box”) use cases� Describe what system does� Do not describe how system does it� Example of a step:

� “system records the sale”

� How-based (“glass box”) use cases� Describe mechanism – how the system does it� Example of a step:

� “system records sale to database”

� Example 2: � “system issues SQL INSERT command”

� Which is better?

Types of Use Cases II:Essential Vs. Concrete Style

� Essential: “user is authenticated”

� Concrete: “user types name and password”

� Which captures intent?

� Which impacts UI?

� Which is good to do first?

� Which is good to do later?

Use Cases:Concrete Vs. Essential

versusWhat-Based Vs. How-Based

� Which pairs of terms are more-or-less synonymous?

Types of Use Cases III

� Brief – 1 paragraph of main use case instance� Casual – Multiple paragraphs

� each is a different use case instance (scenario)

� Fully dressed – Full details � …of each step� …of each variation� …with preconditions and postconditions

� (what are those?)� What is a precondition/postcondition for the UML editor?

� See: Arlow and Neustadt Figs. 4.9-4.11, 4.13-4.15, 5,5-5.6, 5.8-5.9, 5.11-5.13, etc.; Larman table on pp. 50-53 (2nd ed.), 68-72 (3rd ed.)

� A&N examples are short; reality can be over 1 or 2 pages

� Which might one write first? Second? Third?

Example of Use Case –brief format

� Customer brings items to checkout counter. Cashier records each item. System displays each item & price, and current total. Customer provides payment somehow. System validates it, logs it, and updates inventory data. System prints receipt and customer waves a cheery goodbye. (e.g. L. p. 46 (2nd), 63 (3rd))

� This “brief format” use case actually contains several use case instances…

Casual Format for Use Cases

� Like brief format, except:

� Multiple paragraphs instead of one

� Each paragraph covers a different scenario

� One paragraph is the main success scenario

� Other alternatives are in other paragraphs

Fully Dressed Use Case

http://api.ning.com/files/iaBxrA602vVRg-cJuQTS1k*p088*NcQhp87iZ6VY1VFILwHPGN*9ub*xBTW2VLoGSMcsTjf82l9-4E9JIaPA3MPR7rEEeG*h/dog.jpg

� Has multiple scenarios

� (Like casual format)

� Has numbered steps

� (Formal, not casual)

� Has extra sections

� Is fully detailed

Examples

See several figures in Arlow and Neustadt

- Note: you can have alternate subsections

- Step 6, alternate step 6a, and 6b

- Steps can have substeps

In Larman see Fig. p. 50 ff., 2nd ed.; p. 68 ff., 3rd ed.

Types of Use Cases IV:1-Column Vs. 2-Column

� Used for “fully dressed” use cases

� 2-Column (see e.g. L. p. 53, 2nd; p. 79, 3rd):� Left column is for things outside actors do

� Right column is for things the system does

� Makes the interaction with the system clear

� 1-Column:� More compact

� Various other format options exist

More Parts of the Use Case

� Main Success Scenario� “Happy path” typically with no branches

� It’s what you hope will happen

� Extension (to alternative paths)� All the (“not-so-happy”) branches off the main success scenario

� Can be several of them� steps numerically keyed to Basic Flow

� (5a instead of 5, etc.)

� longer than Basic Flow

The Fully Dressed Use Case

� Primary actor – the main system user

� Stakeholders and their interests –

� A use case should describe all behaviors needed to serve the stakeholder(s)

� …that is what should be in a use case

More Use Case Sections…

� Precondition –� something that must hold

� …before a use case begins

� Postcondition –� something that must hold

� …after a use case ends

� (Postcondition is also called

success guarantee)

Example?

More Parts of the Use Case

� Special Requirements

� Constraints that aren’t things the system does

� Technology and Data Variations List

� Requirements that are almost design-like in flavor

� We’re not designing yet

� but when we can’t avoid it entirely…

� …this is where these aspects go

…If Time Allows

� List some use cases for the _______ sysetm or UML editor system

� For one of them, list use case instances