HARAMAYA UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEMS

Ethiopian Railway Ticket Booking System

Prepared By:

Name ID No

1. Minase Amauel 1988/13

2. Mohammed Molla 2044/13
3. Oliyad Temesgen 2249/13
4. Yosef Israel 3093/12

Submission Date: May 02, 2024

Haramaya University

Haramaya, Ethiopia
 HARAMAYA UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEMS

Ethiopian Railway Ticket Booking System

A Project Submitted to the Department of Information Systems of

Haramaya University in Partial Fulfillment of the Requirements for the Degree of
Bachelor of Science in Information Systems.

Prepared By:

Name ID No

1. Minase Amauel 1988/13

2. Mohammed Molla 2044/13
3. Oliyad Temesgen 2249/13
4. Yosef Israel 3093/12

Advisor: Mr. Tilahun M.

Co-advisor: Mr. Desalegn W.

Submission Date: Dec 29, 2023

Haramaya University

Haramaya, Ethiopia
 COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION SYSTEMS

CERTIFICATE OF APPROVAL
We hereby certify that we have read and evaluated this Industrial Project I Ethiopian Railway
Ticket Booking System prepared under our guidance by the following students. We recommend
that it be submitted as fulfilling the Industrial Project I requirement.

Prepared By:

Name ID No

1. Minase Amauel 1988/13

2. Mohammed Molla 2044/13
3. Oliyad Temesgen 2249/13
4. Yosef Israel 3093/12

Name and Signature of members of Examining Board

Title Name Signature Date

Advisor Mr. Tilahun M.
Co-Advisor Mr. Desalegn W.
Examiner 1
Examiner 2
Examiner 3
 DECLARATION

We, the undersigned, declare that this project is our original work and has not been presented for

a degree in any other university, and that all sources of materials for the industrial project I have

been duly acknowledged.

Name ID No

1. Minase Amauel 1988/13 ________________

2. Mohammed Molla 2044/13 ________________
3. Oliyad Temesgen 2249/13 ________________
4. Yosef Israel 3093/12 ________________

Dec,2023

This Project has been submitted for examination with my approval as an advisor

Advisor: Mr. Tilahun M. _______________

Co-advisor: Mr. Desalegn W. _______________

Dec,2023

i
ACKNOWLEDGEMENT

We would like to express our sincere gratitude to all those who have contributed to the
development of this project. First and foremost, we are deeply thankful to our advisors Mr. Tilahun
M. and Mr. Desalegn W. For their guidance, support and their continuous assistance and
encouragement throughout the preparation of this document as well as for the demonstration. They
were both our advisor and source of valuable information. Finally, thanks to our friends, who have
helped and given us suggestions and idea supports to develop this project.

ii
Table of Contents
DECLARATION ............................................................................................................................. i

ACKNOWLEDGEMENT .............................................................................................................. ii

List of Figures ............................................................................................................................... vii

List of Tables ............................................................................................................................... viii

List of Abbreviation ........................................................................................................................ x

Abstract .......................................................................................................................................... xi

CHAPTER ONE ............................................................................................................................. 1

1. INTRODUCTION ................................................................................................................... 1

1.1. Background of the Project ................................................................................................ 1

1.2. Motivation of the Project.................................................................................................. 3

1.3. Statement of the Problem ................................................................................................. 4

1.4. The Objectives of the Project ........................................................................................... 5

1.4.1. General Objective ..................................................................................................... 5

1.4.2. Specific Objectives ................................................................................................... 5

1.5. Methodology of the Project .............................................................................................. 6

1.5.1. System Development Model ..................................................................................... 6

1.5.2. System Development Tools ...................................................................................... 9

1.6. Data source and Data collection Methods ...................................................................... 10

1.7. Scope and Delimitation of the Project............................................................................ 11

1.7.1. Scope of the Project ................................................................................................ 11

1.7.2. Delimitation of the Project ...................................................................................... 11

1.8. Significance of the Project ............................................................................................. 12

1.9. Feasibility Assessment ................................................................................................... 12

1.9.1. Economic Feasibility .............................................................................................. 12

iii
 1.9.2. Technical Feasibility ............................................................................................... 13

1.9.3. Operational Feasibility ............................................................................................ 13

1.9.4. Schedule Feasibility ................................................................................................ 13

1.10. Budget Plan................................................................................................................. 14

1.11. Management Issue ...................................................................................................... 15

1.11.1. Team Configuration and Management ................................................................... 15

1.11.2. Communication Plan............................................................................................... 16

1.12. Organization of this Work .......................................................................................... 16

CHAPTER TWO .......................................................................................................................... 18

2. USER REQUIREMENTS SPECIFICATIONS AND ANALYSIS ...................................... 18

2.1. Overview Of the Existing Systems ................................................................................ 18

2.2. Overview Of the Proposed Systems ............................................................................... 18

2.3. Functional Requirement ................................................................................................. 20

2.4. Class Responsibility Collaborator (CRC) ...................................................................... 21

2.5. Supplementary Specifications ........................................................................................ 26

2.5.1. Business Rules ........................................................................................................ 26

2.5.2. Non-Functional requirements ................................................................................. 27

2.6. Use Case Modeling ........................................................................................................ 28

2.6.1. Essential Use Case .................................................................................................. 28

2.6.2. Essential Use Case Description .............................................................................. 29

2.6.3. System Use Case ..................................................................................................... 29

2.6.4. System Use Case Description ................................................................................. 31

2.7. User Interface Prototyping ............................................................................................. 38

CHAPTER THREE ...................................................................................................................... 39

3. SYSTEM DESIGN ................................................................................................................ 39

iv
 3.1. Class Modeling............................................................................................................... 39

3.1.1. Classes-type Layered Architecture ......................................................................... 39

3.1.2. Class Model ............................................................................................................ 41

3.2. User Interface Design ..................................................................................................... 42

3.3. Sequence Diagram.......................................................................................................... 44

3.4. Activity Diagram ............................................................................................................ 46

3.5. State Chart Diagram ....................................................................................................... 49

3.6. ERD and Normalization ................................................................................................. 52

3.6.1. Entity Relationships Modeling (ERM) ................................................................... 52

3.6.2. Normalization ......................................................................................................... 53

3.7. Relational Persistent Modeling ...................................................................................... 57

3.8. Component Diagram ...................................................................................................... 61

3.9. Deployment Diagram ..................................................................................................... 62

CHAPTER FOUR ......................................................................................................................... 63

4. IMPLEMENTATION ........................................................................................................... 63

4.1. Overview ........................................................................................................................ 63

4.2. System Development Tools ........................................................................................... 64

4.3. Sample Code of Systems ................................................................................................ 65

4.4. Testing ............................................................................................................................ 71

4.4.1. Unit Testing ............................................................................................................ 71

4.4.2. System Testing ........................................................................................................ 72

4.4.3. Acceptance Testing ................................................................................................. 72

4.4.4. Performance Testing ............................................................................................... 73

4.5. Clients Feedback ............................................................................................................ 74

4.6. User Manuals.................................................................................................................. 75

v
 4.6.1. Admin Manual ........................................................................................................ 75

4.6.2. Passenger Manual ................................................................................................... 77

4.7. Conclusion and Recommendation .................................................................................. 78

References ..................................................................................................................................... 80

Appendix I .................................................................................................................................... 82

Appendix II ................................................................................................................................... 84

vi
List of Figures

Figure 1:Iterative Waterfall............................................................................................................. 7

Figure 2:Gantt Chart ..................................................................................................................... 14
Figure 3:Essential Use Case.......................................................................................................... 28
Figure 4:System Use Case ............................................................................................................ 30
Figure 5:UI Prototyping ................................................................................................................ 38
Figure 6:Class-Type Layered Architecture ................................................................................... 40
Figure 7:Class Diagram ................................................................................................................ 42
Figure 8:Intro UI ........................................................................................................................... 42
Figure 9:Login or Register UI....................................................................................................... 42
Figure 10:Login UI ....................................................................................................................... 43
Figure 11:Register UI ................................................................................................................... 43
Figure 12:Home Screen UI ........................................................................................................... 43
Figure 13: Book UI ....................................................................................................................... 43
Figure 14:Sequence Diagram for Register Use case..................................................................... 44
Figure 15:Sequence Diagram for Login Use case ........................................................................ 45
Figure 16:Sequence Diagram for Book Use case ......................................................................... 46
Figure 17:Activity Diagram for Register Use Case ...................................................................... 47
Figure 18:Activity Diagram for Login Use Case .......................................................................... 48
Figure 19:Activity Diagram for Book Use Case........................................................................... 48
Figure 20:Activity Diagram for Pay Use Case ............................................................................. 49
Figure 21:State Chart Diagram for Register Use Case ................................................................. 50
Figure 22:State Chart Diagram for Login Use Case ..................................................................... 51
Figure 23:State Chart Diagram for Book Use Case ...................................................................... 51
Figure 24:State Chart Diagram for Pay Use Case ........................................................................ 52
Figure 25:ERD .............................................................................................................................. 53
Figure 26:Relational Persistent Model.......................................................................................... 60
Figure 27:Component Diagram .................................................................................................... 61
Figure 28:Deployment Diagram ................................................................................................... 62
Figure 29: Admin Login ............................................................................................................... 75

vii
Figure 30: Admin Analytics Overview ......................................................................................... 76
Figure 31: Admin Logout ............................................................................................................. 76
Figure 34: User Register Screen ................................................................................................... 77
Figure 33: User Login Screen ....................................................................................................... 77
Figure 32: Welcome Screen .......................................................................................................... 77
Figure 35: User Booking Page ...................................................................................................... 77
Figure 36: User Home Page .......................................................................................................... 77

List of Tables

Table 1:Budget Plan...................................................................................................................... 14

Table 2: Team Configuration ........................................................................................................ 15
Table 3: Communication Plan ...................................................................................................... 16
Table 4:CRC for Actor Classes..................................................................................................... 23
Table 5:CRC for UI Classes ......................................................................................................... 24
Table 6:CRC for Business/Domain Classes ................................................................................. 26
Table 7:Essential Use Case Description ....................................................................................... 29
Table 8:Register Use Case Description ........................................................................................ 31
Table 9:Login Use Case Description ............................................................................................ 32
Table 10:Book Use Case Description ........................................................................................... 33
Table 11:Pay Use Case Description .............................................................................................. 34
Table 12:Scan QR Codes Use Case Description .......................................................................... 35
Table 13:Manage Paid Ticket Use Case Description ................................................................... 36
Table 14:Manage Refund Requests Use Case Description........................................................... 36
Table 15:Logout Use Case Description ........................................................................................ 37
Table 16:Admin 1NF .................................................................................................................... 54
Table 17:Passenger 1NF ............................................................................................................... 54
Table 18:Ticket Officer 1NF ........................................................................................................ 54
Table 19:Ticket 1NF ..................................................................................................................... 54
Table 20:Booking 1NF ................................................................................................................. 54

viii
Table 21:Route 1NF ...................................................................................................................... 55
Table 22:Journey 1NF................................................................................................................... 55
Table 23:Payment 1NF ................................................................................................................. 55
Table 24:Ticket 2NF ..................................................................................................................... 56
Table 25:Booking 2NF ................................................................................................................. 56
Table 26:Booking 2NF ................................................................................................................. 56
Table 27:Journey 2NF................................................................................................................... 56
Table 28:Relational Persistent Modeling ...................................................................................... 57

