Use CasesUse Cases

Jerzy.Nawrocki@put.poznan.plwww.cs.put.poznan.pl/jnawrocki/require/

Requirements Engineering & Project ManagementLecture 2

J.Nawrocki, Use Cases

Key Roles in XPrince

Project ManagerAnalyst Architect

Time Time

J.Nawrocki, Use Cases

ArchitectureAim

& ScopeXPrince Artefacts

Business Model and System Scope

Most Important Use Cases

Architect. Vision & Tools

Requirements Spec.

Mockup

Accept. Tests Frame

Initial Prototype (code + test cases)

GUI Design

A&S Plan

Init. Project Plan

Architect. Plan

Updat. Proj. Plan

Analyst Architect Project Manager

J.Nawrocki, Use Cases

Business Model & Scope: Use Cases

DeanDean: • Sets number of places for each MS Degree Programme.• Gets list of students assigned to each MS Programme.StudentStudent: • Enters her preferences by sequencing MS Degree Programmes

from the most to the least interesting.• Gets information about the MS Programme to which she has

been assigned.

J.Nawrocki, Use Cases

Agenda

•Historical Perspective•Scenarios vs. Use Cases•Poorly-Written Use Case•Patterns for Effective Use Cases•Elicitation of Use Cases•Use Cases vs. User Stories

• Introduction• XPrince Team• Project Lifecycle• The Analyst Role• The Architect Role• The Project

Manager Role• Scaling up• Conclusions

J.Nawrocki, Use Cases

Ivar Jacobson

1967: Ericsson, telecommunication systems

1985: Ph.D., Dep. of Computer Systems, The Royal Institute of Tech., Stockholm

1987: Founder of Objectory AB -> (Objectory Process)

1995: Objectory AB merges with Rational

2003: IBM buys Rational

http://www.analisi-disegno.com/uml/JacobsonInterview.htmlhttp://www.jaczone.com/

J.Nawrocki, Use Cases

Ivar Jacobson

Addison-Wesley, 1992

J.Nawrocki, Use Cases

Use Case Diagram in UML

Construct itinerary

Merchant bank

Find flight

Travel agent

Airline reservationReserve

flight

Issue ticket

J.Nawrocki, Use Cases

Agenda

•Historical Perspective•Scenarios vs. Use Cases•Poorly-Written Use Case•Patterns for Effective Use Cases•Elicitation of Use Cases•Use Cases vs. User Stories

• Introduction• XPrince Team• Project Lifecycle• The Analyst Role• The Architect Role• The Project

Manager Role• Scaling up• Conclusions

J.Nawrocki, Use Cases

The same goal

Use Case as a set of scenarios

Scenario #1

Scenario #2

Scenario #3

Use Case

J.Nawrocki, Use Cases

Behavioural scenario

Get Paid for Car AccidentActors: Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representativeScenario #11. Claimant submits claim with substantiating data.2. Insurance Company verifies that Claimant owns a valid policy.3. Insurance Company assigns Agent to examine the case.4. Agent verifies that all details are within policy guidelines.5. Insurance Company pays Claimant.

J.Nawrocki, Use Cases

Behavioural scenario

Get Paid for Car AccidentActors: Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representativeScenario #21. Claimant submits claim with substantiating data.2. Submitted data is incomplete and Insurance Company requests

missing information.3. Claimant supplies missing information.4. Insurance Company verifies that Claimant owns a valid policy.5. Insurance Company assigns Agent to examine the case.6. Agent verifies that all details are within policy guidelines.7. Insurance Company pays Claimant.

J.Nawrocki, Use Cases

Behavioural scenario

Get Paid for Car AccidentActors: Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representativeScenario #31. Claimant submits claim with substantiating data.2. Insurance Company verifies that Claimant owns a valid policy.3. Claimant does not own a valid policy, so Insurance Company

declines claim, notifies Claimant , records all this, and terminates proceedings.

J.Nawrocki, Use Cases

A use caseGet Paid for Car Accident

