CS6003ES Advanced Software Engineering: London Metropolitan University, Faculty of Computing

London Metropolitan University, Faculty of Computing
CS6003ES Advanced Software Engineering

Coursework Assignment, Semester 1 (part 1), 2022/23
Module Leader: Dr. Lochandaka Ranathunga
Part 1 weighting: 30% in total
GROUP STUDENT ID NUMBERS: __________________________________
_____________________________________________________________________________
NAMES_____________________________________________________________________
_____________________________________________________________________________
Submission deadline: 1ST of March 2023
The electronic version of your group report must indicate all group members’ ID number,
Surname and First name in the first page or at the beginning of program file (as comments).
1
22060563|nipuna kusal suraweera CS6003ES | ASE
If you think there is a good reason for late submission, such as illness, and you have supporting
documentary evidence then you should follow the “mitigating circumstance” procedures outlined in the
Red Book, otherwise assignments will NOT be accepted by the module Organizer after the due date.
PLAGIARISM
You are reminded that there exist regulations concerning plagiarism. Extracts from these
regulations are printed overleaf. Please sign below to say that you have read and understand
these extracts:
(Signature:)_____________________________________________________________
_____________________________________________________________________________
This header sheet should be attached to the assignment specification and to the work you submit. No work will be accepted without
it.
Extracts from University: Regulations on Cheating, Plagiarism and Collusion
2
Section 2.3: “The following broad types of offence can be identified and are provided as
indicative examples”
(i) Cheating: including taking unauthorized material into an examination; consulting

unauthorized material outside the examination hall during the examination;
obtaining an unseen examination paper in advance of the examination; copying
from another examinee; using an unauthorized calculator during the
examination or storing unauthorized material in the memory of a programmable
calculator which is taken into the examination; copying coursework.
(ii) Falsifying data in experimental results.
(iii) Personation, where a substitute takes an examination or test on behalf of the candidate.
Both candidate and substitute may be guilty of an offence under these Regulations.
(iv) Bribery or attempted bribery of a person thought to have some influence

on the candidate’s assessment.
(v) Collusion to present joint work as the work solely of one individual.
(vi) Plagiarism, where the work or ideas of another are presented as the candidate’s
own.
(vii) Other conduct calculated to secure an advantage on assessment.
(viii) Assisting in any of the above.
Some notes on what this means for students:
1. Copying another student's work is an offence, whether from a copy on paper or from a
computer file, and in whatever form the intellectual property being copied takes,
including text and computer programs.
3
2. Taking extracts from published sources without attribution is an offence. To quote ideas,
sometimes using extracts, is generally to be encouraged. Quoting ideas is achieved by
stating an author's argument and attributing it, perhaps by quoting, immediately in the
text, his or her name and year of publication, e.g. " e = mc2 (Einstein 1905)". A references
section at the end of your work should then list all such references in alphabetical order of
authors' surnames. (There are variations on this referencing system, which your tutors
may prefer you to use.) If you wish to quote a paragraph or so from published work then
indent the quotation on both left and right margins, using an italic font where practicable,
and introduce the quotation with an attribution.
4
CS6003ES – Advanced Software Engineering COURSEWORK PART 1
SUBMISSION DEADLINE: 1ST of March 2023
1. Description and requirements:
You are required using an appropriate approach to analyse, design,

implement and test the software for the scenario described below:
Scenario
FuelIn is a responsible public company establish in Sri Lanka where they distribute and manage
fuel supply island wide. They have several registered fuel stations at all the districts. FuelIn
wishes to introduce an Online fuel requesting and que management system for the requirement
of fuel distribution and tracking. End consumers are to be given facilities to request a fuel based
on the quota given for the vehicle registration number. The requesting customers can obtain a
token with expected filling time and date with 3 hours of tolerance. If the fuel distribution
cannot made available, the customer will be given a new scheduled period. If there is no any
scheduled delivery to a particular filling station or scheduled fuel stock is finished, the necessary
message will be given and requests are not permitted from those fuel stations. Once the
delivery schedule to the given filling station is confirmed by the dispatch office in the head
office, notification SMS/email will be sent to all token holders to make the payment. If the
customer unable to satisfy the payment and obtain fuel, quota will be deducted. As tokens are
issued only for the scheduled delivery amount of liters, the non-committed or unpaid fuel stocks
can be made available to request on demand after the scheduled payment time, those tokens
are issued for the same day collection. End consumers can take a token from the filling station
also using the same system when scheduled delivery is available. Twelve hours before the
5
delivery happens to the filling station, end consumers will receive sms/email as a reminder with
amount requested. Each vehicle receive a new quota after in each weeks period. The filling
station orders are to be taken separately using the system. The fuel stocks are to be distributed
according to population density within the area of filling stations
You are required to design a web and mobile apps to achieve above objectives. High-level
system requirement can be found in above description and some special requirements are also
given below.
1. System has two components
a. Web server with the database.
b. Client web Application with the Database Server.
c. Mobile app can use the same application services provided by the server (Data
operations).
2. The consumers should be able to register in the system and multiple registrations per
vehicle number should be prevented.
3. Filling station manager should be able to verify the tokens and details of the consumers
vehicle.
4. Filling station manager should be able to mark the status of the requests upon pumping
the fuel.
5. Based on the distribution of fuel for the outlets, head office should be able to view the
status of each outlet.
By considering the brief outline requirement given above, the hidden and potential
requirements are to be derived by you for the purpose and mention those clearly. The hidden
requirements are to be logically match with the outline requirement given above
Group Tasks:
6
1. System architecture design with the communication Diagram.
2. Software requirements specification should clearly indicate the Potential

requirements and the hidden requirements (including required reports).
3. Software design and its specification using UML with Object Oriented Analysis
Design techniques.
Individual Tasks:
1. Each member of the group must implement a part (more than two components) of the
software, such as interface including login function, daily report software.
2. Each member of the group must test your implemented software. It includes
software-testing design (With Test cases), test implementation and test report.
This coursework also requires each group to give a group presentation in week 10. The
requirements for presentation have been included in the Marking Scheme.
2. Submission:
By the deadline you must submit an electronic version of the complete documentation and
software.
7
3. Marking Scheme (TOTAL 100 MARKS):
The marks for this assessment are based on the following assessment criteria:
8
Items
Max. Mark
Over all report including report title, abstract,

6%
content and page number, etc
Group presentation in week 10
20 %
At least it contains project planning, requirement
and design specifications. It needs PowerPoint
slides.
System architecture design

8%
Requirements specification 15 %
Functional, non-functional, etc
Design specification 16 %
Use of UML, OOAD, etc.
Implementation 20 %
Use any programming/ DB / web language of your

choice
Testing 15 %
Software-testing design (With Test cases), test