ix
List of Abbreviation

1NF: First Normal Form

2NF: Second Normal Form

3NF: Third Normal Form

AALRT: Addis Ababa Light Railway Transit

CRC: Class Responsibility Collaborator

CRS: Computerized Reservation System

ERD: Entity Relationship Diagram

ERM: Entity Relationships Modeling

ERC: Ethiopian Railway Corporation

IDE: Integrated Development Environment

PRS: Passenger Reservation System

PHP: Hypertext Preprocessor

PERT: Project Evaluation Review Technique

QR: Quick Response

SMS: Short Message Service

UC: Use Case

UML: Unified Modeling Language

UI: User Interface

x
Abstract

The Ethiopian Railway Ticket Booking System aims to revolutionize the current Semi-automated
ticketing process by introducing a modern digital mobile platform. This transformative project
responds to the inefficiencies and limitations of the existing system, providing passengers with a
modernized and user-friendly experience. By incorporating mobile accessibility and dynamically
generated QR codes, the proposed system streamlines ticket reservations, enhances real-time
information access, and automates key processes, ultimately reducing processing times and
minimizing errors. The digital platform offers scalability, allowing for increased user demands,
and prioritizes security measures to ensure the integrity of passenger data. Through its innovative
features and a commitment to technological advancement, the project seeks to open the way in a
new era of efficiency and convenience in Ethiopian Railway ticket bookings, contributing to the
modernization of railway services and enhancing the travel experience for passengers.

xi
CHAPTER ONE

1. INTRODUCTION

1.1. Background of the Project

The first digitized railway ticket booking system was launched by Indian Railways with the
introduction of the Computerized Reservation System (CRS) known as "Indian Railways
Passenger Reservation System (PRS)" on November 15, 1985. This marked a significant milestone
in the history of railway ticketing as it transitioned from manual methods to computerized systems
[1].

The initial implementation of the computerized reservation system aimed to streamline the ticket
booking process, reduce manual errors, and enhance the efficiency of railway operations. Over
time, digital ticketing systems have evolved globally, becoming commonplace in railway networks
around the world, contributing to improved customer convenience and operational efficiency.

In 2016 it was stated that The Addis Ababa Light Railway Transit (AALRT) will soon implement
an electronic ticketing system. The AA-LRT operates under the Ethiopian Railway Corporation
(ERC). The electronic ticketing using kiosk machines now is being implemented only in the capital
of Ethiopia, Addis Ababa [2].

The local Ethiopian Railway Ticket Booking System currently is semi-automated which needs the
physical presence of travelers at the stations in order to buy their ticket, hence this existing system
faces certain challenges and inefficiencies, prompting the need for a more advanced and automated
solution. The existing system is most likely to face challenges such as queue congestions, limited
accessibility, human errors, time-consuming process, ineffective record keeping, limited payment
options, overhead costs, scalability issues, customer dissatisfaction, security concerns, lack of real-
time information, inflexibility in modifications. Addressing these challenges by transitioning to an
automated railway ticket booking system can significantly enhance efficiency, customer
satisfaction, and overall operational effectiveness.

1
In today's advancing technological landscape, there is a rising demand for various ticketing
systems. Digital ticketing methods, including e-ticketing and m-ticketing, are often perceived as
similar concepts, yet they differ in crucial aspects. It's essential not to conflate the two, as each
operates independently and has distinct functionalities. While both fall under the umbrella of
digital ticketing, they have unique processes and characteristics that set them apart. Understanding
these differences is crucial to navigating and take advantage of their respective benefits effectively
[3].

E-ticket can be traced with the phrase ‘Print it’, it allows consumers to gain a certain amount of
time before events such as cinema and concerts or before travelling by plane, train or bus. E-
Tickets are different from traditional tickets. They provide a wide range of advantages that
traditional don’t offer. An E-ticket can be directly printed at home. Whereas M-ticket can be traced
with the phrase ‘Show it’, since it does not need to be printed. Holds on to various methods through
which it can be implemented depending on the technology used. In a system based on text
messaging, the user receives their ticket in the form of either an alphanumeric code or a barcode.
In a process based on a mobile application, the user carries out a transaction through the app and
receives a verification, such as a QR code, specific to their account. Among these methods the
proposed Ethiopian Railway Ticket Booking System is a system in which a user or traveler can
book and select travel payment methods through mobile application and checked in to the journey
through the QR code generated from the booking data entry result and payment confirmation.

This project as mentioned earlier mostly is under the category of usage of m-ticketing for
transforming the existing system of Ethiopian Railway Ticket Booking System into automated or
digital system, this distinct category is selected for the reason that mobile tickets offer more
advantages than traditional one’s better commodity for users, less queuing. And costs will also
drop because of the reduced printing and diffusion costs. Furthermore, it will be impossible to lose
your ticket. Consumers now gain time because they have the possibility to buy and use their tickets
whenever they want and wherever they are thanks to their smartphones. The M-ticket is also eco-
friendlier, compared to the E-ticket it doesn’t need to be printed, paper consumption will thus
decrease, making it even better for our planet.

The proposed system holds for the currently available and active routes provided by the ERC, with
certain features such as Process Payment, Search trip schedule by depart and destination, Reserve

2
Seat number, Consider Class type, Reservation code expiring time, Notifications, Schedule
Change and others.

1.2. Motivation of the Project

The development of the Ethiopian Railway Ticket Booking System consists several motivations
behind it. The primary driving force behind initiating this project stems from the financial
constraints faced by university students, who typically fall within the low to medium income
brackets. Given this financial context, train travel emerges as the preferred mode of transportation
between home and campus. This preference is influenced by safety concerns with buses and the
financial challenges associated with air travel. Currently, purchasing train tickets involves process
of physically going to the stations in Dire Dawa and Addis Ababa, incurring wastage of time and
tiresome experience caused by waiting lines for purchasing tickets and being punished certain
amount of money for losing the paper ticket and cancellation of journey. Recognizing that many
university students share these difficulties, we propose the development of a system that can be
facilitated by the Ethiopian Railway Corporation (ERC). This system aims to allow travelers to
easily reserve and purchase train tickets through their smartphones, eliminating the need for
physical visits to the station and streamlining the payment process.

The other motivations which led us for the development of the proposed system are:

➢ Addressing the manual booking challenges

➢ Digital transformation in transportation
➢ Promoting Accessibility
➢ Improving Record-Keeping and Data Management
➢ Contributing to Efficiency and Cost Reduction

Generally, the motivation behind the Ethiopian Railway Ticket Booking System project is rooted
in a commitment to improving passenger experiences, embracing technological advancements, and
addressing the evolving needs of Ethiopia's growing railway infrastructure.

3
 1.3. Statement of the Problem

Currently ERC is using a semi-automated system in which the ticket officers use computers to
insert user details every single time either that same or new user needs to buy ticket, which makes
it hard for the users to reserve and buy tickets whenever needed and as easily needed. As a context
to depict the problem , Most of students of Haramaya University and other customers of ERC
stated that they usually have to be present physically at the corresponding station whenever they
want to reserve and buy tickets, indeed one needs to be physically present at the station at the exact
time of start of the journey but it is not necessary to be physically present during reservation and
payment process of the travel ticket which creates tiresome experience for the customer and also
the staffs of ERC and cost incurred for manual resources such as paper and also the manual labor
itself.

Considering the context there are several challenges coming up with the usage of the existing
system such as:

➢ Queue Congestion: Long queues at ticket counters lead to congestion and delays for
passengers, especially during peak travel times.
➢ Limited Accessibility: Passengers may face difficulties accessing ticket counters, limiting
their ability to purchase tickets conveniently.
➢ Human Errors: Semi-automated processes are prone to human errors, such as incorrect
data entry, leading to discrepancies in ticket information and potential customer
dissatisfaction.
➢ Time-Consuming Process: The Semi-automated ticketing process is time-consuming,
both for passengers waiting in line and for the staff processing transactions, resulting in
inefficiencies.
➢ Ineffective Record-Keeping: The existing record-keeping systems may lack accuracy and
can be challenging to maintain, making it difficult to track passenger information and
manage the overall ticketing process efficiently.
➢ Limited Payment Options: Traditional ticket booking often involves limited payment
options, restricting passengers to cash transactions and excluding more modern payment
methods.

4
 ➢ Overhead Costs: Maintaining semi-automated ticketing processes involves higher
overhead costs, including paper, and other resources, contributing to operational expenses.
➢ Customer Dissatisfaction: Delays, errors, and inefficiencies in the semi-automated
booking process contribute to customer dissatisfaction, impacting the overall passenger
experience.
➢ Security Concerns: The existing system lack robust security measures, making them
susceptible to fraud, ticket tampering, or other security breaches.
➢ Lack of Real-time Information: Passengers may face challenges obtaining real-time
information about ticket availability, schedules, and other relevant details, leading to
inconvenience and uncertainty.
➢ Inflexibility in Modifications: Making changes to booked tickets or accommodating last-
minute adjustments can be difficult and may require additional semi-automated
interventions.

In order to overcome the stated problem and sub-problems coming up with it we have proposed a
technological solution coined as Ethiopian Railway Ticket Booking System based on QR-code
generation.

1.4. The Objectives of the Project

1.4.1. General Objective

➢ The main objective of this Project is to develop a Digital means of ticketing for Ethiopian
Railway Corporation.

1.4.2. Specific Objectives

➢ To Develop a User-Friendly Booking Interface

➢ To Implement User Authentication and Authorization
➢ To Integrate Dynamic QR-Code Generation
➢ To Establish a Centralized Database System
➢ To Incorporate Payment Gateway Integration
➢ To Incorporate Refund method

5
 ➢ To provide seat selection feature using seat maps
➢ To Develop an Admin Panel for System Management
➢ To Implement Ticket Modification and Cancellation
➢ To Provide User Notifications
➢ To Provide Comprehensive System Documentation

1.5. Methodology of the Project

1.5.1. System Development Model

The methodology section of a project outlines the approach, tools, and techniques that will be
employed to achieve the objectives of the project or development effort. For this project here the
Iterative waterfall methodology is utilized as a methodology.

The Waterfall methodology is a linear and sequential approach to software development. It

consists of distinct stages or phases, and progress is seen as flowing steadily downwards (like a
waterfall) through these phases. Each phase must be completed before moving on to the next one,
and changes are typically discouraged once a phase has been completed. It is a linear process for
design and development, where line items for creating the software are set and completed in order.
Once one step is complete, the team moves onto the next step. The team typically can’t go back a
step without starting over from the beginning of the process, as each step is contingent on the ones
leading up to it. Therefore, the classical waterfall life cycle model needs some feedback mechanism
to correct the errors in the previous phases [4].

This feedback mechanism is introduced and named it Iterative waterfall model.

6
Figure 1:Iterative Waterfall

Iterative model was introduced because of problems faced in Waterfall model. The iterative
waterfall model is used in the development of the system. The system is developed in increments,
each increments adding some functional capability to the system until the full system is fully
implemented. The advantage of this approach is that it will result in better testing, as testing of
each increment is easier than testing the entire system in totality. Furthermore, this approach
provided us with important feedback that was very useful in the implementation of the system.
The iterative waterfall model is very similar to the classical waterfall model, but there are feedback
paths; these feedback paths make the model realistic [5].

7
Stages of the model used for this project include:

