Software Requirements
Specification
for
Bus Karaao Bus Management/Reservation
System
Version 1.1
Prepared by:
Muhammad Farzam Ali Khan (SE-21086)
Muhammad Zeeshan Akram (SE-21097)
Date: 22-12-2022
Table of Contents
Table of Contents .......................................................................................................................... ii
Revision History ............................................................................................................................ ii
1. Introduction ..............................................................................................................................3
1.1
1.2
1.3
1.4
1.5
Purpose ............................................................................................................................................ 3
Document Conventions.................................................................................................................... 3
Intended Audience and Reading Suggestions .................................................................................. 3
Product Scope .................................................................................................................................. 3
References........................................................................................................................................ 3
2. Overall Description ..................................................................................................................4
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Product Perspective ......................................................................................................................... 4
Product Functions ................................................................ Ошибка! Закладка не определена.
User Classes and Characteristics ..................................................................................................... 5
Operating Environment.................................................................................................................... 8
Design and Implementation Constraints .............................. Ошибка! Закладка не определена.
User Documentation ............................................................ Ошибка! Закладка не определена.
Assumptions and Dependencies ...................................................................................................... 9
3. External Interface Requirements ...........................................................................................9
3.1
3.2
3.3
3.4
User Interfaces ................................................................................................................................. 9
Hardware Interfaces ....................................................................................................................... 10
Software Interfaces ........................................................................................................................ 10
Communications Interfaces ................................................. Ошибка! Закладка не определена.
4. System Features......................................................................................................................10
4.1 System Feature 1 ............................................................................................................................ 10
4.2 System Feature 2 (and so on) ............................................... Ошибка! Закладка не определена.
5. Other Nonfunctional Requirements .......................................................................................1
5.1
5.2
5.3
5.4
5.5
Performance Requirements .............................................................................................................. 1
Safety Requirements ........................................................................................................................ 1
Security Requirements ..................................................................................................................... 2
Software Quality Attributes ............................................................................................................. 2
Business Rules ................................................................................................................................. 3
6. Other Requirements ................................................................................................................3
Appendix A: Glossary....................................................................................................................3
Appendix B: Analysis Models .......................................................................................................3
Appendix C: To Be Determined List ............................................................................................3
Revision History
Name
Date
Reason For Changes
Version
BusKaraao_v1.0
BusKaraao_v1.1
17/12/2022
23/12/2022
Initial document made with all requirements
Added activity & use case diagrams
1.0
1.1
Page |3
1. Introduction
1.1 Purpose
The root cause for drafting this document is to elaborate the behavior of ‘Bus Karaao’, an
application/web based, bus reservation & management system which will be operated city-to-city
across the country through a fleet of buses and cabs. It will use Google Maps to keep track of each
terminal, as well as passengers checking in and out, traffic, and anticipated travel time to the terminal.
Users of ‘Bus Karaao’ will have access to a map, allowing them to keep track of where the bus is
going. Cashless payments via mobile banking applications, VISA, MasterCard, PayPak, Gold, Silver,
and Platinum Cards will also be accepted.
The system will also feature a captain mode, which will contain records of pre-registered passengers,
their contact information, and boarding passes, as well as their check-in and check-out
stations/terminals, and will be accessible only by authorized captains.
An Administrative subsystem will also be a part of the system which will manage the users, captains,
buses, cabs and all the related functionalities of the system.
1.2 Document Conventions
The following conventions are used in the document:
SRS
SDLC
GPS
OTP
SMS
PIN
Software Requirement Specification
Software Development Life Cycle
Global Positioning System
One Time Password
Short Message Service
Personal Identification Number
1.3 Intended Audience and Reading Suggestions
The intended audience for this this system include:
Travelers/Passengers within Karachi and other Pakistani cities seeking for a relaxing interstate bus
journey are encouraged to use the general user platform of the system.
Experienced Bus/Cab Drivers are going to use the driver platform to manage their journey.
Qualified System Administrators will be using the admin platform to monitor and manage the
whole system.
Page |4
1.4 Product Scope
Today, time is more valuable than anything else. We need to cut our time wastage by more than 70%,
reduce bus reservation waiting time and the possibility of seats being unavailable, and follow on
through our commitments to fulfil our objectives as we move towards a digital Pakistan.
This bus management/reservation software system will consist of a website and mobile application
that allows users to make advance reservations and receive notifications about upcoming rides,
including the bus registration number, captain's name, contact information, and the bus boarding pass
number. The system will facilitate users to follow the bus's whereabouts and assess the journey, bus,
timeliness, captain, and other factors after checking out. Individuals who book seats using the app
will be offered an optional paid (minimum) cab service that will travel across the city, picking up
customers from their homes and dropping them off at the terminal. Furthermore, application users
will be able to add a beverage to their transport for a little fee in order to make the travel a bit
smoother and more dependable.
System will also contain captain(drivers) and administrator modes. Captains will be able to manage
everything related to the bus while administrator will manage the whole system and makes sure it is
running correctly. The system also contains a relational database containing a list of bus schedules
and related information.
2. Overall Description
2.1 Product Perspective
“Bus Karaao” is a self-contained system that manages numerous elements of travel, including
passenger and bus captain information, as well as all bus routes. Various stakeholders are involved in
this bus reservation system.
When accessing the system for the first time, the users (passenger, captain) would register.
1.
Passenger (User):
 The user must log into the system before using it.
 The user must specify the pick-up and drop-off locations of his trip as well as the
