5What is a Use Case (I)A depiction of the following requirement informationBasic functionalityAny precondition for the functionalityFlow of events (scenario) for the functionalityAny postcondition for the functionalityAny error condition and alternative flow
6Why Use Cases? (I)Other requirements engineering methods have many limitationsDo not necessarily map well to design/codeRequire additional work/effort/thoughtDo not translate well to acceptance testsAre difficult for non-experts/other stakeholders to understandUse cases attempt to bridge the understandability gapDescribe system behavior, flows of eventsDescribe user requests and system responsesUseful in formulating test steps and verification pointsWhy not just the other requirements engineering techniques you learned about?
7Why Use Cases? (II)Together, the set of use cases specify the complete functionality of the systemBut they do not encompass all of the requirementsNot good for specifyingUser interfacesData formatsBusiness rulesNon-functional requirementsData format: e.g., a customer in our records consists of the following info…Business rules: e.g., what is a gold, bronze, silver member
8Why Use Cases? (II)Together, the set of use cases specify the complete functionality of the systemBut they do not encompass all of the requirementsNot good for specifyingUser interfacesData formatsBusiness rulesNon-functional requirementsProduce use cases in conjunction with other requirements engineering methods
9Use Cases: Keep it Simple This is a diagram of a use case.Use cases are a simple and powerful way to define requirements for software behavior
10Example: ATM Use Case Diagram This is a diagram of a use case.
11What is a Use Case? (II) Use cases are textual descriptions of Major functions the system will perform for its usersGoals the system achieves for its users along the wayA use case describes a set of flows or scenariosEach scenario is a sequence of steps describing an interaction between a “user” and a “system”The use case is a collection of scenarios that together accomplish a specific user “goal”Each scenario corresponds to a single path or flow through a use caseGoals e.g., creating a login, loggin in, user authorization, etc. as part of doing a bigger task within the systemSingle path/flow: e.g., scenario 1: PIN entered successfully. Scenario 2: PIN incorrect. Scenario 3: PIN incorrect 3 times, system boots user out
12Example: Buy a ProductA scenario is a sequence of steps describing an interaction between a user and a systemFor an online store, we might use narrative text to describe the following “Buy a Product” scenario*:“The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale.The system checks the authorization on the credit card and confirms the sale both immediately as well as with a follow-up .”*Adapted from “UML Distilled” by Martin Fowler
13Alternative Flows for Buy a Product In our Buy a Product scenario things went well…It is the “happy day” scenario or Basic FlowBut things can go wrong…The credit card authorization might failThis would be a separate scenario or Alternative FlowYou may not need to capture shipping and credit card information for returning customersThis is yet another scenario, a second alternative flowA use case is a set of scenarios serving a common goalThe user does not always succeed but the goal remains
14Alternative Flows for Buy a Product In our Buy a Product scenario things went well…It is the “happy day” scenario or Basic FlowBut things can go wrong…The credit card authorization might failThis would be a separate scenario or Alternative FlowYou may not need to capture shipping and credit card information for returning customersThis is yet another scenario, a second alternative flowA use case is a set of scenarios serving a common goalThe user does not always succeed but the goal remainsAnd there are usually multiple scenarios for success and “unsuccess.”A use case should capture all possible scenarios—successful and unsuccessful ones
15What is an Actor?Actors are not part of the system—they represent roles a user of the system can playAn actor may actively interchange information with the systemAn actor may be a provider or a receiver of information (or both)An actor can represent a human, a machine, or another system (e.g., software, hardware, database)
16Identifying Actors (I) Actors are discoveredIn any documents describing system scope/definitionBy talking with customers and domain expertsUseful questions for identifying actors include:Who uses the system?Who installs the system?Who starts up the system?Who shuts down the system?What other devices and external systems work directly with the system?
17Identifying Actors (II) Addition questions for identifying actors are:Who gets information from this system?Who provides information to the system?Does anything happen automatically at a preset time?Who is interested in a certain requirement?Where in the organization is the system used?Who will benefit from the use of the system?Who will support and maintain the system?Does the system use an external resource?Does one person play several different roles?Do several people play the same role?Does the system interact with a legacy system?Automatic: e.g., system sends when bill dueExternal resource: e.g., travel systems that use other (e.g., orbitz), similarly insurance quoting systems, paypal, UCI net IDLegacy system: an old system that is outdated in some way. Sometimes they keep them around for various reasons (too critical to take down, old data formats, still works well, etc.), but a new system will use them.
18What is a Use Case? (III)A use case is a dialogue between actors and the systemA use case is initiated by an actor to invoke a certain functionality in the systemA use case is a complete and meaningful flow of eventsA use case captures the contract or “guarantees” that will hold at the conclusion of the use case
19Benefits of Use CasesCapture the intended behavior of the system you are developingWithout having to specify how that behavior is implementedAllow developers to come to a common understanding with your system’s end users and domain expertsRealized by design and implementation elements working together to carry out each use caseHelp verify and validate your design and implementation featuresAgainst user goals and requested functions
20A Variety of ReadersMarketing personnel, human factors engineers, specialty engineers: Approve what the system should doSystem engineers: Ensure system requirements are met by the use casesReviewers: Examine the flow of eventsSoftware developers: Use as a basis for analysis, design, implementationSystem and software testers: Use as basis for test casesProject leads: Use for project planningTechnical writers: Use for writing the end user’s guideThese are not necessarily unique to use cases over req docs, all of these people and all those I told you about before with req docs might read req docs/use cases too. Neither list is exhaustive, just some possible types of people.
21Identifying Use Cases – Useful Questions What functions will the actor want from the system?Does the system store information? What actors will create, read, update, or delete that information?Does the system need to notify an actor about changes in its internal state?Are there any external events the system must know about? What actor informs the system about those events?What are the tasks of each actor?What use cases will support and maintain the system?Can all functional requirements be performed by the use cases?
22Use Case Flow of EventsDescribe only the events needed to accomplish required behavior of the use caseIn terms of what the system should do, not how it does itIn terms the audience (customer/stakeholder/other) will understandUsing business domain terminology, not implementation terminologyThe flow of events should describeWhen and how the use case starts and endsThe interactions (in sequence) between use case and actorsWhat data is needed by/exchanged during the use caseThe basic flow (normal sequence) of events for the use caseDescription of any alternative or exceptional flows of events
23Example Use Case: Buy a Product Level: Sea LevelBasic Flow (Main Success Scenario)Customer browses catalog and selects items to buyCustomer goes to check outCustomer fills in shipping informationSystem presents full pricing information, including shippingCustomer fills in credit card informationSystem authorizes purchaseSystem confirms sale immediatelySystem sends confirmation to customerAlternative Flow3a. Customer is regular (repeat) customer1. System displays current shipping, pricing, and billing information2. Customer may accept or override defaults, returns to BF at step 6
24Discussion (I) Begin by describing the Basic Flow Add variations Main success scenarioSequence of numbered stepsAdd variationsAlternative FlowsStill achieve the goal successfullyException FlowsFail to achieve the goal
25Discussion (II) Each use case has a primary actor Has the goal the use case is trying to achieveThere may be additional, secondary actorsEach step in the use case flow should be a clear, simple statementShow who is engaged and involved in the stepShow the intent of the actor—what the actor wants, not how the system does itTherefore do not describe or include UI details in the text of the use case steps
26Use Case Levels of Granularity (I) Cockburn’s use case level of granularity or “level” is useful but challengingCore use cases are at “sea level”An interaction with an actor toward a visible tangible goalCan be done at one sitting at a computerFish levelUse cases that are included by sea-level use casesKite levelShow how sea-level use cases fit into larger business contextAlso called summary-level or business-level use casesCannot be done in one sitting, and may require multiple people, organizations, and systems interactingEstablish your own conventions for levels for your projectExamples sea level: withdraw money, deposit check, check balanceFish level: Authorize customer, generate receiptKite level: Mange ATM operations, manage investments, manage loansThis is just one scheme, there are others, and you can make your own
27Use Case Levels of Granularity (II) Clamp level: e.g., put cursor in entry field
28Use Case “Includes”One use case includes another use case in its entiretyAnalogous to a program calling another or a routine using a subroutineThe “call” is mandatoryThe calling/including use case must flow through the included use caseAn application of reuse, modularity, anticipation of changeMultiple use cases share the same functionalityThis functionality is placed in a separate use caseAvoids repetition of the same information in multiple use casesExamplesLogon/logoffUser authentication/authorization
30Use Case “Extends” An extends relationship is used to show Optional behaviorBehavior that is only run under certain conditions, such as triggering an alarmAn “interruption” in the basic flow when the condition comes trueFor example, a use case that monitors the flow of packages on a conveyer belt can be extended by a Trigger Alarm use case if the packages jamTypically occurs when an alternative flow has gotten too big for a particular use case
31Example: Auto Purchasing System Differing schools of thought as to what “extends” really means and what should happen after the extended UC is finished—go back to main flow, terminate UC, or something else?
32Parts of a Use Case Use cases can be as simple as Or as complex as a paragraph of informal textOr as complex astemplate-based forms that remind developers what information to includeWhat to use depends on the formality level of the projectHigh formality -> formal templatesMid formality -> templates with some of the fieldsLow formality -> paragraphs of text
33Use Case Template Name/title Description Revision History Actors System ScopeGoalLevelAssumptionsRelationshipsIncludesExtendsExtension PointsPreconditionTrigger Events
35Use Case DiagramsA use case diagram is a graphical view of some or all of the actors, use cases, and their interactions identified for a systemEach system typically has a Main Use Case diagramA picture of the system boundary (actors) and the major functionality provided by the system (use case packages)Other use case diagrams may be created as neededA diagram showing all the use cases for a selected actorA diagram showing all the use cases being implemented in an iterationA diagram showing a use case and all of its relationships
38Use Case Model - Definition Consists ofUse casesIllustrating the system’s intended functions/behaviorsActorsIllustrating the system’s immediate surroundingsDiagramsIllustrating relationships between the system and its surroundingsThere will generally be one use case model per system, containing multiple use cases, actors, and diagrams
39Use Case Model – Purpose (I) Used as a unifying thread throughout developmentThe same use case model used in requirements is used in design, implementation, and testUsed to identifyWho will interact with the system and what the system should doWhat interfaces the system should haveOther related requirements documents may be linkedSecurity, performance, reusability, other “ilities”UI, reports, messages, outstanding items, other project management/tracking issues
40Use Case Model – Purpose (II) Used to communicate with the end users and domain expertsProvides buy-in at an early stage of developmentEnsures a mutual understanding of the requirementsUsed to verify thatAll behavioral (system interaction) requirements have been capturedDevelopers have understood the requirements
41Use Case Model – Purpose (II) Used to communicate with the end users and domain expertsProvides buy-in at an early stage of developmentEnsures a mutual understanding of the requirementsUsed to verify thatAll behavioral (system interaction) requirements have been capturedDevelopers have understood the requirementsThe most important role of a use case model is to communicate the system’s functionality and behavior to the customer or end user
42Use Cases: Not so Fast…If you don’t fully understand the ins and outs of use cases, it is easy to misuse them or turn them into “abuse” casesEllen Gottesdiener: “Top Ten Ways Project Teams Misuse Use Cases – and How to Correct Them.” The Rational Edge, June 2002 (Part I), July 2002 (Part II).Martin Fowler: “Use and Abuse Cases.” Distributed Computing, April 1998.Doug Rosenberg: “Top Ten Use Case Mistakes.” Software Development, February 2001.Susan Lilly: “How to Avoid Use Case Pitfalls.” Software Development, January 2000.Kulak and Guiney: “Use Cases: Requirements in Context.” Second Edition, Addison-Wesley 2003.
43Top Misguided Guidelines (Gottesdiener) Don’t bother with any other requirements representationsUse cases are the only requirements model you’ll need!Stump readers about the goal of your use caseName use cases obtusely using vague verbs such as “do” or “process”Include nonfunctional requirements and UI details in your use case textUse lots of extends and includes in your initial use case diagramsThis allows you to decompose use cases into tiny units of workInclude nonfunction req’s… SEPARATE CONCERNSUse lots of extends… INCREMENTALITY
44Ten Misguided Guidelines (Cont’d) Don’t involve subject matter experts in creating, reviewing, or verifying use casesThey’ll only raise questions!If you involve users in use cases definitions at all, just “do it”Why bother to prepare for meetings with the users?Write your first and only use case draft in excruciating detailWhy bother iterating with end users when they don’t even know what they want?Don’t validate or verify your use casesThat will only cause you to make revisions and do more rework!For meetings w/ users, come prepared with “focus questions” about how they accomplish the tasks they doWrite your first and only use case… INCREMENTALITYDon’t validate or verify… RIGOR AND FORMALITY
45Reminder: Fundamental Principles Rigor and formalitySeparation of concernsModularityAbstractionAnticipation of changeGeneralityIncrementalityTime for an example?These principles apply to all aspects of software engineering
46For Informatics 43 – Keep it simple We will do simple use case diagrams.It’s a model - don’t try to make the model do too much.Focus on the most important activities.For homework 1: no pictures. Use actor – use case style, e.g.:In discussion this week you will do slightly more complicated onesBank customer – withdraw cashStudent – enroll in courseWeb user – search by keywordTicket vendor – sell ticket
47Homework 1 Identify main use cases in the Use Cases section Expand on each one in the System Requirements Specification sectionMight have a section for each use case/actor
48SummarySystem behavior is documented in a use case model, illustratingintended functions (use cases)surroundings (actors)relationships between them (use case diagrams)The most important role of a use case model is to communicate the system’s functionality and behaviorWritten in concise, simple prose, use cases are understandable by a wide range of stakeholdersEach use case contains a flow of eventsWritten in terms of what the system should do, not how it should do it
49Don’t forget Homework 1 draft due tonight 11:55pm Introduction and Overview/Executive Summary
50Next Time Software architecture Quiz 2 Mythical Man Month Today’s lecture (use cases)MMM: Know the causes of late SW projects he suggests, Brooks’ Law, the purposes of use cases, what a use case, actor, diagram, etc. are and how to use them at a basic level. Basic, alternative, exception flow.