Transportation Fare Payment System Design

This document outlines the design of a transportation fare payment system. It details various use cases such as fare determination, card payment, transaction saving, and exception handling. The design includes descriptions, triggers, preconditions, postconditions, normal flows, alternative flows, exceptions, and assumptions for each use case. The document also provides notes and issues for further clarification.

[Year]
INTRODUCTION TO SYSTEM DESIGN
STUDENT NAME
STUDENT ID

Contents
Question 1...................................................................................................................................................2
1.1 One-to-one interviews.......................................................................................................................2
1.2 Workshop..........................................................................................................................................2
1.3 Use of requirements gathering tools.................................................................................................2
1.4 Brainstorming....................................................................................................................................2
1.5 Current system documentation.........................................................................................................2
1.6 Questionnaires..................................................................................................................................2
1.7 Observation.......................................................................................................................................2
1.9 Prototyping........................................................................................................................................3
2 Question 2................................................................................................................................................3
2.1 Use case diagram...............................................................................................................................3
2.2 Use case list.......................................................................................................................................4
2.3 Travel Swipe card transaction system................................................................................................4
2.3.1 UC-1............................................................................................................................................4
2.3.3 UC-3............................................................................................................................................5
2.3.4 UC-4............................................................................................................................................6
3 Question 3................................................................................................................................................7
3.2 use case list........................................................................................................................................8
3.3 charge fare sub system......................................................................................................................8
3.3.1 UC-1............................................................................................................................................8
3.3.2 UC-2............................................................................................................................................9
3.3.3 UC-3..........................................................................................................................................10
3.3.4 UC-4..........................................................................................................................................11
4 references...............................................................................................................................................11

Question 1
To obtain information necessary for the development of the use case model, the following types of
requirements gathering techniques can be used.
1.1 One-to-one interviews
This type of technique of requirements gathering involves arranging a one-to-one interview or meeting
with the relevant stakeholders involved with the system. The meeting is between the system analyst
and one stakeholder at a time. For example the interview can be with the prospective customer where
by the system analyst will interview the customer to get user stories from the customer.
1.2 Workshop
The workshop technique is a method of requirements gathering where by the relevant stakeholders
hold a workshop to determine the requirements of the proposed system. This technique can obtain a lot
of information if preparation before the workshop is done by all stakeholders before the workshop.
1.3 Use of requirements gathering tools
Use of requirements gathering tools for example Axia’s RFI/RFP templates which comprise a huge list of
potential requirement and all stakeholders are given the template to choose the requirements they see
fit the proposed system. The templates are split into different modules so that each stakeholder is given
the module that is relevant to them.
1.4 Brainstorming
Brainstorming technique of requirements gathering can be done either individually or in groups with all
stakeholders. While brainstorming ideas are collected. These ideas are then analyzed to come up with
the requirements of the proposed system
1.5 Current system documentation
IF there is a current system in use, its documentation can be analyzed to come up with the requirements
for the proposed system. The documentation of the existing system could include software vendor
manuals and user manuals.
1.6 Questionnaires
Questionnaires method of requirements gathering is somehow similar to interviews but the questions
asked to gather requirements are phrased as questionnaires which are given to all stakeholders. The
questionnaires can be in form of a printed physical document, verbal questionnaire or even a web based
form designed as a questionnaire. The questionnaires answered are then analyzed to come up with the
requirements which are used to come up with the use case diagram.
1.7 Observation
Observation is a method of requirements gathering where by a system analyst observes how operations
are done for the existing system and then draws requirements from the observation analysis.
Observation can involve doing the work yourself as a system analyst to understand exactly how the
current system is working.

1.9 Prototyping
Prototyping is a method of requirements gathering where by requirements are collected and a
prototype is created. The prototype is then used by the stakeholders so that they can get a feel of what
the new system will be like. This will help them to understand what they actually need the new system
to do thus they are able to provide better requirements (Seymour and Biemer, 2011).
2 Question 2
The diagram below shows the use case diagram representing the required functionality of the system.
2.1 Use case diagram

2.2 Use case list
Use Case ID Primary Actor Use Cases
UC-1 traveller Swipe on station :includes (send information,card validation)
UC-2 traveller Swipe off station includes (send information,card validation)
UC-3 Fare determining
module
Determine fare: includes (determine time,determine type of
traveller, determine travel time)
UC-4 Fare determining
system
Charge fare
2.3 Travel Swipe card transaction system
2.3.1 UC-1
Use Case ID: UC-1
Use Case Name: Swipe on station
Created By: Student name and student ID
Date Created: 8/20/2017
Actors: Traveler
Description: A traveler swipes on station to start a journey on a certain zone. The swipe
on is supposed to grant the traveler access to the station
Trigger: User swipes their card on the station terminal
Preconditions: The card of the user must have enough money to travel from one zone to
another.
Postconditions: The system will grant the traveler access to the station. If validation of the
card fails, then the traveler will be shown a message that the card has been
declined and the system will show the reason why the card has been
declined. If the card is accepted then the information about the traveler,
time and the zone is sent to the main system
Normal Flow:  User swipes the card on the station computer
 The system validates the card by checking if it’s acceptable and if
the customer has enough money to travel from one zone to another
 If the card is declined system shows the message
 If the card is accepted the system sends information and grants
access to the traveler.

