University of Wollongong in Dubai

CSIT114 – System Analysis

Understanding Users

Dr. Haitham Yaish

Dr. Zeenath Reza Khan
 Document Change Control

Version Author Date Change Description

1.0 Dr. Zeenath Reza Khan Autumn 2019 Defined the first version
2.0 Dr. Haitham Yaish Autumn 2023 Updated and created
new Lecture Content.

3
 Agenda

• User Stories
• User Stories - Class Activity
• Use Cases
• Use Case Diagram
• Case Study
• Use Case Diagram - Class Activity

4
 User Stories

• Identifying user stories and use cases is a key task when defining functional
requirements, because these form the basis for the list of functions the system
needs to carry out.

• All recent approaches to system development begin the requirements

modelling activity with the concept of a user story or a use case.

• User stories are favoured by highly Agile system development methodologies.

• The Agile development philosophy is to work directly with users and avoid
doing too much documentation.

• In contrast, a use case approach traditionally meant analysts complete much

documentation for each use case, focusing on detailed steps carried out by the
user and the system.

5
 User Stories

• In meetings with stakeholders, analysts encourage

participants to write out each user story on an index card or
on a shared whiteboard app.

• The objective is to get a potential user to articulate what he

or she wants to do with the new system.

• The standard template for a user story looks like this:

“As a <role played>, I want to <goal or desire> so that <reason or benefit>.”

6
 User Stories

• For example, some user stories for a bank teller might be:
- “As a teller, I want to make a deposit to quickly serve more
customers.”
- “As a teller, I want to balance the cash drawer to assure there
were no errors.”

• As a customer of the bank using an ATM machine, some user

stories might be:
- “As a bank customer, I want to withdraw cash and feel
confident the stack of cash I get is the correct amount.”
- “As a bank customer, I want to deposit a check and feel
confident the deposit is recorded correctly.”

7
 User Stories

User Stories acceptance criteria

• These indicate the features that must be present for the user
to be satisfied with the resulting implementation.
• They focus on functionality, not on features or user-interface
design.

Example:

8
 User Stories

User Stories acceptance criteria

Example:

9
 User Stories

User Stories acceptance criteria

• The programmer analyst uses the acceptance criteria to clarify
the expectations of the user and to verify the user is looking at
the user story at an appropriate level of analysis.

• When the user story is implemented and refined, the

acceptance criteria are used for testing.

• Some consider it much like a contract between the developers

and the users that limits controversy later in the project.

10
 User Stories

Class Activity

• Work in a group to write a user story for

Software/application you used before.

11
 Use Cases

• Use case— an activity that the system performs,

usually in response to a request by a user.

• Use cases define functional requirements

– Ex. Create customer account, Look up customer,
Process account, Enrolment of subjects…etc.

• Two techniques for Identifying use cases

1. User goal technique
2. Event decomposition technique

12
 Use Cases

Technique 1 – User Goal Technique

• This technique is the most common in industry

– Simple and effective

• Identify all of the potential categories of users of the system

(example: admin, user, operator, executive managers)

• Interview and ask them to describe the tasks the computer

can help them with (example: shipping personnel –
shipment)

• Probe further to refine the tasks into specific user (shipping

personnel) goals, “I need to Ship items, Track a shipment,
Create a return”

13
 Use Cases

Technique 1 – User Goal Technique

14
 Use Cases

Technique 1 – User Goal Technique

Specific Steps
For each type
of user,
Further interview
Classify the
classify them to find a
potential users
potential users list of specific
Identify all the in terms of
by goals they will
potential their
organizational have when
users for the functional role
level (e.g., using the new
new system (e.g., shipping,
operational, system
marketing,
management, (current goals
sales)
executive) and innovative
functions to
add value)

15
 Use Cases

Technique 1 – User Goal Technique

Specific Steps

Review the
Look for
Identify where completed list
Create a list of duplicates with
different types with each type
preliminary use similar use case
of users need of user and
cases organized names and
the same use then with
by type of user resolve
cases interested
inconsistencies
stakeholders

16
 Use Cases

Technique 2 – Event Decomposition Technique

• More Comprehensive and Complete Technique
– Identify the events that occur to which the system must
respond.
– For each event, name a use case (verb-noun) that
describes what the system does when the event occurs Too
(but no need to go to the underlying functions). narrow
• Challenge: the appropriate level of details; for
example
– Typing a customer name on the form as a use case Too broad
– Is a use case- includes all working activities with
customers, e.g., adding new customer accounts,
updating records and contacting late-paying customers? appropriate
– Is a use case- is the entire process of adding a new
customer account?
17
 Use Cases