1. Requirements Gathering and Analysis:

• Identify and document the requirements for the Ethiopian Railway Ticket Booking System,
including user roles, functionalities (e.g., ticket booking, seat selection, payment
processing).
• Engage with potential users, to gather comprehensive requirements.
2. System Design:
• Create a detailed system design based on the gathered requirements. Design the
architecture of the system, including databases, modules, and interfaces.
• Specify how users will interact with the system, detailing user interfaces, and workflows.
3. Implementation (Coding):
• Write the code for the Ethiopian Railway Ticket Booking System based on the detailed
design specifications.
• Implement features such as user authentication, ticket booking, seat selection, payment
processing, and any other functionalities required for the system.
4. Testing:
• Conduct various types of testing, starting with unit testing for individual components and
progressing to integration testing to ensure that different parts of the system work together.
• Perform system testing to evaluate the entire system against the specified requirements.
• Validate the correctness and reliability of the ticket booking process
5. Deployment (Installation):
• Deploy the developed system to the production environment, making it available for use
by railway staff and customers.
• Provide training to railway staff on how to use the system.
6. Maintenance and Support:
• Address any post-deployment issues or bugs promptly.
• Provide ongoing support to users and address any necessary updates or enhancements.
• Monitor the system's performance, ensuring that it meets the operational requirements of
the Ethiopian Railway Ticket Booking System.

8
Characteristics and Considerations of the model:

✓ Sequential Flow: Each stage must be completed before moving on to the next.
✓ Document-Driven: Emphasis on extensive documentation at each stage to provide a clear
record of requirements, design, and other decisions.
✓ Inflexibility: Changes to requirements after the project has started are discouraged and may
be costly to implement.
✓ Well-Suited for Well-Defined Projects: Waterfall is often best suited for projects with well-
defined and stable requirements.

1.5.2. System Development Tools

Since the system consists of two major modules:

✓ Mobile application: through which the users (Passengers) experience the booking system
and
✓ Web Application: through which the Administrators and Ticket Officers experience the
booking system

It encompasses distinct framework and programming languages to develop the mentioned modules
and provide an integrated common database in between them.

Mobile Application Development and Web Application Development: Flutter

This project uses flutter which is an open-source UI software development toolkit created by
Google for building natively compiled applications for mobile, web, and desktop from a single
codebase. It allows developers to use a single codebase to create applications for different
platforms, reducing development time and effort.

Flutter primarily uses the Dart programming language. Dart is a modern, object-oriented language
with a syntax that is easy to learn. It was developed by Google, and it's designed for building web,
mobile, and server applications [6].

9
Back-End development: Firebase (Cloud Firestore)

Firebase is a Backend-as-a-Service (BaaS) app development platform that provides hosted

backend services such as a real-time database, cloud storage, authentication, crash reporting,
machine learning, remote configuration, and hosting for your static files [7]. It provides a set of
tools and services that enable developers to build, test, and deploy applications quickly and
efficiently. Firebase offers a wide range of features, including real-time databases, authentication
services, cloud functions, cloud storage, hosting, analytics, and more. It is designed to simplify
backend development and provide scalable infrastructure for applications.

Here, it is intended to use the firebase as a back-end for both the mobile application and the web
modules as a central back-end server.

Integrated Development Environment (IDE)

Integrated Development Environment (IDE) is a software application that provides comprehensive

tools and features to facilitate the development of software applications. It typically includes an
editor for writing code, a compiler or interpreter for building and running the code, debugging
tools, and additional features to streamline the development process [8].

✓ Visual Studio Code: for the Web application development

✓ Android Studio: for the Mobile application development

1.6. Data source and Data collection Methods

To do this project, the project team uses data collection methodology to gather the necessary
information that is needed to develop this project. The project team used Interview as a primary
data collection method and document analysis and Internet as a secondary data collection method.

1. Interview: Informal interviews are utilized in order to gain information required for both
the documentation and implementation phase of the project.
2. Document Analysis: To get more information about our project we have used documents
that help us to develop our project. During the analysis of documents, we give special
consideration to those documents which can bring more features to our system.

10
 3. The Internet: We have utilized the official pages of ERC and EDR for gathering different
requirements that helped as on the development of models of several activities.

1.7. Scope and Delimitation of the Project

1.7.1. Scope of the Project

The project limits its encompassing areas with respect to various phenomena. Geographically the
system focusses on the Ethiopian railway network which has Addis Ababa to Dire Dawa as its
main route and vice versa, covering major routes and stations within the country, as mentioned
earlier currently active local route is the Addis Ababa- Djibouti Railway line while the other two
are not currently available, the system’s user scope limits with the primary users of the system
being passengers looking to book railway tickets. The system allows users to search, select, and
book railway tickets. The system will be developed using specific programming languages,
frameworks, and technologies as outlined in the methodology.

The Ethiopian Railway Corporation (ERC) is engaged in both passenger and freight transportation.
Our current project exclusively centers on passenger transport, with a particular emphasis on the
ticketing service offered within the main stations along the primary routes. While the corporation
delivers various services at these stations, such as residence assistance for guiding travelers and
guards for physical security, our project's scope is confined to the ticketing service, excluding other
station services.

The project’s security measures are also limited to protect user data, financial transactions, and the
overall integrity of the system. A notification system is integrated to update users on booking
status, modifications, and cancellations.

1.7.2. Delimitation of the Project

The project consists of its mentioned scope boundaries and delimits the following areas which are
specified with respect to certain phenomena, Geographically the system will not cover further
international railway routes. In accordance to its functionality the project will not include features
unrelated to the core functionalities of ticket booking which is QR code generation, and associated
processes. The system is directed not to employ technologies or frameworks outside of those

11
specified in the methodology, and finally notification system will not cover every possible
communication channel but will focus on essential updates for users.

1.8. Significance of the Project

The result of the project is expected to contribute to the main actors who are currently taking part
in the existing semi-automated system used by ERC which are The Passengers and the Ticket
Officers working in ERC.

The project is also anticipated to serve as a guiding example for future developers, providing
valuable insights on the seamless transformation of manual ticket booking and seat reservation
systems within the Ethiopian transportation sector into efficient digital platforms. The project
documentation and implementation will stand as a mentor, offering a blueprint for the
digitalization of various transportation modes, facilitating a smoother transition for upcoming
developers in Ethiopia.

1.9. Feasibility Assessment

Feasibility study is the process of determination of whether or not a project is workable [9].

There are some feasibility studies concerning different approaches:

1.9.1. Economic Feasibility

Economic feasibility identifies that whether the new developing system is economically feasible
or not. Economic justifications include a broad range of concerns that include cost benefits
analysis.

Since the system is being automated to avoid extreme problems of semi-automated ticketing
system, this in return helps them to increase satisfaction that they can get before.

For the project we are working on we have the following benefits and costs.

➢ Tangible Benefits:

The primary benefit of this project stems from the implementation of a newly computerized
system, aiming to decrease the resources allocated to semi-automated operations.

12
Intangible Benefits:

Intangible benefits in the system development include:

✓ Increased speed of activity

✓ Increased feasibility.
✓ Increased authentication, and.
✓ More timely information.
✓ Time Saving

1.9.2. Technical Feasibility

Technical feasibility is a study of resource availability that may affect the ability to achieve an
acceptable system.

The evaluation determines whether the technology needed for the proposed system is available or
not. And in our case the technology needed for this project are available.

1.9.3. Operational Feasibility

It is a measure of how well a proposed system solves the problems and how it satisfies the
requirements identified in the requirements analysis phase of system development.

On this study we can identify whether the process in the new Ethiopian Railway Ticket Booking
System can satisfy all the needs present in the requirement analysis phase or not.

➢ Implementation – To implement Ethiopian Railway Ticket Booking System there is a need

to know the hard ware and internet resource.
➢ Resistance – Try to omit or avoid systems that make users ambiguous or confused.
➢ Strategies – Our aim of developing these systems is to make all users applicable or fully
satisfied with it.

1.9.4. Schedule Feasibility

The project is intended to be with in fixed time interval. Unless and otherwise we may fail in
difficulty in cost estimation and as well as we may fail in the financial problem, to overcome such

13
problem we fixed the time interval in which we should finish the development of the whole time
among different section of project by using the one of two techniques of schedule which are PERT
(Project Evaluation Review Technique) and Gant Chart. Well, we use Gant chart for our planning
and project review schedule.

Figure 2:Gantt Chart

1.10. Budget Plan

A project budget is a plan that details how much you'll spend, for what, and by when. When you
create a budget plan in advance and use it to monitor spend throughout your project, you can reduce
the likelihood that you'll run out of resources or go over budget—a common occurrence in many
workplaces [10].

Table 1:Budget Plan

Category Details Amount (ETB)

Transportation Mainly From campus to Dire 600 ETB
Dawa Railway Station and
way round
Internet Usage Internet usage when there is a 1000 ETB
need to update document at

14
 the time of not being in the
computer laboratory but other
places.
Print Printing document for hard 300 ETB
copy submission of the system
documentation
Personal Expense Costs for meetings on lounges 1500 ETB
Paper, Pen and Pencil Usage - 500ETB
TOTAL - 3900ETB

1.11. Management Issue

1.11.1. Team Configuration and Management

In our project, we have 4 members where each of us has specified work and also the projects are
supervised by one of our members.

The table below describes the types of tasks and also responsibility each of us can have:

Table 2: Team Configuration

Tasks Group Member/s ID No

Project Manager Yosef Israel Configuring and assigning specific tasks
System Minase Amanuel & Requirement gathering, identifying documents and
Requirement and Oliyad Temesgen materials needed for developing the project as well
Specification as identifying the functional and non-functional
(SRS) requirements to be delivered be the proposed
system
Analysis and Mohammed Molla & Developing architectural view of the system using
Design Yosef Israel various visual features such as diagram after
analysis collected data…

15
 Documentation Oliyad Temesgen System analysis and design documentation
Reviewer reviewing and find errors and gaps left unseen by
the rest of team members
Code Mohammed Molla & Writing the code for the proposed system and
(Implementation) Yosef Israel integration of front-end and back-end
developments.
Testing Minase Amanuel Finally putting the developed system in to test
using well-known testing techniques.

1.11.2. Communication Plan

While working on our project, we use the following techniques in order to meet one another and
communicate by exchanging our suggestions and ideas.

The table below describes the techniques of our communication methods:

Table 3: Communication Plan

No Techniques Frequency Durations

1 Mobile Phones Whenever Needed -
2 Telegram (Group chat and 2 Times a week 3 hours
Video calls)
3 Meet Physically 5 Times a week 3 hours

1.12. Organization of this Work

The structure of this work comprises four chapters, each contributing to a thorough comprehension
of the project. In the initial chapter, an introduction to the project is presented, offering a detailed
overview of the system. This includes background information on the previous works related to
the system, establishing the project's context. Additionally, the chapter articulates the problem
statement, explaining the specific challenges the system seeks to address. To provide a clear project
direction, both general and specific objectives are defined. The chapter also outlines the scope of

16
the system, precisely describing project boundaries. A brief explanation of the development
methodology is provided, and the significance of the proposed application is underscored,
emphasizing its potential impact and benefits.

The second chapter is dedicated to user requirements and analysis. Here, an analysis of the existing
system is conducted, identifying any limitations or bottlenecks that necessitate resolution. The
chapter explores functional requirements, precisely describing the specific features and
functionalities the proposed system should incorporate.