kind, such as business class or economical, to schedule a ride.
 Following that, the user will see a list of the buses that are scheduled for the
selected date and time.
 A chart showing the bus's occupied and available seats will be shown, allowing
users to choose the seat or seats of their choice.
 They can also reserve a cab to take them to and from the station to their destination.
 The user has the option to add-on services (food/beverages).
 The user will next navigate through several payment gateways to choose a payment
option and pay the total amount.
 After payment, the user will receive a message, acquire a digital ticket, and be able
to board the bus at the specified time and date.
 Through integrated Google Maps, the customer may track the bus path as well as
the cab before pick-up and till drop-off.
 The user has the right to cancel the ticket 24 hours prior to the bus arriving, and the
money will be credited back to the user's account following certain criteria.
 Customers are led to a review form after their ride to provide feedback and ratings.
Page |5
2.
Captain (User):
 The captain must log into the system before using it. (separate login app/webpage
for captains)
 Captain will be allowed to navigate between terminals and keep a check of who is
waiting and where.
 He will be able to find the nearest fuel stations and review the latest traffic
information.
 In the event of an emergency or arising queries, he will be permitted to get in touch
with the system administrator(s).
 It will be the captain's responsibility to check in at the terminal, wait for the
passengers for a little while, and then check out before departing.
3.
Admin:
 System will first request admin to login to admin account. (separate login
app/webpage for admins)
 System will enable admin to keep track of all bus drivers.
 They will be responsible for supervising all bus scheduling.
 Adding vehicles or drivers, generating reports.
 Revising and rescheduling day and night captain and ride shifts.
2.2 User Classes and Characteristics
Administrators, bus/cab drivers, and passengers will be the system's primary consumers and the three
classes within the system. The commuters will directly access the system and independently schedule
their journeys. With the adoption of an interactive Graphical User Interface (GUI), the system is also
made to be consumer-friendly, considering the fact that not every user is computer- proficient.
 Administrators:
Each administrator will have completed post-secondary business administration training. They
will be responsible for supervising all bus scheduling, verifying all registered users before
allowing them to log in, acknowledging any payments made on the system, adding vehicles or
drivers, generating reports, and revising and rescheduling day and night captain and ride
shifts, among other tasks.
 Passengers:
The passengers will schedule their journeys by reserving seats, ordering a cab to take them
from their home to the terminal, and adding some meals to their journey. However, this
obviously just needs a basic understanding of how computers and the internet work.
 Bus and Cab Drivers:
The authorized drivers will be able to check for reserved seats, accept or reject cab rides,
travel between terminals, pick up customers from wherever in the city, and drop them to the
bus terminal(s).
Page |6
Fig.1: Use Case for Administrator
Page |7
Passenger
Fig.2: Use Case for Passenger
Page |8
Driver
Fig.3: Use Case for Driver
2.3 Operating Environment
To design and implement a user interface React Native will be used. MySQL will be used as a
database to design and implement the necessary entities, tables and relations. Python programming
language will be used to connect database with user interface. Apart from that the system will have a
website able to run on any browser like Chrome. The system will also have android and iOS mobile
applications able to run on Android 8.1 and above or iOS 8 and above.
Page |9
2.4 Assumptions and Dependencies
 Existing third-party licensed login and signup panels can be incorporated and given minor
