Online Railway Reservation System

Software Requirements
Specification
For
<ONLINE RAILWAY RESERVATION SYSTEM>
Prepared by
Zobia Aziz 121
Shafaq Javaid 081
Muniba Ashraf 185
Munaza Asif 069
Ali Raza 193
<LAHORE GARRISON UNIVERSITY >
<4 Jan 2016>
CONTENTS
Online Railway Reservation System

1. Introduction
------------------------------------------------------------------------------------------------------- 3
1.1.Purpose
----------------------------------------------------------------------------------------------------3
1.2.Scope
------------------------------------------------------------------------------------------------------- 3
1.3.Definitions, acronyms & abbreviations
--------------------------------------------------------------- 4
1.4.References
--------------------------------------------------------------------------------------------------- 4
1.5.Overview
----------------------------------------------------------------------------------------------------4
2. Overall
description----------------------------------------------------------------------------------------------- 5
2.1.Product perspective
----------------------------------------------------------------------------------------5
2.1.1. User interfaces
------------------------------------------------------------------------------------------ 6
2.1.2. Software
interfaces--------------------------------------------------------------------------------------6
2.1.3. Communications
interfaces----------------------------------------------------------------------------7
2.1.4. Memory
constraints--------------------------------------------------------------------------------------7
2.1.5.
Operations-------------------------------------------------------------------------------------------------7
2.1.6. Site adaptation
requirements---------------------------------------------------------------------------7
2.2.Product
functions---------------------------------------------------------------------------------------------7
2.3.User
characteristics----------------------------------------------------------------------------------------- 10
2.4.
Constraints---------------------------------------------------------------------------------------------------- 10
2 | Page

2.5.Assumptions and
dependencies--------------------------------------------------------------------------- 10
3. Specific Requirements
----------------------------------------------------------------------------------------------11
3.1 External interface requirements
-------------------------------------------------------------------------- 11
3.1.1 User interfaces
--------------------------------------------------------------------------------------------11
3.1.2 Software interfaces
-------------------------------------------------------------------------------------11
3.1.3 Communication
interfaces ------------------------------------------------------------------------------12
3.2 Performance requirements
----------------------------------------------------------------------------------12
3.3 Design constraints
----------------------------------------------------------------------------------------------12
3.5 Hardware Requirements
------------------------------------------------------------------------------------- 13
3.6 Software
Requirements--------------------------------------------------------------------------------------- 13
3.7 Other Requirements
--------------------------------------------------------------------------------------------14
3.8 Non Functional
--------------------------------------------------------------------------------------------------14
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.9 Diagrams
Use Case
---------------------------------------------------------------------------------------------------------15
Class
Diagram---------------------------------------------------------------------------------------------------16
State
Diagram---------------------------------------------------------------------------------------------------17
Sequence Diagram
--------------------------------------------------------------------------------------------18
3 | Page

DFD----------------------------------------------------------------------------------------------------------------19
1. INTRODUCTION
1.1.
PURPOSE
The purpose of this source is to describe the railway reservation system which
provides the train timing details, reservation, billing and cancellation on various types of
reservation namely,
Confirm Reservation for confirm Seat.
Reservation against Cancellation.
Waiting list Reservation.
Online Reservation.
The origin of most software systems is in the need of a client, who either wants to
automate the existing manual system or desires a new software system. The software
system is itself created by the developer. Finally, the end user will use the completed
system. Thus, there are three major parties interested in a new system: the client, the
user, and the developer. A few factors that direct us to develop a new system are given
below -:
1. Faster System
2. Accuracy
3. Reliability
4. Informative
5. Reservations and cancellations from anywhere to any place
1.2.
SCOPE
Railways 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 TRAIN
BOOKING OF A SELECTED FLIGHT
PAYMENT
4 | Page
1.3.
CANCELLATION
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS

TERM
DEFINITION
USER
Admin/Administrato
r
Web-Portal
Someone who interacts with system for ticketing purpose.

System administrator who is given specific permission for
managing and controlling the system
A web application which present special facilities for
admin.
Any person who has interaction with the system who is not
a developer.
Data Flow Diagram
Software Requirements Specification
Stakeholder
DFD
SRS
1.4. REFERENCES
[1] IEEE Software Engineering Standards Committee, IEEE Std 830-1998, IEEE
Recommended Practice for Software Requirements Specifications, October 20,
1998.
[2] https://www.scribd.com
[3] http://www.slideshare.net
[4] www.oocities.org
[5] www.about.com
1.5.
OVERVIEW
The remaining sections of this document provide a general description, including

characteristics of the users of this project, the product's hardware, and the
functional and data requirements of the product. General description of the project is
discussed in section 2 of this document. Section 3 gives the functional requirements,
data requirements and constraints and assumptions made while designing of it. It also
gives the user viewpoint of product. Section 3 also gives the specific requirements of
the product. Section 3 also discusses the external interface requirements and gives
detailed description of functional requirements. Section 4 is for supporting information.
5 | Page
2. OVERALL DESCRIPTION
This document contains the problem statement that the current system is facing. It lists
and briefly describes the major features and a brief description of the proposed system.
The online reservation System has its database centrally located. The online
reservation system involves three main actors the database, online operator and a
database scheduler. The database scheduler updates the database, the online operator
accepts and confirms the booking and updates the database.
2.1 PRODUCT PERSPECTIVE