The third chapter offers a detailed insight into the system design for the proposed system. It
clarifies how the system is intended to function, encompassing various components and modules.
The chapter dives into the architecture and design. This section acts as a blueprint for the
development process, guiding implementation and ensuring a well-designed, cohesive application.

The fourth chapter depicts about the implementation phases that have already taken place by the
project team, the sample code and prototype of the system followed by the results for different
testing types in context with the proposed system and the user manual which can help users of the
system to utilize the app easily and finally it holds on to conclusion of the whole idea of the paper
and the system and also recommendations to different personnels.

This organizational structure allows readers to develop a comprehensive understanding of the

project, progressing logically from introduction and user requirements analysis to detailed system
design. Such a structure facilitates effective communication of the project's objectives, scope, and
methodologies.

17
CHAPTER TWO

2. USER REQUIREMENTS SPECIFICATIONS AND ANALYSIS

2.1. Overview Of the Existing Systems

An examination of the current semi-automated Ethiopian Railway ticket booking system reveals
an operational method that relies on both computers based on the ticket officer side and non-
automated processes on the user’s side. In this existing system, the booking of railway tickets is
managed through semi-automated procedures with a very little assistance of technological tool on
the ticket officer’s side. Customers typically engage with railway staff directly in person or through
non-digital means, to inquire about ticket availability, make reservations, and complete the
booking process.

Despite its reliance on human interactions, the semi-automated system may present certain
challenges, including potential inefficiencies, longer processing times, and a higher likelihood of
errors in data entry or ticket allocation. Additionally, the absence of automation may limit the
system's ability to provide real-time updates, hinder scalability, and pose challenges in adapting to
increasing demands for railway services.

In summary, the existing Semi-automated Ethiopian Railway ticket booking system operates
through conventional, non-digital methods for users, relying on human interactions. The
assessment of this system lays the groundwork for exploring the need for and benefits of
transitioning to a more modern and automated approach.

2.2. Overview Of the Proposed Systems

The proposed Ethiopian Railway ticket booking system represents a transformative shift from the
existing semi-automated processes to a fully digital mobile ticketing platform. This innovative
system aims to make use of modern technologies to streamline and enhance the efficiency of the
ticket booking experience for both passengers and railway personnel.

Key features and aspects of the proposed system include:

Mobile Accessibility

18
The proposed system introduces mobile accessibility, allowing passengers to perform ticket
bookings using their smartphones. This provides users with the convenience of making
reservations anytime, anywhere.

QR Code Integration

A notable feature of the system is the incorporation of dynamically generated QR codes. These
QR codes serve as digital representations of tickets, facilitating secure and efficient ticket
validation.

Real-Time Updates

Unlike the semi-automated system, the proposed digital platform offers real-time updates on ticket
availability, trip schedules, and other relevant information. Passengers can access the latest
information, ensuring a more informed and convenient booking process.

Efficient Record-Keeping

The system employs digital databases for efficient record-keeping. Passenger details, booking
history, and trip schedules are stored electronically, reducing the reliance on semi-automated
paperwork and minimizing the risk of errors.

Automated Processes

Automation is introduced in various processes, including ticket allocation, seat reservations, and
payment processing. This automation contributes to faster transaction processing and a reduction
in semi-automated intervention.

User-Friendly Interface

A user-friendly interface is prioritized to enhance the overall user experience. Both passengers and
railway personnel can navigate the system effortlessly, contributing to increased user adoption.

Security Measures

Security features, including secure transactions and secure user authentication, are implemented
to safeguard passenger information and ensure the integrity of the ticketing process.

Seat Selection Feature

19
Here, user selects the seat before payment, Hence if the user did not finish purchasing the ticket
and is only on booked status the seat will not be fully reserved where as if the user completes its
navigation to purchase the ticket including the payment process the selected seat will be reserved
for that specific passenger.

Integration with Payment Gateways and Refund Process

The system integrates with secure payment gateways, allowing passengers to make secure online
payments for their bookings. This adds a layer of convenience and flexibility to the payment
process.

The proposed Ethiopian Railway ticket booking system represents a digital transformation aimed
at improving accessibility, efficiency, and user experience. By incorporating mobile ticketing, QR
code technology, and automation, the system aims to overcome the limitations of the existing semi-
automated system and usher in a new era of modern and convenient railway ticket bookings.

2.3. Functional Requirement

The functional requirements of the "Ethiopian Railway Ticket Booking System" outline the
specific capabilities and features that the system must possess to meet the needs of its users. These
requirements are essential for the successful development and operation of the system. The
following functional requirements are identified for the project:

• User Registration and Authentication: Users should be able to create accounts securely.
The system should authenticate users during the booking process.
• Search and View Train Schedules: A search feature to find available trains based on
criteria like date, time, and destination. Display detailed train schedules, including
departure and arrival times.
• Seat Availability and Selection: Show the availability of seats found in the train. Allow
users to select and reserve specific seats.
• QR Code Generation: Dynamically generate a unique QR code for each purchased ticket.
The QR code should contain essential details like the user's information, journey details.
• Booking and Payment Processing: Provide a user-friendly booking process with a step-
by-step interface. Support payment process securely for ticket purchases.

20
 • Ticket Confirmation and Receipt: Display a confirmation of the booked ticket. Email or
SMS the user the ticket details and a digital confirmation containing the QR code.
• User Profile Management: Allow users to manage their profiles, including updating
personal information and viewing booking history.
• Reservation Expiring time: Ensure real-time validation to prevent the use of duplicate or
expired QR codes.
• Cancellation: Enable users to cancel booked tickets.
• Admin Dashboard: An administrative interface to manage user accounts, train schedules,
and bookings.
• Notification System: Automated email or SMS notifications for booking confirmation,
changes in schedule, or cancellations.
• Mobile Responsiveness: Develop a responsive design to facilitate easy use on various
devices, including smartphones and tablets.

2.4. Class Responsibility Collaborator (CRC)

Class Responsibility Collaboration (CRC) cards are a brainstorming tool used in the design of
object-oriented software. It is a collection of standard index cards that have been divided into
three sections [11].

Each card lists:

➢ Class Names: Located at the top of the card, describes the class that the CRC card
represents
➢ Responsibilities: Represented along the left side of the card. Each distinct responsibility
is on its own row. It is simply something that a class knows or does.
➢ Collaborators: Another class that a class interact with to fulfill its responsibilities.
CRC card can be applied for different class types of a system, such as: User Interface class,
Business (Domain class) and Actor class:
➢ Actor Classes: - actors that appear in use case.
➢ Business Classes: - places, things, concepts, and events that describe what the business is
all about.
➢ UI Classes: - screens, menus and navigation.

21
A. Actor Classes CRC
Admin <<Actor Class >>

• Username • Journey<<Business Class>>

• Password • Route<<Business Class>>
• Login () • Login UI<<UI Class>>
• Logout () • Admin UI<<UI Class>>
• Manage Journey ()
• Manage Fares ()
• Manage Ticket Officer ()
• Manage Route ()
• Refund Request Approval ()

User <<Actor Class >>

• Password • Register UI <<UI Class>>

• Email • Login UI <<UI Class>>
• Register () • User UI <<UI Class>>
• Login () • Ticket Officer<<Actor Class>>
• Logout () • Ticket<<Business Class>>
• Select Routes () • Journey<<Business Class>>
• Search Journey () • Payment<<Business Class>>
• Select Seat ()
• Book Ticket ()
• Pay ()
• View QR code ()
• View Book History ()
• View Notification ()
• Request Refund ()

22
 Ticket Officer <<Actor Class>>

• Username • Login UI <<UI Class>>

• Password • Ticket Officer UI <<UI Class>>
• Login () • User <<Actor Class>>
• Logout ()
• View Passenger Details ()
• Scan QR Code ()

Table 4:CRC for Actor Classes

B. UI Classes CRC

Admin UI <<UI Class>>

• Login () • Admin<<Actor Class>>

• Add Journey ()
• Remove Journey ()
• Manage Fares ()
• Manage Ticket Officer ()
• Manage Route ()
• Refund Request Approval ()

Register UI <<UI Class>>

• Register form • User<<Actor Class>>

23
 Ticket Officer UI <<UI Class>>

• Login () • Ticket Officer<<Actor Class>>

• View Passenger Booking ()
• QR scan ()

Login UI <<UI Class>>

• Username • Admin<<Actor Class>>

• Password • User<<Actor Class>>
• get user () • Ticket Officer<<Actor Class>>

User UI <<UI Class>>

• Register () • User<<Actor Class>>

• Login ()
• Select Routes ()
• Select Seat ()
• Search Journey ()
• Pay ()

Table 5:CRC for UI Classes

C. Business Classes CRC

Booking<<Business Class>>

24
• Book_id • User<<Actor Class>>
• Date • Journey<<Business Class>>
• User Details • Route<<Business Class>>
• Trip Summary

Route <<Business Class>>

• Starting Point • Admin<<Actor Class>>

• Destination Point • User<<Actor Class>>

Reservation System <<Business Class>>

• Payment Option • User<<Actor Class>>

• Seat Allocation ()
• Confirm Payment ()
• Generate QR code ()

Payment <<Business Class>>

• Payment Option • User<<Actor Class>>

• Confirm Payment () • Admin<<Actor Class>>
• Generate QR code () • Ticket Officer<<Actor Class>>
• Refund ()

25
 Journey <<Business Class>>

• Journey_id • User<<Actor Class>>

• Date • Admin<<Actor Class>>
• Route_id
• Class_type
• Fares

Table 6:CRC for Business/Domain Classes

2.5. Supplementary Specifications

2.5.1. Business Rules

Business rules are the policies and procedures that govern the operation of the system [12].
Identifying the business rule of the proposed system help to ensure that the system is used in a
consistent and effective manner and also to specify and describe each use case in an effective way.

BR 01: User Registration and Authentication

• Users must register with valid and verifiable personal information to create an account.
• Authentication is mandatory for accessing any booking-related functionalities.
• Users are allowed a single account, and account sharing is strictly prohibited.

BR 02: Ticket Booking

• Each user can select an option for a one-way trip round trip.
• Each User can select the class type whether it is hard seat, hard sleeper or soft sleeper.
• Rule: Ticket bookings must be made at least 24 hours before the departure time.

BR 03: Payment

• Payment must be made at the time of booking using approved and secure payment methods.

BR 04: Train Schedule

26
 • The system must display accurate and up-to-date train schedules, including arrival and
departure times.
• Rule: Train schedules may be subject to change, and users must be notified in advance.

BR 05: Seat Selection

• Users can select their preferred seats before payment; Hence the seat will be approved as
taken if only user has paid for the booking, subject to availability.

BR 07: Refund Process

• Users can cancel their journey and request refunds.

• On refund the system uses the policy used by the Railway corporation in which it deducts
19.84 % of Total Payment from the paid fares and return the remaining amount.

BR 06: System Notifications

• Users should receive email and/or SMS notifications for successful bookings, changes in
schedule, and other relevant updates.

2.5.2. Non-Functional requirements

Non-Functional Requirement is a specification that describes the system’s operation capabilities

and constraints that enhance its functionality, and these constraints may be speed, security,
reliability, usability, efficiency Maintainability and so on [13].