adjustments based on the specifications provided by the user.
 Self-collected databases will be maintained.
 It is anticipated that the administration section will have sufficient skilled officials to maintain
the system.
3. External Interface Requirements
3.1 User Interfaces
There will be 3 webpages/apps which will include a window asking to login as a passenger, driver
and admin respectively.
Passenger Login: Once the passenger logins as user with correct Id and password, a window will
display showing six options namely.
➢ Set Location: It will enable passenger to set their location through maps.
➢ Set Destination: It will enable passenger to set their destination through maps
➢ Ride (Confirm): To confirm the ride, payments and cab options will be displayed.
➢ View Map: It will enable passenger to view real time map with all terminals, buses and cabs
marked.
➢ Refunds: Show refunds requests history and allows users to request a refund on rides before
checking in.
➢ Feedback and Complaints: Option to send feedback and complaints to admins.
➢ Log Out: Passenger can Log out from the system.
Admin Login: Once the user logins as admin with correct Id and password, on the home page, the
administrator will see a total of five options: Databases, Ongoing Rides, Upcoming Rides, Feedback
and Complaints and Log Out.
➢ Databases: It will enable admin to monitor and edit databases of the system to make any changes
regarding rides.
➢ Ongoing Rides: Show on going rides in real time.
➢ Upcoming Rides: It will enable admin to view scheduled rides.
➢ Feedback and Complaints: Admin will be able to manage customer feedback and complaints
through this option.
➢ Contact Driver: Admin will be able to manage communication with drivers(captains).
➢ Log Out: Admin can Log out from the system.
Drivers (Captain) Login: One id and password for logging in the teacher website will be collectively
given
to all the students and all the students can login that ID. The website will contain the course
contents including course outline, lectures etc...
P a g e | 10
3.2 Hardware Interfaces
An internet connection is required for the application to run and connect to admin and system
database. The software requires network devices (routers, switches, LAN cables) and proper
LAN/WLAN connection to either mobile phones or laptop/desktops.
3.3 Software Interfaces
4. System Features
<This template illustrates organizing the functional requirements for the product by system features,
the major services provided by the product. You may prefer to organize this section by use case,
mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever
makes the most logical sense for your product.>
4.1 System Feature 1 - Monitoring and Management of the System – Admin Panel
4.1.1 Description and Priority
A smart strategy to determine how extensible and usable your system would be to set
up and monitor its most enlightening features using a dashboard. Using a modern
admin dashboard, the website or app owner can simply track buses and the
percentage of positive reviews they receive. Additionally, they can keep a check on
data like the top-rated captain(s), buses, etc. This functionality will be given top
importance because the system wouldn't be complete without the admin panel.
4.1.2 Response Sequence
 Admin would be required to enter his log in credentials on the admin log-in page.
 On the home page, the administrator will see a total of four options: Databases,
Ongoing Rides, Upcoming Rides, and Log Out.
 He will then be asked for selection.
 The administrator would get hyperlinks to all the databases (user, captain, cab
driver, buses, payments, feedbacks) after he clicks ‘Databases’.
 Each hyperlink would have a ‘View’ button next to it and clicking it would
bring up a tabular display of all the data from that database.
 Options like Edit, Add, and Delete would be available beneath the tabular data.
 The admin would navigate among the three and select one, as per the
requirement(s).
P a g e | 11
 The admin would locate the moving rides (on a map) and the corresponding ride
data by clicking on ‘Ongoing Rides’.
 By selecting ‘Upcoming Rides’, the administrator will see a list of the buses that
