Use Case Analysis 16-Apr-17 Software Engineering

Use Cases in UML UML provides a graphical representation for use cases called the use case diagram. A Use Case Model consists of: – a use case diagram, – use case descriptions, … 16-Apr-17 Software Engineering

Use Case Diagram - Example Payment Authorization service Process sale Cashier Handle returns <<actor>> Tax calculator Process rental System administrator Manage security <<actor>> Accounting system Manage users Use Case Diagram: illustrates a set of use cases for a system. 16-Apr-17 Software Engineering

Extends Use the extends relationship when you have a use case that is similar to another use case but does a bit more. In this example the basic use case is Capture deal. • In case certain limits for a deal are exceeded the additional use case Limits exceeded is performed. 16-Apr-17 Software Engineering

Extends (2) Extensions are used instead of modeling every extra case by a single use case. Extensions are used instead of creating a complex use case that covers all variations. How do you address case variation? • Capture the simple, normal use case first. • For every step in that use case ask: “What could go wrong here?“ • Plot all variations as extensions of the given use case. 16-Apr-17 Software Engineering

Uses(includes) The uses relationship occurs when you have a chunk of behavior that is similar across several use cases. 16-Apr-17 Software Engineering

Uses and Extends The similarities between extends and uses are that they both imply factoring out common behavior from several use cases to a single use case that is • used by several other use cases or • extended by other use cases. Apply the following rules: • Use extends, when you are describing a variation on normal behavior. • Use uses when you want to split off repeating details in a use case. 16-Apr-17 Software Engineering

Actors and Use cases 16-Apr-17 Software Engineering

More on Use Cases Narrate use cases independent of implementation State success scenarios (how do you determine the success of a use case). A use case corresponds to one or more scenarios. Agree on a format for use case description Name a use case starting with a verb in order to emphasize that it is a process. “verb + noun phrase” (Buy Items, Enter an order, Reduce inventory) 16-Apr-17 Software Engineering

More on Use Cases Use cases drive the whole development process. Use cases are not object-oriented. Use cases represent an external view of the system. Use cases should be written and named at the domain level in requirements. Adjust the granularity of your use cases according to the complexity of the individual problem you are working on, bearing in mind that • too many use cases can be overwhelming while • too few use cases may hide important details. 16-Apr-17 Software Engineering

More on Use cases Use cases force one to look at exceptional as well as normal behavior. – helps us to surface hidden requirements Use cases can help formulate system tests. – “Is this use case built into the system?” Use case templates facilitate interviewing and reviews. Ease an iterative development lifecycle – levels of precision for a use case by refinement Support an incremental development lifecycle – E.g. “Foobar” Release 1: use cases 1-20; “Foobar” Release 2: use cases 1-29. 16-Apr-17 Software Engineering

More on Use Cases Use Simple Grammar (active voice) – GOOD “1. Actor requests System for rum-flavored popcorn.” – BAD “1. The System was requested by the Actor for some of the rum-flavored variety of popcorn.” Avoid "if" statements. Factor out into “alternative flows” instead. Look for ways that each step in the basic flow can fail. – a single step may have several alternatives 16-Apr-17 Software Engineering

Summary One method to identify use cases is actor-based: - Identify the actors related to a system or organization. - For each actor, identify the processes they initiate or participate in. A second method to identify use cases is event-based: - Identify the external events that a system must respond to. - Relate the events to actors and use cases. The following questions may be used to help identify the use cases for a system: What are tasks of each actor ? Will any actor create, store, change, remove, or read information in the system ? What use cases will create, store, change, remove, or read this information ? Will any actor need to inform the system about sudden, external changes ? Does any actor need to be informed about certain occurrences in the system ? Can all functional requirements be performed by the use cases ?

How it Fits Together Preliminary Investigation Report Requirements Specification Use-Cases a. All High Level b. Some Expanded Prototypes Use-Case Diagram Budget, Schedule Draft Conceptual Model Glossary (data dictionary)

Exception handling Document exception handling or branching What is expected of the system when a “Buy Item” fails ? What is expected of the system when a “credit card” approval fails ? 16-Apr-17 Software Engineering

A sample Use Case Use case: Buy Items Actors: Customer, Cashier Description: A customer arrives at a checkout with items to purchase. The cashier records the purchase items and collects payment. On completion the customer leaves with items. 16-Apr-17 Software Engineering

Developing a Use Case Ask yourself these questions: - What are the main tasks or functions that are performed by the actor? - What system information will the actor acquire, produce or change? - Will the actor have to inform the system about changes in the external environment? - What information does the actor desire from the system? -Does the actor wish to be informed about unexpected changes? 16-Apr-17 Software Engineering

Use Case Description It includes – How the use case starts and ends – The context of the use case – The actors and system behavior described as intentions and responsibilities – All the circumstances in which the primary actor’s goal is reached and not reached – What information is exchanged 16-Apr-17 Software Engineering

Ranking Use Cases Use some ordering that is customary to your environment Example: High, Medium, Low Example: Must have, Essential, Nice to have Useful when deciding what goes into an increment POST example: Buy Items - High Refund Items - Medium (Why?) Shut Down POST terminal - Low 16-Apr-17 Software Engineering

Ranking the Use cases The developers should consider the architectural risk. Do not omit use cases which later cause you to do a lot of rework to fit them in. Concentrate to the use cases which are technologically most challenging. The developers should be aware of the schedule risks. “I’m pretty sure I know how long it will take.” “I can estimate the time only to the nearest man-month.” “I have no idea.” 16-Apr-17 Software Engineering