➢ Reliability: The system should be reliable and matured enough in giving its service.
➢ Workability: The system should be suitable for all the users. It should be accurate in
performing its functions and secured enough from attacks by external users. It should be
fully functional in terms of providing all the functions expected it to perform.
➢ Efficiency: The system should be efficient and the response time should be minimal. It
should be capable of running on minimum hardware requirements.
➢ Usability: The system should be understandable by all users. The Interface should be easy
to use and it should have a customary look and feel so that users can easily be familiar with
the system.

27
 ➢ Maintainability: The system should be easily maintainable in case of problem and gives
consistent services all times without fluctuation since there is internet connection and
should be testable.
➢ Availability: The system is available for the users whenever there is an internet connection.
➢ Security: The system should be securing from external attackers and internet issue. It
should have user’s database and should authenticate each user on login and should grant
user specific services.

2.6. Use Case Modeling

2.6.1. Essential Use Case

An Essential use case is a structured narrative, expressed in language of the application domain
and of users, comprising a simplified, generalized, abstract technology-free and implementation
independent description of one task or interaction that is complete, meaningful and well-defined
from the point of view of users in some role in relation to a system and that embodies the purpose
or intentions underlying the interaction [14].

Figure 3:Essential Use Case

28
 2.6.2. Essential Use Case Description

Table 7:Essential Use Case Description

SN Use Case Description

1 Provides ID Passenger to buy ticket have to authenticate
him/her self-using his/her Personal ID which
consists of personal details.
2 Buy Ticket After authenticating oneself passenger can buy
ticket by paying the issued amount of money
3 Enter/Start Journey using Ticket On date of Journey passenger holds on to the
bought paper ticket and enter the train passing
certain security measures and start his/her
journey
4 View Passenger ID Ticket Officer Verify the passenger using his/her
ID
5 Issues Ticket After verification Ticket Officer prints and gives
the ticket to the passenger
6 Manage Train Schedule The Manager adds schedules and make them
available and might cancel them if there is
certain maintenance error on the available trains
available.
7 Inform Train Schedules to Ticket The station Managers inform ticket officers
Officers about available schedules so that the ticket
officers can notify the passengers on available
Schedules.

2.6.3. System Use Case

A system use case describes the interaction between the user and system in a more detailed way
than essential use case. It is a type of UML (Unified Modeling Language) diagram that visually
represents the interactions between external actors (such as users or other systems) and a system

29
[15]. It is a high-level diagram used to capture the primary functionalities or use cases of a system
and the actors involved in those interactions.

Figure 4:System Use Case

30
 2.6.4. System Use Case Description

Table 8:Register Use Case Description

Use Case Name Register

Use Case ID UC 01

Description This use case enables users to initiate their interaction with the system by
inputting specific personal details., during the initial installation of the
application.

Actors Passengers

Pre-Condition The passenger must have volunteer to use this system

Basic Flow 1. User: Installs and opens the application

2. User: Clicks Register Option
3. System: Displays Registration Form
4. User: Enters required information
5. User: Submits the registration
6. System: Validates Information entered by the user and sends
success message.
7. End Use Case

Post Condition Passenger will be registered as a user of the system and will have an
account to which he/she can login whenever needed, and Information
entered will be stored in the database and QR codes on later processes.

Exceptional Flow o E6. System: Validates input encounter error and asks user to re-try
o E7. User: Corrects the error and re-submit
o E8. System: Validates input and send success message
o E9. End Use Case

Include None

31
 Extends None

Table 9:Login Use Case Description

Use Case Name Login

Use Case ID UC 02

Description This use case allows mentioned actors to verify their identity, gain access
to the system upon successful validation, and utilize the services offered
by the system.

Actors Passengers, Admin, and Ticket Officers

Pre-Condition User must have an account, valid username and password, and must be
aware about the information required.

Basic Flow 1. User: Clicks Login Option

2. System: Displays Login Form
3. User: Enters required information
4. User: Submits the information entered
5. System: Validates input by the user and display corresponding user
screen.
6. End Use Case

Post Condition User will be allowed to navigate through various screens consisting
several services under them.

Exceptional Flow o E6. System: Validates input encounter error and asks user to re-try
o E7. User: Corrects the error and re-submit
o E8. System: Validates input and display corresponding user screen.
o E9. End Use Case

Include Register Use Case

32
 Extends None

Table 10:Book Use Case Description

Use Case Name Book Ticket

Use Case ID UC 03

Description This use case allows passengers to book their ticket before payment by
filling up their desired selections.

Actors Passengers

Pre-Condition User must have an account and logged in.

Basic Flow 1. User: Opens the application

2. User: Select Start and Destination Point and Clicks Search Journey
3. System: Displays Options for way round trip, date selection, class
type selection.
4. User: Submit selected features
5. System: Fetches available journeys and display with fares attached
to each of the journeys
6. User: Selects Journey
7. System: Display Trip Summary
8. User: Confirm Booking
9. System: Sends Ticket number to the passenger
10. End Use Case

Post Condition User will receive ticket number as a confirmation to booked ticket and will
be allowed to pass to payment process

Exceptional Flow o E2. User: Enters the same start and destination point
o E3. System: Asks user to enter different start and destination point
o E4. User: Input incorrect selection

33
 o E5. System: Asks user to re-enter selections then fetch and display
available journeys
o E7. User wants to change his/her idea of selection from displayed
trip summary
o E8. User navigate back and modify selections before confirming
the booking
o E9. End Use Case

Include Login Use Case

Extends None

Table 11:Pay Use Case Description

Use Case Name Purchase Ticket

Use Case ID UC 04

Description This use case allows passengers to pay the fare amount attached on their
selected journey through payment options available

Actors Passengers

Pre-Condition User must have an account, logged in and have confirmed their bookings
and received ticket numbers.

Basic Flow 1. User: Selects Continue to payment option

2. System: Fetches available payment options
3. User: Select desired payment option
4. User: Uses ticket number as conformation to booked ticket
5. System: Conform Payment
6. System: Stores Passenger’s details from registration form and Trip
Summary and stores them in QR code

34
 7. System: Provide passengers a unique QR codes
8. End Use Case

Post Condition User will receive QR code and later uses them for check-in process on
journey date

Exceptional Flow -

Include Login Use Case

Extends None

Table 12:Scan QR Codes Use Case Description

Use Case Name Scan QR codes

Use Case ID UC 05

Description This use case allows ticket officers to verify the QR codes generated by
the system and authorize the passengers to start their journey

Actors Ticket Officers

Pre-Condition The system must have generated QR codes as a conformation to payment

process

Basic Flow 1. Ticket Officer: Uses QR code scanner

2. Scanner: Fetches payment Conformations and trip summary of
passenger
3. Ticket Officer: Allows passengers through check-in
4. End Use Case

Post Condition User will get verified to attend the journey

Exceptional Flow -

35
 Include None

Extends None

Table 13:Manage Paid Ticket Use Case Description

Table 14:Manage Refund Requests Use Case Description

Use Case Name Manage Refund Requests

Use Case ID UC 07

Description This use case allows Admin to approve the refund requests from
passengers

Actors Admin

Pre-Condition The Passenger first must have already requested refund

Basic Flow 1. Admin: Selects the Manage Refund Requests Option

2. System: Fetch and displays available requests
3. Admin: Conforms reverse payment to the passengers
4. End Use Case

Post Condition Passenger will be refunded after journey cancellation

Exceptional Flow -

Include Login Use Case

Extends None

36
Table 15:Logout Use Case Description

Use Case Name Logout

Use Case ID UC 08

Description This use case allows mentioned actors to exit out of their main page

Actors Passengers, Ticket Officer, Admin

Pre-Condition User must have logged in first

Basic Flow 1. User: Selects Logout Option

2. System: Sends request ‘Are you sure you want to logout’
3. User: Accepts Logging Out
4. System: Display Initial Page
5. End Use Case

Post Condition User exit their Home page

Exceptional Flow -

Include None

Extends Login

37
 2.7. User Interface Prototyping

Figure 5:UI Prototyping

38
CHAPTER THREE

3. SYSTEM DESIGN

Design is:

➢ The intermediate language between requirements and code

➢ The first step in moving from problem domain to solution domain.
➢ Proceeding from abstract to more complex representations
➢ Determines the major characteristics of a system.

Design of the system is simply a blueprint for a solution of the system [16].

3.1. Class Modeling

3.1.1. Classes-type Layered Architecture

Is a common architectural strategy to layer the architecture of the system in to several layers/strata
of class types [17].

Below the class-type layered architecture of the proposed system is depicted as follows:

39
User Interface Layer
• Admin Home Page
• Login/Register Form
• Ticket Officer Home Page
• Passenger Home Page
• Booking UI
• Payment UI

Ethiopian Railway Ticket Booking System

Control/Process Layer
• Register
• Login
• Book
• Payment
• Refund
• QR Generation

Business or Domain Layer

• Booked Ticket
• QR Codes

Persistence Layer
• Accounts
• Passenger Details
• Book History
• Journey Details
• Seats
•

Ethiopian Railway Ticket

Figure 6:Class-Type Layered Architecture
Booking System Database

40
 3.1.2. Class Model

A class diagram is a type of diagram used in system analysis and design to visually represent the
structure and relationships of classes within a system. It captures the static structure of Object-
Oriented systems, or how they are structured rather than how they behave [18].

In a class diagram, a class is represented as a rectangular box with three compartments:

• Class Name: This is the name of the class and is usually written in bold at the top of the
box.
• Attributes: This compartment lists the attributes or properties of the class. Attributes are
the data members that describe the characteristics of the class.
• Methods/Operations: This compartment contains the methods or operations that the class
can perform. Methods represent the behavior or actions associated with the class.

Lines and arrows are used to represent relationships between classes. The relationships can include
associations, generalizations, aggregations, and compositions. Here are some common elements
you might find in a class diagram:

• Association: Represents a relationship between two classes. It is typically drawn as a line

connecting the classes with an optional arrow indicating the direction of the relationship.
• Generalization/Inheritance: Represents an "is-a" relationship between classes. It is depicted
as a line with a triangular arrowhead pointing to the superclass.
• Aggregation: Represents a "has-a" relationship between classes, where one class contains
another class. It is shown as a diamond shape on the container class end of the relationship
line.
• Composition: Similar to aggregation, but it implies a stronger relationship where the
contained class is part of the container class. It is also shown as a diamond shape on the
container class end, but with a filled diamond.

41
Figure 7:Class Diagram

3.2. User Interface Design

Figure 8:Intro UI Figure 9:Login or Register UI

42
 Figure 10:Login UI Figure 11:Register UI

Figure 12:Home Screen UI Figure 13: Book UI

43
 3.3. Sequence Diagram

A sequence diagram is a type of interaction diagram in the field of system analysis and design,
which is a phase in the software development life cycle. Sequence diagrams are used to visualize
and document the flow of interactions or messages between different components or objects within
a system over time [15]. They are particularly useful in illustrating the dynamic aspects of a system,
showing how various components collaborate to achieve a specific functionality or behavior.

Figure 14:Sequence Diagram for Register Use case

44
Figure 15:Sequence Diagram for Login Use case

45
Figure 16:Sequence Diagram for Book Use case

3.4. Activity Diagram

An activity diagram is another type of diagram used in system analysis and design to model the
dynamic aspects of a system. It is a graphical representation of workflows or processes within a
system, showing the sequence of activities and actions that take place [19].

46
A given Activity diagram Consists:

