AIRLINE

RESERVATION

PROJECT
 Table of Contents

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References
1.5 Technologies to be used
1.6 Overview

2. Overall Description
2.1 Use-Case Model Survey
2.2 Architecture diagram & database design
2.3 Assumptions and Dependencies

3. Specific Requirements
3.1 Use-Case Reports
3.2 Supplementary Requirements

4. Supporting Information

5. Concerns / Queries / Doubts if any:

 SOFTWARE REQUIREMENT SPECIFICATION

1. Introduction
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.

1.1 Purpose
This document describes the software requirements for the Airline
Reservation System built for the Indian Aviation Industry.

1.2 Scope
The Indian Aviation Industry is requesting proposals to build a prototype
of an Airline Reservation System (ARS) for their current system. This new
ARS needs to be scalable enough so that it can accommodate the
increase in reservations in India. The system will be designed to provide
an electronic version of the railway passenger reservation system in India.
The system will have a user-friendly graphical interface and will be more
cost effective compared to the current non-electronic version of the
reservation system.
The objectives of this development effort are:
• To provide existing clerks with a new environment in which to
make reservations for airline travel.
• To provide an avenue for customers to get their tickets in a
more convenient way.
• To regain control of the airline ticket sales to avoid scalping and
overselling of tickets.
• To implement a prototype of a scaled down version of the final
system to test the solution and further develop requirements.
• To collect statistics in a more efficient manner for future airline
development and construction.
• To increase efficiency of airlines.

1.3 Definitions, Acronyms and Abbreviations

ARS-Airline Reservation System
CASE – Computer Aided Software Engineering
PP - Project Plan
SRS - Software Requirement Specification
GUI – Graphical User Interface
UML – Unified Modeling Language

1.4 References

· Introduction – Indian Airline Passenger Reservation System Prototype

http://www.cs.swt.edu/~donshafer/project_documents/5391_Case.html

· Situation Update – Indian Airline Passenger Reservation System

http://www.cs.swt.edu/~donshafer/Marketing Update(1).html
 · Pressman, Roger S., Software Engineering: A Practitioner’s Approach,
McGraw-Hill Companies, Inc., 1997.

1.5 Technologies to be used

1. C++.
2. ARGO UML.

1.6 Overview
Chapter 2 of the SRS is a overall description of the characteristics of the
software to be built, its functions, its users, its constraints and its
dependencies.

Chapter 3 is about specific requirements, such as functional

requirements, external interface requirements, performance requirements,
and also design constraints and quality characteristics.

Chapter 4 includes all the supporting information, such as the Table of

Contents, the Appendices, and the Index.

Chapter 5 is about the concerns, queries and doubts if any.

2. Overall Description
This section describes the general factors that affect the product and its
requirements. This section consists of five subsections that follow. This
section does not state specific requirements. Each of the subsections
makes those requirements easier to understand, it does not specify
design or express specific requirements. Such detail is provided in section
3.

2.1 Use-Case Model Survey

2.1.1 Introduction
The purpose this document is to provide a brief description of the project
and to describe known actors and their interaction with the system. This
includes a list of names and brief descriptions of all use cases and actors,
along with applicable diagrams and relationships.

2.1.2 Survey Description

The scope of this effort is to stimulate an airline reservation system that
will allow the passenger to reserve and cancel tickets provided by a host.

2.1.3 Identified Actors

1. Passenger
2. Administrator

2.1.4 Actors Description

2.1.4.1 Passenger
A Passenger can reserve and cancel tickets, view flight details, pay
ticket fare and print ticket.
 2.1.5 Identified Use Cases
1. Login
2. Reserve Tickets
3. Flight Enquiry
4. Cancel Tickets
2.1.6 Use Case Description
2.1.6.1 Login
This helps both the Passenger and the Administrator to login into the
system.

2.1.6.2 Reserve Tickets

This allows the Passenger to reserve tickets for traveling in the given
route bus as per his wish. One can reserve any number of tickets
according to the availability of seats.

2.1.6.3 Flight Enquiry

This shows the list of airlines, fare type, price, depart time, arrival time
and the flight duration. This can be viewed by both Passenger and the
Administrator.

2.1.6.4 Cancel Tickets

This helps the Passenger to cancel the reserved tickets and get back
the refund amount.

2.1.7 Flow of events

2.1.7.1 Login
Pre Condition:
The Passenger and Administrator enters the
username and password.
Main Flow:
Verifying the user name and password.
Post Condition:
Enter into the system if valid else ask to re-enter
the user name and password.

2.1.7.2 Reserve Tickets

Pre Condition:
The Passenger must give details like from and to
city, depart and return dates, class and number of Passengers.
Main Flow:
Check the entered details in the database.
Post Condition:
Update the database.

2.1.7.3 Flight Enquiry

Pre Condition:
The Passenger must perform the Reserve Tickets
function.
 Main Flow:
The Passenger can access the Flight details.
Post Condition:
Update the database.

2.1.7.4 Cancel Tickets

Pre Condition:
The Passenger must give details like reservation
number and flight details.
Main Flow:
Check the entered details in the database.
Post Condion:
Update the database.