implementation and test report., plus evidence of
the testing with prepared test data as specified in
the requirements specification
Total 100%
THIS COURSEWORK HAS TO BE COMPLETED IN GROUPS OF THREE TO FOUR STUDENTS.
9
10
Acknowledgement
We would like to thank our lecturer Mrs. Yamuna who support us to do this module
successfully and give important hints of the assignment. This group assignment is done
by us based on our personal studies and research and gives credits to our lecturer who
guided us to do this assignment successfully. I like to thank our parents for giving us the
effort to do our studies properly. Also, we would like to thank our friends for their
encouragement and support
11
Contents
Coursework Assignment, Semester 1 (part 1), 2022/23.............................................................1
Part 1 weighting: 30% in total.................................................................................................1
GROUP STUDENT ID NUMBERS: __________________________________..........................1
PLAGIARISM............................................................................................................................2
Acknowledgement..........................................................................................................................8
1.0. Introduction...........................................................................................................................11
1.1. Purpose..............................................................................................................................11
1.3. Intended Audience and Reading Suggestions....................................................................11
1.4. Project Scope and Objectives.............................................................................................12
1.4.1. Project Scope..................................................................................................................12
1.4.2. Objectives.......................................................................................................................13
1.5. References.........................................................................................................................13
1.6. Overview of the Existing Fuel Requesting System............................................................13
1.6. Drawbacks of the Existing System....................................................................................14
1.7. Future Enhancements.........................................................................................................15
2.0. Overall Description................................................................................................................15
2.1. Product Perspective............................................................................................................15
2.2. Product Features................................................................................................................16
2.3. User Classes and Characteristics........................................................................................18
2.4. Feasibility Study................................................................................................................20
2.5. Requirement Collection.....................................................................................................22
2.5.1. Requirement Gathering Techniques............................................................................22
2.5.2. Justification for requirement gathering.......................................................................23
2.6. Operating Environment......................................................................................................26
12
2.7. Design and Implementation Constraints............................................................................26
2.8. User Documentations.........................................................................................................28
2.9. Assumptions and Dependencies.........................................................................................28
2.10. Maintenance of the system...............................................................................................29
3.0. System Architecture and Design............................................................................................31
3.1. Architecture Design..........................................................................................................31
3.2. High Level System Architecture........................................................................................32
3.3. User Interface Design........................................................................................................32
3.3.1. Data Input Design.......................................................................................................32
3.3.2. Data Output Design.....................................................................................................32
3.4. Identify the Objects, Data and File Structures....................................................................33
3.5. System Components and Interactions................................................................................33
3.6. UML Diagrams..................................................................................................................33
3.6.1. Use Case Diagram......................................................................................................33
3.6.2. Activity Diagram........................................................................................................33
3.6.3. Class Diagram.............................................................................................................33
3.6.4. ER Diagram................................................................................................................33
4.0. Requirements Specification...................................................................................................35
4.1. Functional Requirements...................................................................................................35
4.1.1. Functional Requirements for users..............................................................................35
4.1.2. Functional Requirements for Fuel Station...................................................................38
4.1.3. Functional Requirements for FuelIn Company...........................................................40
4.2. Non-Functional Requirements...........................................................................................40
5.0. Implementation......................................................................................................................44
5.1. Software Tools and Technologies..........................................................................................44
5.1.1 Justification about System Tools and Technology.......................................................45
13
5.2. Implementation Environment.................................................................................................46
5.1.1 Hardware Implementation............................................................................................46
5.1.2 Software Implementation.............................................................................................47
5.2. Module Structure...............................................................................................................47
5.3. Important Codes.................................................................................................................47
6.0. Testing...................................................................................................................................48
6.1. System Test plan................................................................................................................48
6.2. Test Cases and Results.......................................................................................................48
7.0. Conclusion.............................................................................................................................48
References....................................................................................................................................48
Appendix......................................................................................................................................48
Group Contribution.......................................................................................................................48
Table Of Figures
Figure 1 Fueling organizational Structure.....................................................................................17
Figure 2: Google Form to Gather data..........................................................................................32
Figure 3: Google form...................................................................................................................33
Figure 4: Client - Server Architecture............................................................................................40
Figure 5 System Architecture Design............................................................................................41
Figure 6 Login...............................................................................................................................43
Figure 7 Sales Reports Deletion form...........................................................................................43
Figure 8 prepare Order.................................................................................................................44
Figure 9 Dashboard.......................................................................................................................44
Figure 10 Request Invoice from Fuel station to Fuel company.....................................................45
Figure 11 Use Case Diagram.........................................................................................................48
Figure 12 Use Case Diagram For Fuel Request..............................................................................49
Figure 13 Use Case Diagram for Payment process........................................................................50
Figure 14 Use Case Diagram for end consumer...........................................................................51
Figure 15 Over all Activity Diagram..............................................................................................52
Figure 16 Activity Diagram – Login...............................................................................................53
Figure 17 Activity Diagram – Fuel Delivery Scheduling.................................................................54
Figure 18 Activity Diagram – Fuel Inventory management...........................................................56
Figure 19 Activity Diagram – Payment Process.............................................................................58
Figure 20 Class Diagram................................................................................................................60
14
Figure 21 ER Diagram....................................................................................................................60
Figure 22 Sequence Diagram........................................................................................................61
Figure 23 Important Code 1..........................................................................................................89
Figure 28 Database table 1...........................................................................................................92
Figure 29 Database Table 2...........................................................................................................93
Figure 30 Testing..........................................................................................................................94
Figure 31 Test Cases And Results 1..............................................................................................97
Figure 32 Test Cases And Results 2...............................................................................................97
Figure 33 Test Cases and Results 3...............................................................................................98
Figure 34 Test Cases and Results 4...............................................................................................98
Figure 35 Test Case and Results 5.................................................................................................99
Figure 36 Home page..................................................................................................................102
Figure 37 Lubricants...................................................................................................................102
Figure 38 Unlimited Services......................................................................................................103
Figure 39 Edit Order...................................................................................................................103
Figure 40 Manage Invoices.........................................................................................................104
Figure 41 B/W Dates Report Form..............................................................................................104
Figure 42 Sales report.................................................................................................................105
Table Of Tables
Table 1:Organization's Roles and Responsibilities........................................................................17
Table 2: User Functional Requirements........................................................................................63
Table 3: Fuel Station Functional Requirements............................................................................68
Table 4: FuelIn Company Functional Requirements.....................................................................72
Table 5 Group Contribution........................................................................................................106
15
1.0. Introduction
1.1. Purpose
This document's primary purpose is to provide a thorough explanation of the
FuelIn Online fuel requesting and queue management system. It will describe the
functions and features of the system, its interfaces, what the system will perform, the
limitations that must be met for it to function, and how the system will respond to outside
stimuli. This document will be submitted for approval to the FuelIn and is intended for
both stakeholders and system developers.
This software will serve as a queue management and online fuel ordering system.
This system is intended to improve fuel management, queue management and tracking
fuel deliveries and fuel distribution efficiency in the midst of a fuel crisis. Without it,
these tasks would have to be carried out manually and may encounter numerous
difficulties. The system serves the needs of the customer, registered fuel stations, and
FuelIn while being simple to comprehend and use by enhancing communication between
fuel distributors, fuel stations, and customers and maximizing the speed of the fuel
distribution process and make clear tracking of fuel deliveries.
The system is made to specifically allow users to register their vehicles in order to obtain
a fuel token. Also, the fuel stations have the capability to check the car details using this
system and issue a token to the customer. The FuelIn firm will inform the customer
though a SMS about the specifics of the fuel distribution, and the customer can refuel
their vehicles without having to stand in line.
16
1.2. Organizational Module
Figure 1 Fueling organizational Structure
This structure has the CEO at the top, followed by, there are several department heads
who oversee different areas of the company, such as fuel distribution, technology, sales
and marketing and human resources. Finally, there are district managers who are
responsible for overseeing the fuel station managers in each district, who in turn manage
the staff at each fuel station.
Table 1:Organization's Roles and Responsibilities
Role Responsibilities
Board of Directors Take final decisions of overall operations
according to the board of directors
CEO Responsible for overall management and
strategic direction of the company
Head of Fuel Distribution Responsible for managing the distribution of
fuel to all fuel stations
Dispatch Office Manager Responsible for managing the dispatch office,
which schedules and coordinates fuel deliveries.
Fuel Delivery Coordinator Responsible for coordinating the actual delivery
of fuel to each fuel station
Head of Technology Responsible for overseeing the company's
17
technology strategy and ensuring that
technology is used to improve business
processes and operations
System Architect Responsible for designing and developing the
online fuel requesting and que management
system.
Software Development Responsible for managing the team that
Manager develops and maintains the company's software
applications
Quality Assurance Manager Responsible for ensuring that the software
applications meet the required quality standards
and are free of bugs and errors
District Managers Responsible for managing the fuel stations in
their respective districts and ensuring that
operations run smoothly.
Fuel Station Managers Responsible for managing day-to-day
operations at the fuel stations, including
managing staff, inventory, and customer
service.
Attendants and other staff Responsible for providing customer service,
dispensing fuel, and managing inventory at the
fuel station
Head of Sales and Marketing Responsible for developing and implementing
sales and marketing strategies to promote the
company's products and services.
Responsible for managing the sales team and
ensuring that sales targets are met.
Marketing Manager Responsible for developing and implementing
marketing campaigns and initiatives.
Customer Service Manager Responsible for managing the customer service
team and ensuring that customers receive high-
18
quality service.
Head of Human Resources Responsible for developing and implementing
HR strategies and policies.
HR Manager Responsible for managing HR operations,
including recruitment, training, performance
management, and employee relations.
Training and Development Responsible for developing and implementing
Manager employee training and development programs
1.3. Intended Audience and Reading Suggestions

The stakeholders who have a stake in the project's success as well as developers, testers,
project managers, and others are the target audience for this Software Requirements
Specification (SRS) document. The document is meant to help the development team
implement the project's requirements and to give clients and end users a higher-level
insight. Each stakeholder group's needs have been taken into consideration while
developing the language and degree of depth in the paper. Project managers and
consumers will need a higher-level overview, whilst developers and testers will need
more technical specifics.
In order to make it easier to navigate, headings, subheadings, and bullet points have been
used throughout the document. To make sure that the document satisfies their needs and
is simple to understand, feedback from the intended audience has been solicited and
integrated.
1.4. Project Scope and Objectives
1.4.1. Project Scope

Lack of foreign exchange reserves made it challenging for the nation to import the
necessary amount of fuel, which led to the fuel crisis. As a result, there were lengthy lines
at fuel stations and a shortage of fuel, which caused problems with transportation and
economic disruption.
19
This web based software will allow for the efficient and fair allocation of fuel. Customers
received tokens from fuel stations under this system based on the type of fuel they need,
and the license plate numbers on their vehicles. Consumers will be able to buy fuel on the
day indicated on their token, which will help to shorten queues and discourage hoarding.
The system has two main components: a web server with the database and a client web
application with the database server. Consumers can register and the system prevents
multiple registrations per vehicle number. The system sends reminders to end consumers
12 hours before delivery, and the fuel stocks are distributed according to population
density within the area of filling stations. Non-committed or unpaid fuel stocks can also
be made available for on-demand requests after the scheduled payment time.
FuelIn will be able to better manage the limited supply of fuel and avoid panic buying by
applying this application. This will help to ensure that fuel is distributed more equally
and that critical services like public transportation can continue to function. The token
system will also help to prevent illegal fuel trading and price gouging by more efficiently
regulating fuel supplies.
1.4.2. Objectives
 Provide end-users a simple and efficient way to request fuel based on their quotas.
 Allow end-users to get a token with a 3-hour tolerance period and an expected
filling time and date.
 Enable FuelIn to handle island-wide fuel supply and distribution, with real-time
tracking of fuel supplies and distribution schedules.
 Ensure that end-users are advised of scheduled fuel delivery and have the option
to pay in advance.
 Provide for variable fuel delivery scheduling and quota control based on vehicle
registration numbers.
 Make sure the system is easy to use and secure, with clear instructions and
adequate security measures in place to protect user data and payment information.
20
 Provide for separate order management for filling stations, as well as fuel supply
distribution based on population density inside the filling station region.
1.5. References
1.6. Overview of the Existing Fuel Requesting System

FuelIn, a public Fuel company in Sri Lanka, commissioned the Online Fuel Requesting
and Queue Management System to streamline the fuel distribution process for end users.
Customers can use this web and mobile application to receive tokens indicating the
estimated filling time and date, with a three-hour tolerance window. Filling station
managers can utilize the system to validate tokens and vehicle details, while head office
can see the status of each outlet based on fuel distribution. Fuel distribution was done in a
more traditional way, with petrol stations ordering fuel from FuelIn and the fuel being
delivered based on demand.
The former fuel distribution method required fuel stations to submit fuel orders with
FuelIn based on their estimated demand. Fuel companies would then provide the fuel to
the fuel stations in accordance with their requests. The fuel would then be sold to
customers, who would pay according to the government-set prevailing pricing.
During the fuel crisis, however, this method encountered difficulties and FuelIn has to
face these difficulties as well which was being unable to purchase enough fuel to match
the demand of petrol stations. This resulted in fuel shortages and long lines at fuel
stations.
1.6. Drawbacks of the Existing System

There were various issues with fuel delivery that contributed to the country's fuel crisis.
Following are some of the major disadvantages:
 Fuel shortages and long queues: Fuel Companies were unable to purchase enough
fuel to meet the demand of petrol stations due to a shortage of foreign exchange.
This resulted in fuel shortages and long lines at fuel stations, which
inconvenienced customers and disrupted transportation and other sectors.
21
 Hoarding and black-market sales: Several fuel station owners used hoarding to
create artificial shortages, allowing them to sell fuel at inflated prices on the black
market. This aggravated the fuel scarcity and increased to customer anxiety.
 Inadequate supply chain management: There were also supply chain management
concerns within the CPC, such as fuel shipments and distribution delays. This
added to the fuel shortage and caused problems in transportation and other
industries.
 Price difficulties: The government's decision to subsidize fuel prices caused
