1. Use Case Analysis
16-Apr-17
Software Engineering

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. Actors and Use cases
16-Apr-17
Software Engineering

9. 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

10. 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

11. 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

12. 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

13. 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 ?

14. 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)

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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