Technique 2 – Event Decomposition Technique

Appropriate level of detail for identifying use cases focuses on
Elementary business processes (EBP)
– A most fundamental task in a business process that is
performed by one person in one place in response to a
business event, adds measurable value, and leaves the
system and its data in a stable and consistent state

• Event – something that occurs at a specific time and place,

can be described, and should be remembered by the system.

18
 Use Cases

Events and Use Cases

19
 Use Cases

Types of Events
• External Event
– An event that occurs outside the system, usually initiated by an
external agent or actor.
• Temporal Event
– An event that occurs as a result of reaching a point in time.
• State Event
– An event that occurs when something happens inside the system that
triggers some process.
– E.g., reorder point is reached for inventory item.

20
 Use Cases

Technique 2 – Event Decomposition Technique

External Event

• External agent or actor wants something resulting in a

transaction
– E.g., Customer buys a product.
• External agent or actor wants some information
– E.g., Customer wants to know product details.
• External data changed and needs to be updated
– E.g., Customer has new address and phone.
• Management wants some information
– E.g., Sales manager wants update on production plans.

21
 Use Cases

Technique 2 – Event Decomposition Technique

Temporal Event

• Internal outputs needed at points in time

– Management reports (summary or exception)
– Operational reports (detailed transactions)
– Internal statements and documents (including payroll)
• External outputs needed at points of time
– Statements, status reports, bills, reminders

22
 Use Cases

Technique 2 – Event Decomposition Technique

State Events

• An event that occurs when something happens inside the

system that triggers the need for processing
– If sales of produce result in adjustment to inventory and inventory in
stock drops below a reorder point, it is necessary to reorder
– “Reorder point reached”

23
 Use Cases

Finding the actual event that affects the system

24
 Use Cases

Finding the actual event that affects the system

• The sequence of “transactions” for one specific customer resulting in many events.
• Thinking through this type of sequence can help identify events.

25
 Use Cases

Technique 2 – Event Decomposition Technique

Specific Steps
1. Consider the external events in the system environment that
require a response from the system by using the checklist

2. For each external event, identify and name the use case that
the system requires

26
 Use Cases

Technique 2 – Event Decomposition Technique

Specific Steps

3. Consider the temporal events that require a response from the system by
using the checklist shown below

4. For each temporal event, identify and name the use case that the system
requires and then establish the point of time that will trigger the use case (ex.
daily, weekly)

27
 Use Cases

Technique 2 – Event Decomposition Technique

Specific Steps

5. Consider the state events that the system might respond

to, particularly if it is a real-time system in which devices
or internal state changes trigger use cases.
• State events occur as a consequence of external events

6. For each state event, identify and name the use

case that the system requires – ex. “Reorder Point
Reached”

28
 Use Case Diagram

Core process 3: Analysis activities ​

Activity 1: Gather system requirements​

Activity 2: Define requirements​
Activity 3: Prioritize requirements​
Activity 4: Develop User-interface dialogs​
Activity 5: Evaluate requirements with users

29
 Use Case Diagram
Use Case Diagram Notations
Actor
• Represents the roles played by system users.
• It is an external entity and not part of the system.
• Actor can be human user, software, or external system.

Primary Actors
Initiate use cases and interact with the system. They are usually placed on
the left side of the system.

Secondary Actors
Are the actors who assist the primary actor to achieve a use case, and they
are usually displayed on the right side of the system. For secondary Actors
we can use <<Secondary>> stereotype
30
 Use Case Diagram
Use Case Diagram Notations
Use Case
• Represents a single system functionality of the
system.
• Each oval shape is a use case.

Association
• Represents a communication between the
actor and the system through the relationship
between the actor and the use case.

31
 Use Case Diagram
Use Case Diagram Notations
Include
• Is a relationship in which one use case (the base use
case) includes the functionality of another use case (the
inclusion use case).
• The included use case never stands alone. It occurs as
part of the base use case.

The included relationship of this example

indicates that the CheckOrderStatus use
case includes the behaviour of the Login
use case, and the Login use case cannot be
stand-alone.

32
 Use Case Diagram
Use Case Diagram Notations
Extend
• Extend relationship specify that one use case (extension)
extends the behaviour of another use case (base).
• The base use case may stand alone, but under certain behaviour
may be extended by the behaviour of another use case.
• The extended use case is optional use case.

The extend relationships shows the

optional use case Consult Credit Card
Account Balance which is used optionally
only when a user tries to withdraw money
using a credit card, but for other kinds of
withdraw transactions this use case will
not be used.

