Transcript Use Cases Requirements Engineering & Project Management Lecture 2

Requirements Engineering & Project Management
Lecture 2
Use Cases
[email protected]
www.cs.put.poznan.pl/jnawrocki/require/
Key Roles in XPrince
Analyst
Architect
Time
J.Nawrocki, Use Cases
Project Manager
Time
XPrince Artefacts
A&S Plan
Most Important Use Cases
Requirements Spec.
Mockup
Accept. Tests Frame
Analyst
J.Nawrocki, Use Cases
Architect. Vision & Tools
Init. Project Plan
Initial Prototype (code +
test cases)
Architect. Plan
GUI Design
Updat. Proj. Plan
Architect
Aim & Scope Architecture
Business Model and
System Scope
Project Manager
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.
J.Nawrocki, Use Cases
Agenda
• Historical Perspective
•
•
•
•
•
•
Introduction
XPrince Team
Project Lifecycle
The Analyst Role
The Architect Role
The Project
Manager Role
• Scaling up
• Conclusions
J.Nawrocki, Use Cases
• Scenarios vs. Use Cases
• Poorly-Written Use Case
• Patterns for Effective Use Cases
• Elicitation of Use Cases
• Use Cases vs. User Stories
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.html
http://www.jaczone.com/
J.Nawrocki, Use Cases
Ivar Jacobson
Addison-Wesley, 1992
J.Nawrocki, Use Cases
Use Case Diagram in UML
Find flight
Construct
itinerary
Travel
agent
Reserve
flight
Issue
ticket
J.Nawrocki, Use Cases
Airline
reservation
Merchant
bank
Agenda
• Historical Perspective
•
•
•
•
•
•
Introduction
XPrince Team
Project Lifecycle
The Analyst Role
The Architect Role
The Project
Manager Role
• Scaling up
• Conclusions
J.Nawrocki, Use Cases
• Scenarios vs. Use Cases
• Poorly-Written Use Case
• Patterns for Effective Use Cases
• Elicitation of Use Cases
• Use Cases vs. User Stories
Use Case as a set of scenarios
The same goal
Scenario #1
Scenario #2
Scenario #3
J.Nawrocki, Use Cases
Use Case
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.
J.Nawrocki, Use Cases
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.
J.Nawrocki, Use Cases
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.
J.Nawrocki, Use Cases
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:
...
J.Nawrocki, Use Cases
Agenda
•
•
•
•
•
•
Introduction
XPrince Team
Project Lifecycle
The Analyst Role
The Architect Role
The Project
Manager Role
• Scaling up
• Conclusions
J.Nawrocki, Use Cases
• Historical Perspective
• Scenarios vs. Use Cases
• Poorly-Written Use Case
• Patterns for Effective Use Cases
• Elicitation of Use Cases
• Use Cases vs. User Stories
Poorly written use case
Register for Course (Main Scenario)
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.
...
J.Nawrocki, Use Cases
Poorly written use case
Too much user interface detail.
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.
...
J.Nawrocki, Use Cases
Well-written use case
Register for Course (Main Scenario)
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.
...
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
Register for Course (Main Scenario)
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.
...
J.Nawrocki, Use Cases
Agenda
•
•
•
•
•
•
Introduction
XPrince Team
Project Lifecycle
The Analyst Role
The Architect Role
The Project
Manager Role
• Scaling up
• Conclusions
J.Nawrocki, Use Cases
• Historical Perspective
• Scenarios vs. Use Cases
• Poorly-Written Use Case
• Patterns for Effective Use Cases
• Elicitation of Use Cases
• Use Cases vs. User Stories
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
J.Nawrocki, Use Cases
Book trip
Search for flights
Promote vacations
Change booking
Cancel booking
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.
J.Nawrocki, Use Cases
Use case goal levels
Business
Level
Book trip
Book flight
Find flight
Reserve
seat
J.Nawrocki, Use Cases
User
Level
Book hotel
Find hotel
Reserve
room
Subfunction
Level
Agenda
•
•
•
•
•
•
Introduction
XPrince Team
Project Lifecycle
The Analyst Role
The Architect Role
The Project
Manager Role
• Scaling up
• Conclusions
• Historical Perspective
• Scenarios vs. Use Cases
• Poorly-Written Use Case
• Patterns for Effective Use Cases
• Elicitation of Use Cases
• Use Cases vs. User Stories
J.Nawrocki, Use Cases
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.
J.Nawrocki, Use Cases
Short Format
Actor
Description
Administrator
Person monitoring and controlling job control
system
Use Case
Description
Set Monitor Parameters Allow administrator to specify boundaries and
Precision of items being monitored
Select Monitor
Choose something to monitor (e.g. a process
or wait queue)
J.Nawrocki, Use Cases
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
J.Nawrocki, Use Cases
Fully Dressed Format (2)
Success Guarantees: Requestor has goods, correct budet ready do be
debited.
Trigger: Requestor decides to buy something.
Main Success Scenario
1. Requestor: Initiate a request.
2. Approver: Check money in the budget, check price of goods,
complete request for submission.
3. Buyer: Check contents of storage, find best vendor for goods.
4. Authorizer: Validate Approver’s signature.
...
Extensions
1a. Requestor does not know vendor or price: leave those parts blank
and continue.
J.Nawrocki, Use Cases
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?
J.Nawrocki, Use Cases
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.
J.Nawrocki, Use Cases
Agenda
•
•
•
•
•
•
Introduction
XPrince Team
Project Lifecycle
The Analyst Role
The Architect Role
The Project
Manager Role
• Scaling up
• Conclusions
• Historical Perspective
• Scenarios vs. Use Cases
• Poorly-Written Use Case
• Patterns for Effective Use Cases
• Elicitation of Use Cases
• Use Cases vs. User Stories
J.Nawrocki, Use Cases
Use Cases vs. User Stories
Use case
User story
Use case
User story
Customer
J.Nawrocki, Use Cases
Analyst
Use case
Summary
Behavioural description
Several scenarios & 1 goal
Good and bad use cases
Elicitation process
Use 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?
J.Nawrocki, Use Cases