Project Report

Software Requirement Specification

ON
Railway Reservation and Management System
BACHELOR OF TECHNOLOGY
IN
COMPUTER SCIENCE AND ENGINEERING
Submitted by:
Annivesh Ashwin (17070122007)
Akshay Sharma (17070122006)
Abhimanyu Sharawat(17070122002)

Under the Guidance

Of
Professor: Pooja V Kamat
Symbiosis Institute of Technology, Pune 411215
Contents:
1.Introduction:
1.1 Purpose
1.2 Feasiblity Study
1.3 Intended Audience
1.4 Product Scope
1.5 Refernces
2.Overall Description:
2.1 Product Perspective
2.2 Product( High level) Functions
2.3 User Classes and Characteristics
2.4 Technology
2.5 Constraints
2.6 Process Model
2.7 Assumptions and Dependencies
3. Functional Requierements:
4. Furthur Improvements and Additions
 1. INTRODUCTION

1.1 Purpose
The main aim of this Project Report is to engineer a
management system for Railways. It focuses on the
reservation as well as management of various aspects of the
upcoming improvements in Railways. The aspects include
ticket reservation, food and beverages management system
and also includes information about the trains.
The Project also covers information like the management of
arrival and departure timings, stations and also the schedule
for delays.
1.2 Feasibility Study
Railways are the lifelines of the country. A major portion of
the population of our country commute from one place to
another by the convenience of railway network.
The management of the railway network is vital due to
dependency of a huge chunk of people. The proper
management of the arrival as well as departure of the trains
and also the ticket reservation is as important as the travel of
the population.
Hence this project will not only ensure but also help in the
proper conduction of the timetable and help in the
convenience of the people dependent on it.
1.3 Intended Audience
The Intended Audience for this Software include all those
people who use railways as a medium to travel and it includes
all the different categories of age group.
1.4 Product Scope
The Software will be a management system which can be
used to manage the reservation and the management of the rail
network.
The product will also include the information about the trains
like arrival and departure, timings as well as help to develop a
complete schedule for management of stations as well as
information about the starting station and the destination
according to the zones.
The product will be divided upon different zones of the
railway network and will manage each zone accordingly.
The zones could be North, South, East, and West. It will also
include sub zones like North Western, South Western, North
Eastern and South Eastern.
1.5 References
The References for the above project include Google Chrome,
Textbooks and other websites like:
1. IEEE SRS Format
2. Yatra.com
3. Irctc.co.in
4. Indianrail.gov.in
5. www.google.com
 2. OVERALL DESCRIPTION
This document contains the problem statement that the current
system is facing which is hampering the growth opportunities
of the company. It further contains a list of the stakeholders
and users of the proposed solution. It also illustrates the needs
and wants of the stakeholders that were identified in the
brainstorming exercise as part of the requirements workshop.
It further lists and briefly describes the major features and a
brief description of each of the proposed system.
2.1 Product Perspective

Before the automation, the system suffered from the following

DRAWBACKS:
Ø The existing system is highly manual involving a lot of
paper work and calculation
and therefore may be erroneous. This has lead to
inconsistency and inaccuracy in the
maintenance of data.
Ø The data, which is stored on the paper only, may be lost,
stolen or destroyed due to
natural calamity like fire and water.
 Ø The existing system is sluggish and consumes a lot of
time causing inconvenience
to customers and the airlines staff.

Ø Due to manual nature, it is difficult to update, delete, add

or view the data.
Ø Since the number of passengers have drastically
increased therefore maintaining
and retrieving detailed record of passenger is extremely
difficult.
Ø An railways has many offices around the world, an
absence of a link between these
offices lead to lack of coordination and communication.
Hence the railways reservation system is proposed with the
following
Ø The computerization of the reservation system will
reduce a lot of paperwork and
hence the load on the airline administrative staff.
Ø The machine performs all calculations. Hence chances of
error are nil.
Ø The passenger, reservation, cancellation list can easily be
retrieved and any
required addition, deletion or updation can be performed.
Ø The system provides for user-ID validation, hence
unauthorized access is
prevented.

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: -
¨ 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.
¨ Selection: This function allows a particular train to be
selected from the displayed list. All
the details of the train are shown :-
1. train Number
2. Date, time and place of departure
3. Date, time and place of arrival
4. TRAIN Duration
5. Fare per head
6. Number of stoppages – 0, 1, 2…
¨ Review: If the seats are available, then the software prompts
for the booking of train. The
train information is shown. The total fare including taxes is
shown and flight details are
reviewed.
¨ 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.
1. Credit card type
2. Credit card number
3. CVC number of the card
4. Expiration date of the card
5. The name on the card
¨ 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 Classes and Characteristics

Ø EDUCATIONAL LEVEL:-At least user of the system should
be comfortable with applications on the computer system.
English language.
Ø TECHNICAL EXPERTISE: - User should be comfortable using
general purpose applications on the computer system.

2.4 Constraints
Software constraints:
Ø The system will run under windows98 or higher platforms
of operating system.
2.5 Assumptions and Dependencies
Ø Booking Agents will be having a valid user name an
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.

2.6 Technology
The technology required to engineer this software are as
follows:
Core Java
SQL
Data Base Management System
Software Engineering
Data Structures and Algorithms
Hyper Text Markup Language
2.7 Process Model
The process model used for development of the following
software is Incremental Model. This is because this model
requires feedback distributed at each phase and hence we
require to know the feedback before incrementing further.
3. FUNCTIONAL REQUIEREMENTS

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 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.1.2 Design constraints:
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.
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 defence 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.1.3 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.
Minimum Hardware Requirements
Processor Pentium III
Hard disk drive 40 GB
RAM 128 MB
Cache 512 kb
Preferred Hardware Requirements
Processor Pentium IV
Hard disk drive 80 GB
RAM 256 MB
Cache 512 kb
3.1.4 Software requirements:
Any window based operating system with DOS support are
primary requirements for software development. Windows
XP, FrontPage and dumps are required. The systems must be
connected via LAN and connection to internet is mandatory.
3.1.5 other requirements:
Software should satisfy following requirements as well:-
SECURITY
Ø PORTABILITY
Ø CORRECTNESS
Ø EFFICIENCY
Ø FLEXIBILTY
Computer Engineering, BE-6 Page 15
Railway Reservation 15
Ø TESTABILTY
Ø REUSABILTY
3.2 Non-Function Requirements
3.2.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.
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 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 thestability of container and its underlying
operating system.
3.2.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
incase 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 x7 availablity.
3.2.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.
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 Requierements.