pricing issues, which exacerbated the fuel crisis. Due to a lack of foreign cash and
the high expense of importing petroleum at market prices, the government was
unable to prolong the subsidies, causing fuel prices to rise and the situation to
intensify.
Ultimately, these flaws in fuel distribution and management contributed to Sri Lanka's
fuel crisis, highlighting the need for a more effective mechanism to regulate fuel supplies
and avoid hoarding. The token system was implemented in an attempt to overcome these
concerns and avert similar crises in the future.
1.7. Future Enhancements

Real time monitoring and reporting: FuelIn can create a system to monitor Fuel levels in
real-time and generate information on fuel usage patterns, which can help them optimize
their fuel distribution and management process.
Predictive maintenance: FuelIn can foresee equipment faults and plan maintenance in
advance using machine learning techniques. This could lessen downtime and boost
operational effectiveness.
Customer feedback system: By adopting a system to collect consumer input on their fuel
management and queue management procedures, they can better understand where they
can make improvements and increase customer happiness.
Cloud-based system: FuelIn may want to think about switching their queue and fuel
management systems to the cloud, which can enhance system scalability, usability, and
dependability.
22
2.0. Overall Description
2.1. Product Perspective

The context of the product stated in this is the Sri Lankan fuel distribution and
management industry. FuelIn, a responsible public firm that controls fuel supply island-
wide through its registered fuel stations in all districts of Sri Lanka, is developing this
application, an online fuel requesting and demand management system.
A fuel shortage has occurred in Sri Lanka due to a variety of factors, including
disruptions in the supply chain, delays in fuel supplies, and insufficient fuel storage and
distribution infrastructure. As a result, consumers have been forced to wait in enormous
lines for long periods of time to receive fuel, causing inconvenience. FuelIn, a
responsible public corporation that oversees fuel supply and distribution in Sri Lanka, has
proposed an online fuel requesting and que management system to alleviate this issue.
End-users would be able to request fuel online and obtain tokens with predicted filling
times and dates. It would also allow FuelIn to manage fuel supply and distribution more
efficiently by enabling real-time tracking of fuel inventories and distribution schedules.
To address these issues, FuelIn identified the need for an online fuel ordering and queue
management system that would allow end-users to request fuel online, monitor their fuel
quotas, and receive tokens with estimated filling times and dates. The solution would also
assist FuelIn in more efficiently managing fuel supply and distribution by providing real-
time tracking of fuel stockpiles and distribution schedules, allowing for improved fuel
stock planning and management.
Essentially, the solution was created to address the issues that FuelIn and end-users have
in the Sri Lankan fuel distribution and management business, with the purpose of
providing a more efficient and simple way to request fuel and manage fuel supply and
distribution.
23
2.2. Product Features
The following is a list of the main features and functions that the proposed online fuel
requesting and queue management system will execute or allow the user to perform:
Online fuel token request:
 client registration via NIC, email, and phone number

 ability to register customer's automobiles via vehicle registration number
 Customers can use the system to request a fuel token online.
 Fuel limitations are assigned based on the vehicle's license plate number.
Issue tokens:
 End-users are given tokens with estimated filling times and dates.
 Tokens are only issued for the number of liters specified for delivery.
real-time tracking:
 The system has the ability to tracks fuel stocks and distribution schedules in real
time.
 Users receive SMS/email reminders on fuel supply schedules.
Collection and payment:
 Notification To make the payment, all token holders will receive an SMS/email.
 When the planned delivery is available, customers can obtain a token from the
filling station using the same system.
Fuel stock control:
 After the planned payment deadline, non-committed or unpaid fuel stocks might
be made available for request on demand.
 The method will be used to take filling station orders individually.
 The fuel stocks will be apportioned based on population density within the
vicinity of filling stations.
24
Quota management:
 Each vehicle receives a new quota at the end of each week.
Below is a summary of the major features based on the system's actors:
End- Users:
 Register into the system using personal details.

 Use the vehicle identification number to register vehicles (VIN).
 Request fuel online using the quota assigned to the registered vehicle.
 Obtain a token with the expected filling time and date, with a 3-hour tolerance.
 Make the payment through the system.
 Collect the fuel from the filling station during the scheduled delivery time.
 Receive SMS/email notifications about the scheduled delivery time and the
amount of fuel requested.
 If there are any non-committed or unpaid fuel supplies available, request fuel on
demand.
 See each vehicle's fuel quota and payment history.
Filling Station Staff:
 Tokens should be distributed to customers who request fuel at the filling station.
 Update the fuel stock levels at the system's filling station.
Dispatch Office:
 Confirm each filling station's delivery timetable.

 Inform customers to make the payment via SMS/email.
Administrator of the system:
 Control the system and keep the fuel quotas for each car up to date.
 Control the fuel supplies at the filling stations.
 Address any system difficulties that may emerge.
25
2.3. User Classes and Characteristics
User classes can be distinguished based on their frequency of usage, the subset of product
functionalities they utilize, their technical knowledge, their security or privilege levels or
their experience.
Below are the projected user classes that you expect to use this product, characterized by
their characteristics:
 Customers - individuals who require fuel for their vehicles and will use the online
fuel requesting and queue management system to request and obtain fuel.
 Fuel station attendants - employees who will manage the fuel station's physical
infrastructure and use the system to handle walk-in customers.
 Dispatch officers (FuelIn Head office) - employees at the head office who will
monitor and manage the delivery of fuel to the various fuel stations and will use
the system to communicate with the fuel stations and end consumers.
 System administrators - employees responsible for maintaining and managing the
online fuel requesting and queue management system. They will also handle user
accounts, system configurations, and maintenance tasks.
 Technical support - Employees responsible for providing technical support to end
users who may encounter issues with the system.
 Developers - Technical employees responsible for developing and maintaining the
software, including updating features and fixing any bugs or issues that may arise.
Outlined Characteristics of the users of online fuel requesting and queue management
system.
Customer:
 Some individuals may have various levels of technical knowledge when it comes
to using online systems.
 They may choose various payment options, such as credit card or cash.
Fuel Station Employees:
 These are employees who work at registered FuelIn fuel stations.
26
 They oversee fuel delivery and payment processing.
 Individuals may have various levels of technical knowledge when it comes to
using internet services.
 Managers and regular staff may have varying amounts of authority.
Dispatch office:
 These are staff members that are tasked with overseeing FuelIn's timetable for
fuel deliveries.
 To handle fuel distribution, they must have a high level of technical skill.
 Managers and regular staff may have varying amounts of authority.
System administrators:
 These IT specialists oversee the system for managing queues and online fuel
orders.
 In terms of system management and security, they require a high level of
technical proficiency.
 They have privileged access to the system to maintain and update it.
The major purpose is to give end users with an effective and convenient fuel requesting
and que management system, as well as a simplified fuel distribution and tracking system
for FuelIn. End users and FuelIn staff members (e.g., dispatch office people, fuel station
managers and customers) would likely be the preferred user types based on this purpose,
as they directly interact with and profit from the product. Other user classes (for example,
fuel truck drivers and maintenance people) may be necessary for the product to function
successfully, but they may be seen as less vital to satisfy in terms of product design and
functionality. To produce a well-rounded and functional product, it is essential to
consider the requirements and goals of all user classes, but the major focus should be on
the user classes that are most critical to the product's success.
2.4. Feasibility Study

Economic Feasibility
27
The process of determining if the benefits of a project outweigh the costs is known as
economic feasibility. In other terms, it determines whether or not the idea is financially
feasible. This entails calculating and comparing the costs of designing and deploying the
system to the predicted benefits. Estimating the expenses of building the fuel
management system, as well as any ongoing costs for maintenance, support, and
upgrades, would be part of this process for FuelIn. The advantages would include
increased Fuel distribution efficiency and reduced fuel losses due to errors or fraud.
FuelIn is regarded commercially feasible if it can earn enough income to cover its costs
while still making a profit. This can be accomplished through competitive pricing,
efficient operations, and successful marketing methods.
Operational Feasibility
The operational feasibility assessment determines if the technology can be effectively

integrated with the existing business operations and processes. This includes determining
whether or not the system will be adopted by users and whether or not it will increase
productivity and efficiency. This would entail examining the current fuel distribution and
monitoring process and identifying any potential challenges or impediments that might
develop during the implementation of the new fuel management system for FuelIn.
FuelIn can be regarded operationally practicable if it can seamlessly integrate with

existing systems and processes and if it has the requisite resources and skills to properly
manage its operations. This can be accomplished by investing in appropriate technology
and infrastructure, engaging skilled employees, and implementing ongoing training and
development programs.
Technical Feasibility
The technical feasibility of a proposed system determines if it can be developed using

available technology and implemented within the existing technological infrastructure.
This includes determining if the necessary hardware and software can be obtained and
installed, as well as whether the system can be integrated with other systems. For FuelIn,
this would entail examining existing fuel management system technology and
guaranteeing that the proposed system can be created utilizing this technology.
28
FuelIn is technologically feasible if it can use technology to develop a system that is
reliable, efficient, and scalable. This can be accomplished by investing in appropriate
software and hardware solutions, performing frequent testing and quality assurance
procedures, and collaborating with knowledgeable technology vendors.
Legal Feasibility
The legal feasibility of a proposed system determines whether it can be designed and
implemented in accordance with applicable laws and regulations. This includes
determining if the system will violate any existing patents or copyrights, as well as
compliance with data protection and privacy laws. This would entail FuelIn assessing the
legal and regulatory framework governing fuel distribution and ensuring that the planned
fuel management system complies with these rules.
FuelIn is legally feasible if it can operate within the confines of existing laws and
regulations. This can be accomplished by performing extensive study on legal
requirements, obtaining required licenses and permits, and maintaining current on
changing legislation.
Schedule Feasibility
Schedule feasibility assesses whether the proposed system can be created and executed
within the timeframe given. This includes determining if the project can be finished in the
allotted time and whether any established deadlines will be met. This would entail FuelIn
assessing the time required to create and deploy the fuel management system and
guaranteeing that it can be completed within the timeframe specified. This would also
entail identifying any potential delays or bottlenecks that could affect the project's
timeframe.
If FuelIn can complete project deadlines and deliverables on time, it might be termed
timetable realistic. This can be accomplished by developing a realistic project plan with
attainable milestones, providing adequate resources, and conducting regular progress
assessments and changes.
29
2.5. Requirement Collection
It is critical to collect complete and precise criteria to design an effective system that fits
the demands of FuelIn and its consumers. This can assist in ensuring that the system is
built and developed to fit the specific demands of FuelIn and its clients, while also being
scalable, secure, and reliable. There is a danger of designing a system that does not fulfill
the demands of the stakeholders or that is difficult to maintain and update in the future if
suitable requirements are not gathered.
2.5.1. Requirement Gathering Techniques