Alternative Flows:
[Alternative Flow 1 – Not
in Network]
Send information to the main system- if the card is accepted.
Exceptions: If the card is declined the system is supposed to display the message
showing why the card was declined.
Includes: Send information
Frequency of Use: On demand
Special Requirements: The card has to have a chip which contains information about the card
holder and the card is used only at entrance stations
Assumptions: Every customer knows how to use the station by swiping the card on the
station
Notes and Issues: The system must validate the card very fast.
2.3.3 UC-3
Use Case ID: UC-3
Use Case Name: Determine fare
Created By: Student name and student ID
Date Created: 8/20/2017
Actors: Fare determinant module<<system>>
Description: The fare determinant module determine the fare the user is supposed to pay
using the information sent from the traveler subsystem
Trigger: User swipes their card on the exit station terminal
Preconditions: The user must have spied their card on an exit station
Postconditions: The system determines the amount of fare to be charged.
Normal Flow:  System receives information from the exit station
 System determines the type of traveler
 System determines the zones travelled
 System determines zones travelled
Alternative Flows: Eject card from the station

[Alternative Flow 1 – Not
in Network]
Exceptions:
Includes: Determine zones travelled, determine type of traveler, determine time
Frequency of Use: On demand
Special Requirements: The system must perform the use case very fast
Assumptions: The system has already received all the information about the travel and the
traveler
Notes and Issues: The system must process the fare very fast
2.3.4 UC-4
Use Case ID: UC-4
Use Case Name: Charge fare
Created By: Student name and student ID
Date Created: 8/20/2017
Actors: Fare determinant module<<system>>
Description: The system charges the fare determined
Trigger: Fare determining system completes fare determination
Preconditions: The card of the user must have enough money to pay for the determined
amount
Postconditions: An amount is deducted from the user’s card
Normal Flow:  System receives the amount to be deducted
 System deducts the amount from the users account
Alternative Flows:
[Alternative Flow 1 – Not
in Network]
Exceptions: There is not enough money in the user’s account
Includes:

Frequency of Use: On demand
Special Requirements: The card of the user contains information about the user’s account.
Assumptions: The system deducts the amount from the customer without asking for
confirmation
Notes and Issues: The system must be very secure.
3 Question 3
UC-4 use case which is charge fare is expanded to produce the following use case diagram.
3.2 use case list
Use Case ID Primary Actor Use Cases

UC-1 <<system>>payment
module
Fetch amount to be paid
UC-2 <<system>>payment
module
Fetch payment info
UC-3 <<system>>payment
module
Deduct amount
UC-4 <<system>>payment
module
Save transaction details
3.3 charge fare sub system
3.3.1 UC-1
Use Case ID: UC-1
Use Case Name: Fetch fare
Created By: Student name and student ID
Date Created: 8/20/2017
Actors: payment module<<system>>
Description: System fetches the determined fare from the fare determining subsystem
Trigger: Fare determining system completes fare determination
Preconditions: The fare determination module must have completed fare determination
Postconditions: The amount to be charged is fetched from the fare determining subsystem
Normal Flow:  System fetches the amount to be charged from the determining
system
Alternative Flows:
[Alternative Flow 1 – Not
in Network]
Exceptions: The amount is not a correct form
Includes:
Frequency of Use: On demand

Special Requirements: The amount must be in form of a double
Assumptions: The fare determining sub system saves the amount it has determined
Notes and Issues: The sub system will fetch the amount from a database which the fare
determining module saves the amount for that particular journey
3.3.2 UC-2
Use Case ID: UC-2
Use Case Name: Fetch payment info
Created By: Student name and student ID
Date Created: 8/20/2017
Actors: payment module<<system>>
Description: System fetches the payment information of the card holder
Trigger: Fare determining system completes fare determination
Preconditions: The fare determination module must have completed fare determination
Postconditions: The payment info is fetched from the database
Normal Flow:  System fetches the payment info from the database for that pecific
card holder
Alternative Flows:
[Alternative Flow 1 – Not
in Network]
Exceptions: The payment info for that card holder does not exist
Includes:
Frequency of Use: On demand
Special Requirements: The user must exist in the system with his payment info up to date
Assumptions: THe payment info exists for every user who has a card
Notes and Issues: The payment info is fetched fro the record of the card holder

3.3.3 UC-3
Use Case ID: UC-3
Use Case Name: Deduct amount
Created By: Student name and student ID
Date Created: 8/20/2017
Actors: payment module<<system>>
Description: System deducts the amount from the card holders account
Trigger: Fare determining system completes fare determination
Preconditions: The fare determination module must have completed fare determination
Postconditions: An amount is deducted from the users account
Normal Flow:  System takes the amount to be charged and deducts it from the
card holders account
Alternative Flows:
[Alternative Flow 1 – Not
in Network]
Exceptions: Card holder does not have enough money in their account
Includes: Check if user has enough money
Frequency of Use: On demand
Special Requirements: The amount must be in form of a double
Assumptions: The fare determining sub system saves the amount it has determined
Notes and Issues: The payment sub system has to update the new amount after deducting.
3.3.4 UC-4
Use Case ID: UC-4

Use Case Name: Save transaction details
Created By: Student name and student ID
Date Created: 8/20/2017
Actors: payment module<<system>>
Description: System saves the details of a transaction
Trigger: Fare s deducted from the users account
Preconditions: The payment module must have already deducted the fare
Postconditions: A record I created on the database
Normal Flow:  System saves transaction details resulting from a deduction in the
database
Alternative Flows:
[Alternative Flow 1 – Not
in Network]
Exceptions: The deduction was not correct
Includes:
Frequency of Use: On demand
Special Requirements: The transaction details must be gotten from a deduction
Assumptions: The transaction details are saved in a database
Notes and Issues: Every transaction record is a result of a deduction from the users account.
4 references
Seymour, and Biemer, S. M., 2011. Systems Engineering Principles and Practice, 2nd Ed., Hoboken, N.J.,
John Wiley & Sons.