SRS Airline Management System
Software Requirement
Engineering Airline
Reservations System
Table of contents
1. Introduction 3
1.1 Purpose 3
1.2 Scope 3
1.3 Glossary 3
1.4 Overview 3
2. Overall Description 4
2.1 Problem Statement 4
2.2 Existing System 4
2.3 Proposed System 4
2.4 Product Functions 5
2.5 User’s characteristics 6
2.5.1 User’s Requirements 6
2.5.2 User’s Education Level 6
2.5.3 User’s Technical Expertise 6
2.6 Constraints 6
2.7 Assumption and Dependencies 6
3. Requiremnet Specification 7
3.1 Functional Requirement 7
3.1.1 Performance Requirement 7
3.1.2 Design Constraints 7
3.1.3 Hardware Requirement 8
3.1.4 Software Requirement 8
3.1.5 Other Requirement 8
3.2 Non-Functional Requirement 9
4. Diagrams 10
4.1 Use Case Diagram 10
4.2 Class Diagram 11
4.3 State Diagram 12
4.4 Data Flow Diagrams 13
4.4.1 Level 0 13
4.4.2 Level 1 13
4.4.3 Level 2 14
2
Introduction
1.1 Purpose
Airline Reservation System aims to automate the flight operations and ticketing / seat booking and
confirmation sytem 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 sytem
• Cancellation
• Improved and optimized service
1.3 Glossary
ARS-Airline Reservation System
LAN-Local Area Network
GUI-Graphical User Interface
OS-Operating System
RAM-Random Access
Memory MB-Mega Bytes
GB-Giga Bytes
Mbps-Mega bits per second
HDD-Hard Disk Drive 1
UML-unified modeling language
1.4 Overview
The remaining section of this document provide a general description including characteristic
of the users of this product, the product’s hardware, and functional and non-functional
requirements of the product.
3
Overall Description
2.1 Problem Statement
Developing an AIRLINE RESERVATION SYSTEM- ARS for an air line company that want to
automate its flight operations and ticketing / seat booking and confirmation sytem.
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 erroreous. This lead to inconsostency and inacuracy.
• 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.
• Its dificult to update, delete, or view the data due its manual nature.
• Increasing number of passengers leads to difficulty in maintaining and retreiving details.
2.3 Proposed Sytem
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, updation can be performed easily and fast.
• Proper way of confirmation of bookings etc.
4
2.4 Product Functions
Booking agemts with varying levels of familiarity with computers will mostly use this system. With this
on mind, an important feature of this software is that it will be relatively simple to use. The scope of
this product encompasses:
SEARCH: This function allows the booking agent to search for airoplane’s and ticket’s availibility
between two cities, i.e departure city and arrival city, the date of departure, perferred time and number of
passengers.
SELECTION: This function allows a particular airoplane to be selected from the displayed list. All
details such as;
• Airoplane number
• Date, time and place of departure
• Date, time and place of arrival
• Fare per head etc
Review: If seats are available, then system propmts for the booking. All the information including total
fare with taxes and flight details are reviewed.
Traveller Information: The details of all passengers supposed to travel including name, address, contact
number, email etc.
Payment: It asks the agent to enter the various credit card details of the person making reservation i.e.
• Credit card type
• Credit card number
• Expiration date of the card
• The name on card etc
Cancellation: The system allows the passenger to cancel a reservation and register the information
regarding his/her ticket. It includes Confirmation no, name, date of journey, fare deducted.
5
2.5 User Characteristics
2.5.1 User requirements
• User properties like Name, Address, Age,
• Associated with Flight Miles accumulated and Credit Card information.
• Flight properties like Departing/Arriving City, Departure/Arrival dates and times, Miles, and
an identifying Flight Number.
• Flight Seat properties of identifying seat number, reserved and flight
• Associated to Flight by flight number
2.5.2 User Education Level
At least user of the system should be comfortable with English Language.
2.5.3 User’s Technical Expertise
User should be comfortable using general pupose applications on the computer system.
2.6 Constraints
System contstraints:
• The system is a web base, so it will run on a web browser i.e IE, Chrome, Firefox etc.
• The system will run under any OS with internet functionality.
2.7 Assumption and Dependencies
• Booking agent will be having a valid user name and password to access the system.
• The software needs booking agent to have complete knowledge of ARS.
• Software is dependent on access to internet.
6
3 Requirement Specification
This section highlights the functional requirements, non-functional requirements and other
requirements.
3.1 Functional Requirements
3.1.1 Performance requirements
• User Satisfaction: The system is such that it stands up to the user expectations.
• Response Time: The response of all operations is good.
• Error Handling: Response to user errors and undesired situation has been taken
care of to ensure that the system operates without halting.
• Safety and Robustness: The system is able to avoid or tackle disastrous action.
In other words it should be foul proof.
• Portable: The software should not be architectecture specific. It should be
easily transferable to other platforms if needed.
• User Friendliness: The system is easy to learn and understand. A native user
can also use the system effectively, without any difficulties.
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 defense system and
database system. They place restrictions on the ues 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.
7
3.1.3 Hardware Requirements
For the hardware requirements like memory restrictions, cache size, the processor, RAM size
etc... those are required for the software to run.
MINIMUM Hardware Requirements
Processor Pentium IV
Hard Disk Dirve 100 GB
RAM 1 Gb
PREFERED HARDWARE REQUIREMENTS
Processor Core i3
Hard Disk Drive 500 GB
RAM 4 GB
3.1.4 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.1.5 Other Requirement
• Security
• Portability
• Correctness
• Efficiency
• Flexibility
• Testability
• Reusability
8
3.2 Non-Functional Requirements
3.2.1 Security
The system is must automatically log out all cutomers after a period of inactivity. The
system should not leave any cookies on the cutomer’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 continuesly 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 acess of pople 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 retreived from the server and saved by the Organizer. Then the service will be
restarted. It means 24x7 availibilty.
3.2.4 Maintainability In case of a failure, a re-instalization 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.
9
4 Diagram
4.1 Use Case Diagram
10
4.2 Class Diagram
Common Functions
+searchticket()
+bookticket()
+cancelticket()
+makepayment()
+details()
Booking agent Payment
+id: int +CustomerID: char
+name: char +cardNo: char
+passw: char +expirayDate: char
Customer
+CustomerID: Char
+name: char
+address: char
+ph_no: int
+age: int
+adddetails()
+modifydetails()
Booking
+flight_name: char
Refund
+flight_no: char
+amount: float
+destination: char
+CustomerID: char
+date_of_journey:date
+refundAmount() +time: time
11
4.3 State Diagram
12
4.4 Data Flow Diagram
Level 0:
Airline
Admin
Reservation
User
Level 1:
User Airline Database
Seat no
Checked status
username, date Check
No of seats etc Availabilty
Bank details
Payment bill
Print Payment
Confirm ticket
Confirm payment
13
Level 2:
Reservation
Check avail
Give availability
Apply for ticket conform ticket Admin
Conform cancel
Cacel process
Cancellation
Apply for cancel
User
Airline Database
view details
details
Check Status
payment
details Payement payment process
done
Payment
14