• Activities: Represent tasks or actions that are performed within the system. Activities are
usually depicted as rectangles and can represent operations, calculations, or other
behaviors.
• Transitions (Arrows): Represent the flow of control from one activity to another. These
arrows show the sequence in which activities are performed. The transition may be
triggered by a decision, completion of an activity, or other events.
• Control Nodes: Include decision nodes, merge nodes, and fork/join nodes, which control
the flow of activities in the diagram. Decision nodes are diamond-shaped and represent
points where the flow can take different paths based on conditions.
• Initial and Final Nodes: The initial node indicates where the activity starts, and the final
node indicates where it ends.

Figure 17:Activity Diagram for Register Use Case

47
Figure 18:Activity Diagram for Login Use Case

Figure 19:Activity Diagram for Book Use Case

48
Figure 20:Activity Diagram for Pay Use Case

3.5. State Chart Diagram

A State Chart diagram, is a type of diagram used in system analysis and design to model the
dynamic behavior of a system in response to external stimuli. This diagram is part of the Unified
Modeling Language (UML) and is particularly useful for representing the various states that an
object or system can be in and how it transitions between these states based on events or conditions
[20].

A given State Chart diagram consists:

• States: Represent different conditions or situations that an object or system can be in. States
are typically depicted as rectangles with labels.
• Transitions: Represent the flow of control between states and are triggered by events or
conditions. Transitions are depicted as arrows and often include labels indicating the event
that causes the transition.

49
 • Initial and Final States: The initial state represents the starting point of the system, and
the final state represents the end or termination point.
• Actions: Represent activities or operations that occur when a state is entered or exited.
These actions are associated with states or transitions.

Figure 21:State Chart Diagram for Register Use Case

50
Figure 22:State Chart Diagram for Login Use Case

Figure 23:State Chart Diagram for Book Use Case

51
Figure 24:State Chart Diagram for Pay Use Case

3.6. ERD and Normalization

3.6.1. Entity Relationships Modeling (ERM)

A visual representation of various data utilizing conventions that explain how these data are
related to one another is known as an entity relationship diagram (ERD) [21]. Many different
elements make up an entity relationship diagram:
1. Entity: An entity is a thing about which data may be kept. It could be a tangible thing, a
thought, or an occasion. In our case: Passenger, Ticket Officer, Admin, Ticket, Book, Seat, Route,
Journey, Payment.
2. Relationship: In an ERD, a relationship describes the connections between two things. When
referring to a database or a collection of entities.
3. Attribute: An attribute is a quality that can be utilized to identify or describe an entity. They
are frequently depicted as entries inside an entity or as ovals. Our project uses attributes like age
and sex.

52
Figure 25:ERD

3.6.2. Normalization

Normalization is a database design technique that reduces data redundancy and eliminates
undesirable characteristics like Insertion, Update and Deletion Anomalies [22]. Normalization
rules divides larger tables into smaller tables and links them using relationships.

1NF (First Normal Form)

• a single cell must not hold more than one value (atomicity)

• there must be a primary key for identification

• no duplicated rows or columns

• each column must have only one value for each row in the table

So, here below it is tables of Entities are depicted with their respective primary keys as follow:

53
ADMIN

Table 16:Admin 1NF

AdminId AdminUserName AdminEmail

PASSENGER

Table 17:Passenger 1NF

PassengerI PassengerEmai FirstNam MiddleNam LastNam Dob Sex PhoneN

d l e e e o

TICKET OFFICER

Table 18:Ticket Officer 1NF

TicketOfficerId FirstName LastName OfficerUsername OfficerEmail Station

TICKET

Table 19:Ticket 1NF

TicketNumber BookingId PassengerId RouteId JourneyId BookingDate

BOOK

Table 20:Booking 1NF

BookingID PassengerId BookingDate RouteId JourneyId ClassType

54
ROUTE

Table 21:Route 1NF

RouteId Start Destination

JOURNEY

Table 22:Journey 1NF

JourneyId RouteId StartTime ArrivalTime ClassType Fare

PAYMENT

Table 23:Payment 1NF

PaymentId TicketNumber Fare PaymentDate PaymentOption

SEAT

SeatId SeatNumber SeatMap

2NF (Second Normal Form)

A table is said to be in 2NF if it meets the following criteria:

• It’s already in 1NF

• Has no partial dependency. That is, all non-key attributes are fully dependent on a primary
key.

So, here Table: ‘Ticket’ is not in 2NF for the following reasons:

1. In ‘Ticket’ table there exists a partial dependence between ‘BookingDate’ and the primary
key ‘TicketNumber’

So, by creating two separate tables we try to normalize the table as follows:

55
TICKET

Table 24:Ticket 2NF

TicketNumber PassengerId RouteId JourneyId

BOOK

Table 25:Booking 2NF

BookingId BookingDate

Again, here Table: ‘Book is not in 2NF for the following reasons:

1. In ‘Book’ table there exists a partial dependence between ‘ClassType’ and the primary key
‘BookingId’’

So, by creating two separate tables we try to normalize the table as follows:

BOOK

Table 26:Booking 2NF

BookingId BookingDate PassengerId RouteId

JOURNEY

Table 27:Journey 2NF

JourneyId ClassType

3NF (Third Normal Form)

No transitive dependencies.

56
Now, the tables are in 3NF. Each table represents a distinct entity, and relationships are established
using foreign keys.

3.7. Relational Persistent Modeling

A persistent database model stores persistent data in the form of objects, or records that are durable
when changing devices and software. The most popular example of a database model is the
relational model, which uses a table-based format. It doesn’t use objects and their relationships
[15].

Table 28:Relational Persistent Modeling

SN Table Name Attribute Data Type Primary Key Foreign Key

1 ADMIN AdminId INT AdminId
AdminEmail VARCHAR
AdminUserName VARCHAR
2 PASSENGER PassengerId INT PassengerId
PassengerEmail VARCHAR
FirstName STRING
MiddleName STRING
LastName STRING
Dob INT
Sex STRING
PhoneNo INT

57
3 TICKET TicketOfficerId INT TicketOfficerId
OFFICER OfficerEmail VARCHAR
FirstName STRING
LastName STRING
OfficerUsername VARCHAR
Station STRING

4 TICKET TicketNumber INT TicketNumber BookingId

BookingId INT PassengerId
PassengerId INT BookingId
RouteId INT RouteId
JourneyId INT JourneyId
5 BOOK BookingId INT BookingId PassengerId
PassengerId INT RouteId
RouteId INT JourneyId
JourneyId INT
BookingDate INT
6 PAYMENT PaymentId INT PaymentId TicketNumber
TicketNumber INT
PaymentDate INT
PaymentOption STRING
Fare INT
7 JOURNEY JourneyId INT JourneyId RouteId
RouteId INT
StartTime INT
ArrivalTime INT
ClassType STRING
Fare INT

58
8 ROUTE RouteId INT RouteId
Start STRING
Destination STRING

9 SEAT SeatId INT SeatId

SeatNumber INT
SeatMap BLOB

59
Figure 26:Relational Persistent Model

60
 3.8. Component Diagram

A component diagram is a UML diagram that illustrates the organization and relationships among
components in a system [23].

In a component diagram, components are represented as rectangles, and the relationships between
these components are depicted using lines and connectors. Components in this context refer to
modular units or building blocks of a system, which can be software modules, classes, packages,
or even hardware components.

Figure 27:Component Diagram

61
 3.9. Deployment Diagram

Deployment diagrams are used to visualize the topology of the physical components of a system,
where the software components are deployed [24].

Deployment diagrams are used to describe the static deployment view of a system. Deployment
diagrams consist of nodes and their relationships.

Figure 28:Deployment Diagram

62
CHAPTER FOUR

4. IMPLEMENTATION

4.1. Overview

The project implementation overview provides a comprehensive roadmap outlining the essential
steps, tasks, and considerations necessary for executing the Ethiopian Railway Ticket Booking
System. This document serves as a guiding framework for the project team, stakeholders, and any
individuals involved in the implementation phase. It emphasizes the key phases, milestones, and
resources required to successfully carry out the project.

The main aim of project implementation is to translate the project plan into actionable steps,
ensuring the completion of all tasks efficiently and effectively to meet the project goals and
deliverables. The implementation process entails coordinating and executing various activities,
managing resources, and monitoring progress to ensure a successful outcome.

Implementation Phases

1. Project Initiation
➢ Formulate the project team and allocate roles and responsibilities.
➢ Facilitate a kickoff meeting to align stakeholders and communicate project objectives.
➢ Develop a detailed implementation plan, encompassing timelines, milestones, and
deliverables.
➢ Identify and secure necessary resources, including funding, equipment, and personnel.
2. Execution
➢ Commence implementation according to the established plan and timeline.
➢ Coordinate tasks and activities among team members to ensure smooth progress.
➢ Maintain regular communication with stakeholders to provide updates and address concerns.
➢ Monitor project metrics and key performance indicators (KPIs) to gauge progress.
➢ Conduct routine meetings and reviews to evaluate project status and make necessary
adjustments.

63
3. Resource Management
➢ Effectively manage project resources, such as personnel, budget, and equipment.
➢ Allocate tasks and responsibilities to team members based on their expertise and
availability.
➢ Monitor resource allocation to ensure optimal utilization and mitigate bottlenecks.
➢ Address any resource constraints or issues arising during implementation promptly.
4. Risk Management
➢ Identify potential risks and devise strategies to mitigate them.
➢ Regularly assess risks and implement appropriate risk management measures.
➢ Establish contingency plans to address unforeseen events or challenges.
➢ Continuously monitor and evaluate risks throughout the implementation phase.
5. Quality Assurance
➢ Establish quality standards and benchmarks for project deliverables.
➢ Conduct regular quality checks to ensure compliance with established standards.
➢ Promptly address any quality issues and undertake corrective actions as necessary.
➢ Engage relevant stakeholders in quality assurance processes to ensure satisfaction.
6. Documentation and Reporting
➢ Maintain accurate and updated project documentation, including plans, reports, and
records.
➢ Generate progress reports to provide stakeholders with timely updates on project status.
➢ Document lessons learned and best practices for future reference and improvement.
➢ Prepare a final project report summarizing the implementation process and outcomes.

4.2. System Development Tools

In the System Development section, the project team opted for a hybrid approach by utilizing
Flutter for Android for the user module side, catering to passengers, and Flutter Web for the Admin
and Ticket Officer interfaces. This decision was made to utilize the flexibility and efficiency of
Flutter in developing cross-platform applications while ensuring a seamless user experience across
different devices and platforms.

For the user module side, which includes functionalities such as ticket booking, viewing schedules,
and managing personal profiles, Flutter for Android was chosen. Flutter for Android enables the

64
development of native-like mobile applications with excellent performance and rich user
interfaces. This choice ensures that passengers can easily access and interact with the system on
their Android devices, providing a smooth and intuitive experience.

On the other hand, for the Admin and Ticket Officer interfaces, Flutter Web was selected. Flutter
Web extends Flutter's capabilities to web browsers, allowing the development of responsive and
dynamic web applications. By utilizing Flutter Web, the Admin and Ticket Officer interfaces can
be accessed through web browsers on various devices, including desktops and laptops, without the
need for separate development efforts for different platforms.