Use Cases vs. Feature Lists Feature Lists: “the system shall…” More traditional approach Less preferable for user-oriented s/w Only mention function, not flow If flows are written elsewhere, then redundant = hard to maintain in parallel High-level feature lists are okay Include in Vision document “executive summary of use cases” 16-Apr-17 Software Engineering

Format – Example (Fully Dressed) 16-Apr-17 Software Engineering

Use Case Example Use case name: Login Goal: Authenticate user Precondition: System is ready Postcondition: User is logged in Actors: User Triggering event: User requests login Description: User supplies username and password. If the username is known and the password is valid, the user is logged in. Alternatives: 1) User name is not valid: Retry getting user name up to three times, then report failure, record error, and wait one minute before allowing next login. 2) Password is not valid: Retry getting password up to three times, then report failure, records error and wait one minute before allowing next login. 16-Apr-17 Software Engineering

Use Case Example Use Case: Deposit Money Scope: Bank Accounts and Transactions System Level: User Goal Intention in Context: The intention of the Client is to deposit money on an account. Clients do not interact with the System directly; instead, for this use case, a Client interacts via a Teller. Many Clients may be performing transactions and queries at any one time. Primary Actor: Client Basic Flow: 1. Client requests Teller to deposit money on an account, providing sum of money. 16-Apr-17 Software Engineering

Contd… 2. Teller requests System to perform a deposit, providing deposit transaction details. 3. System validates the deposit, credits account with the requested amount, records details of the transaction, and informs Teller. Alternative Flows: 3a. System ascertains that it was given incorrect information: 3a.1. System informs Teller; use case continues at step 2. 3b. System ascertains that it was given insufficient information to perform deposit: 3b.1. System informs Teller; use case continues at step 2. 16-Apr-17 Software Engineering

Each use case may include all or part of the following: Title or Reference Name - meaningful name of the UC Author/Date - the author of the UC and its creation date Modification/Date - last modification to the UC and its date Purpose - specifies the goal to be achieved by the UC Overview - short description of the use cases processes Cross References - requirements references Actors - agents which initiate or participate in the UC Pre Conditions - must be true to allow the execution of the UC Post Conditions - will be set when the use use completes its execution normally Normal flow of events - regular flow of activities of the UC Alternative flow of events - other flow of activities of the UC Exceptional flow of events - unusual situations Implementation issues - possible foreseen problems in the implementation of the UC Use Case Description Each use case may include all or part of the following: Title or Reference Name - meaningful name of the UC Author/Date - the author and creation date Modification/Date - last modification and its date Purpose - specifies the goal to be achieved Overview - short description of the processes Cross References - requirements references Actors - agents participating Pre Conditions - must be true to allow execution Post Conditions - will be set when completes normally Normal flow of events - regular flow of activities Alternative flow of events - other flow of activities Exceptional flow of events - unusual situations Implementation issues - foreseen implementation problems

Example- Money Withdraw Use Case: Withdraw Money Author: ZB Date: 1-OCT-2004 Purpose: To withdraw some cash from user’s bank account Overview: The use case starts when the customer inserts his credit card into the system. The system requests the user PIN. The system validates the PIN. If the validation succeeded, the customer can choose the withdraw operation else alternative 1 – validation failure is executed. The customer enters the amount of cash to withdraw. The system checks the amount of cash in the user account, its credit limit. If the withdraw amount in the range between the current amount + credit limit the system dispense the cash and prints a withdraw receipt, else alternative 2 – amount exceeded is executed. Cross References: R1.1, R1.2, R7

Example- Money Withdraw (cont.) Actors: Customer Pre Condition: The ATM must be in a state ready to accept transactions The ATM must have at least some cash on hand that it can dispense The ATM must have enough paper to print a receipt for at least one transaction Post Condition: The current amount of cash in the user account is the amount before the withdraw minus the withdraw amount A receipt was printed on the withdraw amount The withdraw transaction was audit in the System log file

Example- Money Withdraw (cont.) Typical Course of events: Actor Actions System Actions 1. Begins when a Customer arrives at ATM 2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status 5. Customer chooses “Withdraw” operation 4. System asks for an operation type 7. Customer enters the cash amount 6. System asks for the withdraw amount 8. System checks if withdraw amount is legal 9. System dispenses the cash 10. System deduces the withdraw amount from account 11. System prints a receipt 13. Customer takes the cash and the receipt 12. System ejects the cash card

Example- Money Withdraw (cont.) Alternative flow of events: Step 3: Customer authorization failed. Display an error message, cancel the transaction and eject the card. Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6. Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6. Exceptional flow of events: Power failure in the process of the transaction before step 9, cancel the transaction and eject the card

Exercise Example: Home Security System (SafeHome) Project Brief (provided at the start of the project): - Build a micro-processor based home security system that will protect against and/or recognize a variety of undesirable situations such as illegal entry, fire and flooding. - The product will use appropriate sensors to detect each situation, can be programmed by the homeowner and will automatically telephone a monitoring agency when necessary. 16-Apr-17 Software Engineering

Actors and Interactions - homeowner (the user) - sensors (devices attached to the system) - monitoring and response subsystem (central station that monitors SafeHome) Interactions: - Enters a password to allow all other interactions. This password needs to be validated by the system - Inquires about the status of a security zone which relies on the status of a combination of sensors - Inquires about the status of a sensor - Presses the panic button in an emergency - Activates/deactivates the security system 16-Apr-17 Software Engineering