PROJECT NAME

A PROJECT REPORT

For

MBAB 418: MODELING AND DESIGN LAB

Submitted by

JISHNU P Register Number: 22381018

DURGA PRASATH Register Number: 22381012

SANDRA RAJESH Register Number: 22381040

SULFATH A A Register Number:22381048

RAMYA R Register Number:22381038

DEPARTMENT OF BANKING TECHNOLOGY

SCHOOL OF MANAGEMENT

1|Page
 PONDICHERRY UNIVERSITY, PONDICHERRY- 14

DEPARTMENT OF BANKING TECHNOLOGY

SCHOOL OF MANAGEMENT

PONDICHERRY UNIVERSITY

BONAFIDE CERTIFICATE
This is to certify that the project work entitled “ SRS FOR RAILWAY
RESERVATION SYSTEM ” is a bonafide work done by JISHNU P [Register
Number: 22381018], DURGA PRASATH [Register Number: 22381012], SANDRA
RAJESH [Register Number: 22381040], SULFATH A A [Register Number:
22381048], RAMYA R [Register Number: 22381038], in partial fulfillment of the
requirement for Modeling and Design Lab (MBAB 418) by Pondicherry
University during the academic year 2022-2024.

HEAD OF THE DEPARTMENT FACULTY INCHARGE

Dr. V. Mariappan Dr. A. Suganthy,
Assistant Professor,
Dept of Banking Technology.

Submitted for the University End Semester Lab Examination held on ………….

INTERNAL EXAMINER EXTERNAL EXAMINER

2|Page
 ACKNOWLEDGEMENT

We express our sincere thanks to our beloved Vice Chancellor Prof.

Gurmeet Singh for having provided necessary facilities and encouragement for
successful completion of this project work.
We express our sincere thanks to Dr. V. Mariappan, Head of the
Department, Banking Technology, for his support in making necessary
arrangements for the conduction of project and also for guiding us to execute
our project successfully.
We express our sincere thanks to Dr. A. Suganthy, Assistant Professor,
Banking Technology, for his consistent reviews which motivated us in
completing project.
We thank all our department faculty members, non-teaching staffs and
my friends of Banking Technology Department for helping us to complete the
documents successfully on time.
We would like to express our eternal gratitude to our parents for the
sacrifices they made for educating and preparing us for our future and their
everlasting love and support.
We thank the Almighty for blessing us with such wonderful people and for
being with us always.

3|Page
 Table of Contents

1.INTRODUCTION
1.1. Objective
1.2. Scope
1.3. Glossary
1.4. Overview

2.OVERALL DESCRIPTION
2.1. Product Perspective
2.2. Product Functions
2.3. User Characteristics
2.4. Constrains
2.5. Assumptions and Dependencies
2.6. Apportioning of requirements

3.REQUIREMENT SPECIFICATION
3.1. Function Requirements
3.1.1 Design Constraints
3.1.2 Hardware Requirements
3.1.3 Software Requirements
3.1.4 Other Requirements

4|Page
 3.2. Non-Function Requirements
3.2.1 Performance Requirements
3.2.2 Security
3.2.3 Reliability
3.2.4 Availability
3.2.5 Maintainability
3.2.6 Supportability

4. DIAGRAM
4.1. Use Case Diagram
4.2. Class Diagram
4.3. State Diagram
4.4. Sequence Diagram
4.5. Activity Diagram
4.6. Package Diagram
4.7. Design Diagram
4.8. Collaboration Diagram
4.9. Deployment Diagram

5. REFERENCES

5|Page
Introduction

6|Page
 1.Introduction

Software Requirement Specification (SRS) – a requirements

specification for a system software- is a complete description of the
behaviour of a system to be developed. It includes a set of use cases
that describe all the interactions the users will have with the software.
In addition to use cases, the SRS also contains non-functional
requirements. Non-functional requirements are requirements which
impose constraints on the design or implementation. This is a
documentation of the project Railway Reservation System. A
software has to be developed for automating the manual Railway
Reservation System.
• RESERVE SEATS – Reservation form has to be filled by
passenger. If seats are available entries like train name, number,
destination are made.
• CANCEL RESERVATION – The clerk deletes the entry in the
system and changes in the Reservation Status.
• VIEW RESERVATION STATUS – The user need to enter the
PIN number printed on the ticket.

1.1 Objective
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 timely.
• Confirm reservation for confirm seat
• Reservation against cancellation
• Waiting list reservation
• Online reservation
• Tatkal reservation

7|Page
The basic purpose of Software Requirement Specification (SRS) is to
bridge the communication gap. SRS is the medium through the
client’s and the user’s needs are accurately specified; indeed SRS
forms the basis of software development.
Another important purpose of developing an SRS is helping their
clients understanding their own needs. An SRS establishes the basis
for agreement between the client and the supplier on what the
software product will do.
An SRS provides a reference for the validation of the final product. A
high-quality SRS is a prerequisite to high quality software and it also
reduces the development cost.

