1. Software Engineering Design & Modelling
Capturing Requirements Using
Use Cases

2. Chapter Outline
Use cases
Use case diagrams
Case Study

3. Introduction No system exists in isolation.
Every system interacts with human or automated actors that use the system for some purpose
and those actors expect the system to behave in predictable ways
We can use UML to capture and model the requirements associated with a system
will look at use cases and use case diagram in modelling requirements

4. Use Cases

5. Introduction A use case
specifies the behaviour of a system or part of a system
is used to capture intended behaviour of the system (functional requirements), without having to specify how that behaviour will be implemented
As we implement our system, these use cases are realized by collaborations whose elements work together to carry out each use cases
Well-structured use cases denote essential system or sub-system behaviours only.

6. Definition
A use case is a description of a set of sequences of actions, including variants, that a system performs in order to yield an observable result of value to an actor.
it is a sequence of actions that an actor performs within a system to achieve a particular goal
Graphically, a use case is rendered as an ellipse
Use case’s name

7. Sensors:: Calibrate location
Every use case must have a name that distinguishes it from other use cases
simple name
Path name : the name prefixed by the name of the package in which that use case lives
Graphically, a use case is drawn showing only its name
Sensors:: Calibrate location
Place order
simple name
path name

8. Actors
An actor represents a coherent set of roles that users of use cases play when interacting with these use cases
an actor represents a role that a human (user), a hardware device, or even another system plays with a system
An instance of an actor represents an individual interacting with the system in a specific way
Although actors are used in models, actors are not actually part of the system
they live outside the system

9. Graphically, actors are rendered as stick figures
we can define general kinds of actors (such as Customer) and specialize them (such as CommercialCustomer) using generalization relationships
generalization
actor
Customer
actor
CommercialCustomer
Actors may be connected to use cases only by association
indicates that the actor and the use case communicate with one another, each one possibly sending and receiving messages

10. Properties A use case describes a set of sequences
each sequence represents the interaction of the things outside the system (its actors) with the system itself (and its key abstraction)
a use case represents a functional requirement of your system as a whole
A use case involves the interaction of actors and the system
A use case may have variants
use cases that are specialized versions of other use cases
use cases that are included as parts of other use cases
use cases that extend the behaviour of other core use cases

11. A use case carries out some tangible amount of work
from the perspective of a given actor, a use case does something that’s of value to an actor
Use cases can be applied to the whole or part of the system, including sub-systems and even individual classes and interfaces
these use cases not only represent the desired behaviour of these elements, but they can also be used as the basis of test cases for these elements as they evolve during development

12. Flow of Events
A use case describes what a system does but it does not specify how it does it.
We can specify the behaviour of a use case by describing a flow of events, that should include: -
how and when the use case starts and ends
when the use case interacts with the actors and what objects are exchanged
the basic flow and alternative flows of the behaviour
Therefore, a flow of events can consist of
the main flow of events
exceptional flow of events or alternative flow of events

13. Scenarios
Typically, we describe the flow of events for a use case in text
But eventually, we will want to use interaction diagrams to specify these flows graphically (we will learn in the next chapter)
It is desirable to separate main versus alternative flows because a use case describes a set of sequences
It would be highly impossible to express all the details of a use case in just one sequence

14. Each of these variant can be expressed in a different sequence
Ex: - A use case HireEmployee in a Human Resource system may have many business variations, e.g.: -
A person can be hired from another company (the most common scenario)
A person might be transferred from one division to another
A foreign national can be hired
Each of these variant can be expressed in a different sequence
Each sequence is called a scenario
A scenario is a specific sequence of actions that illustrates behaviour
A scenario is an instance of a use case

15. Collaborations
A use case captures the intended behaviour of the system without having to specify how that behaviour is implemented
However, we eventually need to implement our use cases by creating a society of classes and other elements that work together to implement the behaviour of this use case
This society of elements (both static and dynamic structure) is modelled in the UML as a collaboration

