1).

Introduc on
1.1 Purpose of this document
1.2 Scope of this Document
1.3 Acronyms
1.4 References
1.5 Intended Audience and Reading Sugges ons
1.6 Document Overview
2). Overall descrip on
2.1 Product Perspec ve
2.2 Product Func ons
2.3 User Classes and Characteris cs
2.4 Opera ng Environment
2.5 Design and Implementa on Constraints
2.6 User Documenta on
2.7 Assump ons and Dependencies
3). External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 So ware Interfaces
3.4 Communica on Interfaces
4). Func onal Requirement Speci ca ons (FRS)
4.1 System Features
4.2 Func onal Requirements
4.2.1 Front end (Storefront) Requirements
4.2.2 Back end (Administra ve Tools) Requirements
4.3 Use Cases
4.3.1 Front end (Storefront)
4.3.2 Back end (Administra ve Tools)
5). Non-Fun onal Requirements
5.1 Usability Requirements
5.2 Performance Requirements
5.3 Compa bility Requirements
ti
ti
ft
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
 6). Other Requirements
7). Glossary

So ware Requirements Speci ca on document with example

A So ware Requirements Speci ca on (SRS) is a document that describes the nature of a project,
so ware or applica on. In simple words, SRS document is a manual of a project provided it is
prepared before you kick-start a project/applica on. This document is also known by the names SRS
report, so ware document. A so ware document is primarily prepared for a project, so ware or any
kind of applica on.

There are a set of guidelines to be followed while preparing the so ware requirement speci ca on
document. This includes the purpose, scope, func onal and nonfunc onal requirements, so ware
and hardware requirements of the project. In addi on to this, it also contains the informa on about
environmental condi ons required, safety and security requirements, so ware quality a ributes of
the project etc.

What is a So ware Requirements Speci ca on document?

A So ware requirements speci ca on document describes the intended purpose, requirements and
nature of a so ware to be developed. It also includes the yield and cost of the so ware.

In this document, ight management project is used as an example to explain few points.

Table of Contents
Contents in So ware Requirements Speci ca on document
ft
ft
ft
ft
ft
ft
ft
ft
ti
fl
ti
ti
fi
fi
fi
ft
ti
ti
ti
fi
fi
ti
ti
ti
ti
ti
ft
ti
ft
ft
ft
tt
ti
fi
ft
ti
 SRS report for a Lab Administra on project
Latest Technology Topics
1. INTRODUCTION
1.1 PURPOSE

The purpose of this document is to build an online system to manage ights and passengers to ease
the ight management. <<Include the purpose as applicable to your project >>

1.2 DOCUMENT CONVENTIONS

This document uses the following conven ons. <<Include the conven ons as per your applica on >>

DB Database
DDB Distributed Database
ER En ty Rela onship
1.3 INTENDED AUDIENCE AND READING SUGGESTIONS

This project is a prototype for the ight management system and it is restricted within the college
premises. This has been implemented under the guidance of college professors. This project is useful
for the ight management team and as well as to the passengers.

1.4 PROJECT SCOPE

The purpose of the online ight management system is to ease ight management and to create a
convenient and easy-to-use applica on for passengers, trying to buy airline ckets. The system is
based on a rela onal database with its ight management and reserva on func ons. We will have a
database server suppor ng hundreds of major ci es around the world as well as thousands of ights
by various airline companies. Above all, we hope to provide a comfortable user experience along
with the best pricing available.

1.5 REFERENCES

h ps://krazytech.com/projects
Fundamentals of database systems by ramez elmarsi and shamkant b.navathe
2. OVERALL DESCRIPTION
tt
fl
fl
ti
ti
ti
ti
fl
ti
fl
ti
fl
ti
ti
fl
ti
fl
ti
ti
ti
ti
fl
 2.1 PRODUCT PERSPECTIVE

A distributed airline database system stores the following informa on.

Flight details:
It includes the origina ng ight terminal and des na on terminal, along with the stops in between,
the number of seats booked/available seats between two des na ons etc.
Customer descrip on:
It includes customer code, name, address and phone number. This informa on may be used for
keeping the records of the customer for any emergency or for any other kind of informa on.
Reserva on descrip on:
It includes customer details, code number, ight number, date of booking, date of travel.
2.2 PRODUCT FEATURES