2.1.8 Use Case Diagram

2.2 Architecture diagram & Database Design

2.2.1 Architectural diagram

Figure 2.2 Architectural Diagram of ARS

ARS

Database Server

External
Interfaces
PC

Airline Passenger
Administration

2.2.2 Database Design Schema

Database:
· Stores data
· Creates reports
· Provides access to data
· Updates information

Server:
· Provides access to the database
· Authenticates users
· Processes reservations
· Performs backups
· Produces reports
 External Interfaces:

Personal Computers
· Users (passengers, travel agents, and railroad
administration) may use personal computers to obtain a remote
access to the server and the reservation database via the
Internet.

Computer Hardware and Peripheral Equipment to be used:

· work stations, which include CPUs, monitors, keyboards,
and mice
· Printers
· Network

2.3 Assumptions and Dependencies

The assumptions for the project are:

· Ten flights transport the passengers between three cities known
as Chennai, Delhi and Mumbai.
· There are two classes of tickets as listed below
§ Economy
§ Business
· Reservations will be done on a first come first serve basis.
· The flights will be assumed to be of a constant size that
accommodates 100 passengers at a time. They will consist of:
§ 25 Business class seats.
§ 75 Economy class seats.

The dependencies, or external events, for the project are:

· The institution will provide all the required hardware and software
resources for the development of the project.

3. Specific Requirements
This section of the SRS should contain all the details the software developer
needs to create a design. This is typically the largest and most important
part of the SRS.

3.1 Use-Case Reports

This subsection of the SRS should specify what is to be done by the
product, to what level or specific requirement, what inputs should be
transformed to what outputs (not how this is done), what specific
operations are required. Where the rationale for a requirement is not
obvious, provide an explanation. Where issues need to be resolved,
cite those.
 For each function, specify requirements on inputs, processing, and
outputs. These are usually organized with these four subparagraphs:
(1) Purpose of the function: Provide rationale to clarify the
intent of the function.
(2) Inputs: sources, valid ranges of values, any timing
concerns, operator requirements, special interfaces
(3) Operations to be performed: validity checks, responses to
abnormal conditions, types of processing required
(4) Outputs: destinations, valid ranges of values, timing
concerns, handling of illegal values, error messages,
interfaces required.

3.2 Supplementary Requirements

3.2.1 External Interface Requirements

This should specify:
(1) The characteristics that the software must support for each human
interface to the software product. For example, if the user of the
system operates through a display terminal, the following should be
specified:
(a) Required screen formats
(b) Page layout and content of any reports or menus
(c) Relative timing of inputs and outputs
(2) All the aspects of optimizing the interface with the person who
must use the system. This may simply comprise a list of do's and
don'ts on how the system will appear to the user.

3.2.2 Design Constraints.

Design constraints can be imposed by other standards, hardware
limitations, etc.

3.2.2.1 Standards Compliance.

Specify the requirements derived from existing standards or
regulations. They might include:
(1) Report format
(2) Data naming
(3) Accounting procedures

3.2.2.2 Hardware Limitations.

Identify the requirements for the software to operate inside
various hardware constraints.

3.2.3 Quality Characteristics.

There are a number of quality characteristics that can apply to
software. Pick the ones most important to this product and develop a
section for each one.
Definitions of the quality characteristics follow.
• Correctness - extent to which program satisfies specifications,
fulfills user’s mission objectives
 • Efficiency - amount of computing resources and code required to
perform function
• Flexibility - effort needed to modify operational program
• Integrity/security - extent to which access to software or data by
unauthorized people can be controlled
• Maintainability - effort required to locate and fix an error during
operation
• Portability - effort needed to transfer from one h/w or s/w
environment to another
• Reliability - extent to which program performs with required
precision
• Reusability - extent to which it can be reused in another application
• Testability - effort needed to test to ensure performs as intended
• Usability - effort required to learn, operate, prepare input, interpret
output

3.2.4 Other Requirements.

The database created in the MS Access backend should have rollback

facility.Consistency must be maintained in all related tables in the
database.Only the administraror must be given rights to access and update the
database
Certain requirements may, due to the nature of the software, the user
organization, etc., be placed in separate categories such as those
below.

4. Supporting Information.
The supporting information; that is, the Table of Contents, the Appendices,
and the Index, make the SRS easier to use.
The Appendices are not always considered part of the actual requirements
specification and are not always
necessary. They might include:
(a) Sample I/O formats, descriptions of cost analysis studies, results of
user surveys.
(b) Supporting or background information that can help the readers of
the SRS.
(c) A description of the problems to be solved by the software.
(d) The history, background, experience and operational
characteristics of the organization to be supported.
(e) A cross-reference list, arranged by milestone, of those incomplete
software requirements that are to be
completed by specified milestones.
(f) Special packaging instructions for the code and the media to meet
security, export, initial loading, or other
requirements.
When Appendices are included, the SRS should explicitly state whether or
not the Appendices are to be considered part of the requirements
Result:
Thus the software requirement specification report has been completed.