Case Study Railways

8/8/2019 Case Study Railways

1/11

PROBLEM STATEMENT

A software has to be developed for automating the manual

railway

reservation system. The system should have distributed

functionalities as

described below:-

1.RESERVE SEAT :- A passenger should be able to reserve a

seat in the train

specified by him if available. For this he has to fill a reservation

form with the

details about his journey. The clerk checks for the availability

ofthe seat in the

train and if the seat is available then he makes entries regardingtrain name,

train number, date of journey, boarding station, destination. The

passenger is

the asked to pay the fair .After making payment the passenger

can collect the

ticket from the clerk.

2.CANCEL RESERVATION:-There may arise a case when the

passenger wants to cancel his reservation .For this he has to fill a

cancellation form providing all the details about the ticket

reserved by

him. The clerk then checks for the entries from the database and


2/11

cancels

the reservation finally returning the ticket amount with some

deduction.

3.UPDATE TRAIN INFORMATION & REPORT

GENERATION :- Only

the Administrator has theright to make changes in train

details(train

name, train no. etc.).The system should also be able to generate

report

when needed in the form of reservation charts , train schedule

charts etc.4.

LOGIN: Only the user with specified login id & password can

get

access to the system. Thisprovides security from unauthorized

access.

5.

VIEW RESERVATION STATUS & TRAINSCHEDULE: All the users

should be able to see the information about the reservation status

& train

schedule, train name, train number etc

::USE CASE DIAGRAM


3/11

The use case diagram shows the functional aspects of the

system.The actors are shown with stick diagram & use

cases are shown by ovals.the arrows shows the

relationship between the actor and the use cases.


4/11


5/11

:CONTEXT DIAGRAM:

The context diagram shows the interaction between the

external

entities and the system.Here we dont deal with the internal

subprocesses of the system.

LEVEL-1 DATA FLOW DIAGRAM

Here the internal subprocesses of the system and their


6/11

interaction with the external entites is shown


7/11

Entity relationship dig:

DATA DICTIONARY

Data dictionary ensures that the customer and the developer use

the same definition and terminologies.

Passenger : information maintained abouteach

passenger


8/11

Passenger-details = courtesy title + passenger-name +

passenger-address + phone-no.

PNR No. = information maintained about particular

ticket.

Passenger-name= courtesy title + first-name +

(middle-name) + last-name.

Passenger-address = h-no +street-address + city +postal-code + (country).

First-name = 1{legal character}99.

Middle-name = 1{legal character}99.

Last-name = 1{legal character}99.

Phone-no ={legal number}.

PNR No. = {legal number}10

Legal character = [A-Z | a-z | 0-9 | | - ||]

Legal number = [0-9

Software Requirement Specification:


9/11

1.Intoduction:

1.1Purpose:The purpose of this case study is to describe the

railway reservation systemwhich provides the train timing details ,billing, reservation and

cancellation on various

types of reservation namely.

Confirm reservation for confirm seat.

Reservation against cancellation.

Waiting list reservation.

Online reservation.

Tatkal reservation.

1.2Document Conventions:

Main heading:Bold

1.3Intended Audience and reading suggestions:The different types of readers are:

(a).Customers

(b).Developers

(c).Management people

Specifically,

Passengers

Counter cler

2.1.4Operating Environment:

The OS types are:


10/11

Windows NT

Windows XP

Windows Vista

Windows 7

2.1.5Operations: Any reservation counter from 8 pmto 8am.

Prior to 60 days of journey.

One form for six persons.

Reserved ticket done through pre defined logic.

2.2Product Functions:

It tells the short note about the product.2.2.1Train Details:

Customers may view the train timing at a date their name and

number of tickets.

2.2.2Reservation:

After checking the number of seats available the customers

reserve the ticket.

2.2.3Billing:

After reserving the required amount of tickets,the customer paid

the amount.

2.2.4Cancelation:

Ifthe customer want to cancel the ticket then 10% ofthe amount

per person is deducted.

2.3 User characteristics:Knowledge user

No voice user

Expert user

2.4.Constraints


11/11

Less than 1 sec for local transactions.

3 sec for network trasnsaction.

Uptime of PRS is99.5+%.

Case Study Railways

Documents

Transcript of Case Study Railways