Airline Reservation System Functions Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

This project deals with the development of a Software Requirements Specification (SRS) document that specifies what an airline reservation system should and should not do. The SRS document is divided into five sections namely

System Objectives

This section lists all the goals and objectives of the system categorized based on the viewpoint of the airline company and the customer (passenger). These are higher-level goals which are somewhat broad in nature. They help in a top-down development of the SRS.

System Context

This section clearly depicts the environment and boundaries of the ARS and the entities with which it interacts. It helps us see how the system fits into the existing scheme of things. What the system will do by itself and what it expects other entities to do is clearly delineated.

Functional Requirements

This section is the bulk of the document and precisely states the functions of the system - what it should do and what it should not. This section is split into subsections modeled after the real world activities like reserving tickets, rescheduling tickets etc. Freedom from ambiguity and navigability were kept in mind while documentation. A consistent terminology has been followed throughout and the terms are explained in the appendix. The subsections follow a logical sequence that reflects the real world. For example, a customer cannot reschedule a ticket unless he has bought one earlier and cannot buy one unless he has checked its availability.

Non-functional Requirements

These are quality requirements that stipulate the performance levels required of the system for various kinds of activities. Numerical lower and upper limits set conditions on the response times, access times etc of the system. Sometimes, tradeoffs are necessary among various non-functional requirements.

Future Requirements

These are the specifications which are not provided for now in the current version of ARS but which could be incorporated into future versions. Some of these need advanced technologies and interfaces with other systems. The ARS could be designed in future to enhance the existing capabilities or add entirely new ones.

The assumptions and limitations of the ARS have been interspersed in the SRS to present the same in their proper context.

System Objectives

The Airline Reservation System (ARS) is a software application to assist an airline with transactions related to making ticket reservations, which includes airline schedules, fare tariffs, passenger reservations and ticket records.

The main objectives for the creation of such software are:

Reduce paper work done by the system administrator and reservation clerks as well as the staff members.

To provide a better GUI (Graphical User Interface) to the users. A user has to follow the same steps by the system as they go through in conventional desk-reservation systems.

Also provides for the user appropriate instructions and guides him/her through the steps of reservation or cancellation procedures.

Reservations for individual passengers or groups are stored in a so-called Passenger Name Record (PNR).

The profile (PNR) can also be used by the airline company to track user preferences and travel patterns to serve them better, plan routes, for better marketing and efficient scheduling of flights.

Increase awareness among frequent travelers about various special offers and discounts.

Minimize the number of vacant seats on a flight and maximize flight capacity utilization.

Reduce effort and frustration for travelers in scheduling a trip. Specially in searching for a particular flight between a pair of destinations.

Avoid redundancy in the information required from the customers by creating linked databases and keeping records of related data.

Validating user inputs so that wrong or undesired input is not registered or entertained.

Authentication for different users and administrators will also protect customers' privacy concerns and security issues would be resolved.

System Context

The Airline Reservation System (ARS) will provide the following types of easy-to-use, responsive, and spontaneous graphical interfaces. The key points that are included in designing this part of the project are:

It will provide an easy-to-use, easy-to-learn Graphical User Interface (GUI) with icons and menus providing a Clerk/Administrator's to work freely and in a non-restrictive environment as well as on the World Wide Web for the general customers.

The above two ARS interfaces shall help provide the following functionalities to the users - access to the ARS to check the flight schedule, availability of seats, ticket price and to block, reserve, cancel, and reschedule tickets.

The ARS will also provide administrator privileges so that administrator can make changes in flight schedule, emergency information, flight delays, new price catalogs, VIP reservations etc.

The functionality available through this interface is authenticated because of security constraints.

There are mainly two databases which the system maintains:

Firstly, for registered users of the ARS containing all the personal information of the registered users such as name, contact information or special services requests (SSRs) e.g. for a vegetarian meal, as well as the flights (segments) and issued tickets for which user login is required.

Secondly, flight schedule database which exists independently and is updated by the administrator from time to time. Flight schedule database also contains the base prices of tickets for various flight numbers and the number of seats available on each class on different flights.

Functional Requirements

The main functional requirements for this project can be summarized under the following sub headings:

User Accounts

The passenger, who will henceforth be called the 'user', can choose whether he is a guest (wants to check the availability of tickets, check flight schedules) or a registered user (by registering himself/creating an account using which he can buy /reserve tickets).

Registered User mainly concerns a person who has travelled/booked seats earlier, has a user id and a password plus his personal information stored in the ARS. A registered user will be able to check the availability of tickets as well as block/buy a ticket by logging into the system.

A guest is a person who has not registered himself with the system. A guest can only check the availability of tickets and cannot block or buy tickets.

Checking Availability

After logging in a user (either a registered user or a guest), the system shall request him to enter the following details:

Origin city and destination city,

Class (The inventory of an airline is generally divided into service classes (e.g. First, Business or Economy class) and up to 26 booking classes, for which different prices and booking conditions apply),

One-way or round trip (in case, the trip is a round trip, the system shall also ask the user to enter the departure date on the return trip),

Departure date and

The number of adult passengers, children and senior citizens.

