Lecture 3 Use Cases • Use cases are scenarios for understanding system requirements • A use case is an interaction between users and a system • A use cases can be identified by talking to typical users and discussing the various things they might want to do with the application being prepared Use Case Model • The use-case model captures the goal of the user and the responsibility of the system to its users – The use case model describes the uses of the system and shows the events that can be performed – It shows a system in terms of its users and how it is being used from a user point of view Help Desk Make a call Take the call Client Operator The role of Use Cases • Use cases provide us with comprehensive documentation of the system under study • They represent the external view of the system – Use cases represent the things that the user is doing with the system, which can be different from the users goals • Each use or scenario represents what the user wants to do – It defines what happens in the system when the use case is performed – It must have a name and short textual description, no more than a few paragraphs • Jacobson et al. (1995) describe a use case as “a sequence of transactions in a system whose task is to yield results of measurable value to an individual actor of the system” 4 The role of the Use Case Model • The use case model tries to systematically identify uses of the system – and therefore the systems responsibilities • The use case model expresses what the application will do and not how – The use case model can also be known as a what model • Users are shown in the roles they play – they are named Actors Use case diagrams • Should capture those parts of the system visible to the outside • Actors are roles that people or systems play • Each use case must have a name Use Case Example • A patient calls the clinic to make an appointment for a yearly checkup. • The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. 7 Use Case Componentss • The use case has three components. • The use case task referred to as the use case that represents a feature needed in a software system. • The actor(s) who trigger the use case to activate. • The communication line to show how the actors communicate with the use case. Use Cases • The picture below is a Make Appointment use case for the medical clinic. • The actor is a Patient. The connection between actor and use case is a communication association (or communication for short). Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases. Use-Case Diagram A use case diagram is a collection of actors, use cases, and their communications. The use case description • How and when the use case begins and ends • The interaction between the use case and its actors, including when the interaction occurs and what is exchanged • How and when the use case will store data in the system • Exceptions to the flow of events Use Case Modeling Fowler and Scott (1997) 1. Capture the simple and normal use case first 2. For every step in the use case, identify – What could go wrong here? – How might this work out differently? 3. Extract common sequences into a new, shared use case with the includes associations 4. If you are adding more specialised or exceptional use cases, take advantage of use cases you already have with the extends association 12 Guidelines for Finding Use Cases • Sequential steps – For each actor, find the tasks and functions that the actor should be able to perform or that the system needs the actor to perform • The use case should represent a course of events that leads to a clear goal or goals – Name the use cases – Describe each use case briefly • apply terms with which the user is familiar making the description less ambiguous • this is called the “use case description” 13 Guidelines for Finding Use Cases • While finding use cases, you might have to make changes to your set of actors – All actor changes should be updated in the textual description of actors and use cases • Also watch for the possible use of extends and includes relationships • Naming a Use Case – Should provide a general description of the use case function (verb or verb and noun [e.g. Borrow Books]) 14 4 use case symbols • Actor – and its name Line manager • System boundary Budget Planning – with system name • Interaction Line – and optional qualifier Not an information flow! (secondary) • Use case – and its name Do something Use-Case Diagrams (POST) POST: Point of Sale Terminal Use Case System Boundary POST Buy Item Log In Cashier Customer Refund a Purchased Item Adapted from Larman “Applying UML and Patterns” Rules for Actors • Actors to the outside of the System Boundary • Actors should never communicate with each other • Actors should be named with singular, business relevant nouns • Actors should be roles not positions Example A client makes a call that is taken by an operator, who determines the nature of the problem. Some calls can be answered immediately; other calls require research and a return call. Help Desk Make a call Take the call Client Do research Operator Return a call Support representative Includes and Extends • Includes – You have a piece of behavior that is similar across many use cases – Break this out as a separate usecase and let the other ones “include” it – Examples include • • • • Valuation Validate user interaction Sanity check on sensor inputs Check for proper authorization • Extends – A use-case is similar to another one but does a little bit more – Put the normal behavior in one usecase and the exceptional behavior somewhere else • Capture the normal behavior • Try to figure out what can go wrong in each step • Capture the exceptional cases in separate use-cases – Makes it a lot easier to understand Use Case Description • Other than a short scenario, involving actors associated with the use case, also record – Preconditions • A list of conditions that must be true before the Use case begins – Postconditions • A list of conditions that must be true when a use case ends – Abnormal path(s) – Non-functional requirements 20 {System Name} Author (s): _______________ USE CASE NAME: USE CASE ID: PRIORITY: SOURCE: PRIMARY BUSINESS ACTOR PRIMARY SYSTEM ACTOR OTHER PARTICIPATING ACTORS: DESCRIPTION: PRE-CONDITION: TRIGGER: TYPICAL COURSE OF EVENTS: Date: ___________ Version: ___________ Step 1: Step 2: …. ALTERNATE COURSES: CONCLUSION: POST-CONDITION: BUSINESS RULES IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS ASSUMPTIONS: 21 Another Template Use Case ID: Use Case Name: Created By: Date Created: [Repeat for multiple use cases] Last Updated By: Last Revision Date: Actors: Description: Trigger: Preconditions: Postconditions: Normal Flow: Alternative Flows: Exceptions: Includes: Frequency of Use: Special Requirements: Assumptions: Notes and Issues: 22 Use Case ID: Enter a unique numeric identifier for the Use Case. e.g. UC-1.2.1 Use Case Name: Enter a short name for the Use Case using an active verb phrase. e.g. Withdraw Cash Created By: Last Updated By: Date Created: Last Revision Date: Actors: [An actor is a person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks. Description: [Provide a brief description of the reason for and outcome of this use case.] Trigger: [Identify the event that initiates the use case. This could be an external business event or system event that causes the use case to begin, or it could be the first step in the normal flow.] Preconditions: [List any activities that must take place, or any conditions that must be true, before the use case can be started. Number each pre-condition. e.g. 1. Customer has active deposit account with ATM privileges 2. Customer has an activated ATM card.] Postconditions: [Describe the state of the system at the conclusion of the use case execution. Should include both minimal guarantees (what must happen even if the actor’s goal is not achieved) and the success guarantees (what happens when the actor’s goal is achieved. Number each post-condition. e.g. 1. Customer receives cash 2. Customer account balance is reduced by the amount of the withdrawal and transaction fees] Normal Flow: [Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. 1. Customer inserts ATM card 2. Customer enters PIN 3. System prompts customer to enter language performance English or Spanish 4. System validates if customer is in the bank network 5. System prompts user to select transaction type 6. Customer selects Withdrawal From Checking 7. System prompts user to enter withdrawal amount 8. … 9. System ejects ATM card] Alternative Flows: [Alternative Flow 1 – Not in Network] [Document legitimate branches from the main flow to handle special conditions (also known as extensions). For each alternative flow reference the branching step number of the normal flow and the condition which must be true in order for this extension to be executed. e.g. Alternative flows in the Withdraw Cash transaction: 4a. In step 4 of the normal flow, if the customer is not in the bank network System will prompt customer to accept network fee Customer accepts Use Case resumes on step 5 4b. In step 4 of the normal flow, if the customer is not in the bank network System will prompt customer to accept network fee Customer declines Transaction is terminated Use Case resumes on step 9 of normal flow Note: Insert a new row for each distinctive alternative flow. ] Exceptions: [Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. e.g. Exceptions to the Withdraw Case transaction 2a. In step 2 of the normal flow, if the customer enters and invalid PIN Transaction is disapproved Message to customer to re-enter PIN Customer enters correct PIN Use Case resumes on step 3 of normal flow] Includes: [List any other use cases that are included (“called”) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality. e.g. steps 1-4 in the normal flow would be required for all types of ATM transactions- a Use Case could be written for these steps and “included” in all ATM Use Cases.] Frequency of Use: [How often will this Use Case be executed. This information is primarily useful for designers. e.g. enter values such as 50 per hour, 200 per day, once a week, once a year, on demand etc.] Special Requirements: [Identify any additional requirements, such as nonfunctional requirements, for the use case that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes.] Assumptions: [List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description. e.g. For the Withdraw Cash Use Case, an assumption could be: The Bank Customer understands either English or Spanish language.] Notes and Issues: [List any additional comments about this use case or any remaining open issues or TBDs (To Be Determined) that must be resolved. e.g. What is the maximum size of the PIN that a use can have?] Drawing Use Cases • • • • • Think from an end user perspective Create simple appropriate use case names Actor is a role (not an individual person) Model common use case with <<includes>> Model exceptional behaviour with <<extends>> • Position actors and use cases in a meaningful way 25 Partial POST POST Buy Item Log In Cashier Customer Refund a Purchased Item Start Up Manager Manage Users System Administrator And a Lot More MH Adapted from Larman “Applying UML and Patterns” POST Use-Case Use case: Actors: Type: Description: Buy Item Customer (initiator), Cashier Primary The Customer arrives at the checkout with items to purchase. The Cashier records the purchase items and collects a payment. On completion the Customer leaves with the items POST Expanded Use-Case Use case: Buy Item Actors: Customer (initiator), Cashier Type: Primary and essential Description: The Customer arrives at the checkout with items to purchase. The Cashier records the purchase items and collects a payment. On completion the Customer leaves with the items. Cross Ref.: Requirements XX, YY, and ZZ Use-Cases: Cashier must have completed the Log In use-case When to use Use-Cases • Requirements is the toughest part of software development – A Use-Case is a powerful tool to understand • Who your users are (including interacting systems) • What functions the system shall provide • How these functions work at a high level • Spend adequate time on requirements and in the elaboration phase