IntroductionIntroduction Copyright, 2003 © Jerzy R. Nawrocki [email protected] Models and Analysis.
Use Cases [email protected] Requirements Engineering & Project Management Lecture 2.
-
Upload
derick-cole -
Category
Documents
-
view
222 -
download
1
Transcript of Use Cases [email protected] Requirements Engineering & Project Management Lecture 2.
Use CasesUse Cases
[email protected]/jnawrocki/require/
Requirements Engineering & Project ManagementLecture 2
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
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