Use Cases

1
Use Cases
Requirements Engineering Project
Management Lecture 2

• Jerzy.Nawrocki_at_put.poznan.pl
• www.cs.put.poznan.pl/jnawrocki/require/

2
Key Roles in XPrince
Project Manager
Time
Time
3
XPrince Artefacts
Aim Scope
Business Model and System Scope
AS Plan
Most Important Use Cases
Architect. Vision Tools
Init. Project Plan
Architecture
Requirements Spec.
Initial Prototype (code test cases)
Architect. Plan
Mockup
Accept. Tests Frame
GUI Design
Updat. Proj. Plan
Project Manager
4
Business Model Scope Use Cases

• Dean
• Sets number of places for each MS Degree
  Programme.
• Gets list of students assigned to each MS
  Programme.
• Student
• 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.

5
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

6
Ivar Jacobson
1967 Ericsson, telecommunication systems 1985
Ph.D., Dep. of Computer Systems, The Royal
Institute of Tech., Stockholm 1987 Founder of
Objectory AB -gt (Objectory Process) 1995
Objectory AB merges with Rational 2003 IBM buys
Rational
http//www.analisi-disegno.com/uml/JacobsonIntervi
ew.html http//www.jaczone.com/
7
Ivar Jacobson
Addison-Wesley, 1992
8
Use Case Diagram in UML
Airline reservation
Travel agent
Merchant bank
9
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

10
Use Case as a set of scenarios
The same goal
Scenario 1
Use Case
Scenario 2
Scenario 3
11
Behavioural scenario
Get Paid for Car Accident Actors Claimant
-- Accident victim making claim
Insurance Company -- Company insuring
Claimant Agent
-- Insurance Company representative Scenario
1 1. 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.
12
Behavioural scenario
Get Paid for Car Accident Actors Claimant
-- Accident victim making claim
Insurance Company -- Company insuring
Claimant Agent
-- Insurance Company representative Scenario
2 1. 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.
13
Behavioural scenario
Get Paid for Car Accident Actors Claimant
-- Accident victim making claim
Insurance Company -- Company insuring
Claimant Agent
-- Insurance Company representative Scenario
3 1. 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.
14
A use case
Get Paid for Car Accident Actors Claimant
-- Accident victim making claim
Insurance Company -- Company insuring
Claimant Agent
-- Insurance Company representative Main
Scenario 1. 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. Extensions 1a. Submitted data is
incomplete 1a1. Insurance Company requests
missing information. 1a2. Claimant supplies
missing information. 2a. Claimant does not own a
valid policy . . .
15
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

16
Poorly written use case
Register for Course (Main Scenario)

• Display a blank schedule.
• 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.
• Do.
• Student clicks on a course.
• Update the lower window to show the times the
  course is available.
• Student clicks on a course time and then clicks
  on the Add Course button.
• . . .

17
Poorly written use case
Too much user interface detail.

• Display a blank schedule.
• 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.
• Do.
• Student clicks on a course.
• Update the lower window to show the times the
  course is available.
• Student clicks on a course time and then clicks
  on the Add Course button.
• . . .

18
Well-written use case
Register for Course (Main Scenario)

• Student requests a new schedule.
• The system prepares a blank schedule form and
  pulls in a list of open and available courses
  from the Course Catalog System.
• Student selects primary and alternate courses
  from the available offerings.
• 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.
• . . .

19
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).

20
Poorly written use case
Register for Course (Main Scenario)

• Display a blank schedule.
• 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.
• Do.
• Student clicks on a course.
• Update the lower window to show the times the
  course is available.
• Student clicks on a course time and then clicks
  on the Add Course button.
• . . .

21
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

22
Patterns for effective use cases
User Valued Transactions Identify the valuable
services that the system delivers to the actors
to satisfy their business purposes.
Book trip Search for flights Promote
vacations Create trip itinerary Update trip
itinerary Delete trip itinerary
Book trip Search for flights Promote
vacations Change booking Cancel booking
23
Patterns for effective use cases
Ever 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.
24
Use case goal levels
Why?
User Level
How?
25
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

26
Elicitation of Use Cases

• Breadth Before Depth Conserve your energy by
  developing an overview of your use cases first,
  then progressively add detail.
• Spiral Development Develop use cases in an
  iterative, breadth-first manner, with each
  iteration prograssively increasing the precision
  and accuracy.
• Multiple Forms Select the format based on the
  risks associated with the project and the
  preferences of the people involved.

27
Short Format
Actor Administrator Use Case Set Monitor
Parameters Select Monitor
Description Person monitoring and controlling job
control system Description Allow administrator
to specify boundaries and Precision of items
being monitored Choose something to monitor (e.g.
a process or wait queue)
28
Fully Dressed Format (1)
Buy Something Primary Actor Requestor Goal in
Context Requestor buys something through the
system, gets it. Does not include paying for
it. Scope Business The overall purchasing
mechanism, electronic adn non-electronic, as seen
by the people in the company. Level
Summary Stakeholders and Interests Requestor
Wants what he/she ordered. Company Wants to
control spending but allow needed
purchases. Vendor Wants to get paid for any
goods delivered. Precondition None
29
Fully Dressed Format (2)

• Success Guarantees Requestor has goods, correct
  budet ready do be debited.
• Trigger Requestor decides to buy something.
• Main Success Scenario
• Requestor Initiate a request.
• Approver Check money in the budget, check price
  of goods, complete request for submission.
• Buyer Check contents of storage, find best
  vendor for goods.
• Authorizer Validate Approvers signature.
• . . .
• Extensions
• 1a. Requestor does not know vendor or price
  leave those parts blank and continue.

30
Fully Dressed Format (3)
Priority Various Response Time
Various Frequency Three times a day Channel to
Primary Actor Internet browser, mail system, or
equivalent Channels to Secondary Actors Fax,
phone, car Open Issues When is a canceled
request deleted from the system? What
authorization is needed to cancel a request?
31
Elicitation of Use Cases

• Quitting Time Stop developing use cases once
  they are complete and satisfactorily meet
  audience needs.
• Writers Lincense Small diffrences in writing
  style are inevitable.

32
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

33
Use Cases vs. User Stories
34
Summary
At last!

• Behavioural description
• Several scenarios 1 goal
• Good and bad use cases
• Elicitation process
• Use cases and user stories

35
Questions?
?
36
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?