16. In UML, we can explicitly specify the realization of a use case by collaboration
A given use case is usually realized by exactly one collaboration
realization
Place Order
Order Management
use case
collaboration

17. A simple example 1
Example: - Describing the use case ValidateUser in the context of an ATM system
Main flow of events
The use case starts when the system prompts the CUSTOMER for a PIN number.
The CUSTOMER enters a PIN number via the keyboard
The CUSTOMER commits the entry by pressing the Enter button
The system checks this PIN number to see if it is valid.
If it is, the system acknowledges entry
Use case ends once the system acknowledges the entry

18. Exceptional flow of events
A CUSTOMER can cancel a transaction at anytime by pressing the CANCEL button, thus restarting the use case
No changes are made to the CUSTOMER’s account
The CUSTOMER can clear a PIN number anytime before committing it
The CUSTOMER can re-enter a new PIN number
If the CUSTOMER enters an invalid PIN number, the use case restarts
If this happens three times in a row, the system cancels the entire transaction and the card will automatically be swallowed by the ATM machine

19. Customer Description Use Case Validate User
Validate that the customer is an authorised user or the ATM machine.
Pre-condition:
An ATM card and an authorised PIN number
Main flow of events:
1. The user inserts the ATM card.
2. The system prompts the CUSTOMER for a PIN number.
3. The CUSTOMER enters a PIN number via the keyboard.
4. The CUSTOMER presses the ENTER button.
5. The system checks the PIN number to see if it is valid. If it is, the
system acknowledges entry.
Post-condition:
The CUSTOMER is authorised to continue the transaction.
Validate User
Description
Use Case

20. Use Case
Description
Validate User
(continue…)
Alternate flow of events:
1. The user inserts the ATM card.
2. The system prompts the CUSTOMER for a PIN number.
3. The CUSTOMER presses the CANCEL button.
5. The system stops the transaction and returns the ATM cards.
Post-condition:
No changes are made to the CUSTOMER account.
3. The CUSTOMER enters a PIN number via the keyboard.
4. The CUSTOMER presses the CLEAR button.
5. The CUSTOMER re-enters the PIN number via the keyboard.
6. The CUSTOMER presses the ENTER button.
7. The system checks the PIN number to see if it is valid. If it is, the
system acknowledges entry.
The CUSTOMER is authorised to continue the transaction.

21. Use Case
Description
Validate User
(continue…)
Alternate flow of events:
1. The user inserts the ATM card.
2. The system prompts the CUSTOMER for a PIN number.
3. The CUSTOMER enters a PIN number via the keyboard.
4. The CUSTOMER presses the ENTER button.
7. The system checks the PIN number to see if it is valid. If it is not
valid, the system prompts user to retry.
8. Repeat step 3-7 (maximum three times).
9 If user repeats more than 3 times, system will not return the
ATM card to the CUSTOMER.
Post-condition:
The ATM card is swallowed by the ATM machine. The CUSTOMER is not able to perform any transactions.

22. A simple example 2
Example: In an on-line Bookstore system, user needs to log-in first before he/she could order and purchase any desired books. Describe the use case for the log-in process of the on-line Bookstore system.
Answer: For every log-in process, there are two flows
When the log-in is successful (main-flow)
When the log-in is not successful (alternate-flows)
For each flow, we can describe the sequence/flow of events.

23. Customer Log-in Log-in
A CUSTOMER needs to log-in before performing any transaction
Pre-condition:
A registered user.
Main flow of events:
1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password.
4. The CUSTOMER clicks the OK button.
5. The system validates the log-in information against the ACCOUNT
table in the database.
6. CUSTOMER is an authorised user; the system displays the Personal
Home Page to the CUSTOMER
Post-condition:
The CUSTOMER has been authorised to perform transactions.

24. Log-in
(cont…)
Alternate flow:
1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password.
4. The CUSTOMER clicks the OK button.
5. The system validates the log-in information against the ACCOUNT
table in the database.
6. CUSTOMER is not an authorised user; the system displays a pop-up message to inform the CUSTOMER.
Post-condition:
The CUSTOMER is not authorised to perform transactions.