EXISTING SYSTEM
The existing railway reservation system has many shortcoming associated with it.
In the existing system railway used to set train reservation levels higher than seating
capacity to compensate for passenger cancellation and no-shows accounting to
overbooking in the agent frequently to do so thus wasting time and money for all. With
the advent of the online reservation system these flaws can be overcome.
DISADVANTAGES OF EXISTING SYSTEM
High expensive
Time taken procedures and methods
No user friendly
PROPOSED SYSTEM
The new online reservation system maintains the database centrally giving the
clients the information required from anywhere in the country whenever required.
Through online reservation system customer is able to book & purchase a ticket thus
saving time money for the customer and an railway/agent. As the information is stored
centrally the customer never loses his ticket as in the existing system.
6 | Page

ADVANTAGES OF THE PROPOSED SYSTEM:
Significantly lower expenses

Time savings
More complete and more accurate data
Remote deployment to travelers and in many cases
2.1.1 USER INTERFACES

A first-time user should see the log-in page when he/she opens the site to reserve his/
her seat. see Figure 2. If the user has not registered, he/she should be able to do that
on the log-in page.
Every regular user should have a profile page where they can edit their e-mail address,
phone number and password, see Figure 4. Also, the user can set the preferred
language.
2.1.2 SOFTWARE INTERFACE

Front end -> Visual Basic
Back end -> MS-Access
Web portal
2.1.3 COMMUNICATION INTERFACES
7 | Page

Describe the requirement associated with any communications functions required
by this product, including email, web browser, network server communications
protocols, and electronic forms and so on. Define any pertinent message formatting.
Identify any communication standards that will be used, such as FTP OR HTTP. Specify
any communication
security or
encryption
issues,
data
transfer
rates,
and
synchronization mechanisms.
2.1.4 MEMORY CONSTRAINTS
The system is expected to have a memory capacity of 256 MB and disk space of
500 MB. But it is recommended that the system has a memory capacity of 1GB and disk
space of 1 GB.
2.1.5
OneOPERATION
form for 6 persons only.
Any reservation counter from 8am to pm and online 24 hours

One form for 6 persons only
To save time & queues agent is other guides
2.1.6save
Prior
One
SITE
form
to 90
ADAPTATION
for
days
6
ofcounter
Journey.
only.
REQUIREMENT
Any
Reservation
fromis8 others
am to 8guides.
pm.
To
time
& persons
queues
Agent
Site adaptation is necessary in with this project. Because the railway
reservation system is transported system. No external dependencies are in
place and operation of the system will never change due to location.
2.2 PRODUCT FUNCTIONS

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:
FULL GRAPHICAL INTERFACES FOR CONTROLLING YOUR SYSTEM

This software provide full graphical interface for controlling system.
8 | Page

BACK OFFICE MANAGEMENT AND ADMINISTRATION CONTROL
Back office areas within railway station are where your management team and
supervisors control how your business runs. Using advanced management tools it
allows you to make rapid changes to core data within the system, reacting to market
changes so that your system is positioned where it need to be.
Train Schedules, Fare Pricing, Service Fees, User Management and much more - all
fully managed and controlled using state-of-the-art interfaces in real time.
SEARCH
This function allows the booking agent to search for train 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 train available with different airlines between the designated cities on the specified
date and time. User also searches his favourite seat if it available he can reserve it
otherwise list of available seats appears and he can select from it.
SELECTION
This function allows a particular train to be selected from the displayed list. All the
details of the train are shown:
train Number
Date, time and place of departure
Date, time and place of arrival
TRAIN Duration
Fare per head
9 | Page
USER MANAGEMENT
OFFICE PROFILES
Each group of users is assigned an office from Call Centre, Ticket Offices,
Railway Stations, Res Control, and Revenue Management to Operations and controls
are assigned for each office to permit system use. Credit Limits controlling sales,
invoicing are all managed based on the office which users are assigned to.
USER PROFILES
An individual profile is set up for each user within an office which is used to
control access to different areas of the system, different functions and how the
system behaves based on that profile. With 99 levels of security and function
controls the system administrator can carefully regulate access and usability for
all users.
TRAVELLER INFORMATION
It asks for the details of all the passengers supposed to travel including name,
address, telephone number and e-mail id.
PAYMENT
It asks the agent to enter the various credit card details of the person making the
reservation.
Credit card type
Credit card number
CVC number of the card
10 | P a g e
Expiration date of the card
The name on the card
REPORTING MODULE
If customer facing any problem he can report it covering by Admin, Sales,
Finance, Res Control, Operations and Management Information. But with our customer
reporting module either IT staff or engineers can quickly modify reports or build entirely
new ones within minutes.
SECURITY
This system provides security using biometric system. Any traveler which identify
by biometric system can enter and travels.
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 train No., Confirmation No., Name,
Date of Journey, Fare deducted.
2.3 USER CHARACTERISTICS
EDUCATIONAL LEVEL
At least user of the system should be comfortable with English language.
TECHNICAL EXPERTISE:
User should be comfortable using general purpose applications on the
computer system.
2.4 CONSTRAINS
The system will run under windows 7 or higher platforms of operating system.
11 | P a g e

