Software Requirement Specification

AIRLINE RESERVATION SYSTEM

Version 1.0 Approved

Prepared By :
Hafsa Ahmed (SP16-BSE5A-017)
Faizan Muzaffar (SP16-BSE5A-002)
Bilal Satti (SP16-BSE5A-034)
Sumble Manzoor (SP16-BSE5A-018)

Organization :
Comsats University Wah

Date :
16th May, 2018
1. Revision History
Date Revision Description Author

15-06- 1.0 First draft, requirements specification Bilal

2018 document is created.
16-06- 1.0 Added sections 4 and 5. Hafsa
2018
Contents
1. Revision History ...................................................................................................................... 2
2. Introduction ............................................................................................................................. 4
2.1 Purpose ............................................................................................................................. 4
2.2 Scope of Project ............................................................................................................... 4
2.3 Assumptions and Dependencies: .....................................Error! Bookmark not defined.
2.4 References: ......................................................................Error! Bookmark not defined.
3. Use Case Model Survey: ......................................................................................................... 5
3.1 Use Case Model ............................................................................................................... 5
3.2 List of Actors and their description: ................................................................................. 6
3.3 Use Case Model – Reservation Module: ......................................................................... 7
3.4 Class Diagram: ................................................................................................................. 8
4. Requirements: .......................................................................................................................... 8
4.2 Functional Requirements.................................................................................................. 8
4.3 Non-Functional Requirements: ........................................................................................ 9
4.3.1 Security: .................................................................................................................... 9
4.3.2 Reliability:................................................................................................................. 9
4.3.3 Availability: ............................................................................................................ 10
4.3.4 Maintainability: ....................................................................................................... 10
4.3.5 Supportability:......................................................................................................... 10
4.3.6 User Manual and Samples ...................................................................................... 10
4.3.7 Communication Link .............................................................................................. 10
4.3.8 Environment ............................................................................................................ 10
4.3.9 Logging ................................................................................................................... 10
4.3.10 Error Handling ........................................................................................................ 10
4.4 Glossary...........................................................................Error! Bookmark not defined.
2. Introduction
This document describes the Software Requirement Specifications for the system called ‘Airline
Reservation’.
This current document, should be referred in the [SAD] ((Software Architecture Documentation)
to understand the requirement/design for the system.

2.1 Purpose
The purpose of this document is to present a detailed description of the Airline reservation system.
It will explain the objective and features of the system, the interfaces of the system, what the
system will do, the constraints under which it must operate and how the system will react to
external stimuli. This document is intended for both the stakeholders and the developers of the
system.
A Software has to be developed for automating the manual Airline Reservation System.

1. RESERVE SEATS – Reservation form has to be filled by passenger. If seats are

available entries like plane name, number, destination are made.
2. CANCEL RESERVATION- the Service User (employee) deletes the entry in
the System and changes in the Reservation Status.
3. MAKE PAYMENT-The user (passenger) makes payment to get tickets.
4. VIEW RESERVATION STATUS- The user (passenger) need to enter the
PIN number printed on ticket.
5. VIEW REPORTS-The Admin should be able to view reports.

2.2 Scope of Project

This software system will be a Web Publishing System for a local editor of a regional historical
society. This system will be designed to maximize the editor’s productivity by providing tools to
assist in automating the article review and publishing process, which would otherwise have to be
performed manually. By maximizing the editor’s work efficiency and production the system will
meet the editor’s needs while remaining easy to understand and use.
“Airline Reservation System” is an attempt to simulate the basic concepts of an online
Reservation system. The system enables to perform the following functions:

• SEARCH FOR PLANE

• BOOKING OF A SELECTED TRAVEL
• ONLINE PAYMENT (via CC)
• CANCELLATION
• REPORTING
1.1 REFERENCES

1.1.1 Websites:
 www.google.com

 www.wikipedia.org

1.1.2 Documents:

 Documentation.pdf

 IEEE- 830.pdf

 Software Engineering Seventh Edition Ian Sommerville

1.2 Assumptions and Dependencies

 The project was originally designed, tested and reviewed for QTP version 9.2. If you use
a different version of QTP, some screenshots might see different from yours. Be aware
that some functionality may not work in earlier versions of QTP.
 I will need MS-Excel installed on your computer, to create and modify datasheets files.
 You might need MS-Access to modify and view the flight application database. However
you can use "Snapshot Viewer for MS-Access" from Microsoft at
www/microsoft.com/downloads site. This software is free.
 From presentation one you will need the "Multi Test Manager" provided by HP/Mercury.
We will provide a download link fro this tool.
 We are assuming that you don’t have Quality-Center; this project was designed with no
interaction to Quality Center.

3. Use Case Model Survey:

3.1 Use Case Model

A use case diagram in the Unified Modelling Language (UML) is a type of behavioural diagram
defined by and created from a Use-case analysis. Its purpose is to present a graphical overview
of the functionality provided by a system in terms of actors, their goals (represented as use
cases), and any dependencies between those use cases. The main purpose of a use case diagram
is to show what system functions are performed for which actor. Roles of the actors in the system
can be depicted.
Interaction among actors is not shown on the use case diagram. If this interaction is essential to a
coherent description of the desired behaviour, perhaps the system or use case boundaries should
be re-examined. Alternatively, interaction among actors can be part of the assumptions used in
the use case.

6. Actors
An actor is a person, organization, or external system that plays a role in one or more interactions
with the system.

7. Use cases
A use case describes a sequence of actions that provide something of measurable value to an
actor and is drawn as a horizontal ellipse.

8. System boundary boxes(optional)

A rectangle is drawn around the use cases, called the system boundary box, to indicate its
scope of system. Anything within the box represents functionality that is in scope and
anything outside the box is not.

3.2 List of Actors and their description:

All the uses-case has one or more of the following actors: -
Administrator Administrator actor will interact with the system to configure, start,
stop and to view system log.

Passenger Moment Application will use system to send, receive and get status
of messages and get templates.

Booking Agent Via service provider system will send and receive moment
applications messages.

System System is Message Broker itself.

3.3 Use Case Model – Reservation Module:

Figure 3.1
3.4 Class Diagram:

Figure 3.2

4. Requirements:
4.2 Functional Requirements
Booking agents with varying levels of familiarity with computers will mostly use this system. With
this in mind, an important feature of this software is that it be relatively simple to use. The scope
of this project encompasses: -

1. Search: This function allows the booking agent to search for plane that are available between
the two travel cities, namely the "Departure city" and "Arrival city" as desired by the traveller.
 The system initially prompts the agent for the departure and arrival city, the date of departure,
preferred time slot and the number of passengers. It then displays a list of plane available with
different airlines between the designated cities on the specified date and time.
2. Selection: This function allows a particular plain to be selected from the displayed list. All
the details of the plane are shown :-
3. plane Number
4. Date, time and place of departure
5. Date, time and place of arrival
6. PLANE Duration
7. Fare per head
8. Number of stoppages – 0, 1, 2…
9. Review: If the seats are available, then the software prompts for the booking of plane. The
plane information is shown. The total fare including taxes is shown and flight details are
reviewed.
10. Traveler Information: It asks for the details of all the passengers supposed to travel including
name, address, telephone number and e-mail id.
11. Payment: It asks the agent to enter the various credit card details of the person making the
reservation.
12. Credit card type
13. Credit card number
14. CVC number of the card
15. Expiration date of the card
16. The name on the card
17. Cancellation: The system also allows the passenger to cancel an existing reservation. This
function registers the information regarding a passenger who has requested for a cancellation
of his/her ticket. It includes entries pertaining to the plane No., Confirmation No., Name, Date
of Journey, Fare deducted.

4.3 Non-Functional Requirements:

4.3.1 Security:
The system use SSL (secured socket layer) in all transactions that include any confidential
customer information. The system 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.

4.3.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 functioning
inside a container. Thus the overall stability of the system depends on the stability of container
and its underlying operating system.

4.3.3 Availability:
The system should be available at all times, meaning the user can access it using a web browser,
only restricted by the down time of the server on which the system runs. A customer friendly
system which is in access of people around the world should work 24 hours. In case of a of a
hardware failure or database corruption, a replacement page will be shown. Also in case of a
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 24 x 7
availability.

4.3.4 Maintainability:
A commercial database is used for maintaining the database and the application server takes care
of the site. In case of a failure, a re-initialization of the project will be done. Also the software
design is being done with modularity in mind so that maintainability can be done efficiently.

4.3.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.

4.3.6 User Manual and Samples

User manual will be written explain the functionality and configuration of Message Broker to the
end user. To help developer who will incorporate Message Broker in their application sample code
will be provided.

4.3.7 Communication Link

Message Broker will require intranet and internet access to communicate with moment application
and service providers respectively.

4.3.8 Environment
Message Broker will run as a service on Windows® XP or later.

4.3.9 Logging
Message Broker will log message information on status change for later referrals. Message
Broker will incorporate a mechanism to log all abnormal events during its execution.

4.3.10 Error Handling

All errors at the time of message initiation must be returned to the initiator. All errors during the
processing of message must be properly handled and logged.
DESIGN CONSTRAINTS
In case of changes made to the database ,the application should be able to show the updated
information on the website, without much delay .The database for the project is designed to be of
moderate size. Currently, the application is designed to be able to run in Internet Explorer. The
airline reservation system will be designed in such a way that, it can be run on a Windows 8/10
server. The .net technology will be used to code the project and sql server 2017 will act as the
databse for the project. The project will run on Google Chrome and it should be installed

DESIGN CONSTRAINTS:

5. Glossary:
A brief vocabulary of the terms used to describe the system.

Term Description

The system Refers to the entire Money Route product line (including IDR, Service Hub
and RAC).
System instance An installation of the system.

RRT Route Risk Trading. The owner company

Bank The term Bank refer to financial institutions that accept deposits from the
public and creates credit.

Remittance A remittance is a concept that describes transfer of money (usually) by a

foreign worker to an individual in his/her home country.
Remittance involves the source person, bank, non-bank financial
institutions usually referred as Money Services Business (MSB) and
beneficiary.

Financial The generalized concept refer to a bank or an MSB.

Institution

Risk Risk is potential evaluation of a person or an institution rating to assess a

chance of transferring money in secure hands.
Risk is usually assessed by person’s biodata, capabilities and historical
records.

Money According to the United States Treasury Department:

laundering Money laundering is the process of making illegally-gained proceeds (i.e.
"dirty money") appear legal (i.e. "clean").
Typically, it involves three steps: placement, layering and integration. First,
the illegitimate funds are furtively introduced into the legitimate financial
Term Description
system. Then, the money is moved around to create confusion, sometimes
by wiring or transferring through numerous accounts. Finally, it is integrated
into the financial system through additional transactions until the "dirty
money" appears "clean."

Anti-money Anti-money laundering (AML) is a term to describe the legal controls that
laundering require financial institutions to prevent, detect, and report money laundering
activities.
Anti-money laundering guidelines came into prominence globally as a
result of the formation of the Financial Action Task Force (FATF) and the
promulgation of an international framework of anti-money laundering
standards.

Reviewer A person that examines an article and has the ability to recommend
approval of the article for publication or to request that changes be made
in the article.

Software A document that completely describes all of the functions of a proposed

Requirements system and the constraints under which it must operate. For example, this
Specification document.

Stakeholder Any person with an interest in the project who is not a developer.

User Reviewer or Author.

Diagrams DFD : Data Flow Diagram

ERD : Entity Relationship Diagram
SRS : Software Requirements Specification
STD : State Transition Diagram