AIRLINE
RESERVATION
SYSTEM
Team Members
Chelsi Kothari - 1635
Prateek Drall - 1638
Ravi Meena - 1643
Raghav Sahay - 1648
Class :- CSE - 2
Semester :- 4
Software Requirements
Specification
1 Introduction
1.1 Purpose
Airline Reservation System aims to automate the flight operations and ticketing / seat
booking and confirmation system of an Airline company. The software is providing
options for viewing different flights available within a different timings for a specific day.
That provide customers within facility to able to book ticket smoothly. The customers can
modify and able to cancel the ticket for any reason. That prepare within a role and
policies. The software should provide option for checking availability of the tickets. That
is important for the customers to get message if the ticket unavailable. That will be
displayed into customers. The customers should be noted when the change has been
made or any further changes.
1.2 Scope
The airline booking website is an application stored in the user server. The purpose of
the website is to resolve the client to allow website users to perform tasks related to
booking an airline flight. The system enables to perform the following functions:
• Automation of flight operations
• Automation of ticketing / seat booking
• confirmation system
• Cancellation
• Improved and optimized service
2.1 Problem Statement
Developing an AIRLINE RESERVATION SYSTEM- ARS for an airline company that want to
automate its flight operations and ticketing / seat booking and confirmation system.
2.2 Existing System
Before the automation the system suffered from following DRAWBACKS:
• Existing system is highly manual and involves a lot of paper work and calculation and
therefor may be erroneous. This lead to inconsistency and inaccuracy.
• The data may be lost, stolen or destroyed because it is stored on paper.
• The existing system consumes a lot of time causing inconveniencing to customers and
the staff.
• It’s difficult to update, delete, or view the data due its manual nature.
• Increasing number of passengers leads to difficulty in maintaining and retrieving
details.
2.3 Proposed System
The ARS is proposed with the following,
• The computerization of the reservation system will reduce a lot of paperwork and
hence load on the hence the load on airline admin and staff.
• The machine will perform all calculations. Hence chances of error are nearer to nil.
• The passenger, reservation, cancellation list can be easily retrieved and any required
addition, deletion, update can be performed easily and fast.
• Proper way of confirmation of bookings etc.
3.1 Functional Requirements
3.1.1 Various functions
● User Registration: The system should allow users to register themselves with their
personal information such as name, contact details, email ID, etc.
● Flight Search and Booking: The system should allow users to search for flights based
on their desired destination, date, and time. After selecting a flight, users should be
able to book the flight by providing their personal and payment details.
● Flight Cancellation and Rescheduling: Users should be able to cancel or reschedule
their flights based on the airline's policy. The system should display the cancellation
and rescheduling charges to the users before they make the final decision.
● Seat Selection: Users should be able to select their preferred seats while booking
their flights.
● Payment Gateway: The system should be integrated with a secure and reliable
payment gateway that allows users to make online payments using different payment
methods.
● Flight Status: The system should display the real-time status of the flights to the
users, including the arrival and departure time.
3.1.2 Design constrain
There are a number of factors in the client’s environment that may restrict the
choices of a designer. Such factors include standards that must be followed, resource
limits, operating environment, reliability and security requirements and policies that
may have an impact on the design of the system.
• Standard Compliances This specifies the requirement for standards the
system must follow. The standards may include the report format and
accounting properties.
• Hardware Limitations Hardware limitations can include the types of
machine to be used, operating system available on the system, languages
support and limits on primary and secondary storage.
• Reliability and Fault Tolerance Fault tolerance requirement can be
place a constraint on how the system is to be designed. Recovery
requirements are often on integral part here, detailing what the system
should do if some failure occurs to ensure certain properties. Reliability
requirements are very important for critical application.
• Security Security requirements are particularly significant in defence
system and database system. They place restrictions on the uses of
certain commands, control access to data, provide different kinds of
access requirements for different people, require the use of passwords
and cryptography techniques and maintain a log of activities in the
system.
3.1.3 Software Requirements
Any window based operating system with DOS support are primary requirements for
software development. Windows 7 and up are required. The system must be
connected vie LAN and connection to internet is mandatory.
3.2 Non-Functional Requirements
3.2.1 Security
The system is must automatically log out all customers after a period of
inactivity. The system should not leave any cookies on the customer’s computer
containing the user’s password. The system’s back-end servers shall only be
accessible to authenticated management.
3.2.2 Reliability
The reliability of the overall project depends on the reliability of the separate
components. The main pillar of reliability of the system is the backup of the
database which is continuously maintained and updated to reflect the most
recent changes. Also the system will be functional under a container. Thus the
overall stability of the system depends on the stability of the container and its
underlying OS.
3.2.3 Availability
The system should be available at all the times, meaning the user can access it
using a web browser, only restricted by the down time of the server on which
system runs. A customer friendly system which is in access of people around the
worlds should work 24 hours. In case of a hardware failure or database
corruption, a replacement page will be shown. Also in case of hardware failure
or database corruption backups of the database should be retrieved from the
server and saved by the Organizer. Then the service will be restarted. It means
24x7 availability.
3.2.4 Maintainability
In case of a failure, a re-installation of the system will be done. Also the
software design is being done with modularity in mind so that
maintainability can be done efficiently
3.2.5 Supportability
The code and supporting modules of the system will be well documented and
easy to understand. Online user documentation and Help system requirements
will be provided.
[Link]
This SRS document provides a detailed overview of the functional and
non-functional requirements of the airline reservation system. The system should
be designed to provide a seamless experience to the users, ensuring their
satisfaction and loyalty to the airline.
Use case diagram
UML
State diagram
Data flow diagram
Level 1:
Level 2:
ER diagram
Problem Solving Documentation -
[Link] Problem Solving
a. Anecdotal record: Our team encountered a problem with
the user interface of the airline reservation system, as it
was confusing and difficult to navigate. We brainstormed
solutions and came up with a simplified design that made
it easier for users to book flights. This solution was
implemented.
b. Photographs: We took before and after screenshots of
the user interface to showcase the improvements we
made.
c. Recognition: `NA`
2. Innovations in Teaching and Learning
a. Product: We developed a teaching and learning strategy
for the airline reservation system. This included detailed
documents of the project.
b. Recognition: `NA`.
c. Patent: While we did not file for a patent related to our
teaching and learning strategy, we did explore the
possibility of patenting certain aspects of the airline
reservation system.
3. R&D through Teamwork
a. Documentation: We kept a detailed record of our team's
research and development efforts, including meeting
minutes, progress reports, and communication logs.
b. Research Reports: `NA`.
c. Peer Assessment: We conducted peer evaluations to
ensure that each team member was contributing equally
to the research and development process.
4. Build Student Teams
a. Documentation: We documented the process of forming
and managing our team for the project, including the
selection criteria and team roles.
b. Rubric: We developed a rubric to evaluate our
performance, which included criteria such as teamwork,
innovation, and problem-solving.
5. Reports of Research
a. Research Reports: `NA`.
b. Experimental Set-Ups: We documented the
experimental set-ups we used in our research, including
data sources and analytical tools.
c. Tools Used: We used a variety of languages, tools and
software for our research, including HTML, CSS,
Javascript, ReactJS, NodeJS, MongoDB, ExpressJS, VS
Code etc.
d. Product: Our research resulted in the development of a
new feature for the airline reservation system, which
allowed users to receive personalized flight
recommendations based on their last activities.
e. Publication: `NA`.