Actors: Claimant -- Accident victim making claim Insurance Company -- Company insuring Claimant Agent -- Insurance Company representativeMain Scenario1. Claimant submits claim with substantiating data.2. Insurance Company verifies that Claimant owns a valid policy.3. Insurance Company assigns Agent to examine the case.4. Agent verifies that all details are within policy guidelines.5. Insurance Company pays Claimant.Extensions1a. Submitted data is incomplete: 1a1. Insurance Company requests missing information. 1a2. Claimant supplies missing information.2a. Claimant does not own a valid policy: . . .

J.Nawrocki, Use Cases

Agenda

•Historical Perspective•Scenarios vs. Use Cases•Poorly-Written Use Case•Patterns for Effective Use Cases•Elicitation of Use Cases•Use Cases vs. User Stories

• Introduction• XPrince Team• Project Lifecycle• The Analyst Role• The Architect Role• The Project

Manager Role• Scaling up• Conclusions

J.Nawrocki, Use Cases

Poorly written use case

1. Display a blank schedule.2. Display a list of all classes in the following way: The left window

lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule.

3. Do.4. Student clicks on a course.5. Update the lower window to show the times the course is

available.6. Student clicks on a course time and then clicks on the „Add

Course” button. . . .

Register for Course (Main Scenario)

J.Nawrocki, Use Cases

Poorly written use case

1. Display a blank schedule.2. Display a list of all classes in the following way: The left window

lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule.

3. Do.4. Student clicks on a course.5. Update the lower window to show the times the course is

available.6. Student clicks on a course time and then clicks on the „Add

Course” button. . . .

Too much user interface detail.

J.Nawrocki, Use Cases

Well-written use case

1. Student requests a new schedule.2. The system prepares a blank schedule form and pulls in a list of

open and available courses from the Course Catalog System.3. Student selects primary and alternate courses from the available

offerings.4. For each course, the system verifies that the Student has the

necessary prerequisities and adds the Student to the course, marking the Student as „enrolled” in that course in the schedule.

. . .

Register for Course (Main Scenario)

J.Nawrocki, Use Cases

Other frequent defects

• Too many use cases at low goal levels („Authorize user”).

• Using a use case for non-behavioral information (e.g. forms description – use adornments).

• Too long (should be short, usually 3-9 steps).

• Not a complete goal accomplished (also lack of alternative behaviors description).

• Sentence fragments (e.g. omitting the actors’ names in steps).

J.Nawrocki, Use Cases

Poorly written use case

1. Display a blank schedule.2. Display a list of all classes in the following way: The left window

lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule.

3. Do.4. Student clicks on a course.5. Update the lower window to show the times the course is

available.6. Student clicks on a course time and then clicks on the „Add

Course” button. . . .

Register for Course (Main Scenario)

J.Nawrocki, Use Cases

Agenda

•Historical Perspective•Scenarios vs. Use Cases•Poorly-Written Use Case•Patterns for Effective Use Cases•Elicitation of Use Cases•Use Cases vs. User Stories

• Introduction• XPrince Team• Project Lifecycle• The Analyst Role• The Architect Role• The Project

Manager Role• Scaling up• Conclusions

J.Nawrocki, Use Cases

Patterns for effective use cases

User Valued TransactionsUser Valued Transactions:

Identify the valuable services that the system delivers to the actors to satisfy their business purposes.

Book tripSearch for flightsPromote vacationsCreate trip itineraryUpdate trip itineraryDelete trip itinerary

Book tripSearch for flightsPromote vacationsChange bookingCancel booking

J.Nawrocki, Use Cases

Patterns for effective use cases

Ever Unfolding StoryEver Unfolding Story:

Organize the use case set as a hierarchical story that can be either unfolded to get more detail or folded up to hide detail and show more context.

J.Nawrocki, Use Cases

Use case goal levels

Book hotelBook flight

User Level

Book trip Business Level

Find flightReserve

seat Find hotelReserve

room

Subfunction Level

J.Nawrocki, Use Cases

Agenda

•Historical Perspective•Scenarios vs. Use Cases•Poorly-Written Use Case•Patterns for Effective Use Cases•Elicitation of Use Cases•Use Cases vs. User Stories

