Software Engineering Project

On

“RAILWAY RESERVATION”

MAHARAJA AGRASEN INST.

OF TECHNOLOGY

Developed by

Name : Gaurav Gaur

Branch : C.S.E
Eroll no: 0101482707
 CONTENTS:

 Problem Statement

 Software Requirement Specification

 Use case diagram

 Use case description

 Activity Diagrams

 Sequence Diagrams

 Class Diagram

 Collaboration Diagram

 E-R Diagram
 PROBLEM STATEMENT FOR RAILWAY
RESERVATION SYSTEM
Software has to be developed for automating the manual
reservation system of railway.
The system should be standalone in nature.
It should be designed to provide functionalities like booking
of tickets in which a user should be able to applied for tickets
of any train and of any class.
A limitation is imposed when the number of tickets for which
user apply is greater then available seats or no seats are
available. If seats are not available then put user transaction
in the waiting queue.If the tickets are available then it is
issued to the user and it must be updated in the database
concurrently. The system generates the receipt for the
same.
The software takes the current system date and time as the
date of issue and calculates the amount to be paid by the
user.
It also provide the functionality of cancellation of tickets .If
the user wants to cancel the tickets, he/she must enter the
details. The system check the records from the database if it
is matched with the user entered details, then it cancels the
tickets.
The system also calculates the amount to be return to the
user after deductions. The system must update the database
for the same.
After that system must check for waiting passenger for that
train, if any then these tickets are issued to waiting
passenger and update the database.
The system displays the details of train of which user enter
the name.
The information is saved and the corresponding updating
take place in the database.
In the enquiry, the system should be able to provide
information like the availability of tickets of particular train,
train schedule.
The system should be able to reserve a ticket for a particular
user if the tickets are not currently available.
The corresponding print outs for each entry (issue/cancel) in
the system should be generated.
There should be proper information if the waiting list ticket is
confirmed, through mail or via sms.
It should tell us as to which all stations it haults and current
status of the train should be informed.
Security provisions like the login authenticity should be
provided. Each user should have a user id and a password.
Record of the users of the system should be kept in the log
file. Provision should be made for full backup of the system.
 SOFTWARE REQUIREMENT SPECIFICATION

1. INTRODUCTION

The document aims at defining the overall software requirements for” RAILWAY RESERVATION
SYSTEM”. Efforts are been made to define the requirement exhaustively and accurately. The final product
will be having only features/functionalities mentioned in this document and assumption for any additional
functionality/feature should not make by any of the parties involved in developing/testing/implementing
the products. In case it is required to have some additional features, a formal change request will need to be
raised and subsequently a new release of this document and/or product will be produced.

1.1 PURPOSE

This specification document describes the capabilities that will be provided by the software application
“RAILWAY RESERVATION SYSTEM”. It also states the various required constraints by which the
system will abide. The intended audience for this document is the development team, testing team and the
users of the produced.

1.2 SCOPE

The software “RAILWAY RESERVATION SYSTEM” will be an application that will be used for
automating the railway reservation system. This application will manage information about passengers
details regarding the reservation of seat in different class for different trains, cancellation of seats, waiting
lists of passengers, train schedule. The system also provides the facility to the passenger to check the time-
table of train, reservation level of the seat, waiting seat level.

This application will greatly improve the current manual system and will be much more efficient.

1.3 DEFINITIONS, ACRONYMS AND ABBREVATIONS

The following abbreviations have been used throughout:

DBA – Database Administrator

1.4 REFERENCES

(a) IEEE recommended practice for software requirements specifications-IEEE standard 1830-
1993.

1.5 OVERVIEW

The rest of this SRS document describes the various system requirements, interfaces and functionalities in
details.

2. OVERALL DESCRIPTION

RAILWAY TICKETING SYSTEM is the overall system used for the purpose of reservation of seat in
different class for different trains, cancellation of seats, waiting lists of passengers, train schedule, check
the time-table of train, reservation level of the seat, waiting seat level.

2.1 PRODUCT PERSPECTIVE

The application will be a windows-based, self-contained and independent software product.