are scheduled for the day, along with trip information and timings.
4.1.3
Functional Requirements
A1 – The system shall incorporate mechanism to allow admin to authenticate its
users.
A2 – The system shall allow quick messages to be exchanged between the user and
admin without face-to-face interaction.
A3 – The system shall allow access to maps in admin’s device.
A4 – Availability of seats would be checked and displayed to user from within the
admin-accessible databases.
A5 – The admin would keep a check of the bookings being confirmed and the fare
being generated.
A6 – The admin would be authorized to receive payments and maintain a dedicated
record of payments.
A7 – The admin would be authorized to edit data from the databases.
A8 – The administrator would have rights to add records to the databases.
A9 – Reasonable record deletion from databases would be permitted for the admin.
A10 – The administrator will be able to monitor active rides and the people riding
in them.
A11 – Admin would be in charge of facilitating ride transfers and cancellations, as
well as the corresponding reimbursement claims.
P a g e | 12
4.1.4
Non-Functional Requirements
A12 – Each login attempt would verify the username and password entered, from
the system’s user database.
A13 – A functional live chat-box would be given to the user where he would reach
out the admin/representative team with his queries and problems.
A14 – The admin would click on "Allow Access” option to allow access to maps
application in his device, while using the system only.
A15 – Every time a passenger chooses a seat for a reservation, that seat's availability
is double-checked in the database.
A16 – The user will be informed, and the reservation will be validated after the
cross-checking is completed.
A17 – The validated reservation will proceed towards payment, while the
administrator will acknowledge the payments received against each reservation.
A18 – The admin would record the payments received and compute the net profit
by deducting the cost and service charges from the fare collected.
A19 – The administrator's system's cursor would become active, and editing would
be enabled after clicking the edit button on the presentation of tabular data from the
database.
A20 – For editing purposes, the administrator would go to the search bar and search
using the database's unique primary key, which would direct him to all the
corresponding fields where changes could be made.
A21 – On clicking the ‘Add’ button, the admin would be required to fill out all fields
in a particular database.
A22 – The admin would be able to delete some or all the fields for a certain entry
by selecting the ‘Delete’ button.
A23 – The integrated maps, which will show the instantaneous motion of buses
and their magnified registration number, would allow the admin to know the
whereabouts of each ongoing ride.
A24 – If a cancellation or transfer request is made more than 24 hours before the
ride is scheduled, the admin will accommodate it at no charge, and a full refund will
be added to the user account's wallet. Otherwise, a partial or no refund would be
given.
P a g e | 13
A25 – Likewise, reservations made within 24 hours of the ride's scheduled time will
be eligible for free cancellation or transfer for up to 3 hours of the booking time,
with no additional fees. The administrator will not consider any reimbursement
requests after three hours have passed.
4.2 System Feature 2 - Reservation – User Panel
4.2.1 Description and Priority
The steps to take after entering your login information to use the bus service and
make a reservation. This feature might be referred to as "high priority" because it
serves as one of the primary driving forces behind the application.
4.2.2 Response Sequence

The user will be asked to enable his GPS location.

The search interface opens after the user chooses "search for tickets" from the
application menu.

Users are instructed to submit information about their departure city, arrival city,
and trip date.

According to the user's inputs, the system returns a list of available buses from
which the user may select.

After selecting the bus, the user would be asked if he wants to avail the cab
service to the terminal.