• Introduction• XPrince Team• Project Lifecycle• The Analyst Role• The Architect Role• The Project

Manager Role• Scaling up• Conclusions

J.Nawrocki, Use Cases

Elicitation of Use Cases

• Breadth Before DepthBreadth Before Depth: Conserve your energy by developing an overview of your use cases first, then progressively add detail.

• Spiral DevelopmentSpiral Development: Develop use cases in an iterative, breadth-first manner, with each iteration prograssively increasing the precision and accuracy.

• Multiple FormsMultiple Forms: Select the format based on the risks associated with the project and the preferences of the people involved.

J.Nawrocki, Use Cases

Short Format

ActorActor

Administrator

Use CaseUse Case

Set Monitor Parameters

Select Monitor

DescriptionDescription

Person monitoring and controlling job control

system

DescriptionDescription

Allow administrator to specify boundaries and

Precision of items being monitored

Choose something to monitor (e.g. a process

or wait queue)

J.Nawrocki, Use Cases

Fully Dressed Format (1)

Buy SomethingPrimary ActorPrimary Actor: RequestorGoal in ContextGoal in Context: Requestor buys something through the system, gets it. Does not include paying for it.ScopeScope: Business – The overall purchasing mechanism, electronic adn non-electronic, as seen by the people in the company.LevelLevel: SummaryStakeholders and InterestsStakeholders and InterestsRequestorRequestor: Wants what he/she ordered.CompanyCompany: Wants to control spending but allow needed purchases.VendorVendor: Wants to get paid for any goods delivered.PreconditionPrecondition: None

J.Nawrocki, Use Cases

Fully Dressed Format (2)

Success GuaranteesSuccess Guarantees: Requestor has goods, correct budet ready do be debited.

TriggerTrigger: Requestor decides to buy something.Main Success ScenarioMain Success Scenario1.1. RequestorRequestor: Initiate a request.2.2. ApproverApprover: Check money in the budget, check price of goods,

complete request for submission.3.3. BuyerBuyer: Check contents of storage, find best vendor for goods.4.4. AuthorizerAuthorizer: Validate Approver’s signature.. . .ExtensionsExtensions1a. Requestor does not know vendor or price: leave those parts blank

and continue.

J.Nawrocki, Use Cases

Fully Dressed Format (3)

PriorityPriority: VariousResponse TimeResponse Time: VariousFrequencyFrequency: Three times a dayChannel to Primary ActorChannel to Primary Actor: Internet browser, mail system, or equivalentChannels to Secondary ActorsChannels to Secondary Actors: Fax, phone, carOpen IssuesOpen Issues:When is a canceled request deleted from the system?What authorization is needed to cancel a request?

J.Nawrocki, Use Cases

Elicitation of Use Cases

• Quitting TimeQuitting Time: Stop developing use cases once they are complete and satisfactorily meet audience needs.

• Writers LincenseWriters Lincense: Small diffrences in writing style are inevitable.

J.Nawrocki, Use Cases

Agenda

•Historical Perspective•Scenarios vs. Use Cases•Poorly-Written Use Case•Patterns for Effective Use Cases•Elicitation of Use Cases•Use Cases vs. User Stories

• Introduction• XPrince Team• Project Lifecycle• The Analyst Role• The Architect Role• The Project

Manager Role• Scaling up• Conclusions

J.Nawrocki, Use Cases

Use Cases vs. User Stories

Customer

User story

User story

Analyst

Use case

Use case

Use case

J.Nawrocki, Use Cases

Summary

Behavioural descriptionBehavioural descriptionSeveral scenarios & 1 goalSeveral scenarios & 1 goalGood and bad use casesGood and bad use casesElicitation processElicitation processUse cases and user storiesUse cases and user stories

J.Nawrocki, Use Cases

Questions?

J.Nawrocki, Use Cases

Quality assessment

1. What is your general impression? (1 - 6)2. Was it too slow or too fast?3. What important did you learn during the lecture?4. What to improve and how?