ONLINE

RESERVATION
SYSTEM FOR
RAILWAY
SOFTWARE REQUIREMENT SPECIFICATION:
TABLE OF CONTENTS:
1. INTRODUCTION
Purpose of the document
Scope of the document
Overview
2. GENERAL OVERVIEW
Product Functions
Similar system specifications
User problem specifications
User objectives
General objectives
3. FUNCTIONAL REQUIREMENTS
Description
Criticality
Technical issues
4. NON-FUNCTIONAL REQUIREMENTS
Security
Data encryption
a!imum "o#in attempts
Password Chan#e
Transaction $ecord
%utomatic user lo#out
aintainability
Problem reduction
%utomatic bac&ups
$eliability
%vailability
System availability
Portability
1. INTRODUCTION:
Pur!"# !$ %&# '!(u)#*%:
'n #eneral( purpose of the document is to describe its
purpose and its intended users) 't also specifies all possible re*uirements
accordin# to the user needs)

S(!# !$ %&# '!(u)#*%:
The scope of the document is to describe the developers
of the project of what the customer re*uires( additional re*uirements
which may prove e!istin#( what are the re*uirements that are mandatory)
This also describes about the constraints that where placed upon the
re*uirements elicitation process such as schedules( cost or the
environment to develop the re*uirements)
O+#r+,#-:
The document provides the overview of the final product
as a result of re*uirements elicitation process) So( the final product of
elicitation process is as follows+
,as the details re#ardin# the train)
Contains details about availability(concessions if
any)
Payment details)
2. GENERAL OVERVIEW:
Pr!'u(% $u*(%,!*":
This describes the #eneral functionality of the final
product) ,ere the functionality of the product is supposed to reduce the
pressure of the common end users who uses this software)
S,),./r "0"%#) "#(,$,(/%,!*:
This describes the relation of this product with any
other product) 't specifies if this product is intended to be stand-alone or
used as component of lar#er product) ,ere our product is a stand-alone
product)
U"#r (&/r/(%#r,"%,(":
This describes the feature of the user community
includin# the e!pected e!pertise with software system and the application
domain) ,ere( the user should have the basic &nowled#e of the online
reservation system)
U"#r r!1.#) "%/%#)#*%:
This describes the essential problem confronted by
the user community)
U"#r !12#(%,+#":
This describes the set of objectives and re*uirements for
the system from the user.s perspective) $e#ardin# the considered project
the user may wish to have a complete detail about the train)
G#*#r/. !12#(%,+#":
This list the #eneral constraints based upon the
desi#n team( includin# speed re*uirements( industry protocols( hardware
platform and so forth)
3. FUNCTIONAL REQUIREMENTS:
Functional re*uirements describe the possible effects of a software
system that is what a system must accomplish) Other &inds of
re*uirements such as interface( performance or reliability describe how
the system accomplishes the functional re*uirements)
S&!r% ,)#r/%,+# "#*%#*(# "%/%,*3 &,3&#"% r/*4#'
$u*(%,!*/. r#5u,r#)#*%":
Description +
% full description of the re*uirement is needed)
Criticality +
Describe the essential to the overall re*uirement of
the system because( based on the re*uirements only
decision of the further processin# of the project is decided)
Technical issues+
Describe any desi#n or implementation issues
involve in satisfyin# these re*uirements)
4. NON-FUNCTIONAL REQUIREMENTS:
S#(ur,%0:
System lo#in+
For user to lo#in it re*uires the valid lo#in and
password before #rantin# further access)
Data encryption+
The online reservation system encrypts all information
before writin# it into the database)
a!imum lo#in attempts+
This system allows the ma!imum of three consecutive
attempts)
Transaction recordin#s+
This system shall &eep a record of all failure lo#in
attempts with user lo#in( terminal lo#in and time)
M/,*%/,*/1,.,%0:
Problem reduction+
The major problem in the payroll system shall be
either resolved in two hours maintenance window)
%utomatic bac&ups+
The online reservation system shall perform
automatic bac&ups once per batch)
$eliability+
% simple measure of reliability is the sum of mean
time between failures /T0F1( mean time to failures
/TTF1 and mean time to return /TT$1)
A+/,./1,.,%0:
System availability+
't is the probability that the pro#ram is
operatin# accordin# to the re*uirements at any point of
time and it is defined as
%vailability23TTF 4/TTF5TT$167899:
P!r%/1,.,%0:
The payroll system is provided to different users
provided they meet the specified re*uirements)
US; C%S; D'%G$%+
D#$,*,%,!*:
% behavioral dia#ram that shows a set of use cases and actors and
their relationships is called a use case dia#ram) 't address the static use
case view of a system and important in modelin# the behavior of a system)
The major concepts involved in use case model are+
%ctor + an actor represents anythin# that interacts with the
system)
Use case + a use case is a se*uence of action a system
perform that yields a result to the actor)
$elation + it defines the relationship between actor and a
user)
The actors involved in the use case dia#ram are+
Passen#er
Train details D0/database1
$eservation D0
The use cases involved are+
"o#in
Chec& availability
Date
Train name
$eservation type
Fill and Submit form
a&e reservation
a&e cancellation
'ssue tic&et
USE CASE DIAGRAM DESCRIPTION:
L!3,*:
This function ensures that only authori<ed users #ain access of the
reservation) %n authori<ed user is one who has account on the system)
Users include passen#ers( railway officials and '$ ministry officials) The
user must #ive the valid user name and password)
I*u%": user name and password is a input #iven for the lo#in)
Ou%u%": the output is successful or unsuccessful lo#in)
Pr#(!*',%,!*: only authori<ed users can #ain access)
P!"% (!*',%,!*: should not affect the passen#er database)
B/",( $.!-: chec& the details of train accordin# to the desi#nation)
C&#(4 A+/,./1,.,%0:
This function allows seein# the trains includin# their source(
destination( available seats( arrival and departure time( tic&et amount)
I*u%"+ Train name)
S!ur(#+ the lo#in function is the source use)
Ou%u%"+ Train schedule and availability status is displayed)
Pr#(!*',%,!*+ The user should access web
B/",( $.!-: $eservin# the re*uired number of tic&ets)
M/4# R#"#r+/%,!*:
This function allows for ma&in# reservation for a particular train on
a particular date for certain number of tic&ets)
I*u%": Source( destination( reservation type( train name( date(
time and number of seats)
S!ur(#: User inputs about source( destination and train)
Ou%u%": The output is successful or unsuccessful reservation)
Pr#-(!*',%,!*: =alid information of train name and other details)
P!"% (!*',%,!*: Successful reservation added to passen#er D0)
B/",( $.!-: The user either pay amount or cancel reservation)
P/0 R#"#r+/%,!*:
This function allows the user pay for their reservation) The user
must input a valid credit card number to pay)
I*u%": Type of credit card( card number( card holder name and
phone number)
S!ur(#: The user provides all the necessary details)
Ou%u%": The tic&et will be displayed)
Pr# (!*',%,!*: =alid credit card)
P!"% (!*',%,!*: The Passen#er D0 updated and card balance will
be updated)
B/",( $.!-: The tic&et will be finali<ed)
I""u# T,(4#%:
This function allows issuin# the confirmed tic&et to the concerned
user)
I*u%": >il
S!ur(#: The valid details entered by user and payment paid)
Ou%u%: The tic&et will be displayed which can be printed)
Pr#-(!*',%,!*: Full payment should be paid)
P!"%-(!*',%,!*: The train details Db and passen#er details D0 are
updated)
B/",( $.!-: The print out of the tic&et is ta&en and ?uit)
Check avilability
Make cancellation
Issue ticket
Update databse
Fill and submit form
Login
Date
Train name
Reservation type
Train details D
ONLINE TIC6ET RESERVATION FOR RAILWAY
!assenger
!assenger D
make reservation !ay reservation
CLASS DIAGRAM:
D#$,*,%,!*:
Class dia#ram is also &nown as static structure dia#ram) 't is a
collection of static modelin# elements such as classes and their
relationships) Class dia#rams also show the attributes and operations of
the various classes and the constraints that apply to the way objects are
connected)
The various terminolo#ies used in the class dia#ram are as follows+
A33r#3/%# R#./%,!*"&,:
The a##re#ate relationship shows a whole and part of
relationship between two classes) The classes at the client end of the
a##re#ate relationship are sometimes called the a##re#ate class)
A""!(,/%,!* R#./%,!*"&,:
%n association provides a pathway for communication) The
types of association are+
Uni-directional
0i-directional
D##*'#*(0:
% dependency is a relationship between two model elements in
which a chan#e to one model element will affect the other model element)
G#*#r/.,7/%,!*:
% #enerali<ed relationship between classes shows that the
subclass shares the structure or behavior defined in one or more super
class)
C./"" N!%/%,!*:
The U" notation for class is a rectan#le divided into @ parts
Class >ame
%ttributes
Operations
I*%#r$/(#:
%n interface is a variation of a class) %n interface shares the
same features as a class) 'n other words( it contains attributes and
methods) The only difference is that the methods are only declared in the
interface and will be implemented by the class implementin# the
interface)
STATE C8ART DIAGRAM:
D#$,*,%,!*:
State dia#rams are used to help the developers to understand better
any comple!4unusual functionalities or business flows of speciali<ed areas
of the system) 'n short( state dia#rams depict the dynamic behavior of the
entire system( or a sub-system( or even a sin#le object in a system) This is
done with the help of behavioral elements)
0ehavioral ;lements of state dia#ram are+
I*,%,/. "%/%#: This shows the startin# point or first activity of the flow
denoted by a solid circle) This is also called as a "#u'! "%/%# where the
state has no variable describin# it further and has no activities)
S%/%#: 't represents the state of the object at an instant of time) 'n a state
dia#ram( there will be multiple of such symbols( one for each state of the
object) 't is denoted by rounded rectan#le with compartments)
Tr/*",%,!*: 't is a solid line with arrow head indicatin# the transition of
object from one state to another) Transitions of state that occur after the
completion of some event or action is called #uard condition) This #uard
condition or event is depicted by s*uare brac&ets around the description
of the event or action)
8,"%!r0 S%/%#": % flow may be such that the object #oes into a waitin#
state and on occurrence of certain event it #oes bac& to the state it was last
active) This is shown by the history state which is denoted by letter 8
enclosed in a circle) This is also a pseudo state)
E+#*% /*' A(%,!*: % tri##er that causes a transition to occur is called a
event or action) ;very transition need not occur due to the occurrence of
an event or action directly related to the state that transitioned from one
state to another) %n event4action is written above the transition that
causes it)
F,*/. S%/%#: The end of the state dia#ram is denoted by bull.s eye called
final state) % final state is also a pseudo state)
ACTIVITY DIAGRAM:
D#$,*,%,!*:
%n activity dia#ram is typically used for modelin# the se*uence of
activities in a process) 't provides a way to model the wor&flow of a
business process) %n activity dia#ram is basically a special case of a state
machine where most states are activities)
U",*3 A(%,+,%0 D,/3r/)":
%ctivity dia#ram can model many different types of wor&flows) For
e!ample( a company could use activity dia#rams to model the flow for an
payment dispatch)
U*'#r"%/*',*3 W!r4$.!-":
;ach activity represents the performance of a #roup of actions in a
wor&flow) Once the activity is complete( the flow of control moves to the
ne!t activity or state throu#h a transition) 'f an out#oin# transition is not
clearly tri##ered by an event( then it is tri##ered by the completion of the
contained actions inside the activity) % uni*ue activity dia#ram feature is a
swimlane that defines who or what is responsible for carryin# out the
activity or state) 't is also possible to place objects on activity dia#rams)
The wor&flow stops when a transition reaches an end state)
%ctivity dia#rams cannot reside within the component view it is mostly
attached in use case or lo#ical view)
SEQUENCE DIAGRAM:
D#$,*,%,!*:
% se*uence dia#ram is a #raphical view of a scenario that shows
object interaction in a time based se*uence as what happens first and
what happens ne!t) Se*uence dia#ram establish the roles of objects and
help provide essential information to determine class responsibilities and
interfaces) This type of dia#ram is best used durin# early analysis phases
in desi#n because they are simple and easy to comprehend) Se*uence
dia#rams are normally associated with use cases)
Se*uence dia#rams are closely related collaboration dia#rams and both
are alternate representations of an interaction) There are two main
differences between se*uence and collaboration dia#ram that is se*uence
dia#ram shows time-based object interaction while collaboration shows
how associate with each other object)
% se*uence dia#ram has two dimensions they are+
=ertical placement representin# %,)#
,ori<ontal placement representin# !12#(%"
T!!." !$ "#5u#*(# ',/3r/):
The followin# tools located on a se*uence dia#ram toolbo! enable
you to model se*uence dia#ram+
Object
essa#e icon
Focus of control
essa#e to self
>ote
>ote anchor
Swimlane
COLLABORATION DIAGRAM:
D#$,*,%,!*:
Collaboration dia#rams and se*uence dia#rams are alternate
representations of an interaction) % collaboration dia#ram is an
interaction dia#ram that shows the order of messa#es that implement an
operation or a transaction)
U",*3 C!../1!r/%,!* D,/3r/):
Collaboration dia#rams show objects( their lin&s and their messa#es)
They can also contain simple class instances and class utility instances)
;ach collaboration dia#ram provides a view of interactions or structural
relationships that occur between objects and object-li&e entities in the
current model)
Cr#/%,*3 C!../1!r/%,!* D,/3r/):
The create collaboration dia#ram command creates a collaboration
dia#ram from information contained in the se*uence dia#ram) The Goto
se*uence dia#ram and Goto collaboration dia#ram commands traverse
between an interaction.s two representations)
Collaboration dia#ram contain icons representin# objects) Aou can create
one or more collaboration dia#rams to depict interactions for each lo#ical
pac&a#e in your model) Such collaboration dia#rams are themselves
contained by the lo#ical pac&a#e enclosin# the objects they depict) %n
object specification enables you to display and modify the properties and
relationships of an object)
The associated dia#rams or specifications are automatically updated)
D#",3* show the semantics of mechanism in the lo#ical view and
A*/.0"," indicate the semantics of primary and secondary interactions)
Thus the collaboration dia#rams are used as the primary vehicle to
describe interactions that e!press your decisions about the behavior of the
system)