Having taken all the above input from the user, the system checks for any false entries like the departure date on the return trip being earlier than the departure date on the onward trip. In case of incompatibility, the system shall display a suitable error message and prompt the user to enter the information correctly.

The system then queries the reservation database to check which of the flights on the schedule have seats available. The system displays the results in a suitable form (a tabular form) with the following information depicted for each flight number:

The flight number,

Departure time in origin city,

Arrival time in destination city,

The duration of the flight (taking into account the possibility of a change of time zone) and

The number of seats available on that flight.

There can be several flights between two cities and all of them will be listed for the particular date that the user wants to depart from the Origin City. The user is now asked to check one of the boxes reflecting a choice of a flight number and time.

The system shall now display the price of the ticket for the trip.

The system shall also list any rules regarding the cancellation of tickets - what percentage of the price will be refunded within what date ranges.

Making Reservations/Blocking/Confirmation

After checking availability, the system will now ask the user if he wishes to block/buy the ticket.

If yes, and if the user has been a guest, he will have to first register and become a registered user and then log onto the system.

If the user is already a registered user, and if he has logged on already, he can block/buy the ticket.

The system will now authenticate the user, checking whether his user id and password are correct or not.

Having taken the input from the user, the system shall now proceed to update the reservation database.

It will decrement the number of available seats on the particular flight for the particular class by the number of travelers being represented by the user.

The system accesses the registered user's profile and charges the price of the ticket to his credit card number.

It simultaneously generates a confirmation number and displays it to the user for him to note down.

The ticket has been reserved.

Reschedule Ticket

The system has an option to re-schedule his travel party's trip. In order to do this, the system first logs on the user and requests his confirmation number.

The system shall now ask the user to select new dates from the calendar-menu.

In case, there are no available tickets for the dates entered, it displays a suitable message informing him that rescheduling to that date is not possible.

In case there are tickets available, the system asks the user to select the flight number for the trip and updates the database.

The system accesses reservation database and decrements the number of available seats on the flight(s) by the number of members in the user's travel party.

It then increments the entry for the previous flight by the same number to reflect an increase in the available seats on it as a result of the rescheduling.


User also has an option to cancel a confirmed ticket.

Here, it asks for the confirmation number and accesses reservation database and presents the details of the trip including but not limited to origin city, destination city, date of departure and date of arrival (in case the trip is a round trip).

It then lists the applicable rules and regulations for cancellation of tickets and depending on the system date and the departure date, it displays the percentage of the amount that would be refunded if the user cancels the ticket.

After the user cancels the ticket, the system generates a cancellation number.

It accesses reservation database and updates it by incrementing the number of available seats.

Update Profile

The system shall enable the user to update his profile at any time. Changes can be made in fields including but not limited to address, phone number and preferred credit card number.

View Ticket Status

The system shall allow a user to view all information about his trip. After logging him on, it asks for his blocking number or his confirmation number. It accesses DB-reservation and retrieves the details of the trip and presents them to the user in a convenient format, including any last minute changes to the flight timings etc. Such changes will be highlighted.

Query Flight Details

The system shall allow any user (registered or non registered) to access the details about the arrival and departure times of a flight by requesting the user to input the flight number and date. The system accesses DB-schedule and presents the time of arrival and departure.

Non-functional Requirements


Response time of the Airline Reservation System should be less than 2 second most of the time. Response time refers to the waiting time while the system accesses, queries and retrieves the information from the databases. ARS shall show no visible deterioration in response time as the number of users or flight schedule data increases


ARS shall be available 24 hours a day, 7 days a week providing real time information about flight availability and will have a high degree of fault tolerance. ARS shall be able to recover from hardware failures, power failures and other natural catastrophes and rollback the databases to their most recent valid state.


ARS shall provide an easy-to-use graphical interface similar to other existing reservation system so that the users do not have to learn a new style of interaction aided by the use of various menus, options and icons.

Notification or error messages will also be generated.


Only system administer has the right to change system parameters, such as pricing policy etc. Users need to be authenticated before having access to any personal data.

Future Requirements

5.1 Support for waiting list functionality

5.1.1. ARS shall be made more flexible in ticket reservation handling, and shall accept waiting list for reservation.

5.1.2 The waiting list handling capability of ARS shall be made more advanced, by enabling it to send requests to the Flight Scheduler to schedule extra flights, depending on the demand in a particular corridor, and providing the wait listed passengers with a new flight.

5.2 The telephonic interface of the ARS shall be improved to support more functionality like allowing the customers to cancel a ticket etc., by incorporating security measures.

5.3 ARS shall be made more dynamic and helpful to the users by enabling it to send instant messages to the passengers, of a cancelled or rescheduled flight, through email, phone, fax etc., informing them about the change, and providing them with other feasible alternatives.

5.4 Information about the kind of meals served in a flight and the type of entertainment offered on a flight should be incorporated into the system.

Provide service integration with auto rental agencies and hotel chains.

Interface for the travel agents shall be provided in the future versions with additional features like informing them of any availability of seats on a flight which was earlier booked to capacity.

Choices like aisle or window seats shall be provided to the users.

The ARS shall be able to handle the situation where flight services are available to multiple airports in a single city.