The following strategies would be suitable for acquiring requirements for this case study:
 Interviews: Conducting interviews with FuelIn management, filling station

managers, and end-users to better understand their needs, ewak spots, and
requirements
 Questionnaires and Surveys: Distribute questionnaires and surveys to a bigger
audience to collect more information about customer behavior, fuel consumption
habits, and preferences.
 Prototyping: Creating a system prototype and soliciting feedback from
stakeholders to refine requirements and identify potential difficulties.
 Create use cases to capture system requirements and identify prospective usage
scenarios.
 Observation: Watching the fuel distribution process at filling stations to find areas
for improvement and acquire information.
The project team can compile a complete set of requirements and ensure that the Online
Fuel Requesting and Queue Management System satisfies the demands of all
stakeholders by applying these strategies.
2.5.2. Justification for requirement gathering.

A mix of several methodologies, such as interviews, surveys, and observations, would be
the most realistic requirement gathering technique.
Because the system is intended for end users, conducting interviews with them will aid in
understanding their wants and preferences surrounding the fuel ordering process. Surveys
30
of consumers and fuel station managers can provide useful feedback on the present fuel
distribution mechanism and prospective improvements. Watching and identifying weak
points in the current fuel distribution process can also provide insight into the system's
requirements.
Figure 2: Google Form to Gather data
31
Figure 3: Google form
Moreover, focus groups with important stakeholders can be arranged to acquire

additional comprehensive requirements, such as the system's required features, functions,
and performance. Brainstorming meetings with the development team can aid in the
identification of technical requirements and constraints. Finally, evaluating the applicable
legislation and policies can provide insight into the system's legal and compliance needs.
32
2.6. Operating Environment
The online fuel ordering and queue management system will be web-based and available
from a range of devices such as desktop computers, laptops, tablets, and smartphones.
The system must work with popular online browsers like Google Chrome, Mozilla
Firefox, and Microsoft Edge, as well as operating systems including Windows, macOS,
and Linux. The software will be created with a mobile-first approach, which means it will
be optimized for use on mobile devices. A mobile app will be developed in addition to
the web-based system to provide consumers with a more convenient and user-friendly
manner of accessing the system. The mobile software, which will be accessible for both
Android and iOS devices, will feature capabilities identical to the web-based system.
Other software components or applications, such as payment gateways, SMS and email
service providers must also be compatible with the system. The system will be designed
with a server-client architecture, with the server running on a dedicated computer with
enough processing power, memory, and storage to manage the estimated traffic. The
server will run an operating system and will store and manage data using a database
management system.
2.7. Design and Implementation Constraints

Any limitations, restrictions, or requirements that may effect the creation of the software
product are referred to as design and implementation constraints. These limits could be
technological, organizational, or regulatory issues that developers must consider while
creating and implementing software. Hardware limits, software compatibility, security
needs, resource constraints, specialized technological requirements, communication
protocols, design standards, and other factors that may effect the development process are
examples of such constraints. These constraints can have a significant impact on the final
result by influencing the choice of development tools, programming languages, design
techniques, and other essential considerations.
These are some constraints that development team might face.
Corporate and regulatory policies: Developers may need to ensure that the application
complies with relevant fuel distribution, storage, and transportation regulations and
33
policies. They may also be required to adhere to the policies and procedures of the
company that owns or operates the fuel delivery service.
Schedule: Because the project must be completed within a particular deadline, the
development tools and technologies that can be employed may be limited.
Budget: Development costs must be kept within a particular budget, which may limit the
availability of expensive development tools or technologies.
Hardware limitations: Developers may need to consider the hardware restrictions of the
program, such as memory needs, processor power, and network connectivity. They may
also need to think about the devices and platforms the program will support, such as
smartphones, tablets, and desktop PCs.
Technologies, tools, and databases: To implement the FuelIn application, developers may
need to employ specific technologies, tools, and databases, such as a specific
programming language, database management system, or development framework. They
may also need to ensure that the application is compatible with the fuel delivery service's
existing technology infrastructure.
The supposed system will be built using these Technologies.
 PHP - A server-side scripting language frequently used in web development. It is

simple to learn and use, and there are numerous frameworks and libraries
available to make development more efficient and faster.
 Laravel Framework - This is a PHP web application framework with an elegant
syntax and a modular layout. It includes routing, templating, and authentication
out of the box.
 MySQL - It is an open-source relational database management system that is
widely used and supported. It offers low ownership costs and can manage a large
volume of transactions.
 Visual Studio Code as IDE - Visual Studio Code is a free and open-source code
editor that provides features such as syntax highlighting, code completion,
debugging, and Git integration.
34
Security considerations: The FuelIn application and the data it manages, such as user
credentials, payment information, and vehicle details, may need developers to think about
security. To defend against unauthorized access and data breaches, they may need to
employ measures such as encryption, secure authentication, and secure data storage.
Design conventions and programming standards: To ensure that the application is

manageable, scalable, and resilient, developers may need to adhere to established design
conventions and programming standards. To assure the application's quality and
reliability, they may need to employ approaches such as modular design, code reuse, and
unit testing.
2.8. User Documentations

User documentation is essential for the fuelIn system assists users in understanding how
to utilize the system to achieve their objectives. User guides, online support, and tutorials
can assist consumers in learning how to order fuel online, manage their account, track
their fuel deliveries, and troubleshoot any issues that may arise. Users may struggle to
utilize the system efficiently if there is no clear and thorough documentation, which may
cause dissatisfaction, errors, and lower adoption rates. As a result, user documentation is
an essential component of the fuelIn system's success.
user documentation components that may be delivered along with the software:
 User manual: describes how to use the fuel ordering and delivery system in detail,
including how to place orders, track deliveries, and manage accounts.
 Tutorials: Step-by-step video or interactive tutorials that walk users through
common system tasks or functionalities.
2.9. Assumptions and Dependencies

Assumed factors that could affect the requirements for the online Fuel management and
Queue Management system:
 The assumption that the online fuel delivery service will be accessible via a
variety of devices, including mobile phones, tablets, and laptops, which may have
an impact on the system's design and development.
35
 Assume that users will have access to a dependable internet connection, which
may affect system speed and usability.
 Assume that fuel prices and availability will remain constant, which may have an
impact on the service's business model and pricing approach.
 The assumption that customers would submit correct and valid information during
registration and fuel ordering, which may have an impact on the system's
accuracy and reliability.
 Assumption that the system will integrate with third-party payment gateways and
financial systems, which may have an impact on the system's security and
stability.
External elements on which the project is dependent include:
 Integration with the database management system and web server software, both
of which are well documented.
 Integration with third-party payment gateways and financial systems, both of
which are commercial components that must be tested and incorporated into the
system.
2.10. Maintenance of the system

Maintenance is critical to the long-term performance and sustainability of FuelIn's online
fuel ordering and queue management system. Employees and consumers will utilize the
system daily, and any outages or failures could result in substantial company disruptions
and revenue loss. Maintenance ensures that the system stays operable, up to date, and
secure, reducing the likelihood of problems or downtime. Furthermore, frequent
maintenance can detect and treat possible problems before they become serious concerns,
avoiding costly repairs or system breakdowns. Ultimately, maintenance is an important
part of assuring the system's stability, usefulness, and lifespan for the benefit of both the
firm and its customers.
Among the appropriate system maintenance strategies for the Online Fuel Requesting and
Queue Management System are:
36
Corrective Maintenance: Corrective Maintenance is the process of correcting mistakes or
problems in a system once they have been detected. This can include debugging code,
resolving user interface bugs, and dealing with performance issues. Corrective
maintenance is a reactive process that occurs after a problem has been detected.
Ex:-
 Bug fixes in the system code

 Replacing defective hardware components, such as a hard drive
 After a system failure, restoring data from a backup.
Preventative maintenance: Preventative maintenance is proactive in nature and tries to

prevent future problems from developing. It requires monitoring the system for potential
problems and addressing them before they become serious difficulties. This can involve
routine system backups, server log monitoring, and software component updates.
Ex:-
 Cleaning and calibrating hardware components on a regular basis to avoid failure.

 Using software updates and patches to prevent security flaws.
 Backup data on a regular basis to avoid data loss in the event of a system
breakdown.
Adaptive maintenance: Adaptive maintenance entails updating the system to satisfy

changing user requirements or to adapt to changes in the technological environment. This
can include adding new features, upgrading components, or modifying the user interface
to better match user needs.
Ex:-
 Integrating different system features to satisfy evolving user demands.

 Changing current features in order to increase performance or usability.
 Increasing system capabilities by upgrading hardware components
37
Perfective Maintenance: This type of maintenance entails improving the system's
performance or usability without altering its functioning. To make the system easier to
use, this can include streamlining code, improving the user interface, or adding
documentation.
Ex:-
 Coding refactoring to make it more readable and maintainable.

 to enhance system speed, optimize database queries.
 Performing usability testing and making improvements to the user interface
Scheduled maintenance: Scheduled maintenance is a proactive approach to system

maintenance in which repair actions are planned and scheduled in advance to avoid
unexpected system downtime or failures. This can involve things like regular system
backups, software updates, and hardware checks.
Ex:-
 To minimize user inconvenience, regular backups and system updates are

performed during off-peak hours.
 To minimize the impact on operations, schedule hardware upgrades or
replacements during non-business hours.
 Testing system failover and disaster recovery protocols on a regular basis to
ensure they are working effectively.
3.0. System Architecture and Design
3.1. Architecture Design

The client-server architecture is a distributed application structure that divides tasks or
workloads between resource or service providers, known as servers, and service
requesters, known as clients. In the client-server architecture, when a client computer
sends a data request to the server via the internet, the server acknowledges the request
38
and returns the data packets requested to the client. Customers don't share any of their
assets. Email, the World Wide Web, and other client-server models are examples.
Figure 4: Client - Server Architecture
(syedmodassirali, 2022)
39
Architecture Diagram
Figure 5 System Architecture Design
In this architecture, the customer app communicates with the web application, which has
two main components: the fuel request system and the fuel station management system.
The fuel request system is responsible for handling customer requests for fuel, managing
payment processing through the payment gateway, and updating the delivery status
through the delivery status controller. It also integrates with the bank API to process
payments.
The fuel station management system is responsible for managing fuel station orders
through the fuel station order controller and inventory management through the inventory
management controller. It also integrates with the fuel stock API to manage fuel stocks.
40
3.2. High Level System Architecture
the high-level system architecture of the fuel requesting, and queue management system
would likely involve the following components:
 Web Server: This component would manage the overall functioning of the web