The major features of airline database system as shown in below en ty–rela onship model (ER
model)

layout of airline database system for so ware requirements speci ca on document

The diagram shows the layout of airline database system – en ty–rela onship model

2.3 USER CLASS and CHARACTERISTICS

Users of the system should be able to retrieve ight informa on between two given ci es with the
given date/ me of travel from the database. A route from city A to city B is a sequence of connec ng
ights from A to B such that: a) there are at most two connec ng stops, excluding the star ng city
and des na on city of the trip, b) the connec ng me is between one to two hours. The system will
support two types of user privileges, Customer, and Employee. Customers will have access to
customer func ons, and the employees will have access to both customer and ight management
func ons. The customer should be able to do the following func ons:

Make a new reserva on

• One-way
• Round-Trip
• Mul -city
fl
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fl
ft
fl
ti
fl
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
fl
ti
ti
ti
ti
 • Flexible Date/ me
• Con rma on
Cancel an exis ng reserva on
View his i nerary
The Employee should have following management func onali es:

CUSTOMER FUNCTIONS.
• Get all customers who have seats reserved on a given ight.
• Get all ights for a given airport.
• View ight schedule.
• Get all ights whose arrival and departure mes are on me/delayed.
• Calculate total sales for a given ight.
ADMINISTRATIVE
• Add/Delete a ight
• Add a new airport
• Update fare for ights.
• Add a new ight leg instance.
• Update departure/arrival mes for ight leg instances.
Each ight has a limited number of available seats. There are a number of ights which depart from
or arrive at di erent ci es on di erent dates and me.

2.4 OPERATING ENVIRONMENT

Opera ng environment for the airline management system is as listed below. <<Include the details
as per your applica on >>

distributed database
client/server system
Opera ng system: Windows.
database: sql+ database
pla orm: vb.net/Java/PHP
2.5 DESIGN and IMPLEMENTATION CONSTRAINTS
tf
fl
fi
ti
ti
fl
fl
fl
ti
ti
fl
ff
ti
fl
ti
fl
ti
ti
ti
ti
ff
fl
fl
ti
ti
ti
fl
ti
ti
fl
 The global schema, fragmenta on schema, and alloca on schema.
SQL commands for above queries/applica ons
How the response for applica on 1 and 2 will be generated. Assuming these are global queries.
Explain how various fragments will be combined to do so.
Implement the database at least using a centralized database management system.
2.6 ASSUMPTION DEPENDENCIES

Let us assume that this is a distributed airline management system and it is used in the following
applica on:

A request for booking/cancella on of a ight from any source to any des na on, giving connected
ights in case no direct ight between the speci ed Source-Des na on pair exist.
Calcula on of high iers (most frequent iers) and calcula ng appropriate reward points for these
iers.
Assuming both the transac ons are single transac ons, we have designed a distributed database
that is geographically dispersed at four ci es Delhi, Mumbai, Chennai, and Kolka a as shown in g.
below.

3. SYSTEM FEATURES
DESCRIPTION and PRIORITY
The airline reserva on system maintains informa on on ights, classes of seats, personal
preferences, prices, and bookings. Of course, this project has a high priority because it is very di cult
to travel across countries without prior reserva ons.

STIMULUS/RESPONSE SEQUENCES
Search for Airline Flights for two Travel ci es
Displays a detailed list of available ights and make a “Reserva on” or Book a cket on a par cular
ight.
Cancel an exis ng Reserva on.
FUNCTIONAL REQUIREMENTS
Other system features include:

DISTRIBUTED DATABASE:
fl
fl
fl
ti
ti
ti
ti
fl
fl
ti
ti
ti
ti
ti
fl
fl
fl
ti
ti
ti
ti
fi
ti
ti
ti
fl
ti
ti
ti
ti
ti
ti
ti
tt
ti
ffi
fi
 Distributed database implies that a single applica on should be able to operate transparently on
data that is spread across a variety of di erent databases and connected by a communica on
network as shown in below gure.

Distributed database located in four di erent ci es