2.1.1 SYSTEM INTERFACES

None

2.1.2 USER INTERFACES

The application will have a user friendly and menu based interface.
Following screens can be found:

(a) A login screen for entering the user name, ID number and password for the operator or the
user will be provided. Access to different screens will be based upon the role of the user.
(b) There will be a screen for capturing and displaying passenger details viz. name, age, sex,
address.
(c) There will be a screen for capturing and displaying info, regarding which seat is alotted to
which passenger, date & time of issue and the automatically calculated fare of the tickets
according to different class of ticket is issued.
(d) There will be a screen for capturing and displaying details of all the tickets are available of
the different classes of each train.
(e) There will be a screen for capturing and displaying details of user regarding reservation of
tickets.
(f) There will be a screen for capturing and displaying details of user regarding cancellation of
tickets.
Following lists will be generated:

(a) Passenger list: Printable list of all the passengers reserved for a particular train.
(b) Train list: Printable list of the all the trains along with their ID, starting junction as well as
destination spot.
(c) Train schedule list: printable list of the schedule of a given train.

2.1.3 HARDWARE INTERFACES

(a) Screen resolution of at least 800 X 600 is required for complete and proper viewing of
screens. Higher resolution will not be any problem.
(b) Support for printer: proper drivers must be installed and printer connected will be requested
for printing various above mentioned lists.
(c) Standalone or network based not a concern as it will be possible to run the application on
any of them.

SOFTWARE INTERFACES

(i) Any windows based operating system.

(ii) MS EXCESS 2000 as the DBMS for database future release of the application will aim at
upgrading to ORACLE-8i to DBMS.L
(iii) Crystal reports-8 for generating and viewing reports.
(iv) Visual basic for coding developing the software. The final application packages as an
independent setup program that will be delivered to the client.

2.1.4 COMMUNICATION INTERFACES

None

2.1.5 MEMORY CONSTRAINTS

At least 256 MB of RAM and 80 GB on hard disk will be required for running the application.

2.1.6 OPERATIONS

This product release will not cover any automated housekeeping aspects of the data base. The DBA at
the client site will be responsible for manually deleting old or non-required data.

2.1.7 SITE ADAPTATION REQUIREMENTS

