2What is a Use Case?A Use Case is a text story of some actor using a system to meet one or more goals (or not).
3Basic Use Case Components: Use Case Diagrams are light on detailText Use Cases contain most of the requirementsUse Case Diagrams show only high-level goalsText Use Cases flesh out the detailsUse Cases focus on what user needs are to be fulfilled
4Fig. 6.1A sale consists of sellingone or more items?Use Case Tools
5Example: (POS) Process Sale: brief format use caseProcess Sale:A customer arrives at a checkout with items to purchase.The cashier uses the POS system to record each purchased item.The system presents a running total and line-item details.The customer provides payment information, which the systemvalidates and records.The system updates inventory.The customer receives a receipt and leaves the store.
6Definitions:Actor: Something with behaviour; person (playing role), computer system or organizationScenario: Sequence of actions and interactions between actors and system. Also called use case instance. Just one story of usage, among many.Use Case: Collection of related success and failure scenarios.
7Use Case (Casual Format): typical situation where main scenariois easy but exceptions make all the workHandle Returns:Success:Customer arrives at POS with item to return. Cashier uses POS system to record return.Alternative Scenarios:Unreturnable: Item was unreturnable due to special sale conditions.Failed Credit: Customer paid with credit card but card won’t accept return so pay in cash.Unknown Item: Computer can’t find item code, enter by handSystem Down: Use receipt book to hand-return item.
8Use-Case Model (UP def’n): Collection of Use Cases within the Requirements discipline.Not the only UP Requirements artifact: Supplementary Specification, Glossary, Vision, Business Rules (p 101)Use Case Diagrams just for added context.Nothing OO about Use Cases.
9Why Bother?Focusing on user goals early on keeps you looking at “what” and not “how” too soon.Customers understand their goals more than how a computer system may help meet them.Domain experts can contribute.User-centric; this is good since this is a document a user may very well see.Use Case strength is its ability to scale up or down in terms of level of detail.
10Are Use Cases Functional Requirements? Yes, they describe what a system is supposed to do.A Use Case is a contract on how a system should behave.FURPS+ (p56)Use Cases are not a “features list”.
11Three Kinds of Actors:Primary: Has goals fulfilled by using the system. Generally drives the Use Case definitionSupporting: Provides a service to a system. Example, credit card check for POS. Often a computer system.Offstage: Has an interest but only indirectly (NYSTax)
12Three Use Case Formats: Brief: One-paragraph summary (with title). We will use WikiTitles (AllOneWordWithCapitals) since these are also Wiki links.Casual: Multiple, short paragraphs describing various scenarios.Fully Dressed: All steps and variations in detail.NOTE: After first Requirements Workshop only 10% of UseCases are “fully dressed”. Other Use Cases are briefly or casuallydescribed.
13Fully Dressed Use Case Format Use Case NameWikiName, start with verbScopeSystem boundaries (corp, prog)LevelSummary, subfunction, etcPrimary ActorPrimary system userStakeholdersWho cares and what they wantPreconditionsMust be true to startPostconditionsWhat is guaranteed by successMain Success ScenarioTypical, unconditional path scenarioExtensionsAlternative success or failure scenariosSpecial RequirementsRelated non-functional requirements (RAM)Technology & Data Variations ListVarying IO methods and data formatsFrequency of OccurrenceIs this system used oftenMiscellaneousOpen issues; eg unmanageable failure scenarios
14Fully Dressed Use Case (1): Scope: NextGenPOSApplicationLevel: User GoalPrimaryActor: CashierStakeholdersAndInterests:cashier wants: …customer wants: …company wants: …manager wants: …government wants: …CC company wants: …
15Fully Dressed Use Case (2): Preconditions: Cashier identified and authenticatedPostcondtions: Sale completed, tax calculated, inventory updated, commission recorded, cc approval recordedMainSuccessScenario:Customer arrives with goodsCashier starts new saleCashier enters item identifierSystems records sale and presents description and running total(repeat 3-4 many times)System presents total…
16Fully Dressed Use Case (3): Extensions:…2-4a: Customer tells Cashier of tax-exempt statusCashier verifies, enters tax-exempt codeSystem records tax-exempt status of sale.SpecialRequirements:touch screencc authorization in 30 seconds or lessrobustness of remote system (inventory) failsinternationalizable
17Fully Dressed Use Case (3): TechnologyAndDataVariations:manager override is card swipe or keyed entryitem ID is bar coded or keyed incc uses card reader or keyboardsignature on paper receiptFrequency:All the time.OpenIssues:tax law variationsremote service recovery issuebusiness customization
18What should be in a use case? Section Meanings:Scope: system boundary; two broad types of scope – system and business.Level: level of detail; user or sub-function.User level corresponds to elementary business process (EBP).Sub-function level supports some user level goal and factors out otherwise redundant description.Actor: Who asks the system to fulfil this goal?Stakeholders: Those interested in the system. System implements a contract with stakeholders.What should be in a use case?That which satisfies all stakeholders’ interests
19preconditions: what is true before each instance of the use case Section Meanings (2):Preconditions and Success Guarantees: Keep to the non-obvious. Otherwise, it is just “noise”.preconditions: what is true before each instance of the use casepostconditions: always true on success.Main Success Scenario: The “happy path”. This often has no branches. Put conditions in Extension section. Bullets in this section record:an interaction between actors (system also an actor) that gets the scenario starteda validationa state change
20Failure situations put here. Section Meanings (3):Extensions:Most of the text.All the special cases.Failure situations put here.“Most” stakeholder concerns either here or in Main. (Non-functional requirements elsewhere)Be direct in your expression; not inferential or vagueComplex extensions can become separate use cases.Notation:4a is an exception for main scenario 4.3-6a extension can happen in main scenario steps 3-6.*a can happen in every main scenario step.Subsections of an extension section are “mini”-use cases.
21Specify alternatives such as “print to file or printer”. Section Meanings (4):Special Requirements: This is the place for non-functional requirements, quality attributes or constraints. Include performance, reliability, usability, etc.Technology and Data Variations:Specify alternatives such as “print to file or printer”.Specify the data formats, for example “data exchanged in XML”.Can express future plans for the system.
22Use Cases: Written and Wrong!! Because of the iterative, evolutionary, time-boxed versus waterfall approach, initial use case are always “wrong” because they are always “incomplete”.Fill out your understanding when coding.Good reason for not using Waterfall.
23Questions of Style (Essential Use Cases): The user says she needs to “log in”, meaning userID and password; you describe this as “authentication and authorization”. Don’t be more specific than you need to be.Results on use cases at right level of abstraction.Use cases should express “goals” not “means”.Use cases should express user “intentions” and system “responsibilities”, not concrete actions.Use cases are a “design” document; too early to get bogged down in details.This style results in black-box use cases – use cases that describe what but not how.“How” includes UI details; to be avoided.
24An Actor-Goal Approach: Use cases should always perform an action that results in something useful for the primary actor.This guarantees that your write the use case at the appropriate level.Compare this to the “feature and function” list of the 1970s.Does it ever hurt to focus on what the customer values?Remember we are still early and still talking to the customer a lot; shouldn't get into implementation strategies.
25identify their goals vis-à-vis this system How to Find Use Cases:Remember, use cases satisfy goals of primary actors so:choose a system boundary and identify the primary actors (often brainstorming the actors highlights the system boundaries)identify their goals vis-à-vis this systemdefine the use cases that achieve those goalssystemactors, both primaryand secondary
26Questions to Ask Yourself When Looking for Actors/Goals: Who starts and stops the system?Who does user and security management?Who does system administration?Is “time” an actor? Is the system event driven?Is the system monitored (cron job)?How about updates?Are their non-human primary actors (other systems)?Who evaluates performance and activity?Who looks at the logs?Who gets notified on error?
27Organizing Actors and Goals Draw a little picture (Use-Case Diagram) for each (Actor,Goal) pair or make a list of actors and goalsWhat goes in the picture? system boundary, primary and secondary actors, their goals; ie, the essence of a Use-Case.
28Why focus on Actors and Goals? Don’t ask an actor “What do you do?”, ask “What are your goals?”“What do you do?” will illicit answers thatdescribe how they do things, not what they do.describe current practices not long-term needs“What are your goals?” will illicit answers thatoffer the opportunity to think of new and improved solutionsfocus on business value, not business functionget to the heart of what stakeholders wantgive more opportunity for developer creativity
29Example: Worker Punch Clock System Replacement ActorWhat do you do?What is your goal?workerPunch my card when I get to work, go to and return from lunch, go homeAccurately record the time I am on the jobBook-keeperTransfer worker daily “on-site” hours to book-keeping system,calculate hours.Know how many hours each worker has workedbossSign off on book- keeper Hours and Wages Report, resolve disagreementsPay only for hours worked. Keep workers from “punching in” for one another
30Potential Solutions Computerized login/passwd screen. Employee ID card magnetic strip readerBiometric palm readerOnly the “goals” approach directly lead us to the third solution.
31Fig. 6.2 system boundary some actors are other systems some actors are “offstage”Why is the customer not the primary actor for the POS system?Depends on system boundary.
32Alternatives for Finding Actors/Goals/Use Cases: Start with an External Event Analysis. Responding to external events is what systems do.One use case per user goalUse Case names should be wiki names starting with a verbException: insert/update/delete are grouped as one use case – manage().
33Use Case Tests:Boss Test: Especially for the “architecturally significant” use cases, your boss should think this is essential to the business.EBP Test: An Elementary Business Process is defined asSize Test: Use cases that you can express in less than a page are often not significant. Fully-dressed use cases take 3-10 pages to explain.A task performed by one person in one place at one time,in response to a business event, that adds measurable valueto the business and leaves business data in a consistent state.
34negotiate a supplier contract handle returns log in Exercise:Test the following possible use cases:negotiate a supplier contracthandle returnslog inmove pieces on a game board
35negotiate a supplier contract Exercise:Test the following possible use cases:negotiate a supplier contractbroader and longer than an EBP, “business” not “system” use casehandle returnsBoss, EBP and Size all seem to fitlog innever keep boss happymove pieces on a game boardtoo big
36Actors (primary and secondary), System Boundary and Goals Fig. 6.3A Use Case Diagram:Actors (primary and secondary), System Boundary and Goals
42keeps you from writing a long features list. Motivation:Focusing on user goals:keeps the user happy.keeps you from writing a long features list.Writing a use case in a context of a typical scenariokeeps you working at the right levelaids in cohesion and reduces couplingExample: In an Inventory System we have Product and Inventory objectsand the job of adding a product to inventory.Where to we put the responsibility of adding the Product? Does a Productadd itself? Is the Inventory system responsible for adding things to itself?
43An Aside: A highly cohesive, lowly coupled system Train-RailCar Example:add() method; where does it go?This is a “responsibility” question.
44An Aside (continued):An uncohesive, highly coupled system
45One Final Note:The author says that some times a Use Case point-of-view is not always easy to come up with. In particular, for application servers, database back-ends and other middleware.This is unfortunate since a lot of work being done today is done on these kinds of back-end systems.However, many back-end activities are in support of front-end activities and so the front-end use cases can be an indirect guide to how these back-ends should evolve.As well, even back-end systems benefit from being developed, first from a point-of-view of “what” needs to be accomplished and only later, “how” to do that.
47Monopoly Use Case Text: Scope: Monopoly ApplicationLevel: User GoalPrimary Actor: ObserverStakeholders: Observer; easily observe game simulation outputMain Scenario:Observer requests new simulation, enters num playersObserver starts play.System displays game trace after each playRepeat 3. until game over or Observer cancels
48Monopoly Use Case Text: Extensions:*a: At any time, system fails(System logs each move)Observer restarts systemSystem detects failure and reconstructs correct state, continuesObserver chooses to continueSpecial Requirements:Provide graphical and text trace modes
49Use Cases and Iterative Methods: Functional requirements recorded in Use CasesIn each iteration some Use Cases are developed, partially or completely.Use Case realizations drive the design and development.Use Cases influence documentation designFunctional and system testing corresponds to Use Case ScenariosDevelopment environment UIs are created to manage the most important Use Case scenarios
50Use Case Evolution across Iterations: DisciplineArtifactInception1 weekElab 14 weeksElab 2Elab 33 weeksElab 4Require-mentsUse CaseModel2-day ReqWS, most UCs named, summarized10% in detailNear end, 2- day ReqWSInsight from devel’ment30% in detail50% in detailRepeat, complete 70% of Use Cases in detailRepeat, complete 90% of Use Cases in detailDesignnoneDesign small set of high risk ReqsrepeatRepeat, most things stableImplemen-tationCode, etcImplement theseRepeat,5% of final system built.10% of final system built.15% of final system built.ProjectManage-mentSW Devel PlanVague estimatesEstimates take shapeA little betterMost estimates reationally committed to.Two more phases: Construction and Transition
51UP Artifacts and their Timing: DisciplneArtifactIncepI1Elab.E1..EnConst.C1..CnTrans.T1..TnBusiness ModelingDomain ModelsRequire- mentsUse CaseVisionSup SpecsGlossaryrDesignDesign ModelSW Architecture Documents – start r - refine