Additionally, a common backend powered by Firebase using Firestore Database or Cloud Firestore
was employed to support both the user module and the Admin/Ticket Officer interfaces. Firebase
offers a comprehensive set of backend services, including real-time database and authentication,
which seamlessly integrate with Flutter applications. Firestore Database or Cloud Firestore
provides scalable and flexible NoSQL databases, enabling efficient data storage and retrieval for
the system.

By adopting Flutter for Android and Flutter Web for different user interfaces and integrating them
with Firebase's backend services, the project team ensures consistency, scalability, and
maintainability across the entire system. This approach facilitates streamlined development,
deployment, and management of the Ethiopian Railway Ticket Booking System, ultimately
enhancing the overall user experience and system performance.

4.3. Sample Code of Systems

Sample Code for Passenger Login

import 'package:erbs/Users/homePage.dart';
import 'package:erbs/Users/welcomeScreen.dart';
import 'package:firebase_auth/firebase_auth.dart';
import 'package:flutter/material.dart';

class userLogin extends StatefulWidget {

@override
_userLoginState createState() => _userLoginState();
}

class _userLoginState extends State<userLogin> {

final TextEditingController emailController = TextEditingController();
final TextEditingController passwordController = TextEditingController();

65
bool _obscurePassword = true;
final _formKey = GlobalKey<FormState>();

@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
toolbarHeight: 40,
backgroundColor: Colors.white,
leading: IconButton(
icon: const Icon(Icons.arrow_back_ios),
onPressed: () {
Navigator.of(context).pushReplacement(
MaterialPageRoute(
builder: (BuildContext context) => WelcomeScreen(),
),
);
},
),
),
body: SingleChildScrollView(
child: Form(
key: _formKey,
child: Column(
crossAxisAlignment: CrossAxisAlignment.center,
children: [
Padding(
padding: const EdgeInsets.only(top: 20.0),
child: Image.asset(
'images/train_image.png',
height: 270,
),
),
const Text(
'Login',
textAlign: TextAlign.center,
style: TextStyle(
height: -4,
fontFamily: 'DMSans',
fontSize: 24,
fontWeight: FontWeight.bold,
),
),
Padding(
padding: const EdgeInsets.all(15),
child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: [
Container(
decoration: BoxDecoration(
borderRadius: BorderRadius.circular(10),
color: Colors.grey.shade200,

66
 boxShadow: [
BoxShadow(
color: Colors.grey.withOpacity(0.5),
spreadRadius: 1,
blurRadius: 5,
offset: const Offset(0, 2),
),
],
),
child: Padding(
padding: const EdgeInsets.all(8.0),
child: Column(
crossAxisAlignment: CrossAxisAlignment.stretch,
children: [
TextFormField(
controller: emailController,
cursorColor: const Color(0xFF3F7347),
decoration: InputDecoration(
labelText: 'Email',
border: OutlineInputBorder(
borderRadius: BorderRadius.circular(10),
borderSide: const BorderSide(
color: Colors.grey,
),
),
focusedBorder: OutlineInputBorder(
borderRadius: BorderRadius.circular(10),
borderSide: const BorderSide(
color: Color(0xFF3F7347),
// Change focused color to green
),
),
labelStyle: const TextStyle(
fontFamily: 'DMSans',
fontSize: 14,
color: Colors.grey,
),
),
validator: (value) {
if (value == null || value.isEmpty) {
return 'Please enter your email';
}
// You can add more email validation logic if needed
return null;
},
),
const SizedBox(height: 20),
TextFormField(
controller: passwordController,
obscureText: _obscurePassword,
cursorColor: const Color(0xFF3F7347),
decoration: InputDecoration(

67
 labelText: 'Password',
border: OutlineInputBorder(
borderRadius: BorderRadius.circular(10),
borderSide: const BorderSide(
color: Colors.grey,
),
),
focusedBorder: OutlineInputBorder(
borderRadius: BorderRadius.circular(10),
borderSide: const BorderSide(
color: Color(0xFF3F7347),
// Change focused color to green
),
),
labelStyle: const TextStyle(
fontFamily: 'DMSans',
fontSize: 14,
color: Colors.grey,
),
suffixIcon: IconButton(
icon: Icon(
_obscurePassword
? Icons.visibility
: Icons.visibility_off,
color: Colors.grey,
),
onPressed: () {
setState(() {
_obscurePassword = !_obscurePassword;
});
},
),
),
validator: (value) {
if (value == null || value.isEmpty) {
return 'Please enter your password';
}
// You can add more password validation logic if needed
return null;
},
),
const SizedBox(height: 20),
],
),
),
),
],
),
),
const SizedBox(height: 20),
Center(
child: ElevatedButton(

68
 onPressed: () {
if (_formKey.currentState!.validate()) {
signUserIn(context);
}
},
style: ElevatedButton.styleFrom(
backgroundColor: const Color(0xFF3F7347),
foregroundColor: Colors.white,
padding: const EdgeInsets.symmetric(
horizontal: 30, vertical: 15),
minimumSize: const Size(300, 50),
),
child: const Text(
'Login',
style: TextStyle(fontFamily: 'DMSans', fontSize: 18),
),
),
),
],
),
),
),
);
}

void signUserIn(BuildContext context) async {

try {
if (emailController.text.isEmpty) {
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: Text('Please enter your email.'),
backgroundColor: Colors.red,
behavior: SnackBarBehavior.floating,
shape: RoundedRectangleBorder(
borderRadius: BorderRadius.circular(10),
),
duration: const Duration(seconds: 3),
),
);
return;
}

if (passwordController.text.isEmpty) {
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: Text('Please enter your password.'),
backgroundColor: Colors.red,
behavior: SnackBarBehavior.floating,
shape: RoundedRectangleBorder(
borderRadius: BorderRadius.circular(10),
),
duration: const Duration(seconds: 3),

69
 ),
);
return;
}

final UserCredential userCredential = await FirebaseAuth.instance

.signInWithEmailAndPassword(
email: emailController.text, password: passwordController.text);
final User? user = userCredential.user;
if (user != null) {
Navigator.of(context).pushReplacement(
MaterialPageRoute(
builder: (BuildContext context) => const HomePage(),
),
);
}
} on FirebaseAuthException catch (e) {
String errorMessage = 'Failed to sign in';
if (e.code == 'user-not-found') {
errorMessage = 'No user found with this email.';
} else if (e.code == 'wrong-password') {
errorMessage = 'Incorrect password.';
}
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: Text(errorMessage),
backgroundColor: Colors.red,
behavior: SnackBarBehavior.floating,
shape: RoundedRectangleBorder(
borderRadius: BorderRadius.circular(10),
),
duration: const Duration(seconds: 3),
),
);
} catch (e) {
print('Error signing in: $e');
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: Text('Failed to sign in: $e'),
backgroundColor: Colors.red,
behavior: SnackBarBehavior.floating,
shape: RoundedRectangleBorder(
borderRadius: BorderRadius.circular(10),
),
duration: const Duration(seconds: 3),
),
);
}
}
}

70
 4.4. Testing

4.4.1. Unit Testing

In system development, unit testing plays a crucial role by focusing on the smallest units of system
design, known as modules. These modules are tested separately to ensure they meet the expected
output criteria. For the Ethiopian Railway Ticket Booking System project, all forms are carefully
designed to function as intended. Unit testing involves examining every small modular component
of the system in isolation from others. After the implementation of each unit or function, rigorous
testing is conducted to promptly identify and rectify errors. This process ensures the robustness of
the system. Key steps in unit testing include reviewing program units, executing code tests,
resolving discrepancies, and documenting results.

Here are some specific aspects of unit testing in the project:

Data Entry Modules

➢ Each data entry module, such as product and supplier entry, undergoes thorough validation
checks both pre- and post-runtime to detect any errors or warnings.
➢ Test classes are created for each module to facilitate comprehensive testing.

View Modules

➢ View modules are examined to ensure seamless viewing of updated information.

➢ Correspondence between newly added data and view grids is verified through code and at
runtime.

Report Modules

➢ Report modules are examined for proper reporting and printability.

Each report module is examined before and after runtime to ensure smooth and effective report
generation. In general, unit testing ensures the reliability and functionality of each component of
the system, contributing to the overall quality of the Ethiopian Railway Ticket Booking System.

71
 4.4.2. System Testing

System testing is a crucial phase in the software development life cycle where the entire integrated
system is evaluated to ensure that it meets specified requirements. It involves testing the system
as a whole, focusing on both functional and non-functional aspects to verify its behavior and
performance. This process aims to uncover defects or bugs that may exist in the system before it
is deployed to production environments.

In the context of the Ethiopian Railway booking system, which is based on QR generation
technology, system testing involves comprehensive testing of all system components and features
related to booking train tickets using QR codes. This includes testing the functionality of
generating QR codes for tickets, scanning QR codes, handling various scenarios such as ticket
cancellations or modifications, and ensuring the system's reliability, security, and performance
under different load conditions.

During system testing, testers validate that the Ethiopian Railway booking system accurately
generates QR codes containing relevant ticket information, such as passenger details, journey
details, and seat assignments. They also verify that the QR codes can be successfully scanned and
authenticated by ticket officers or automated gate systems at railway stations.

Additionally, system testing for the Ethiopian Railway booking system would involve evaluating
its compatibility with different devices and platforms, including mobile devices used by passengers
for ticket booking and ticket officers for QR code scanning. It would also encompass testing the
system's integration with other components such as payment gateways, passenger databases, and
train scheduling systems to ensure seamless operation and data synchronization.

4.4.3. Acceptance Testing

Acceptance testing is the final phase of the software testing process, where the system is evaluated
to determine whether it meets the acceptance criteria set by stakeholders. It primarily focuses on
validating whether the system satisfies the business requirements and objectives and is ready for
deployment. Acceptance testing involves testing the system's functionality, usability, reliability,
and performance from the perspective of end-users or customers to ensure that it meets their
expectations and needs.

72
In the context of the Ethiopian Railway booking system, acceptance testing involves testing the
system to ensure that it meets the requirements and expectations of the railway authorities,
ticketing agents, and passengers. This would include verifying that the system accurately generates
QR codes for train tickets, allows seamless booking and payment processes, and provides a user-
friendly interface for both booking tickets and scanning QR codes at railway stations.

During acceptance testing, stakeholders evaluate the system's compliance with specific criteria,
such as the governance to security standards for handling passenger data, and compatibility with
existing railway infrastructure and ticketing processes. They would also assess the system's
reliability in generating and validating QR codes under various network conditions and in different
environments.

Acceptance testing plays a critical role in gaining confidence in the Ethiopian Railway booking
system's readiness for deployment and ensuring that it meets the needs and expectations of all
stakeholders involved, including railway authorities, ticketing agents, and passengers. By
thoroughly evaluating the system against predefined acceptance criteria, stakeholders can make
informed decisions about its suitability for production use and identify any necessary
improvements or modifications before its launch.

4.4.4. Performance Testing

Performance testing is a crucial aspect of software testing that focuses on assessing the speed,
responsiveness, scalability, and stability of a system under various conditions. It involves
evaluating how efficiently the system performs under different workloads and stress levels to
ensure optimal performance and user experience. Performance testing helps identify potential
bottlenecks, issues, or weaknesses in the system's architecture, infrastructure, or code that could
impact its responsiveness or reliability in production environments.