The terminals at client site will have to support the hardware and software interfaces specified ` in the
above section.

2.2 PRODUCT PERSPECTIVE

The system will allow access to only authorized personnel. Depending on user’s role, he/she will be
able to excess only specific modules of the system. A summary of the major functions hat the software
will perform are:

(i) A login facility for enabling only authorized person to the system.
(ii) User (with role of DBA) will be able to add/modify/delete information about different
passengers that can have name in reservation list, waiting list , train schedule.
(iii) User (with role of a operator) will be able to access passengers details, fine details and
view monthly reports.

2.3 USER CHARACTERISTICS

(i) Educational Level: At least graduate should be comfortable with English Language.
(ii) Technical Expertise: Should be comfortable using general purpose applications on a
computer.

2.4 CONSTRAINTS

(i) Since the DBMS being used is MS EXCESS 2000, which is not a very powerful DBMS,
it will not be able to store a very large number of records.
(ii) Due to limited features of DBMS being used, performance tuning features will not be
applied to the queries and thus the system will become slow with the increase in number
of records being used.
(iii) Due to limited features of DBMS being used, database auditing will not be provided.

2.5 APPORTIONING OF REQUIREMENTS

None

3. SPECIFIC REQUIREMENTS

This section contains the software requirement to a level of detail sufficient to enable designers to
design the system and testers to test the system.

3.1 EXTERNAL INTERFACES

3.1.1 USER INTERFACES

The following screens will be provided:

(i) LOGIN SCREEN

 This will be the first screen to be displayed. It will allow user to access different screen
based upon the user’s role. Various fields available on this screen will be :

(a) User ID : Alphanumeric upto 10 characters

(b) Password : Alphanumeric of length upto 10 characters.
(c) Role.
(ii) PASSENGERS INFORMATION SCREEN

This screen is accessible to the data entry operator, controller. It allows the user with the
second role to add/modify/delete/records of passengers, train. The operator can access
and modify these details. The screen will display the list of passengers, their allotted seat
no., train no., and address.

(iii) TRAINS INFORMATION SCREEN

This screen is accessible to the data entry operator which allows to add/modify/delete
train details. This screen will display train no., seat no., number of seats in the train.

(iv) ISSUED TICKET SCREEN

This screen is accessible to the data entry operator. The user can add’/modify
information. Screen displays train name, train number, seat no., passengers name and
other details like issue date, time, number of seats of different class of different trains are
available.

3.1.2 HARDWARE INTERFACES

(i) Screen resolution of at least 800X600 is required for complete and proper viewing of
screens. Higher resolution will not be any problem.
(ii) Support for printer: Proper drivers must be installed and printer connected. Printer will be
requested for printing of monthly reports.
(iii) Standalone or network-based-not a concern as it will be possible to run the application of
any of them.

3.1.3 SOFTWARE INTERFACES

(i) Any windows based operating system

(ii) MS EXCESS-2000 as the DBMS for database future release of the application will aim at
upgrading to ORACLE-8i to DBMS.
(iii) Crystal reports-8 for generating and viewing reports.
(iv) Visual basic for coding developing the software. The final application packages as an
independent setup program that will be delivered to the client.

3.1.4 COMMUNICATION INTERCACES

None

3.2 SYSTEM FEATURES

3.2.1 PASSENGERS INFORMATION MANAGEMENT

DESCRIPTION

The system will maintain record of passengers name, age, address, allotted seat no., passenger
status either in reservation list or in waiting list. The system will allow
creation/modification/deletion of new or existing passengers .
 SEQUENCING INFORMATION

Passenger information for a particular passenger will have to be entered before any enquiry
details, cancellation details can be entered for the student.

ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS

If any of the above validations/sequencing flow does not hold true, appropriate error messages will
be prompted to the user for doing the needful.

VALIDITY CHECKS

(i) Only user with controller or data entry operator will be authorized to access the
passengers information management module.
(ii) Every passenger will have allotted a unique ticket number, seat number.
(iii) Seat number and passenger name can not be blank.

3.2.2 TRAINS INFORMATION MANAGEMENT

DESCRIPTION

The system will maintain information about the train name, train number. Number of seats in a, b,
and general class category. The system will allow creation/modification/deletion of new or
existing seats.

VALIDITY CHECKS

(i) Only user with role of controller or data entry operator can access this module.
(ii) Every seat has a unique number.
(iii) Seat number, class and train name can not be blank.

SEQUENCE INFORMATION

Ticket information will be present in the system before it can be issued.

ERROR HANDLING/RESPNOSE TO ABNORMAL SITUATIONS

If any of the above validations/sequencing flow does not hold true, appropriate error messages will
be prompted to the user for doing the needful.

3.2.3 ISSUED TICKETS MANAGEMENT

The system will maintain information about seats that are issued. Corresponding passenger details
and date of issue.

VALIDITY CHECKS

(i) Only user will role of controller or data entry operator can access issued book’s
information.
(ii) Date of issue must be entered as a six digit number.

SEQUENCE INFORMATION

Passenger information and seat information must be entered before a seat can be allotted . The
issue details must be present before the seat is cancelled.

ERROR HANDLING/RESPONSE TO ABNORMAL SITUATIONS

 If any of the above validations/sequencing flow does not hold true, appropriate error messages will
be prompted to the user for doing the needful.

3.2.4 CANCEL TICKET INFORMATION MANAGEMT

DESCRIPTION

The system will calculate refundable amount to passenger after suitable deductions, based on the
time with respect to validation of ticket & date of return.

VALIDITY CHECKS

(i) Date of return should be a valid six digit number.

(ii) It cannot be blank
(iii) Only controller & data entry operator can access this module

3.3 OTHER REQUIREMENTS

3.3.1 PERFORMANCE REQUIREMENTS

None

3.4 DESIGN CONSTRAINTS

None

3.5 SOFTWARE SYSTEM ATTRIBUTES

3.5.1 SECURITY

The application will be password protected. Users will have to enter correct username, password
and role to access the application.

3.5.2 MAINTAINABILITY

The application will be designed in a maintainable manner. It will be easy to in corporate new
requirements in the individual modules .

3.5.3 PORTABILITY

The application will be easily portable on any WINDOW based system that has MS-ACCESS
2000 installed.

3.6 LOGICAL DATABASE REQUIREMENTS

The following information will be placed in a database.

(i) Passenger information : name, age, sex, address.

(ii) Seat information : train number, seat number, number of seats in train.

3.7 OTHER REQUIREMENTS

None
 USE CASE DIAGRAM

Login

Enquiry

Operator User

Booking

Cancellation
 USE CASE DESCRIPTION

1. LOGIN

1.1 INTRODUCTION

This use case documents the procedure for logging into the Railway Reservation
System based on user privileges.

 Operator (Login, Enquiry, Booking, Cancellation).

 User (Login, Enquiry, Booking, Cancellation).

1.2 ACTORS

Operator, User

1.3 PRE-CONDITIONA

None

1.4 POST-CONDITION

If use case is successful, the user is logged into the system, otherwise the system state
is unchanged.

1.5 FLOW OF EVENTS

1.5.1 BASIC FLOW

 This use case starts when actor wishes to log into the Railway Reservation
System.

1. The system requests that the actor enters his/her user_id and password.
2. The actor enters user_id and password.
3. The system validates the user_id and password and checks for his/her
privileges.
4. If the actor is “operator”, he/she will be logged into the system and presented
with operator’s menu.
5. Otherwise, if the actor is “User”, he/she will be logged into the system and
presented with user’s menu.
6. The use case ends.

1.5.2 ALTERNATE FLOW

1.5.2.1 INVALID NAME/PASSWORD

If the system receives an invalid user_id or password, an error message is

displayed and the use case ends.

1.6 SPECIAL REQUIREMENTS

None

1.7 RELATED USE CASES

None

2. ENQUIRY

2.1 INTRODUCTION

This use case documents the procedure of ENQUIRY for following accounts :

1. Enquiry regarding trains

2. Enquiry for reservation status.

2.2 ACTORS

Operator, User.

2.3 PRE-CONDITION

Operator must be logged in to the system

2.4 POST-CONDITION
 If use case is successful, the user can get information regarding trains,reservation
Otherwise, the system state is unchanged.

2.5 FLOW OF EVENTS

2.5.1 BASIC FLOW

The use case starts when a system can get the enquiry from the user.
1. The system checks the type of enquiry
2. The system submits the user query to controller of the system .
3. The controller search the information from the database.
4. The resultant information is presented infront of the user.
5. The use case ends.

2.5.2 ALTERNATE FLOWS

2.5.2.1 INVALID ENQUIRY

If the user enter the wrong details ,then the system shows message according to
the query and the use case ends.

2.6 SPECIAL REQUIREMENT

None

2.7 RELATED USE CASES

None.

3. BOOKING

3.1 INTRODUCTION

This use case documents the procedure of booking of tickets and update the database
after each transaction .

3.2 ACTOR

Operator, User

3.3 PRE-CONDITION
 Operator/User must be logged into the system

3.4 POST-CONDITION

If the use case is successful, the ticket is issued to the passenger , otherwise the
system state is unchanged.

3.5 FLOW OF EVENTS

3.5.1 BASIC FLOW

1.This use case starts when a user enter train name.

2.The system read the information and check the availability of the seats.
3.If the seats are available ,the system execute the transaction .
4.The resultant information is updated in the data base.
5. The issue details are sent to the printer to generate the tickets.
6. The use case ends.

3.5.2 ALTERNATE FLOW

3.5.2.1 NON -AVAILABILTY

If the seats are not available the system sends the message accordingly ,and puts
the user transaction in waiting state ,and according to the priority the seats are
allotted to the users . The use case end here.

4. CANCELLATION

4.1 INTRODUCTION

This use case documents the procedure for canceling of issued tickets according to
the customer transaction.

4.2 ACTORS

Operator, User.

4.3 PRE-CONDITION

Operator/ user must be logged into the system.

 4.4 POST-CONDITION

If the use case is successful , the request or recommendation are fulfilled and
database is updated accordingly.

4.5 FLOW OF EVENTS

4.5.1 BASIC FLOW

This use case starts when a enters the details regarding canceling of tickets.

1. The system check the details regarding the query of the customer.
2. The system updates the train reservation status.
3. The system refunds the amount to the user after suitable deductions.
4. The system checks list of waiting passengers and allot the vacant seats.
5. The use case ends.

4.6 SPECIAL REQUIRMENTS

None

4.7 RELATED USE CASES

None
ACTIVITY DIAGRAM OF LOG IN
Enter User Name &
Password

Validation
If wrong Enter your
correct Password

If correct Password

Access User
Account

ACTIVITY DIAGRAM OF BOOKING

 request for a
booking

check whether a
seat is available No

Yes

add the name in

reserve the waiting list
seat

confirm
reservation

ACTIVITY DIAGRAM OF CANCELLATION

 get the details for
cancellation

update train
reservation status

refund the amount to the passenger

after suitable deductions

SEQUENCE DIAGRAM : BOOKING

Operator / User Booking Form Controller Train_detail Sorry message Passenger Passenger
box detail Train Detail

Enter1:
Train
name 2: name
Submit
3:
Get Train Detail

4:
Check availabil-

ity of seats
5:
Seat not available

6:
Add Record

Update7:Details

Update Details 8:
9:
Booking

Successfully

SEQUENCE DIAGRAM : CANCELLATION

 Operator / User Cancellation Controller Train Table Passenger Train
Form Detail Table

1:
Enter Train
2:
Details Submit Details
3:

Check Details
Cancel4:seat
Update table
Update5:table

6:
Cancellation
successful

SEQUENCE DIAGRAM : ENQUIRY

 User / Operator Enquiry Form Controller Train_master

1:
Enter Details
Submit2:Details
Search

3:

Show4:Train
Information

SEQUENCE DIAGRAM : LOGIN

 Operator / User Login Form Controller Login_Detail

1:
id,password
2: details
submit

3:
Get Login
details

4:

5: Check Login
Error or
Success

CLASS DIAGRAM : LOGOCAL VIEW

 Login_Detail Train_Master
Username Train id
Password Train Name
Capacity(I/II)
Add() Source
Delete() Destination
Update() Time
Days
Train_Details
Date Add()
Time Delete()
Train Name Update()
Available seats(I/II) GetDetails()

Add() Passenger_Train_Detail
Delete() Train Name
Update() Seat no.
GetDetails() Class(I/II)
date
Time
Passenger_Details
Add()
Passenger Name
Delete()
Address
Update()
Age
GetDetails()
Phone no.
Train Name

CLASS DIAGRAM : USE CASE VIEW / LOGIN DETAIL

 Login_Detail
Train_Master
M

M
Train_Details
M

Passenger_Train_Det...

M
M

Passenger_Details
M
M

COLLABORATION DIAGRAM : LOGIN

 1:
Operator / Login
User Form

5:
4:

2:

3:
Controller Login_Det
ail

COLLABORATION DIAGRAM : ENQUIRY

1:
Operator Enquiry
/user form

2:
4:

3:
Controlle Train
-r Master

COLLABORATION DIAGRAM: BOOKING

 4:

1: 2: 3:
Operator Booking Controll-- Train
/User form er 7 Detail
9:

6:
5:

Sorry Message
box Passenger Passenger
Detail Train Detail

7:
8: 7

COMPONENT VIEW : MAIN

 boundaries entities

Control

COMPONENT VIEW : MAIN

boundaries entities

Control

COMPONENT DIAGRAM : CONTROL/MAIN

 Train_ Train_
master Details

Passenger_T
Passenge rain_Details
r_Details

COMPONENT DIAGRAM : ENTITIES / MAIN

Login_details

E –R DIAGRAM