application and database server.
 Database Server: This component would store and manage all data related to fuel
requests, filling stations, delivery schedules, customer details, and payment
transactions.
 Client Web Application: This component would provide the end users with the
ability to request fuel based on the quota given for the vehicle registration
number. It would also provide a means for customers to obtain tokens, make
payments, and receive reminders.
 Mobile App: This component would provide mobile users with access to the same
application services provided by the server, including data operations related to
fuel requests, filling stations, delivery schedules, customer details, and payment
transactions.
 Dispatch Office: This component would manage the delivery schedules to the
filling stations and confirm the scheduled delivery to the given filling station,
after which notifications would be sent to all token holders to make the payment.
 Filling Station Manager: This component would verify the tokens and details of
the consumers' vehicles and mark the status of the requests upon pumping the
fuel.
 Head Office: This component would be able to view the status of each outlet
based on the distribution of fuel for the outlets.
41
3.3. User Interface Design
3.3.1. Data Input Design
Figure 6 Login
Figure 7 Sales Reports Deletion form
42
Figure 8 prepare Order
3.3.2. Data Output Design
Figure 9 Dashboard
43
Figure 10 Request Invoice from Fuel station to Fuel company
3.4. Identify the Objects, Data and File Structures

Some conceivable objects, data, and file structures for FuelIn's fuel management and
queue management system design. Here's an explanation for each:
Objects:
 Vehicles: physical fuel-consuming items

 Tokens: Customers are given physical objects that represent a particular amount
of Fuel for eventual usage.
 Employee of a filling station: personnel that work at Fuel stations and interact
with customers.
 Dispatch Officer: workers in charge of the fuel management and queue
management systems
Data:
 Fuel cost: the cost of a specific amount of fuel.

 Tank fuel level: the amount of fuel in each fuel tank.
 Vehicle types and fuel consumption rates: the many vehicle types that can be
fueled at the station, as well as their respective fuel consumption rates
44
 Token distribution per car: the number of tokens distributed per vehicle dependent
on its fuel consumption rate.
 Customer sales transactions: records of Fuel and token purchases
 Stock levels of fuel and tokens: The amount of fuel and tokens that are currently
in stock at the station.
 tank maintenance records: records of Fuel pump and tank maintenance and repair
work.
 Schedules and quantities of fuel delivery: the timetable and quantity of fuel
delivered to each fueling station.
 Management reports include sales reports, maintenance reports, and inventory
reports, among other things.
Files Structure:
 Fuel inventory database: keeps track of the fuel level in each tank, the capacity of
the pumps, and the amount of fuel sold.
 Vehicle database: contains data on vehicle kinds, fuel consumption rates, and
token allocations.
 Database of sales transactions: stores data on fuel and token purchases, usage, and
payments.
 Maintenance database: keeps records of Fuel pump and tank maintenance and
repair operations.
 Fuel delivery database: stores information about fuel delivery schedules and
volumes.
 Queue database: stores queue information as well as token usage.
 Managerial report database: Sales reports, maintenance reports, and inventory
reports are just a few of the reports kept in the managerial report database that are
produced for managers.
45
3.5. System Components and Interactions
The Online Fuel Requesting and Queue Management System is made up of two major
components:
 Web server with the database: This component oversees managing the database,
which includes all the required information about FuelIn requests, filling station
orders, and fuel stock distribution. In addition, the web server manages
communication between the client web application and the database server.
 Client web application with database server: This component oversees allowing
end users to request fuel based on their vehicle registration number. The client
web application talks with the database server to obtain the necessary information
and to update the database with fresh fuel demands.
46
3.6. UML Diagrams
3.6.1. Use Case Diagram
Figure 11 Use Case Diagram
47
Figure 12 Use Case Diagram For Fuel Request
In this use case diagram, we have two main actors: Customer and Admin. The Customer
actor can request fuel, and view fuel requests. The admin actor can view fuel requests and
manage fuel delivery.
The Request Fuel use case allows the Customer to request fuel based on their vehicle
registration number and quota. The View Fuel Requests use case allows both the
Customer and Admin to view the status of fuel requests. The Manage Fuel Delivery use
case allows the "Admin" to manage fuel delivery by scheduling the delivery, managing
fuel stock, and sending payment notifications.
48
Figure 13 Use Case Diagram for Payment process
In this use case diagram, we have two main actors: Customer and Admin. The Customer
actor is responsible for requesting payments for fuel purchases, while the "Admin" actor
can view payment history and refund payments.
The Request Payment use case allows the Customer to request payment for a fuel
purchase by providing the token number, payment amount, vehicle registration number,
and payment status. The View Payment History use case allows the admin to view the
payment history, including the payment date, amount, and status. The Refund Payment
use case allows the admin to refund payment by providing the payment ID, refund
amount, and reason.
49
Figure 14 Use Case Diagram for end consumer
 Request Fuel: End consumers can request fuel using the online fuel requesting
system by providing their vehicle registration number and fuel requirement.
 Receive Token with Scheduled Filling Time: After making a request, end
consumers will receive a token with a scheduled filling time and date along with 3
hours of tolerance.
 Receive Payment Notification: End consumers will receive a notification
SMS/email to make payment once the delivery schedule to the given filling
station is confirmed by the dispatch office.
 Make Payment: End consumers will make payment for the fuel using the online
system.
50
 Collect Fuel: End consumers can collect their fuel from the filling station at the
scheduled filling time
3.6.2. Activity Diagram
Figure 15 Over all Activity Diagram
Explanation:
 The process starts with the user logging in to the system.

 The user can then request fuel and the system will check their quota.
 If the quota is available, a token will be issued to the user and they will wait for
the scheduled delivery.
 Once the scheduled delivery is confirmed, the user will receive a notification to
make the payment and collect the fuel.
51
 If the user does not make the payment within the given time, the token will expire
and they will have to request on-demand fuel or wait for the next scheduled
delivery.
 If the scheduled delivery is cancelled, the user can request fuel from another
station.
Activity Diagram for Login
Figure 16 Activity Diagram – Login
52
Activity Diagram For Fuel Delivery Scheduling
Figure 17 Activity Diagram – Fuel Delivery Scheduling
Receive Order
 Verify that the order is valid and includes the necessary information (e.g. delivery
location, fuel quantity, delivery date/time).
 Check the customer's account to ensure they have sufficient quota for the
requested fuel.
 Determine the optimal delivery route and assign a delivery vehicle.
53
Check Inventory
 Check the inventory levels at the distribution center to ensure there is enough fuel
to fulfill the order.
 If necessary, arrange for additional fuel to be transported from another
distribution center.
Assign Delivery
 Assign a delivery driver and vehicle to fulfill the order.

 Provide the driver with the necessary information (e.g. delivery location, fuel
quantity, delivery time).
Notify Customers
 Notify the customer who placed the order of the expected delivery time and any
relevant information (e.g. delivery vehicle details).
 Notify any other customers who have requested fuel from the same filling station
of any potential delays or schedule changes.
Deliver Fuel
 Deliver the fuel to the specified location.

 Verify the quantity of fuel delivered and obtain any necessary signatures or
documentation.
Update Inventory
 Update the inventory levels at the distribution center to reflect the fuel delivery.
 Update the customer's account to deduct the appropriate amount of quota for the
delivered fuel.
54
Activity Diagram – Fuel Inventory management
Figure 18 Activity Diagram – Fuel Inventory management
Receive Inventory Update
 Receive an update from the fuel delivery team on the quantity of fuel delivered to
the distribution center.
 Verify that the update includes accurate information on the type and quantity of
fuel delivered.
 Enter the update into the inventory management system.
Verify Update
55
 Check the inventory levels in the distribution center before and after the fuel
delivery to verify that the update is accurate.
 Check for any discrepancies or errors in the update and reconcile as necessary.
 Check the fuel quality to ensure that it meets regulatory requirements.
Update Inventory
 Update the inventory levels in the distribution center to reflect the fuel delivery.
 Update the inventory management system to reflect the new inventory levels.
 Ensure that the updated inventory levels are accurate and up-to-date.
Notify Management
 Notify the fuel management team of the updated inventory levels.

 Alert the team of any potential shortages or surpluses in fuel inventory.
 Provide recommendations on fuel procurement or distribution based on the
updated inventory levels.
56
Activity Diagram – Payment Process
Figure 19 Activity Diagram – Payment Process
Receive Payment Request
 Receive a payment request from the customer for the fuel ordered.
 Verify that the payment request includes accurate information on the customer's
details, the fuel ordered, and the payment amount.
 Enter the payment request into the payment processing system.
57
Verify Request
 Verify that the payment request is valid and meets the company's payment policy.
 Check for any discrepancies or errors in the payment request and reconcile as
necessary.
 Confirm that the customer has sufficient funds to complete the payment.
Process Payment
 Process the payment using the payment processing system.

 Verify that the payment has been successfully completed and the funds have been
transferred to the company's account.
 Update the payment status in the payment processing system.
Notify Customer
 Notify the customer that the payment has been processed and the fuel is ready for
pickup.
 Send an email or SMS notification to the customer with the payment confirmation
and instructions for fuel pickup.
Update Customer's Quota
 Update the customer's quota in the fuel request system to reflect the amount of
fuel paid for.
 Deduct the amount of fuel requested by the customer from the customer's weekly
quota.
 Update the fuel request system to indicate that the fuel has been allocated to the
customer.
58
3.6.3. Class Diagram
Figure 20 Class Diagram
3.6.4. ER Diagram
Figure 21 ER Diagram
59
3.6.4. Sequence Diagram
Figure 22 Sequence Diagram
60
State Diagram
In this state diagram, the Fueling system goes through different states based on the
actions performed by the end consumers and the system itself. Here is a brief explanation
of each state:
 Request New: This is the initial state where the end consumer requests fuel for
their vehicle.
 Token Issued (Valid): After the request is made, the system issues a valid token to
the end consumer with an expected filling time and date with 3 hours of tolerance.
 Payment Confirmed/Token Issued (Not Valid): Once the delivery schedule to the
given filling station is confirmed, the system sends a notification SMS/email to all
token holders to make the payment. If the customer fails to make the payment and
obtain fuel, the token becomes invalid.
61
 Fuel Dispensed/Token Cancelled (Not Valid): If the end consumer successfully