The user would then have an option to choose the desired add-on
(food/beverage).
4.2.3 Functional Requirements
B1 – Access to user’s current location would be asked.
B 2 – Search option requesting the departure, arrival city with favorable dates.
B3 – The application would verify the dates and needed fields for validity before
requesting matching trips from the system's database.
B4 – A window with the available buses and their categories for economy and
business class displays.
B5 – Available and unavailable seats would be displayed using different colors along
with the gender who confirmed the seat.
P a g e | 14
B6 – User can select a seat accordingly and click on the OK option.
B7 – Show users a reservation form where they would fill in their name and address
and have the ID of the bus they selected automatically filled in.
B8 – A window appears asking user to make a choice between choosing and not
choosing cab service.
B9 – Add on window would be displayed where user would select the desired food
and beverage.
B10 – Submit option to be clicked and provided data would be validated to be finally
redirected to the payment page.
4.2.4 Non-Functional Requirements
B11 – The user can click the "turn on" option to enable his location when a popup
providing the essential information about turning on GPS location appears.
B12 – The application shows a search option that asks the user to enter their departure
and arrival cities into separate entry boxes before clicking "Submit" to initiate their
search request.
B13 – A loading symbol appears followed by the available buses attained through
the information available in system.
B14 – The bus will be categorized in economy and business class where upon a single
click on any one option, a selection would be made.
B15 – For easy selection, the booked seats in the selected bus category will be
displayed in red, while the available seats will be shown in green. A single click on
the chosen seat(s) would count as a selection and designate them as unavailable for
other users.
B16 – The seats next to available seats would be categorized with the keywords “F”
(for females) and “M” (for males) so user clicks on the desired seat that would be
reserved in the database and then marked unavailable.
B17 – A window with a label and a checkbox asking whether a cab would be needed
to get to the bus terminal, is displayed. Here, the user selects one choice and hits
"OK".
P a g e | 15
B18 – In case of a positive answer for a cab service, he would be redirected to the
cab service panel on a new window.
B19 – There is an add-on option where the system handling the menu chart for
specific days would display the available meal options and various beverages.
B20 – A user can choose from a variety of food and drink options with only one click.
There is then a submit option to store his data.
B21 – The system would update the data, and the user would then be redirected to
the payment page in the next window.
4.3 System Feature 3 - Communication with Admin – Captain Mode
4.3.1 Description and Priority
Real-time, two-way communication of captain with admin regarding any emergency
or live status of schedule and road safety. Since it is an important safety feature, this
feature is of high priority.
4.3.2 Response Sequence

Captain will login.

Captain will select ‘Contact Admin’ from the application menu.

The application will display calling screen.

Admin panel will be alerted within 10 seconds of a call.

Call timer will start immediately after appropriate admin receives call.
4.3.3 Functional Requirements
C1 – Captain will be able to contact admin.
C2 – Admin will be able to either hold, receive call or send a temporary message
instead.
4.3.4 Non-Functional Requirements
C3 – The application should handle communication in a fast and stable manner.
C4 – The system will first initiate communication using mobile sim capabilities.
C5 – If there are no sim signals, the system will switch to radio communication.
C6 – An on-screen notification will pop on both admin and captain screens which
will show the call duration.
P a g e | 16
4.4 System Feature 4 - Navigation – Captain Mode
4.4.1 Description and Priority
Navigation will be required by the captain to guide him through different routes to
his/her destination. It is an important fundamental feature of travelling, so it is of
high priority.
4.4.2 Response Sequence

Captain will login.

Captain will be asked to open GPS.

The captain will select ‘Navigation’ on main screen.

The application will prompt the captain to set destination.

Captain would be prompted to set stops between the journeys.

A screen will show real-time navigation through the selected routes with
expected arrival time and total distance.

The captain would be alerted about possible petrol pumps along the route.
4.4.3 Functional Requirements
C7 – Captain should be able to navigate uninterrupted.
C8 – Access to captain’s current location would be asked.
C9 – Access to stable internet.
C10 – Interactive map appearing with various available routes.
C11 – Captain can view all available petrol pumps and toll booths on the route.
4.4.4 Non-Functional Requirements
C12 – The application should calculate and show expected arrival time to destination.
C13 – The application should also show the distance to destination.
C14 – Captain would be able to set destinations through various route options.
C15 – Real-time traffic data would be shown along the route selected.
C16 – Notification will be sent to captain about possible road accidents along the
route.
P a g e | 17
4.5 System Feature 5 - Access to Captain Profile – Captain Mode
4.5.1 Description and Priority
Individual captains will have profiles with personal information where they will have
ratings and reviews based upon customers. This profile will also be visible to
customers. Since it is not the main functionality of this application, this feature is of
low priority.
4.5.2 Response Sequence

Captain will login.

The captain will select ‘Profile’.

Personal information will be visible, which the captain can change as
required.

View ‘Funds’.

View ‘Ratings and Reviews’.

Select ‘Change password’.

System will generate an automatic ‘change password’ email and to captain’s
email

Follow the email’s instruction to change password.
4.5.3 Functional Requirements
C17 – Change personal information as needed.
C18 – Add payment options to profile.
4.5.4 Non-Functional Requirements
C19 – System will generate an automated email to possible ‘change password’
requests.
C20 – The updated information by captain will be saved and updated in the system
database as well.
C21 – The system will save and calculate a driver rating upon customer feedback
and reviews.
P a g e | 18
4.6 System Feature 6 - Online Payment
4.6.1 Description and Priority
A high-priority feature that facilitates the user with the service that allows them to
make payments online using a computer, smartphone, or tablet.
4.6.2 Response Sequence