1.2 Scope
“Railway Reservation System” is an attempt to stimulate 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
• Cancellation
• Freight revenue enhancement
• Passenger revenue enhancement
• Improved and optimized service

1.3 Glossary
This should define all technical terms and abbreviations used in the
document
➢ NTES – National Train Enquiry System
➢ IVRS – Interactive Voice Response System
➢ PRS – Passenger Reservation System

8|Page
 ➢ DFD – Data Flow Diagram
➢ ERD – Entity Relationship Diagram
➢ SRS – Software Requirement Specification
➢ STD – Software Requirement Specification

1.4 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 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 are made while
designing the E-Store. 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.

9|Page
Overall Description

10 | P a g e
 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 data which is stored on the paper only, may be lost, stolen,
or destroyed due to natural calamity like fire and water.
• The existing 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.
• The existing system is highly manual involving a lot of paper
work and calculation and therefore maybe erroneous. This has
led to inconsistency and inaccuracy in the maintenance of data.
• A railway 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 system provides for user-id validation, hence authorized
access is prevented.
• The machine performs all calculations. Hence chances of errors
are nil.

11 | P a g e
 • The computerization of the reservation system will reduce a lot
of paperwork and hence the load on the airline administrative
staff.
• The passenger reservation and cancellation list can be easily
retrieved and any required addition, deletion or updating can be
performed.

2.2 Project 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 simply 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.
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. Fair per head
6. Number of stopes
Review: If the seats are available, 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
email id.
Payment: It asks the agent to enter the various credit card details of
the person making the reservation.

12 | P a g e
 1. Credit card type
2. Credit card number
3. CVC number of the number
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.

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
Software constraints:
• The system will run under windows9,8 or higher platforms of
operating system.

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

13 | P a g e
Requirement Specification

14 | P a g e
 3.REQUIREMENT SPECIFICATION

3.1 Function Requirements

3.1.1 Design constrain

There are 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 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.
❖ 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.
15 | P a g e
3.1.2 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 111
Hardware disk drive 40 GB
RAM 128mb
Cache 512kb

Preferred Hardware Requirements

Processor Pentium 1V
RAM 256MB
Cache 512kb

3.1.3 Software requirements

• Any windows-based operating system with DOS support are
primary requirements for software development. Windows XP,
Frontpage and dumps are required. The system must be
connected via LAN and connection to internet is mandatory.

16 | P a g e
3.1.4 Other requirements
• Security
• Portability
• Correctness
• Efficiency
• Flexibility
• Testability
• Reusability

3.2 Non- Function requirements

3.2.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 to ensure that the system operates
without halting.
• Safety and resources: The system is able to avoid and tackle
disastrous action. 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 friendly: The system is easy to learn and understand. A
native user can also use the system effectively, without any
difficulties.

17 | P a g e
3.2.2 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 customers computer
containing the user’s password. The system back-end servers shall
only be accessible to authenticated management.

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

3.2.4 Availability
The systems should be available in 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 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.

18 | P a g e
3.2.5 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.6 Supportability
The code and supporting modules of the system will be well
documented and easy to understand. Online user documentation and
help system requirements.

19 | P a g e
Diagram

20 | P a g e
 4.1 Use-case Diagram

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 use case diagram is to show what system
functions are performed for which actor. Roles the actors in the
system can be depicted.

21 | P a g e
 4.2 Class Diagram
The class diagram depicts a static view of an application. It
represents the types of objects residing in the system and the
relationships between them. It shows the attributes, classes,
functions, and relationships to give an overview of the software
system.

22 | P a g e
 4.3 State Diagram

A state machine diagram models the behaviour of a single

object, specifying the sequence of events that an object goes
through during its lifetime in response to events.

23 | P a g e
 4.4 Sequence Diagram

This is the UML sequence diagram of RAILWAY RESERVATION

SYSTEM application which shows various kinds of interactions
between the objects. It depicts all the objects involved in the
scenario. It is typically associated with use case realizations.

24 | P a g e
 4.5 Activity Diagram

Activity diagram is another important behavioral diagram

in UML diagram to describe dynamic aspects of the system. Activity
diagram is essentially an advanced version of flow chart that
modeling the flow from one activity to another activity.

25 | P a g e
 4.6 Package Diagram

A package diagram in the Unified Modeling Language depicts

the dependencies between the packages that make up a
model.

26 | P a g e
4.7 Design Diagram

27 | P a g e
 4.8 Collaboration Diagram

A Collaboration Diagram is a diagram that shows object interactions

organized around the objects and their links to each other. They are
very useful for visualizing the relationships.

28 | P a g e
 4.9 Deployment Diagram

Deployment diagram visualizes the application and is used to

describe the hardware components. It also describes the runtime
processing nodes.

29 | P a g e
5. References

1.IEEEE SRS Format

2. Yatra.com
3. Irctc.co.in
4.Indianrail.gov.in
5. www.google.com

30 | P a g e