makes the payment, the fuel is dispensed, and the token becomes invalid.
However, if the end consumer fails to collect fuel or cancels the token, the token
becomes invalid.
 Expired (Not Valid): If the token's expected filling time and date have passed or
the delivery could not be made, the token becomes invalid. The end consumer
needs to request a new token to receive fuel.
These states show the life cycle of a token in the Fueling Online Fuel Requesting and
Queue Management System.
4.0. Requirements Specification
4.1. Functional Requirements

4.1.1. Functional Requirements for users
Table 2: User Functional Requirements
Function Conditions Process

Sign up with FuelIn  User should  When you provide your NIC,
Fuel and queue access the mobile number, name, and
management system FuelIn address and complete the
Company form, the system will generate
website with an OTP code for you. After
their own car or entering the OTP code, the
vehicles. user must permit updating of
the vehicle's information
(vehicle number and chassis
number)
 If an invalid NIC or mobile
number is entered, the device
will display an error message.
 Moreover, numerous
62
registrations for the same
vehicle number should be
avoided, however
registrations for the same NIC
or mobile number are
permitted.
 According to the
aforementioned
circumstances, an information
message should appear.
 An appropriate fuel quota
should be given to the
customer.
Login/Logout  User must be  The user is directed to the
registered with home page if their username
the FuelIn and password match their
business. registered user account.
 The user's car  If the username and password
ought to be are wrong, a "Invalid
registered with Username & Password" error
a fuel quota. message will be displayed.
 Write username  According to the
and password. aforementioned
circumstances, an information
message should appear.
 User functionalities that are
pertinent should be turned on
Issue Token (online)  User must have  End-users are given tokens
logged in in to with estimated filling times
the system. and dates.
63
 User must have  Tokens are only issued for the
enter their number of liters specified for
vehicle details delivery.
to the system
Request Token  The user must  The user should be able to

be logged into enter the necessary fuel
the system. allotment in liters, the
 Username and necessary price, and the
password must necessary option to reserve
be valid the desired date and time
 The user should frame.
be able to
choose the  Customers can request a
closest filling token with an expected filling
station, a date in time and date with a tolerance
a specific week, of three hours. A new
and an available scheduled period will be
time period. provided to the customer if
the fuel distribution cannot be
made available.
 Only amounts less than or

equal to the applicable fuel
quota may be entered by the
user. If the sum is exceeded,
an error message is displayed.
This ought to hold true
regardless of the price
entered.
64
 End users will receive an
email or SMS reminder with
the requested amount 12
hours before the delivery
occurs at the filling station.
 Every week, a new quota is

given to each vehicle.
 In accordance with these

circumstances, informational
messages should appear.
 For the chosen fueling station,

a token id should be produced
and the appropriate
notification should be sent.
Check token status  The user must  The ability for the user to
have been view the pertinent token
logged into the status and details should exist.
program.
 Tokens created
previously
ought to be
accessible.
Make Payments  The user needs  If using a credit or debit card,
to sign into the the user must provide those
system. details and the appropriate
65
 Tokens created payment.
previously
ought to be  Considering the
accessible. circumstances, informational
 The system messages should appear.
should allow
the user to  The creation of a payment ID
choose the and the transmission of
appropriate pertinent notifications for the
token before chosen filling station are
displaying the required.
appropriate
amount. User
ought to be able
to choose
payment
method.
Cancel payment.  The user needs  Considering the
to sign into the circumstances, informational
system. messages should appear.
 Tokens created  The payment id should be
previously canceled, and the chosen
ought to be filling station should receive
accessible. the appropriate notification.
 The user should
be able to
choose the
appropriate
payment ID and
cancel.
Check History  The user must  The user should be able to
66
have logged view the history of all the
into the system. requested tokens with detials.
 Tokens that
have already
been produced
should be
available.
4.1.2. Functional Requirements for Fuel Station

Table 3: Fuel Station Functional Requirements

Register Fuel  The user should  If an invalid NIC is entered, the
Station go to the FuelIn mobile device displays the error
Company message Invalid NIC, Mobile
website. number.
 Submit the  Several registrations per NIC
record after number are not prohibited. Also,
entering the registration for the same BRN
BRN, NIC, number should be prohibited.
Mobile Number,  After the FuelIn company has
Station Name, approved the request, the status
and Address. should be changed.
 According to the given conditions,
an information message should
appear.
 A registration id must be created.
67
Login/Logout  The user must  If the username and password
have registered match a registered user account,
with the FuelIn the user is directed to the home
System page.
 Enter username  If the username and password are
and password. incorrect, the error message
"Invalid Username & Password" is
displayed.
an information message should
appear.
 Appropriate user functions should
be enabled.
Request Fuel  The user must  Request Succeed should appear as
have logged into an information message.
the system.  Should generate a Request id and
 Choose the Fuel send the required request message
station to the FuelIn company.
registration id,
the fuel type, the
needed liter
quantity, the
required date,
and save the
request.
View Fuel  The user must  Fuel request details should appear
Requests have logged into according to request ID
the system.
 Check the status
of the fuel
68
Request Id.
Make  The user must  Once the dispatch office in the
Payments have logged into head office has confirmed the
the system. delivery schedule to the given
 Fuel requests filling station, a notice SMS/email
that have already will be sent to all token holders to
been created make the payment.
should be
available.  The user should be able to select
the appropriate Fuel request Id,
and the system should display the
appropriate amount. The user
should be able to choose a
payment method.
 If the payment method is a credit
card, the user must input the card
information and pay the applicable
amount.
information messages should
appear.
 Payment ids should be generated,
and the FuelIn company should be
notified.
Check fuel  The user must  The user should be able to
stock have logged into examine the relevant stock status
availability the system. as well as the available fuel stock
 Option to check in the fuel station.
the stock
availability.
69
Fuel Issue  The user must  fuel station manager can update
have logged into the requested fuel amount to the
the system. relevant tokens after verifying the
 Tokens that have vehicle details and quota.
already been  Just the specified amount of fuel
requested should can be issued by the fuel station.
be available. The applicable vehicle type fuel
 The fuel station quota cannot be exceeded.
manager can  If there is no scheduled delivery to
access all token a certain filling station or if the
details relevant scheduled fuel stock is depleted,
to the fuel station the necessary message should be
and filter provided to specific token holders.
payment  Fuel station tokens are only
completed provided for the scheduled
tokens. delivery number of liters; non-
committed or unpaid fuel
inventories might be made
available to request on demand
after the scheduled payment time,
and those tokens are issued for
same-day collection.
information messages should
appear.
 Token status should be updated,
and fully issued tokens should be
deleted from the pending list.
Check History  The user must  The fuel station manager has
have logged into access to all transaction history
70
the system. records pertaining to the fuel
station.
View Reports  The user must  The fuel station manager has
have logged into access to all fuel station reports.
the system. Payment reports and sales reports,
for example.
4.1.3. Functional Requirements for FuelIn Company

Table 4: FuelIn Company Functional Requirements

Login  A user account is  The user is directed
required. to the home page if
 Enter, username their username and
and password. password match
their registered user
account.
 If the username and
password are
wrong, a "Invalid
Username &
Password" error
message will be
displayed.
 According to the
aforementioned
circumstances, an
information
message should
71
appear.
 User functionalities
that are pertinent
should be turned on
View registered and  The user needs to  The administrator
registration pending fuel log into the system. of FuelIn has access
station list  Registered Fuel to the registration
stations. status of each fuel
station.
 Moreover, a FuelIn
user may accept or
reject a registration
request.
 After approval or
rejection, pertinent
information
messages should
appear, and the
appropriate fuel
station should be
notified.
 The registration list
needs updating.
72
Remove fuel station. The user needs to log into  The administrator
the system. of FuelIn has access
Registered fuel stations. to all the
information about
registered Fuel
stations and the
choice to delete
them.
 Pop-up
notifications with
pertinent
information should
be sent to the
appropriate Fuel
station.
 A registration list
update is required.
Check Fuel Request  The user needs to  The fuel that has
log into the system. already been
requested ought
should be available.
 Users of FuelIn can
examine the entire
list of fuel requests.
Manage Fuel Requests  The user needs to  Users of FuelIn can
sign into the examine the entire
system. list of fuel requests.
 Previously And the request can
requested fuel be accepted or
requests should be rejected by a FuelIn
accessible. user. The
73
appropriate Fuel
station should
receive notified if
the request is
rejected.
 Also, there should

be a choice to
prioritize the
request based on
the order of the
request, and Fuel
inventories should
be dispersed based
on population
density in the
vicinity of filling
stations.
 If the request is
approved,
notification should
be sent to the gas
station for payment.
 A fuel delivery
schedule should be
created using the
criteria.
 The required Fuel
amount should be
74
equal to or less than
the stock of fuel
that is already
available.
Issue Fuel Stocks  The user needs to  After the requests
sign into the are prioritized,
system. users of FuelIn can
 Previously choose the requests
requested fuel for which the
requests should be payment has been
accessible. made in full.
 To display the Fuel
stock that is
available, choose
that option. It is
possible to update
the desired fuel
amount to the
appropriate request
id after verifying
the pertinent
request details.
 The fuel station can
only supply the
specified amount of
fuel. cannot be
greater than the
requested quantity.
 The necessary
notice should be
provided for a
75
specific filling
station if there is no
scheduled delivery
to that station or the
scheduled fuel
stock has run out.
 Fuel is only
supplied for the
number of liters of
scheduled delivery;
however, after the
specified payment
time, non-
committed or
unpaid fuel supplies
may be made
accessible upon
request.
Check payments  The user needs to Users of FuelIn can
sign into the examine all the payment
system. information for the fuel
 Previously request list.
requested fuel
requests should be
accessible.
View reports  The user needs to  Users of FuelIn get

log into the system. access to all reports
related to Fuel
stations. Reports on
stock data and
76
sales.
Add main Data  The user needs to  All key details can
log into the system. be added by the
FuelIn Admin.
Update information
about fuel prices,
such as fuel type.
 In the context of
these
circumstances,
informational
messages should
appear.
 Update the relevant
key data list.
Add Users  The admin user  The system allows
needs to log into the FuelIn Admin
the system to Add, Modify,
and Set Permissions
for the appropriate
Users.
 In light of the
aforementioned
circumstances,
informational
messages should
appear.
 Update the list of
pertinent info.
77
4.2. Non-Functional Requirements
Usability Requirements
The system should be user-friendly, simple to understand, and straightforward to use.