After booking, the bill is generated consisting of all expenses, ride expenses,
cab service, and add-on services.

User is presented with payment choices and can pay via banking apps, credit
card, debit card, etc. by selecting one.

Depending on the customer's selection, fill required information and submit
it.

Payment is made - the user gets proof of payment through a notification.

In the end, the digital ticket will be generated which can be downloaded in
the pdf form or can be printed to board a bus on the schedule.
4.6.3 Functional Requirements
D1 – After successful booking, the user would proceed to the billing.
D2 – The system would generate a unique voucher no. or transaction ID for the bill.
D3 – For payment, the user would navigate through payment gateways i.e., banking
apps, credit cards, debit cards, etc.
D4 – After payment, a confirmation message would be sent to the user.
D5 – A digital ticket would be given to the user by tapping the “Get the Ticket”
button for boarding which would show the ride details, the bus as well as the captain
info.
D6 – Users can communicate 24/7 with the captain.
4.6.4 Non-Functional Requirements
D7 – On clicking the “GENERATE BILL” button user would be able to see the total
bill including the expenses of the bus ride, cab service charges (if booked), beverages
and snacks.
P a g e | 19
D8 – On choosing any online banking app, the unique generated voucher number
would be entered by the user while making the payment.
D9 – By clicking the pay button, the amount would be deducted from the user’s
account and a successful transaction would be made.
D10 – On selecting the card option, the system would get the registration no. and
security PIN from the user which would be verified by the bank and a one-time
password would be sent to him via SMS and e-mail.
D11 – System would ask the user for OTP; payment would be authorized, and the
amount would be deducted from the respective bank account.
D12 – User would be notified about the payment received through e-mail and SMS.
D13 – Boarding ticket generated can be downloaded in the pdf form or can be printed.
D14 – Ticket would show the passenger’s name, pick up and drop off location,
boarding time, seat number, bus registration number, captain profile, etc.
D15 – Communication between customer and captain would be possible via app.
4.7 System Feature 7 - Booking a Cab – User Panel
4.7.1 Description and Priority
This feature will help the passenger of the bus to book the cab to travel to its
destination from bus terminal. This includes user (passenger) profile to login. Then
choose the ride and then pay the fare calculated. This feature will also preview the
driver history of the cab for the satisfaction of the passenger. This feature is of high
priority.
4.7.2 Response Sequence

To book the cab the user (passenger) will login to profile.

Then he will provide the destination and select the available ride.

Next, he will pay the fare calculated.

Also, user can preview driver history.
P a g e | 20
4.7.3 Functional
Requirements
E1 – Make a booking.
E2 – Check the booking status.
E3 – Fare calculation.
E4 – Check driver history.
4.7.4 Non-Functional Requirements
E5 – On Passenger will login and choose the available ride with amendable fare
according to passenger’s destination and the distance travelled using google maps
navigation.
E6 – The information filled by passenger will be updated to Admin panel. BC.7
Passenger will confirm the booking that he has done approving the given information
that he has given.
E7 – Fare will be calculated based upon passenger provided information.
E8 – Fare will be calculated based upon passenger provided information.
E9 – Maintain the data about driver is idle or working at a particular time.
E10 – Maintain the data that driver was ever been to that destination before or not.
4.8 System Feature 8 - Checking User Details – Cab Panel
4.8.1 Description and Priority
This feature will check the user-based information. It will check user login details.
Also provide data of their past and current activity regarding booking. It provides
Information of available rides. Confirm the booking for user. Update the new user
data to database. The priority is medium for this feature.
P a g e | 21
4.8.2 Response Sequence
 System will check for login details.
 Show all available rides
 Confirm the selected ride.
 Preview user activity
 Record feedback.