Distributed database located in four di erent ci es

CLIENT/SERVER SYSTEM

The term client/server refers primarily to an architecture or logical division of responsibili es, the
client is the applica on (also known as the front-end), and the server is the DBMS (also known as the
back-end).

A client/server system is a distributed system in which,

Some sites are client sites and others are server sites.
All the data resides at the server sites.
All applica ons execute at the client sites.
4. EXTERNAL INTERFACE REQUIREMENTS
4.1 USER INTERFACES

Front-end so ware: Vb.net version

Back-end so ware: SQL+
4.2 HARDWARE INTERFACES

Windows.
A browser which supports CGI, HTML & Javascript.
4.3 SOFTWARE INTERFACES

Following are the so ware used for the ight management online applica on. <<Include the
so ware details as per your project >>

So ware used Descrip on

ft
ft
ti
ft
ft
ti
ft
ti
fi
ff
ff
ff
fl
ti
ti
ti
ti
ti
ti
 Opera ng system We have chosen Windows opera ng system for its best support and user-
friendliness.
Database To save the ight records, passengers records we have chosen SQL+ database.
VB.Net To implement the project we have chosen Vb.Net language for its more interac ve support.
4.4 COMMUNICATION INTERFACES

This project supports all types of web browsers. We are using simple electronic forms for the
reserva on forms, cket booking etc.

5. NONFUNCTIONAL REQUIREMENTS
5.1 PERFORMANCE REQUIREMENTS

The steps involved to perform the implementa on of airline database are as listed below.

A) E-R DIAGRAM

The E-R Diagram cons tutes a technique for represen ng the logical structure of a database in a
pictorial manner. This analysis is then used to organize data as a rela on, normalizing rela on and
nally obtaining a rela on database.

ENTITIES: Which specify dis nct real-world items in an applica on.

PROPERTIES/ATTRIBUTES: Which specify proper es of an en ty and rela onships.
RELATIONSHIPS: Which connect en es and represent meaningful dependencies between them.
The diagram shows the ER diagram of airline database
the diagram shows the ER diagram of airline database

B) NORMALIZATION:

The basic objec ve of normaliza on is to reduce redundancy which means that informa on is to be
stored only once. Storing informa on several mes leads to wastage of storage space and increase in
the total size of the data stored.

If a database is not properly designed it can give rise to modi ca on anomalies. Modi ca on
anomalies arise when data is added to, changed or deleted from a database table. Similarly, in
fi
ti
ti
ti
ti
ti
ti
ti
fl
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
fi
ti
ti
ti
ti
 tradi onal databases as well as improperly designed rela onal databases, data redundancy can be a
problem. These can be eliminated by normalizing a database.

Normaliza on is the process of breaking down a table into smaller tables. So that each table deals
with a single theme. There are three di erent kinds of modi ca ons of anomalies and formulated
the rst, second and third normal forms (3NF) is considered su cient for most prac cal purposes. It
should be considered only a er a thorough analysis and complete understanding of its implica ons.

5.2 SAFETY REQUIREMENTS

If there is extensive damage to a wide por on of the database due to catastrophic failure, such as a
disk crash, the recovery method restores a past copy of the database that was backed up to archival
storage (typically tape) and reconstructs a more current state by reapplying or redoing the
opera ons of commi ed transac ons from the backed up log, up to the me of failure.

5.3 SECURITY REQUIREMENTS

Security systems need database storage just like many other applica ons. However, the special
requirements of the security market mean that vendors must choose their database partner
carefully.

5.4 SOFTWARE QUALITY ATTRIBUTES

AVAILABILITY: The ight should be available on the speci ed date and speci ed me as many
customers are doing advance reserva ons.
CORRECTNESS: The ight should reach start from correct start terminal and should reach the correct
des na on.
MAINTAINABILITY: The administrators and ight in chargers should maintain correct schedules of
ights.
USABILITY: The ight schedules should sa sfy a maximum number of customers needs.
fl
ti
fi
ti
ti
ti
ti
fl
fl
fl
tt
ft
ti
ti
ff
ti
ti
fl
fi
ti
fi
ffi
ti
ti
ti
fi
ti
ti
ti