33
 Use Case Diagram
Use Case Diagram Notations
Generalization
• This relationship is represented by the inheritance
arrow.
• Reduce the complexity in use case diagrams by modelling
overlapping behaviours between actors and use cases.

Generalization between Actors Generalization between Use Cases

34
 Use Case Diagram
Use Case Diagram Notations
System Boundary
• Is an important notation in a use case
diagram that separates actors from use
cases.
• The actors are all outside of the
boundary and the use cases are all
inside.

35
 Case Study

Example : Use cases of writing articles

Primary Actor Secondary Actor

36
 Case Study

Example : Airline Booking System

37
 Case Study

Example: A use case diagram of university student enrolment subsystem

38
 Case Study

Automatic Teller Machine (ATM)

Problem statement
This case study concerns a simplified system of the automatic teller
machine(ATM). The ATM offers the following services:

1. Distribution of money to every holder of a smartcard via a card reader and

a cash dispenser.
2. Consultation of account balance, cash and cheque deposit facilities for
bank customers who hold a smartcard from their bank.

Do not forget either that:

3. All transactions are made secure.
4. It is sometimes necessary to refill the dispenser, etc.

39
 Case Study

Automatic Teller Machine (ATM)

From these four sentences, we will work through the following
activities to draw the use case diagram of the ATM:

Identify the actors.

Identify the use cases

Construct a use case diagram

Write a textual description of the use cases

40
 Case Study

Automatic Teller Machine (ATM)

Sentence 1 :Distribution of money to every holder of a smartcard via a card
reader and a cash dispenser.

• Every “holder of a smartcard”. He or she will be able to use the ATM to withdraw money
using his or her smartcard.

• However, be careful: the card reader and cash dispenser constitute part of the ATM. They can
therefore not be considered as actors!

• Another trap: is the smartcard itself an actor? The card is certainly external to the
ATM, and it interacts with it... Yet, we do not recommend that you list it as an actor.

• We are putting into practice the following principle: eliminate “physical” actors as much as
possible to the advantage of “logical” actors.

• The actor is the who or what that benefits from using the system.

• It is the card holder who withdraws money to spend it, not the card itself!

41
 Case Study

Automatic Teller Machine (ATM)

Sentence 2 : Consultation of account balance, cash and cheque
deposit facilities for bank customers who hold a smartcard from
their bank.

• Identifies additional services that are only offered to bank

customers who hold a smartcard from this bank.

• This is therefore a different profile from the previous one,

which we will realise by a second actor called Bank
customer.

42
 Case Study

Automatic Teller Machine (ATM)

Sentence 3 : All transactions are made secure.

• Encourages us to take into account the fact that all transactions are made secure. But
who makes them secure?

• There are therefore other external entities, which play the role of authorisation
system and with which the ATM communicates directly.
• An interview with the domain expert is necessary to allow us to identify two different
actors:
1. The Visa authorisation system (VISA AS) for withdrawal transactions
carried out using a Visa smartcard (we restrict the ATM to Visa smartcards for
reasons of simplification).

2. The information system of the bank (Bank IS) to authorise all transactions
carried out by a customer using his or her bank smartcard, but also to access the
account balance.

43
 Case Study

Automatic Teller Machine (ATM)

Sentence 4 : It is sometimes necessary to refill the dispenser, etc.

• Reminds us that an ATM also requires maintenance work, such

as refilling the dispenser with bank notes, retrieving cards
that have been swallowed, etc.

• These maintenance tasks are carried out by a new actor,

which – to simplify matters – we will call Maintenance
operator.

44
 Case Study

Automatic Teller Machine (ATM)

Step 1 : Identify the actors.

From the previous analysis we can conclude that the actors of

the ATM are:
1. Card Holder
2. Bank customer
3. VISA AS
4. Bank IS
5. Maintenance Operator

45
 Case Study

Automatic Teller Machine (ATM)

Step 2 : Identify the use cases

Maintenance
Bank IS Operator
Actors Bank Customer VISA AS
Card Holders
- Authenticate - Authenticate Will be Will be - Refill
Use Cases a visa card a bank card associated to associated to Dispenser
- Withdraw - Withdraw other use other use - Retrieve
Money Using Money Using a case (Card cases (Bank Swallowed
a Visa Card bank Card holder use Customer) as Cards
case) as secondary
- Consult the secondary actor - Retrieve
balance actor Deposited
- Deposit Cash Cheques
- Deposit Bank
Cheque

46
 Case Study

Automatic Teller Machine (ATM)