4.8.3 Functional Requirements
E11 – Authenticating users based on username and password.
E12 – Keeping session track of user activity.
E13 – Recording client’s request for booking.
E14 – Checking whether the vehicle is available for booking.
E15 – Keeping history of bookings.
E16 – Keeping record of feedbacks received from the clients.
4.8.4 Non-Functional Requirements
E17 – Ask passenger login details. Check whether profile exists or not.
E18 – Display passenger present or previously done booking activity.
E19 – Take passenger request to Admin panel to approve booking from Admin.
E20 – Allow passenger to see how many cabs are available for booking.
E21 – Update cab detail to Admin after booking i.e., departure time, arrival time,
reaching time.
E22 – Enable passengers to comment/criticize on the service provided and share their
experience in the feedback form.
E23 – Each feedback must be updated in database.
P a g e | 22
4.9 System Feature 9 - E-Mail Alert – Cab Panel
4.9.1 Description and Priority
This feature enables to send confirmation email to user containing CAB number and
PIN. Also notify the cab driver of booking confirmation and provide user PIN. It will
send thank you email whenever a user posts any feedback.
4.9.2 Response Sequence
System will send PIN and CAB number to user and then to CAB driver when booking
got confirmed. System will generate a thank you email whenever any feedback gets
posted.
4.9.3 Functional Requirements
E24 – The passenger will get email with PIN when booking is confirmed.
E25 – Notify Cab Driver while cab got booked and give user PIN.
E26 – The passenger gets a thank you mail on posting feedback.
4.9.4 Non-Functional Requirements
E27 – When booking got approve from Admin end then generates a confirmation
email regarding booking containing CAB number and PIN.
E28 – When booking approved from Admin end it will generate a notification
message at captain end providing user PIN.
E29 – When passenger post the feedback and it got updated to database then an email
with greetings is generated and sent to passenger.
4.10 System Feature 10 - Cancel Reservation
4.10.1 Description and Priority
24 hours prior to the departure, those who have made reservations will be able to
cancel them. It has low priority because it is not an essential component of the
application.
P a g e | 23
4.10.2 Response Sequence

User will select the “Cancel Ride” to cancel the reservation.

A message informing the user to phone the admin team to cancel their
reservation will appear if he cancels less than 24 hours before departure.

If he cancels 24 hours before the departure, the system will instruct pay
processor to refund the reservation fees.

The database will be updated and the status of “RESERVED” will be
changed to the status of “CANCELLED”

A notification will be sent to the user upon the cancellation of his
reservation.
4.10.3 Functional Requirements
F1: User will be able to cancel the ride 24 hours before the departure by clicking
“CANCEL RESERVATION”. If he wishes to cancel less than 24 hours, he will be
instructed to contact the admin team.
4.10.4 Non-Functional Requirements
F2 – The system will prompt the user to confirm if they really want to cancel their
reservation or not before taking further actions.
F3 – Those rides scheduled to depart within the next 24 hours, an error message will
be displayed asking the user to call a number to cancel.
F4 – For the rides scheduled to depart 24 hours or more in the future, the system
willrefund the reservation fees.
F5 – The database will be updated from the status of “RESERVED” to
“CANCELLED”.
F6 – An on-screen notification as well as an email and a sms message will be sent
to the user upon the successful cancellation of his ride.
4.11 System Feature 11 - Refund
4.11.1 Description and Priority
User will be able to submit a refund application through the app if he wishes to get
refunded due to any kind of inconvenience in his journey or any other reason. It has
low priority as it is not the main functionality of the application.
P a g e | 24
4.11.2 Response Sequence

User will select the “REFUND” option on the home page.

Then he will be required to enter booking number and mobile number and
select “CONTINUE”.

The system will verify the booking through the given booking number.

The user will be prompted for a refund explanation.

User will submit the application.

Admin team will receive and review the application to carry out further
refund process.

The refund status will be updated as the refund process proceeds.