This is significant since FuelIn will be used by a diverse group of people, including fuel
station attendants, managers, and government officials. Usability standards ensure that
the system is simple to use and error-free, resulting in increased productivity and user
satisfaction.
Ex-
 The system should have a user-friendly interface that is simple to navigate and
utilize for both staff and customers.
 System should have different logins for Customers and Fuel stations.
Performance Requirements
The system must function efficiently and effectively. This is critical because FuelIn will
process a considerable quantity of data related to fuel distribution and monitoring, and it
is critical that the system can manage big amounts of data without slowing down or
crashing. The system's performance criteria ensure that it can meet the demands of its
users.
Ex-
 During peak hours, the system should be able to manage a high volume of fuel
transactions without any delays or system crashes.
 To avoid overstocking or understocking of Fuel, the system should offer real-time
data on inventory levels and use.
Space Requirements
The system should be built to make the most use of the available space. This is
significant since Sri Lankan fuel stations may have limited space for new equipment.
78
Space constraints guarantee that the system is designed to fit within the given area while
not interfering with other operations or equipment in the fuel station.
Ex-
 The system should be built to fit into the restricted area available at Fuel stations,
which are frequently small and cramped.
 Because petrol stations have limited space for equipment, the system should not
take up too much physical area.
Dependability Requirements
The system must be always dependable and accessible. This is critical since any
downtime or system failure can interrupt fuel delivery and monitoring, resulting in fuel
shortages and other problems. Dependability criteria ensure that the system is built to be
dependable, resilient, and accessible to its users.
Ex-
 Because Fuel stations are open 24 hours a day, the system should be always
available.
 Backup power sources should be installed in the system to ensure service
continuity during power outages.
Security Requirements
The system should be secure and safeguard vital fuel distribution and monitoring data.
This is critical since any security breach can result in major consequences such as fuel
theft, fraudulent operations, or disruption of fuel distribution. Security requirements
ensure that the system is secure and that suitable safeguards are in place to prevent
unauthorized access or data breaches.
Ex-
79
 To prevent unwanted access to the system, the system should have strong
authentication and authorization methods.
 To protect sensitive client information, the system should encrypt all data
transmissions.
Operational Requirements
The system should be simple to use and maintain. This is significant since FuelIn will be
utilized by fuel station employees and managers who may lack extensive technical
knowledge. Operational requirements guarantee that the system is simple to use, with
clear instructions and support materials.
Ex-
 The system should be simple to install and maintain, with little downtime for Fuel
stations.
 The system should work with existing Fuel station equipment, such as pumps and
fuel storage tanks.
Development Requirements
The system's architecture should be flexible and scalable, making it simple to add new
features or scale up as needed. This is significant because FuelIn may require evolution
over time to satisfy changing demands or requirements. The requirements for
development ensure that the system is built to be flexible and adaptable, with a modular
architecture that can allow future adjustments or enhancements.
Ex-
 To ensure future growth and expansion, the system should be constructed with
dependable and scalable technologies.
 To ensure quality and maintainability, the system should adhere to established
development processes and best practices.
Regulatory Requirements
80
The system must adhere to all applicable laws and regulations governing fuel delivery
and monitoring. This is significant since noncompliance can result in legal and financial
consequences. Regulatory requirements guarantee that the system is built to be in
accordance with applicable rules and regulations, and that suitable controls are in place to
assure compliance.
Ex-
 The system must adhere to all applicable laws and regulations governing the sale
and distribution of fuel.
 The system should provide regulatory authorities with reliable and timely data for
monitoring and compliance purposes.
Legislative Requirements
All statutory criteria for fuel distribution and monitoring should be met by the system.
This is significant since noncompliance can result in legal and financial consequences.
Legislative mandates ensure that the system is built to last.
Ex-
 The system should adhere to all applicable data privacy and security legislation.
 For legal and accounting considerations, the system should keep precise records
of all fuel transactions.
5.0. Implementation
5.1. Software Tools and Technologies
Many software tools and technologies can be utilized to create the FuelIn Online Fuel
Requesting and Queue Management System. Some of them are:
 Programming Languages: Depending on the developer's experience and the

project's requirements, the system can be implemented in a variety of
programming languages such as Java, Python, PHP, and.NET.
81
 Web Development Frameworks: The use of web development frameworks such
as Angular, React, and Vue.js can help to streamline and improve the
development process.
 Relational Database Management Systems (RDBMS): To store and manage the
system's data, a relational database management system (RDBMS) such as
MySQL, Oracle, or SQL Server can be utilized.
 Web servers, such as Apache or Nginx, can be used to host the web application
and serve user requests.
 Version Control Systems: A version control system, such as Git, can be used to
manage and track changes to source code.
 Integrated Development Environments (IDEs): IDEs such as Eclipse, NetBeans,
and Visual Studio can offer a full development environment for developing,
testing, and deploying the system.
These are only a handful of the software tools and technologies that can be utilized to
create the Online Fuel Requesting and Queue Management System. The specific tools
and technologies selected will be determined by the project's requirements, the
competence of the development team, and other variables such as budget and time
restrictions.
5.1.1 Justification about System Tools and Technology

The software tools and technologies PHP, HTML, Bootstrap, and CSS are perfect for
developing the Online Fuel Requesting and Queue Management System. The web server
and client application that will communicate with the database will be built using PHP, a
server-side scripting language. The principal markup language used to structure and
convey the system's content, on the other hand, is HTML. It will be used to generate web
pages with which end users will interact.
Bootstrap is a CSS framework that includes a number of tools for creating responsive and
mobile-first websites. It will be used to design a user-friendly and visually appealing
system interface.
82
The MySQL database management system will be used to create an online fuel request
and queue management system. MySQL is a free and open-source relational database
management system that offers a scalable and dependable solution for data storage and
management. It is great for online applications because it can efficiently handle high-
volume, complicated queries and transactions.
The system can use MySQL to store and handle client information, fuel requests, and
queue management data. Tables for fuel station details, fuel requests, tokens, and client
information can be added to the database. MySQL has capabilities like data encryption,
replication, and backup to ensure data integrity and security.
Additionally, PHP integrates well with MySQL and provides significant tools for
accessing and modifying MySQL databases. Developers may quickly connect to the
MySQL database, retrieve and change data, and run complicated queries using PHP.
Furthermore, Bootstrap and CSS make it simple to develop a user experience that is
responsive, assuring excellent performance on both desktop and mobile devices. Overall,
the combination of PHP, HTML, Bootstrap, CSS, and MySQL results in a strong and
effective solution for constructing the Online Fuel Requesting and Queue Management
System.
5.2. Implementation Environment

The implementation environment for the Online Fuel Requesting and Queue
Management System would be determined by several factors, including the system's
specific hardware and software needs, the availability of resources, and the money
allowed for implementation.
Preferably, the system can be implemented on a web server with the necessary hardware
and software configurations to handle the development technologies PHP, HTML,
Bootstrap, CSS, and MySQL. Also, the server needs to have enough storage space to hold
the system's database and application code.
In terms of software, the server should have Apache or Nginx web server software, a
PHP interpreter, a MySQL server, and an operating system such as Linux or Windows.
83
Ultimately, the implementation environment should be built to provide a stable and
secure platform for the system to run efficiently and effectively, guaranteeing that end
users can access the system with no downtime or performance issues.
5.1.1 Hardware Implementation

Here are the hardware Implementations that needed for Run the fuel requesting and
queue management system.
For the server system
The ideal server hardware requirements for managing the predicted workload of the
FuelIn fuel management and queue management system would be:
 Processor: A multi-core Intel Xeon or AMD Ryzen CPU with a high clock speed.
 Memory: At least 16GB of RAM is required to ensure smooth functioning and the
handling of multiple requests at the same time.
 Storage: SSD-based storage with at least 100GB free space for system files and
databases.
 Network: Gigabit Ethernet or higher is recommended for quick data transfer
between the server and clients.
 Power: An uninterruptible power supply (UPS) is required to ensure that the
server continues to operate during power outages or surges.
It should be noted that the hardware requirements may vary depending on the estimated
workload, number of concurrent users, and other considerations.
For customers
The minimum hardware requirements for a computer to execute a web-based application

smoothly are as follows:
 Intel Core i3 or comparable processor

 RAM: 4GB or more
 128GB SSD or greater storage
 Display resolution of 1366x768 or higher
84
 Ethernet port or Wi-Fi access to the network
Browser: Google Chrome, Mozilla Firefox, or Microsoft Edge (latest version).
It should be noted that these are the bare minimums, and the actual hardware required
may vary depending on the specific software and system requirements.
Mobile versions
The following mobile hardware characteristics would be ideal:
 iOS 13 or later is required for iPhones and iPads; Android 10 or later is required
for Android phones and tablets.
 Processor: A dual-core 1.2 GHz CPU is required for iPhones and Android phones,
and a quad-core 1.5 GHz CPU is required for iPads and Android tablets.
 RAM: iPhones and Android phones must have at least 2GB of RAM; iPads and
Android tablets must have at least 3GB of RAM.
 Storage: iPhones and Android phones must have at least 16GB of internal storage;
iPads and Android tablets must have at least 32GB of internal storage.
 Display: At least 4.7-inch HD display with 720 x 1280 pixel resolution for
iPhones and Android phones; at least 8-inch Full HD display with 1200 x 1920
pixel resolution for iPads and Android tablets
 Wi-Fi or cellular data connectivity with at least 3G or 4G/LTE speed is required
for reliable network connectivity.
It's crucial to note that these are basic hardware requirements, and the precise hardware
required to run the FuelIn system's mobile app may vary based on the complexity and
feature needs of the FuelIn system's mobile app.
5.1.2 Software Implementation

The Agile Software Development Life Cycle (SDLC) approach will be used to construct
the FuelIn fuel management and queue management system, which allows for flexibility
and adaptability to changing requirements. The data storage application will be designed
with a MySQL server database and developed with PHP, bootstrap, and JavaScript. A
JDBC connection will be used to connect to the database.
85
The server will require the following things:
 Domain
 SSL digital certificate to ensure website data protection and security.
 an appropriate server operating system, such as Windows Server or Linux.
 Web server software (for example, Apache or Nginx), database software (for
example, MySQL), and computer language runtime environment (e.g. Node.js).
5.2. Module Structure

The organization and arrangement of software components or modules that comprise a
system is referred to as module structure. The FuelIn fuel management and queue
management system's module structure may include the following modules:
 Authentication Module: This module handles user authentication and