2.5 ASSUMPTIONS AND DEPENDENCIES
Booking Agents will be having a valid user name and password to access the
software.
The software needs booking agent to have complete knowledge of railways

reservation system.
Software is dependent on access to internet.
3. SPECIFIC REQUIREMENTS
3.1 External interface requirements
3.1.1 USER INTERFACES
A first-time user should see the log-in page when he/she opens the site to reserve his/
her seat. see Figure 2. If the user has not registered, he/she should be able to do that
on the log-in page.
Every regular user should have a profile page where they can edit their e-mail address,
phone number and password, see Figure 4. Also, the user can set the preferred
language.
12 | P a g e

3.1.2 SOFTWARE INTERFACE
Front end -> Visual Basic
Back end -> MS-Access
Web portal
3.1.3 COMMUNICATION INTERFACES
Describe the requirement associated with any communications functions required
by this product, including email, web browser, network server communications
protocols, and electronic forms and so on. Define any pertinent message formatting.
Identify any communication standards that will be used, such as FTP OR HTTP. Specify
any communication
security or
encryption
issues,
data
transfer
rates,
and
synchronization mechanisms.
FUNCTION REQUIREMENTS
3.2. Performance Requirements
User Satisfaction:- The system is such that it stands up to the user expectations.
Response Time:- The response of all the operation is good. This has been made
possible by careful programming.
Error Handling: - Response to user errors and undesired situations 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. The system safeguards against undesired events,
without human intervention.
Portable: - The software should not be architecture 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.3. DESIGN CONSTRAIN
13 | P a g e

There are a number of factors in the clients 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. An SRS (Software Requirements Analysis and Specification) should
identify and specify all such constraints.
Standard Compliance: - This specifies the requirements for the standards the system must
follow. The standards may include the report format and accounting properties.
Hardware Limitations :- The software may have to operate on some existing or predetermined
hardware, thus imposing restrictions on the design. Hardware limitations can include the types
of machines to be used, operating system available on the system, languages supported and
limits on primary and secondary storage.
Reliability and Fault Tolerance: - Fault tolerance requirements can place a major constraint on
how the system is to be designed. Fault tolerance requirements often make the system more
complex and expensive. Requirements about system behavior in the face of certain kinds of
faults are specified. Recovery requirements are often an integral part here, detailing what the
system should do I some failure occurs to ensure certain properties. Reliability requirements are
very important for critical applications.
Security: - Security requirements are particularly significant in defense systems and database
systems. They place restrictions on the use 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.
3.5.
HARDWARE REQUIREMENTS
For the hardware requirements the SRS specifies the logical characteristics of each interface
b/w the software product and the hardware components. It specifies the hardware requirements
like memory restrictions, cache size, the processor, RAM size etc... Those are required for the
software to run.
Hardware Requirements
Processor Pentium IV
Hard disk drive 80 GB
RAM 256 MB
Cache 512 kb
14 | P a g e

3.6.
SOFTWARE REQUIREMENTS
Any window based operating system with DOS support are primary requirements for software
development. Windows XP required. The systems must be connected via LAN
3.7.
Other requirements:
Software should satisfy following requirements as well
SECURITY
PORTABILITY
CORRECTNESS
EFFICIENCY
FLEXIBILTY
TESTABILTY
REUSABILTY
3.8. Non-Function Requirements

Security:
This system provides security using biometric system. 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 customers computer containing the users password. The systems backend servers shall only be accessible to authenticated management.
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.
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.
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
15 | P a g e

software design is being done with modularity in mind so that maintainability can be done
efficiently.
Supportability:
The code and supporting modules of the system will be well documented and easy to
understand online user documentation and help system requirements.
USE-CASE DIAGRAM
16 | P a g e
CLASS DIAGRAM
17 | P a g e
STATE DIAGRAM
18 | P a g e
SEQUENCE DIAGRAM
19 | P a g e
DATA FLOW DIAGRAM

Level 0:
Enter detail
20 | P a g e User
Get ticket
Railway
Reservation
Admin
Level 1:
Level 2:
21 | P a g e
Reservation
Apply for ticket
Check availability
Give availability
Admin
Conform ticket
Cancellation process
Apply for cancelation
User
Cancelation
Conform cancellation
Railway database
Cancelation
database
View detail
Details
Enter payment detail
Check status
Payment process
Payment done
Payment
22 | P a g e

Online Railway Reservation System

Uploaded by

Copyright:

Available Formats

Online Railway Reservation System

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Railway Reservation System

Uploaded by

Copyright:

Available Formats

Software Requirements

Zobia Aziz 121

Shafaq Javaid 081

Muniba Ashraf 185

Munaza Asif 069

Ali Raza 193

<LAHORE GARRISON UNIVERSITY >

<4 Jan 2016>