Step 3 : Construct a use case diagram

First Version

47
 Case Study

Automatic Teller Machine (ATM)

Step 3 : Construct a use case diagram

Second Version –
Improve the
model

48
 Case Study

Automatic Teller Machine (ATM)

Write a textual description of the use cases

• Once the use cases have been identified, you then have to describe them!

• Textually explain all the interactions between the actors and the system.

• The use case must have a clearly identifiable beginning and end.

• The possible variants must also be specified, such as:

- Main success scenario
- Alternative sequences
- Error sequences

49
 Case Study

Automatic Teller Machine (ATM)

Write a textual description of the use cases

In this case study we will

demonstrate a textual
description for the Withdraw
Money Using a Visa Card use
case.

50
 Case Study

Automatic Teller Machine (ATM)

Write a textual description of the use cases

Postconditions:
• The cashbox of the ATM contains
fewer notes than it did at the start of the
use Case.

51
 Case Study

Automatic Teller Machine (ATM)

Write a textual description of the use cases

52
 Case Study

Automatic Teller Machine (ATM)

Write a textual description of the use cases
• Another possible presentation consists in separating the actions of the actors and
those of the system into two columns as follows:

53
 Case Study

Automatic Teller Machine (ATM)

Write a textual description of the use cases
• “Alternative” sequences:

The scenario goes back to point 4

54
 Case Study

Automatic Teller Machine (ATM)

Write a textual description of the use cases
• “Alternative” sequences:

55
 Case Study

Automatic Teller Machine (ATM)

Write a textual description of the use cases
• Samples of Error sequences:

56
 Class Activity

E-scooter Rental System – Case study

An E-scooter rental company in Dubai wants to develop a mobile application that can
handle E-scooter rental, E-scooter return, and E-scooter auctions. The E-scooter
customer can rent the E-scooter by picking it up, and then return it after a certain
period of time. At the time of rent, the E-scooter customer has the option to rent a
single rent to E-scooter or buy a membership that offers 10 hours ride of the scooter,
which can be charged by the Visa Authentication System using the customer's credit
card that details added to the mobile application. When the E-scooter is returned, the
customer will be charged for this rental trip using the credit card of the customer
through the Visa Authentication System, or if he/she has a membership already the
system will deduct it from the account balance of the customer membership the
number of hours/minutes the customer rented the E-scooter. Moreover, the agent of
the renting E-scooter company auctions the E-scooter that has accumulated over
5,000 Kilometres of usage.

57
 Class Activity

E-scooter Rental System – Case study

Solution
An E-scooter rental company in Dubai wants to develop a mobile application that can
handle E-scooter rental, E-scooter return, and E-scooter auctions. The E-scooter
customer can rent the E-scooter by picking it up, and then return it after a certain period
of time. At the time of rent, the E-scooter customer has the option to rent a single rent
to E-scooter or buy a membership that offers 10 hours ride of the scooter, which can be
charged by the Visa Authentication System using the customer's credit card that details
added to the mobile application. When the E-scooter is returned, the customer will be
charged for this rental trip using the credit card of the customer through the Visa
Authentication System, or if he/she has a membership already the system will deduct it
from the account balance of the customer membership the number of hours/minutes
the customer rented the E-scooter. Moreover, the agent of the renting E-scooter
company auctions the E-scooter that has accumulated over 5,000 Kilometres of usage.

Actor
Use cases
Relationships (between use cases)

58
 Class Activity

E-scooter Rental System – Case study

Solution

59
 References
• Satzinger, J., Jackson, R. & Burd, S. (2016) Systems Analysis And Design In A
Changing World. 7th Edition, Boston, Mass. Cengage Learning.
• Unhelkar, B., 2017. Software engineering with uml. CRC Press.
• Roques, P., 2006. UML in practice: the art of modeling software systems
demonstrated through worked examples and solutions. John Wiley & Sons.
• Relationships in use-case diagrams.
https://www.ibm.com/docs/en/rational-soft-arch/9.5?topic=diagrams-relationship
s-in-use-case
. Last Accessed 1 October 2023.
• What is a use case diagram?
https://www.educative.io/answers/what-is-a-use-case-diagram . Last Accessed 1
October 2023.
• Primary and Secondary Actors (Use Case Diagram).
https://www.softwareideas.net/primary-and-secondary-actor-use-case-diagram
Last Accessed 1 October 2023.
• What is a use case diagram?
https://www.educative.io/answers/what-is-a-use-case-diagram Last Accessed 2
October 2023.

60
 THANK YOU
Any Question ?

61