In the context of the Ethiopian Railway booking system, which relies on QR code generation
technology, performance testing is essential to ensure that the system can handle the expected
volume of ticket bookings and QR code validations efficiently, especially during peak periods of
ticket sales or train departures. This involve assessing the system's ability to generate QR codes
quickly and accurately, process ticket bookings and payments promptly, and validate QR codes or
inspection points without delays or errors.

73
During performance testing, various scenarios would be simulated to evaluate the system's
performance under different levels of concurrent user activity, network traffic, and data load.
Testers would measure key performance metrics such as response times, throughput, resource
utilization, and error rates to identify any performance bottlenecks or areas for optimization. They
would also assess the system's scalability by gradually increasing the workload to determine its
capacity limits and ensure that it can accommodate future growth in user traffic and transaction
volumes.

4.5. Clients Feedback

We have received valuable feedback from stakeholders regarding the Ethiopian Railway booking
system, which is based on QR generation technology.

User-Friendly Interface: Stakeholders have expressed satisfaction with the user-friendly

interface of the Ethiopian Railway booking system. They appreciated its intuitive design, clear
navigation, and overall ease of use. The system's interface was found to be simple and well-
organized, allowing passengers to navigate through the booking process without any confusion.

Seamless Booking Experience: Clients praised the smooth and seamless booking experience
provided by the web-based system. They highlighted the stability and reliability of the platform,
which ensured uninterrupted booking sessions and minimized technical disruptions. Passengers
reported no major issues during the booking process, resulting in a stress-free and efficient
experience.

Accessibility and Convenience: The clients appreciated the online nature of the booking system,
which provided convenience and accessibility to passengers. They noted that passengers could
book tickets from any location with an internet connection, eliminating the need for physical
ticketing counters. This flexibility allowed passengers to book tickets at their convenience and
reduced logistical challenges.

Security and Integrity: Stakeholders were impressed by the robust security measures
implemented in the booking system. They acknowledged the use of advanced authentication
techniques, secure data encryption, and safeguards against fraudulent activities. These security
measures instilled confidence in the integrity and fairness of the booking process.

74
Efficient Ticketing and Confirmation: Feedback highlighted the efficient ticketing and
confirmation process of the online system. Clients expressed satisfaction with the timely issuance
of tickets and confirmation emails, enabling smooth travel planning for passengers. The automated
ticketing system provided accurate and prompt confirmation, enhancing overall efficiency.

Comprehensive Reporting and Analytics: Clients praised the system's reporting and analytics
capabilities, which provided detailed insights into booking statistics and passenger preferences.
They found the reports to be comprehensive and useful in identifying trends, optimizing resource
allocation, and making data-driven decisions for future service enhancements.

In General, the stakeholders' feedback indicates a positive response to the Ethiopian Railway
booking system. The system's user-friendly interface, seamless booking experience, accessibility,
security measures, efficient ticketing, comprehensive reporting, and analytics capabilities were the
key factors contributing to stakeholder satisfaction. The online system has successfully
streamlined the ticket booking process, benefiting both passengers and railway authorities.

4.6. User Manuals

4.6.1. Admin Manual

Login

Figure 29: Admin Login

75
Admin Dashboard Overview

➢ Admin can perceive analytics overview corresponding to the system from its panel

Figure 30: Admin Analytics Overview

Admin Logout

➢ Admin can logout of its panel by hitting the logout icon on the top right corner of the top
bar

Figure 31: Admin Logout

76
 4.6.2. Passenger Manual

Login

If user
already have Otherwise
account

Figure 34: Welcome Screen Figure 33: User Login Screen Figure 32: User Register Screen

User’s Home Page

➢ User after logging in or registering to the app he/she can use the services that are offered
by the application by navigating through different pages starting from its Home Page

Figure 36: User Home Page Figure 35: User Booking Page

77
 4.7. Conclusion and Recommendation

Conclusion

The development of the Ethiopian Railway Ticket Booking System incorporating QR code
generation marks a significant stride towards modernizing the nation's transportation
infrastructure. Through careful planning, robust technological implementation, and user-centric
design, this project has successfully addressed critical challenges faced by passengers and the
railway authorities alike. The integration of QR code technology not only streamlines the ticket
booking process but also enhances security and efficiency within the railway system.

The adoption of such innovative solutions aligns with Ethiopia's broader vision of utilizing
technology to drive socioeconomic progress. By embracing digital transformation in the
transportation sector, the country can unlock a numerous benefit, including improved passenger
experience, optimized operations, and enhanced revenue generation. Furthermore, the
implementation of the Ethiopian Railway Ticket Booking System sets a precedent for future
undertakings aimed at modernizing other aspects of public infrastructure.

Recommendations

Moving forward, several recommendations can further enhance the effectiveness and sustainability
of the Ethiopian Railway Ticket Booking System:

Continuous Improvement: As a developer it is recommended that the project team takes place
on an ongoing refinement and enhancement of the ticket booking system based on user feedback
and emerging technological advancements. Regular updates and maintenance are essential to
ensure optimal performance and address evolving customer needs.

Accessibility and Inclusivity: Efforts should be made to ensure that the booking system is
accessible to all segments of society, including individuals with disabilities and those in remote
areas with limited internet connectivity. User interfaces should be intuitive and user-friendly,
accommodating diverse user demographics.

Partnership and Collaboration: Collaboration with relevant stakeholders, including government

agencies, railway authorities, and technology providers, can facilitate the seamless integration of

78
the ticket booking system into the existing infrastructure. Partnerships can also foster knowledge
exchange and resource sharing to drive continuous innovation.

Security and Data Privacy: Robust security measures must be implemented to safeguard
passenger data and prevent unauthorized access or fraudulent activities. Compliance with
international standards and regulations concerning data privacy and cybersecurity should be
prioritized to build trust and confidence among users.

Promotional Campaigns: To encourage widespread adoption of the ticket booking system,

targeted promotional campaigns should be launched to raise awareness among potential users.
Marketing efforts can highlight the benefits of using QR code technology for ticketing, such as
convenience, speed, and reliability.

By incorporating these recommendations into the ongoing development and implementation

process, the Ethiopian Railway Ticket Booking System can serve as a model for utilizing
technology to modernize public transportation infrastructure and enhance the overall passenger
experience.

Additional Recommendations for those who can use this document as another continual project
initiation, it is recommended that next gen developers should add more feasible functionalities
which can make the system more seamless in experience such as:

Consider taking varying number of passenger which enables for one user to purchase multiple
tickets for others by only adding passenger details of his/her fellows.

Localization using different languages implementation to the application which can help
passengers utilize the app to its fullest extent with better understanding.

79
References

[1] A. Desk, 28 MARCH 2023. [Online]. Available: https://www.news18.com/auto/evolution-

of-train-ticketing-from-manual-printing-to-online-booking-7407511.html. [Accessed Dec
2023].

[2] M. Gebrehiwot, 13 December 2016. [Online]. Available:

https://www.ethiosports.com/2016/12/13/addis-ababa-light-rail-transit-to-introduce-e-
ticketing-system/.

[3] G.-A. Hanin, 04 02 2015. [Online]. Available: https://mobilosoft.com/en/blog/e-tickets-vs-

m-tickets-difference-and-benefits-for-consumers/.

[4] F. A. Rasch, Methodologies in Project Management, Author(s), 2019.

[5] N. (Official), 2 April 2021. [Online]. Available: https://notepub.io/notes/software-

engineering/software-development-life-cycle/sdlc-iterative-waterfall-model/.

[6] M. L.Napoli, Beginning Flutter A Hands On Guide To App Development, Canada: John
Wiley & Sons, Inc..

[7] "Firebase," [Online]. Available: https://docs.flutter.dev/data-and-backend/firebase.

[8] K. L. Busbee, "Integrated Development Environment," [Online]. Available:

https://press.rebus.community/programmingfundamentals/chapter/integrated-development-
environment/.

[9] G. Wright, July 2020. [Online]. Available:

https://www.extension.iastate.edu/agdm/wholefarm/html/c5-65.html.

[10 C. MacNeil, "How to create (and stick with) a project budget," 20th November 2022.
] [Online]. Available: https://asana.com/resources/project-budget.

[11 "Class Responsibility Collaborator (CRC) Cards: An Agile Introduction," [Online].

] Available: https://agilemodeling.com/artifacts/crcmodel.htm.

[12 "Monday Blog," 26 May 2021 . [Online]. Available: https://monday.com/blog/project-

] management/business-rules/.

[13 L. Chung, Non-Functional Requirements.

]

80
[14 J. N. E. T. Robert Biddle, Wellington, New Zealand: Author(s).
]

[15 Y. G., System Analysis and Design, Haramaya,Ethiopia.

]

[16 C. L. Schweiger, System Design Overview, Author(s).

]

[17 S. W.Ambler, The Object Primer, Randy Miler.

]

[18 M. Felici, Class Diagrams.

]

[19 "MindManager," [Online]. Available: https://www.mindmanager.com/en/features/activity-

] diagram/#:~:text=Activity%20diagrams%20show%20the%20flow,and%20to%20model%2
0sales%20processes..

[20 "UML - Statechart Diagrams," [Online]. Available:

] https://www.tutorialspoint.com/uml/uml_statechart_diagram.htm.

[21 R. Peterson, "Entity Relationship (ER) Diagram Model with DBMS Example," 9 December
] 2023. [Online]. Available: https://www.guru99.com/er-diagram-tutorial-dbms.html.

[22 "Database Normalization – Normal Forms 1nf 2nf 3nf Table Examples," 21 DECEMBER
] 2022. [Online]. Available: https://www.freecodecamp.org/news/database-normalization-
1nf-2nf-3nf-table-examples/.

[23 "Open Risk Manual," [Online]. Available:

] https://www.openriskmanual.org/wiki/Component_Diagram.

[24 "Deployment Diagram," [Online]. Available:

] https://www.openriskmanual.org/wiki/Deployment_Diagram.

[25 C. MacNei, "Asana," 20 November 2022. [Online]. Available:

] https://asana.com/resources/project-budget. [Accessed 03 December 2023].

[26 "React JS Introduction," [Online]. Available: https://www.geeksforgeeks.org/reactjs-

] introduction/.

[27 A. Jalli, 21 Dec 2022. [Online]. Available: https://builtin.com/software-engineering-

] perspectives/laravel.

81
 Appendix I

Interview Questions

User Needs and Pain Points

✓ Can you describe your typical experience when booking a railway ticket in Ethiopia?
✓ What are the main challenges or pain points you encounter during the current ticket
booking process?
✓ Are there specific features or functionalities you wish existed in a railway ticket booking
system?

User Preferences

✓ How important will it be in ease of use and a friendly user interface to you when using a
ticket booking system?
✓ Are there any specific features from other ticket booking systems that you find particularly
useful?

Payment Preferences

✓ What payment methods do you prefer when booking railway tickets?

✓ Are there any concerns or preferences related to online payment security that we should
address?

Notification

✓ How do you prefer to receive notifications and updates about your booked tickets? (Email,
SMS, app notifications, etc.)
✓ What type of information would you like to receive before, during, and after your journey?

Mobile Usage

✓ Do you often use mobile devices for tasks like ticket booking? If so, what features would
you expect from a mobile app for this purpose?

82
Security Concerns

✓ What security measures would make you feel more confident in using an online ticket
booking system?
✓ Are there specific concerns related to the security of your personal information or payment
details?

Seat Availability

✓ Was there a condition in which you can select seats in the current system?

83
 Appendix II

Low-Fidelity Paper Traces of Models

84