25. Use Case Diagrams

26. Introduction
Use case diagrams are used to model the dynamic aspect of a system
are central to modelling the behaviour of a system, a subsystem, or a class
A use case diagram shows a set of use cases and actors and their relationships
Use case diagrams are applied to model the use case view of a system
involves modelling
the context of a system, subsystem or class
The requirements of the behaviour of these elements

27. Use case diagrams are important for
visualizing, specifying, and documenting the behaviour of an element
They make systems, subsystems, and classes approachable and understandable by presenting an outside view of how those elements may be used in context
testing executable systems through forward engineering
comprehending executable systems through reverse engineering

28. With the UML, we apply use case diagrams to visualize the behaviour of a system, subsystem, or class so that
users can understand how to use that element
developers can implement that element

29. Definition
A use case diagram is a diagram that shows a set of use cases and actors and their relationships
It commonly contains: -
Use cases
Actors
Dependency, generalization and association relationships
May also contain notes, constraints, packages and instances

30. Organizing use case diagrams
There are three types of relationships that can be applied in a use case diagram: -
(A) Generalization relationships between actors (as seen in slide 9)
(B) Dependency and generalization relationships between use cases
(C) Association relationships between actors and use cases

31. Receive additional call
Place phone call
Receive phone call
Use scheduler
Cellular Telephone
Place conference call
Receive additional call
<<extend>>
(B)
Time scheduler
Date scheduler
(C)
Cellular network
Individual user
(A)
User
Corporate user

32. Generalization relationships between use cases are similar to generalization among classes: -
The child use case inherits the behaviour and meaning of the parent use case
The child use case may add to or override the behaviour of its parent
The child use case may be substituted any place that the parent may appear

33. For dependency relationships among use cases, there are two stereotypes that can be applied: -
include
one use case explicitly includes the behaviour of another use case at a specified point within a course of action
The include use case does not stand alone; it has to be connected with one or more base use cases.
We apply include relationship in order to factor common behaviour by pulling such behaviour from other use cases that it includes
include relationship is essentially an example of delegation where
a set of responsibilities in the system is captured in one place (the included use case) and other parts of the system (other use cases) can include this set of responsibilities whenever they need to use that functionality

34. UML notation: Example Customer
Base Use Case
Included Use Case
<<include>>
Log in
Add to Wish List
Check Out
<<include>>
Customer
A CUSTOMER of an internet bookstore must be logged-in first before he/she can add items to his/her Wish List or to check out the items in the Shopping Cart

35. extend
A base use case implicitly includes the behaviour of another use case at one or more specified points.
We apply extend relationship in order to factor variants by pushing such behaviour into other use cases that extend it
extend relationship is used to
model the part of a use case the user may see as optional system behaviour
model a separate sub-flow that is executed only under given conditions
model several flows that may be inserted at a certain point, governed by explicit interaction with an actor

36. <<extend>>
UML notation:
Example
Base Use Case
Extended Use Case
<<extend>>
<<extend>>
(order ID)
Check Order Status
Cancel Order
Customer
A CUSTOMER of an internet bookstore has the option of cancelling an Order in conjunction with checking the status of that Order.

37. Actors may be connected to use cases only by association
indicates that the actor and the use case communicate with one another, each one possibly sending and receiving messages

38. Use Case Diagrams – Common Uses
When we model the behaviour of a system (the static use case view of the system), we will apply the use case diagrams in two ways: -
To model the context of a system
To model the requirements of a system

39. 1) Modelling the context of the system
Involves drawing a line around the whole system and determining which things or actors lie outside the system and interact with it
Ex: - In a credit card validation system, things such as accounts, transactions, and fraud detection agents are found inside the system, whereas things such as credit card customers and retail institutions are found outside the system
The things that live inside the system are responsible for carrying out the behaviour that those on the outside expect the system to provide
All those things on the outside that interact with the system constitute the system’s context, which defines the environment in which the system lives
A use case diagram is used to specify the actors and the meaning of their roles