authorization to access the system. It has features including user registration,
login, password management, and access control. This module ensures that only
authorized users have access to the system and that their data is protected.
 Fuel Management Module: This module handles fuel inventory and transactions.
Fuel delivery scheduling, Fuel level monitoring, fuel quality control, and fuel
purchase management are among the features. This module manages the Fuel
inventory in an efficient and precise manner.
 Queue Management Module: This module manages the queue of vehicles waiting
to be fueled. It has features including queue management, fuel dispensing
management, and customer notification management. This module guarantees that
the fuelIn’s process is streamlined and that clients are properly served.
86
 Payment Module: This module oversees processing payments for Fuel purchases.
It has features like payment gateway connection, invoice generation, and payment
tracking. This module makes certain that the payment procedure is safe and clear.
 Reports Module: This module generates reports for fuel inventory, transactions,
and revenue. It contains features like report preparation, data analysis, and
visualization. This module assists in making informed judgments about fuel
management and business operations.
 Notification Module: This module is responsible for sending notifications to

consumers and administrators. It offers features including SMS and email
notifications, as well as real-time alerts. This module guarantees that consumers
are notified of their fueling status and that administrators are informed of system
events.
 Admin Module: This module is responsible for system configuration and user
management. It has features including system settings management, user
administration, and system backup management. This module guarantees that the
system is correctly configured and that users are managed efficiently.
 Integration Module: This module handles the system's integration with various
external systems such as payment gateways, customer databases, and fuel quality
sensors. It contains features like data mapping, API integration, and system
testing. This module ensures that the system is compatible with other systems and
that data may be exchanged in real time.
87
Overall, FuelIn's fuel management and queue management system's modular structure is
intended to cover all areas of fuel management and customer service, from fuel inventory
management to payment processing and reporting.
5.3. Important Codes
Figure 23 Important Code 1
88
89
90
Database
Figure 28 Database table 1
91
Figure 29 Database Table 2
6.0. Testing
6.1. System Test plan

Testing
The testing phase of the software development lifecycle is critical to ensure that the
software meets the desired requirements and functions as expected. It involves a thorough
investigation and discovery process to identify any issues or bugs in the code and
programming. The project team develops a test plan outlining all the necessary testing
methods, including unit, integration, system, acceptance, and regression. Each of these
testing methods is conducted in a specific order to ensure that the software is thoroughly
tested and meets the required standards.
The testing phase is an iterative process, meaning that any issues or bugs discovered
during testing are addressed, and the testing process is repeated until the software meets
all the required standards. The development team can ensure that the software meets the
92
customer's requirements and delivers value to the end users by conducting thorough
testing. Overall, the testing phase is a crucial step in the SDLC that ensures the quality
and reliability of the software.
Figure 30 Testing
System Test plan
The FuelIn Online Fuel Requesting System is a new platform designed to manage and
distribute fuel supplies to registered fuel stations across Sri Lanka. The system allows
end-users to request fuel based on the quota given for the vehicle registration number and
obtain a token with an expected filling time and date with a 3-hour tolerance. This test
plan aims to ensure that the system is functional, secure, and user-friendly by testing
various components such as user authentication, fuel requesting, payment processing,
filling station management, user notifications, security, compatibility, and performance.
By conducting these tests, we aim to identify and resolve any issues that may impact the
system's functionality, security, or user experience, ensuring that FuelIn can provide a
reliable and efficient fuel distribution service to its customers.
1. System Testing
 Test functional and non-functional requirements.
 Conduct parallel requests and load testing to ensure the system can handle
high traffic.
 Verify system can generate tokens with expected filling time and date,
with 3-hour tolerance.
93
 Customers should be prevented from requesting fuel if there is no planned
supply or if the stock of fuel is insufficient.
 As soon as the distribution schedule is set, confirm that token holders are
notified through SMS or email.
 If the customer cannot pay and take fuel, verify that the quota is over.
2. User Acceptance Testing (Beta)
 Get feedback on the system's UI and UX from end users by asking them to
test it out.
 To make sure that the system is usable by everyone, test it with a wide
range of users.
 Check that fuel can be ordered by end users based on the allotted amount
for the vehicle's number plate.
 Test that when scheduled delivery is possible, end customers can get a
token from the filling station using the same system.
94
3. Payment Processing Testing
 Test the payment processing system to make sure it is safe and capable of
accepting various payment methods.
4. Security Testing
 Verify that user data is encrypted and securely stored.
 Check the system for any potential security flaws, such as cross-site
scripting, and SQL injection.
 Verify that only individuals with permission can access sensitive
information, such as payment details.
5. Filling Station Management Testing
 Test the system's ability to handle filling station orders individually and
distribute fuel stocks in accordance with the population nearby the filling
station.
6. Compatibility Testing
 Check the system's compatibility with various browsers, operating
systems, and devices.
 Verify that the system can accommodate different screen resolutions and
device orientations.
7. Performance Testing
 Analyze the system's response time under various user and network
conditions.
 Check to see if the system can handle high levels of web traffic
95
6.2. Test Cases and Results
Figure 31 Test Cases And Results 1
Figure 32 Test Cases And Results 2
96
Figure 33 Test Cases and Results 3
Figure 34 Test Cases and Results 4
97
Figure 35 Test Case and Results 5
98
7.0. Conclusion
The fuel management and queue management system from FuelIn is a crucial tool for oil
firms like FuelIn to organize their fuelling processes, boost productivity, and shorten
client wait times. The system has a number of modules, including ones for managing
fuel, lines, payments, and reporting in real-time. It is significant to remember that
fulfilling non-functional needs, such as usability, performance, security, and regulatory
compliance, is essential to the system's success. The specific software and hardware
requirements have already been specified, and the feasibility studies have demonstrated
that FuelIn is qualified to build this system. In order to identify potential objects, data,
and file structures for system designing, a module structure has been proposed.
Customers, gasoline attendants, supervisors, and the FuelIn system itself all interact
within the system. Overall, FuelIn's fuel management and queue management system
installation will improve their business operations, raise customer satisfaction,
and boost earnings.
99
References
syedmodassirali, 2022. geeksforgeeks.org. [Online]
Available at: https://www.geeksforgeeks.org/client-server-model/
[Accessed 24 02 2023].
100
Appendix
Figure 36 Home page
Figure 37 Lubricants
101
Figure 38 Unlimited Services
Figure 39 Edit Order
102
Figure 40 Manage Invoices
Figure 41 B/W Dates Report Form
103
Figure 42 Sales report
104
Group Contribution
Table 5 Group Contribution
LMU ID Student Name Contributions

22060563 G H Nipuna Kusal Sraweera Role: BA/Lead
Contributions
o Document Formatting
o Introduction
o Functional, nonfunctional
Requirements
o Overall Description
o System Architecture
o Requirement Specification
o Implementation
o Software Development
Dilusha Nipun Keerthirathne o UI/UX designing.

o Document Formatting
o Backend software development
o System Testing
o Software Integration
o Database Designing
o Testcases designing
22059314 Ravichandran Shathis o Diagram Design
o Origination Structure
o Architecture Design
Documentation
o Software development
o Software testing
105
22059307 K A Deshan o Frontend development
Sachintha Kannangara o System Testing
o Test plan designing
o Document editing
o UI/UX designing.
o Database Designing
106

CS6003ES Advanced Software Engineering: London Metropolitan University, Faculty of Computing

Uploaded by

Copyright:

Available Formats

You might also like

CS6003ES Advanced Software Engineering: London Metropolitan University, Faculty of Computing

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CS6003ES Advanced Software Engineering: London Metropolitan University, Faculty of Computing

Uploaded by

Copyright:

Available Formats

London Metropolitan University, Faculty of Computing

CS6003ES Advanced Software Engineering

Module Leader: Dr. Lochandaka Ranathunga

Part 1 weighting: 30% in total

GROUP STUDENT ID NUMBERS: __________________________________

Submission deadline: 1ST of March 2023

Extracts from University: Regulations on Cheating, Plagiarism and Collusion

(i) Cheating: including taking unauthorized material into an examination; consulting

(ii) Falsifying data in experimental results.

(iv) Bribery or attempted bribery of a person thought to have some influence

(vii) Other conduct calculated to secure an advantage on assessment.

(viii) Assisting in any of the above.

Some notes on what this means for students:

SUBMISSION DEADLINE: 1ST of March 2023

1. Description and requirements:

You are required using an appropriate approach to analyse, design,

1. System has two components

a. Web server with the database.

b. Client web Application with the Database Server.

2. Software requirements specification should clearly indicate the Potential

Over all report including report title, abstract,

System architecture design

Functional, non-functional, etc

Use of UML, OOAD, etc.

Use any programming/ DB / web language of your

Software-testing design (With Test cases), test

THIS COURSEWORK HAS TO BE COMPLETED IN GROUPS OF THREE TO FOUR STUDENTS.

Part 1 weighting: 30% in total.................................................................................................1

GROUP STUDENT ID NUMBERS: __________________________________..........................1

1.3. Intended Audience and Reading Suggestions....................................................................11

1.4. Project Scope and Objectives.............................................................................................12

1.4.1. Project Scope..................................................................................................................12

1.6. Overview of the Existing Fuel Requesting System............................................................13

1.6. Drawbacks of the Existing System....................................................................................14

1.7. Future Enhancements.........................................................................................................15

2.0. Overall Description................................................................................................................15

2.1. Product Perspective............................................................................................................15

2.2. Product Features................................................................................................................16

2.3. User Classes and Characteristics........................................................................................18

2.4. Feasibility Study................................................................................................................20

2.5. Requirement Collection.....................................................................................................22

2.5.1. Requirement Gathering Techniques............................................................................22

2.5.2. Justification for requirement gathering.......................................................................23

2.6. Operating Environment......................................................................................................26

2.8. User Documentations.........................................................................................................28

2.9. Assumptions and Dependencies.........................................................................................28

2.10. Maintenance of the system...............................................................................................29

3.0. System Architecture and Design............................................................................................31

3.1. Architecture Design..........................................................................................................31

3.2. High Level System Architecture........................................................................................32

3.3. User Interface Design........................................................................................................32

3.3.1. Data Input Design.......................................................................................................32

3.3.2. Data Output Design.....................................................................................................32

3.4. Identify the Objects, Data and File Structures....................................................................33

3.5. System Components and Interactions................................................................................33

3.6. UML Diagrams..................................................................................................................33

3.6.1. Use Case Diagram......................................................................................................33

3.6.2. Activity Diagram........................................................................................................33