To check the refund status, user will enter refund request in “REFUND
STATUS” option shown on home page.
4.11.3 Functional Requirements
G1 – User will be able to submit a refund application through the
app.
G2 – User will be able to check the refund status.
4.11.4 Non-Functional Requirements
G3 – User will select refund option that will be on home page.
G4 – He will have to enter the booking number and mobile number (both the
fieldsare necessary) and then select continue.
G5 – The system will verify his ride instantly to take him to next page.
G6 – He will give the explanation of why he wants refund in a message box that
canhave 500 characters
G7 – User will submit the application and an on-screen confirmation message will
be shown upon the successful submission of his request.
G8 – A refund request number will be given to the user through email and a SMS
message.
G9 – To check the refund status, user will enter the request number and check the
progress. He will also be informed about the expected time taken to complete the
refund process.
P a g e | 25
4.12 System Feature 12 - Feedback and Complaint Option
4.12.1 Description and Priority
The user will be able to give feedback on all the services offered or submit a
complaint about the trip. Since it is not the main purpose of the system, it is not
given high priority.
4.12.2 Response Sequence

User will select the complaint option on the home page.

The he will be given a choice between “SUGGESTION” or “COMPLAIN”.

After choosing one of the above, he will have to choose the type and title of
his suggestion or complain.

If he chooses complains then he will have to give the booking details
(booking number, mobile number, and departure date) based on which he is
complaining.

User will then write his comment in a message box provided.

Then he will submit his suggestion or complain by clicking on the submit
button.

The system forwards his complaint to the administrative team for
consideration and possible response.
Software Requirements Specification for <Project>
Page 1
4.12.3 Functional Requirements
H1 – User can submit feedback and complaints regarding all the services provided.
4.12.4 Non-Functional Requirements
H2 – User will select the complaint option on the home page.
H3 – Then he will be given two options to select between suggestions and
complains.He must select one to proceed to next options.
H4 – On clicking any of the above two options, he will select the type of
suggestion or complain from the dropdown menu that contains 6 options i.e.,
Bus, Cab, Staff, Mobile App, Refunds, Payment.
H5 – Then he will select any aspect of the above selected type through drop
down menu.
H6 – Then he will write his comments in a comment box provided that will
have thecapacity of 500 characters.
H7 – The complaint cannot be processed without the selection of the type,
title (an aspect of that type), and comment.
H8 – User will receive the confirmation message upon the successful
submission ofhis/her complain.
5. Other Nonfunctional Requirements
5.1 Performance Requirements
 Efficiency:
Efficiency of any system is concerned with the minimum processing time as well
as the optimal use of system resources in designing the proposed systems. Our
application will be efficient in using processing resources. It will efficiently run
on all android, iOS, and web devices.
Software Requirements Specification for <Project>
Page 2
 Response Time: The system must respond in no more than three seconds
afterverifying the relevant information.
 Users’ Capacity: A maximum of 2500 people should be able to access the
system at once.
 User Interface: The user-interface screen shall respond within 5 seconds.
5.2 Safety Requirements
 Security and Redundancy: Data inserted by user is secured and saved by
thisapplication, and will be redundant, to perform the exact action in specified
situation.
 Passenger Identification: The system requires the passenger to identify
himself/herself using PIN.
 Login ID: Any user who uses the system shall have a Login ID and Password.
 Modification: Any database modification (insert, remove, or update) must
besynchronized and carried out alone by the system administrator(s).
 Administrators' Rights: Administrators shall be able to view and modify all
information in the databases.
5.3 Security Requirements
<Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect the
product. Define any security or privacy certifications that must be satisfied.>
5.4 Software Quality Attributes
 Maintainability:
-
Back Up: The system shall provide the capability to back-up the Data.
-
Errors: The system shall keep a log of all the errors and should be able
tohandle unexpected errors quickly and easily.
Software Requirements Specification for <Project>
Page 3
 Reliability:
-
Availability: The system shall always be available.
 Extensibility:
-
Future Accommodations: The application should be flexible enough to
allow improvements for the future and should be able to adapt any
additionalfuture change in activities.
5.5 Business Rules
➔ All bus drivers are strictly required to follow every traffic law.
➔ All bus drivers and conductors are required to complete their 12-hour shift unless a valid reason
is given.
➔ There should be no smoking inside the bus.
➔ Any passenger that is not paying the correct amount is to be immediately removed from the bus.
6. Other Requirements
 Conformity: The systems must adhere to the accessibility requirements for
Windows, Linux, and macOS.
 Network Connection: The system needs to be online always, and the optimized
server must always be active.
Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>
Appendix B: Analysis Models
<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>
Appendix C: To Be Determined List
<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>