40. Example: - Credit Card Validation System Retail institution Customer
Perform card transaction
Retail institution
Customer
Process customer bill
Reconcile transactions
Sponsoring financial institution
Individual customer
Corporate customer
Manage customer account

41. To model the context of a system,
Identify the actors that surround the system by considering
Which groups require help from the system to perform their tasks
Which groups are needed to execute the system’s functions
Which groups interact with external hardware or other software systems
Which groups perform secondary functions for administration and maintenance
Organize actors that are similar to one another in a generalization/ specialization hierarchy
Provide a stereotype for actors, if it aids understandability
Populate a use case diagram with these actors and specify the paths of communication form each actor to the system’s use case

42. 2) Modelling the requirements of a system
Involves specifying what the system should do (from the point of view of outside the system), independent of how that system should do it
A use case diagram is used to specify the desired behaviour or the requirements of a system
A requirement is a design feature, property or behaviour of a system
When a system’s requirements is stated, we are asserting a contract between the things that lie outside the system and the system itself
It declares what we expect the system to do
A system’s functional requirements can be expressed as use cases, and the UML’s use case diagrams are essential for managing these requirements

43. Example: - Credit Card Validation System Customer Retail institution
Perform card transaction
Report on account status
Customer
Process customer bill
Detect card fraud
Retail institution
Reconcile transactions
Manage network outage
Manage customer account
Sponsoring financial institution

44. To model the requirements of a system: -
Establish the context of the system by identifying the actors that surround it
For each actor, consider the behaviour that each expects or requires the system to provide
Name these common behaviours as use cases
Factor common behaviour into new use cases that are used by others; factor variant behaviour into new use cases that extend more main line flows
Model these use cases, actors, and their relationships in a use case diagram
Adorn these use cases with notes that assert non-functional requirements (if necessary)

45. Use Case Diagrams - Summary
When you draw a use case in the UML
Give it a name that communicates its purpose
Show only those use cases that are important to understand the behaviour of the system or the part of the system in its context
Show only those actors that relate to these use cases
Try not to show too many kinds of relationships

46. Case Study: On-Line Bookstore

47. On-line Bookstore is a web application that can be accessed by the store’s registered customer, whereby each customer can order books, review one or more books sold in the book store, and sell used books to other customers. Before performing any one of these transactions, the customer must first log-in into the system using their user id and password kept in their account.
Problem: Draw the use-case diagram for the above system

48. The steps involved: - Identify the actor : CUSTOMER
Identify the use case for the actor:
CUSTOMER
REGISTER
LOG-IN
ORDER BOOKS
CHECK OUT
REVIEW BOOKS
SELL USED BOOKS
For each use case, determine include and extend relationships, if any
A Customer needs to log-in first before he/she can order books, check out, review books or sell used books: include relationship
A Customer can proceed to check out after he/she has ordered books: extend relationship

49. Use Case Context Diagram
On-line Bookstore System
Register
<<extend>>
(CustID)
Check out
Customer
Order books
<<include>>
<<include>>
Sell used books
Log-in
<<include>>
Review books
Use Case Context Diagram

50. Use Case Functional Requirements Diagram
On-line Bookstore System
Register
<<extend>>
(CustID)
Check out
Customer
Order books
<<include>>
<<include>>
Sell used books
Log-in
<<include>>
Use Case Functional Requirements Diagram
Review books

51. Use Case
Description
Register
A new CUSTOMER needs to first register into the system before performing any transaction.
Actor/s: CUSTOMER
Pre-condition: An unregistered CUSTOMER.
Main flow of events:
1. The CUSTOMER clicks the REGISTER button on the Home Page.
2. The system displays the Register Page.
3. The CUSTOMER enters all of the required information.
4. The CUSTOMER clicks the SEND button.
5. The system checks that all of the required information were entered. If
yes, the system update the CUSTOMER’s record in the CUSTOMER
and ACCOUNT tables in the database. System displays OK message.
Post-condition:
The new CUSTOMER has registered. The ACCOUNT and CUSTOMER tables are updated.
Log-in
A CUSTOMER needs to log-in before performing any transaction
Pre-condition: A registered user.
1. The CUSTOMER clicks the Log-in button on the Home Page.

52. Use Case
Description
Log-in
(continue…)
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password.
4. The CUSTOMER clicks the OK button.
5. The system validates the log-in information against the ACCOUNT
table in the database.
6. CUSTOMER is an authorised user; the system displays the Personal
Home Page to the CUSTOMER
Post-condition:
The CUSTOMER has been authorised to perform transactions.
Alternate flow:
1. The CUSTOMER clicks the Log-in button on the Home Page.
6. CUSTOMER is not an authorised user; the system displays a pop-up message to inform the CUSTOMER.
The CUSTOMER is not authorised to perform transactions.

53. Use Case
Description
Order Books
A CUSTOMER can order books to purchase.
Actor/s: CUSTOMER
Pre-condition: User have logged-in.
Main flow of events:
1. The CUSTOMER enters the keyword for a book and clicks the
SEARCH button on the Personal Home Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER chooses the desired book and clicks the ADD TO
SHOPPING CART button on the web page.
4. The system adds the book into the CUSTOMER’s Order table
in the database.
Post-condition:
The ORDER table has been updated.
Check Out
A CUSTOMER can purchase the books in his/her Shopping Cart.
Pre-condition: The user have logged in and has at least one book in the Shopping Cart. Main flow of events:
1. The CUSTOMER clicks the Check out button on the Web Page.

54. Use Case
Description
Check Out
(continue…)
2. The system displays the books in the ORDER table of the
CUSTOMER on the web Page.
3. The CUSTOMER checks the order list for any inconsistency. If
nothing found, CUSTOMER clicks the PROCEED button.
4. The system displays the Invoice page.
5. The Customer enters the relevant credit card information and clicks
the OK button.
6. The system checks that the credit card is valid. Then, the system
displays the Delivery Details page.
7. The CUSTOMER chooses destination for delivery, along with
delivery options. Then, he/she clicks the PROCEED button.
8. The system will display the check-out information for confirmation.
7. The CUSTOMER checks that all information is correct and then
clicks the OK button.
8. The system sends a confirmation via CUSTOMER’s .
Post-condition:
The ORDER table has been updated.
Sell used books
A CUSTOMER can sell his/her used books.
Actor/s: CUSTOMER
Pre-condition: The user have logged-in..

55. Use Case
Description
Sell Used Books
(continue…)
Main flow of events:
1. The CUSTOMER clicks the Sell Used Books button on the Home
Page.
2. The system displays the Sell used books web page.
3. The CUSTOMER enters the required information on the used books
that he/she wants to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the information that
the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are accurate.
If yes, the CUSTOMER clicks the OK button on the web page.
7. The system updates the USED BOOKS table in the database.
Post-condition:
The Used Books table has been updated.
Review Books
A CUSTOMER can review books.
Actor/s: CUSTOMER
Pre-condition: User have logged-in..
1. The CUSTOMER enters the keyword to search for a book and then
clicks the SEARCH button on the Personal Web Page.

56. Use Case
Description
Review Books
(continue…)
2. The system displays the matching books on the web Page.
3. The CUSTOMER checks for the desired book and clicks on the chosen book icon.
4. The system displays the book’s detail in the Book Detail web page.
5. The CUSTOMER clicks the REVIEW button on the web page.
6. The system displays the Review Book web page.
7. The CUSTOMER clicks on the desired star button and the click the
OK button on the web page.
8. The system calculates the overall rating of the book and updates the
Book table in the database.
9. The system displays the Book Detail web pages that have been
updated.
Post-condition:
The BOOK and REVIEW tables are updated.