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
 Maximum Login attempts
 Password Change
 Transaction Record
 Automatic user logout
 Maintainability
 Problem reduction
 Automatic backups
 Reliability
 Availability
 System availability
 Portability
1. INTRODUCTION:

 Purpose of the document:

In general, purpose of the document is to describe its
purpose and its intended users. It also specifies all possible requirements
according to the user needs.

 Scope of the document:

The scope of the document is to describe the developers
of the project of what the customer requires, additional requirements
which may prove existing, what are the requirements that are mandatory.
This also describes about the constraints that where placed upon the
requirements elicitation process such as schedules, cost or the
environment to develop the requirements.

 Overview:
The document provides the overview of the final product
as a result of requirements elicitation process. So, the final product of
elicitation process is as follows:

 Has the details regarding the train.

 Contains details about availability,concessions if
any.
 Payment details.

2. GENERAL OVERVIEW:

 Product functions:
This describes the general functionality of the final
product. Here the functionality of the product is supposed to reduce the
pressure of the common end users who uses this software.

 Similar system specification:

This describes the relation of this product with any
other product. It specifies if this product is intended to be stand-alone or
used as component of larger product. Here our product is a stand-alone
product.

 User characteristics:
 This describes the feature of the user community
including the expected expertise with software system and the application
domain. Here, the user should have the basic knowledge of the online
reservation system.

 User problem statement:

This describes the essential problem confronted by
the user community.

 User objectives:
This describes the set of objectives and requirements for
the system from the user’s perspective. Regarding the considered project
the user may wish to have a complete detail about the train.

 General objectives:
This list the general constraints based upon the
design team, including speed requirements, industry protocols, hardware
platform and so forth.

3. FUNCTIONAL REQUIREMENTS:

Functional requirements describe the possible effects of a software

system that is what a system must accomplish. Other kinds of
requirements such as interface, performance or reliability describe how
the system accomplishes the functional requirements.

 Short imperative sentence stating highest ranked

functional requirements:

 Description:
A full description of the requirement is needed.
 Criticality:
Describe the essential to the overall requirement of
the system because, based on the requirements only
decision of the further processing of the project is decided.
 Technical issues:
Describe any design or implementation issues
involve in satisfying these requirements.
4. NON-FUNCTIONAL REQUIREMENTS:

 Security:

 System login:
For user to login it requires the valid login and
password before granting further access.
 Data encryption:
The online reservation system encrypts all information
before writing it into the database.
 Maximum login attempts:
This system allows the maximum of three consecutive
attempts.
 Transaction recordings:
This system shall keep a record of all failure login
attempts with user login, terminal login and time.

 Maintainability:

 Problem reduction:
The major problem in the payroll system shall be
either resolved in two hours maintenance window.
 Automatic backups:
The online reservation system shall perform
automatic backups once per batch.
 Reliability:
A simple measure of reliability is the sum of mean
time between failures (MTBF), mean time to failures
(MTTF) and mean time to return (MTTR).

 Availability:

 System availability:
It is the probability that the program is
operating according to the requirements at any point of
time and it is defined as
Availability=[MTTF /(MTTF+MTTR)]*100%

 Portability:
 The payroll system is provided to different users
provided they meet the specified requirements.

USE CASE DIAGRAM:

Definition:

A behavioral diagram that shows a set of use cases and actors and
their relationships is called a use case diagram. It address the static use
case view of a system and important in modeling the behavior of a system.

The major concepts involved in use case model are:

 Actor: an actor represents anything that interacts with the

system.
 Use case: a use case is a sequence of action a system
perform that yields a result to the actor.
 Relation: it defines the relationship between actor and a
user.

The actors involved in the use case diagram are:

 Passenger
 Train details DB(database)
 Reservation DB

The use cases involved are:

 Login
 Check availability
 Date
 Train name
 Reservation type
 Fill and Submit form
 Make reservation
 Make cancellation
 Issue ticket
USE CASE DIAGRAM DESCRIPTION:

Login:

This function ensures that only authorized users gain access of the
reservation. An authorized user is one who has account on the system.
Users include passengers, railway officials and IRM ministry officials. The
user must give the valid user name and password.

• Inputs: user name and password is a input given for the login.
• Outputs: the output is successful or unsuccessful login.
• Precondition: only authorized users can gain access.
• Post condition: should not affect the passenger database.
• Basic flow: check the details of train according to the designation.

Check Availability:

This function allows seeing the trains including their source,

destination, available seats, arrival and departure time, ticket amount.

 Inputs: Train name.

 Source: the login function is the source use.
 Outputs: Train schedule and availability status is displayed.
 Precondition: The user should access web
 Basic flow: Reserving the required number of tickets.

Make Reservation:

This function allows for making reservation for a particular train on

a particular date for certain number of tickets.

 Inputs: Source, destination, reservation type, train name, date,

time and number of seats.
 Source: User inputs about source, destination and train.
 Outputs: The output is successful or unsuccessful reservation.
 Pre-condition: Valid information of train name and other details.
  Post condition: Successful reservation added to passenger DB.
 Basic flow: The user either pay amount or cancel reservation.

Pay Reservation:

This function allows the user pay for their reservation. The user
must input a valid credit card number to pay.

 Inputs: Type of credit card, card number, card holder name and
phone number.
 Source: The user provides all the necessary details.
 Outputs: The ticket will be displayed.
 Pre condition: Valid credit card.
 Post condition: The Passenger DB updated and card balance will
be updated.
 Basic flow: The ticket will be finalized.

Issue Ticket:

This function allows issuing the confirmed ticket to the concerned

user.

 Inputs: Nil
 Source: The valid details entered by user and payment paid.
 Output: The ticket will be displayed which can be printed.
 Pre-condition: Full payment should be paid.
 Post-condition: The train details Db and passenger details DB are
updated.
 Basic flow: The print out of the ticket is taken and Quit.
 ONLINE TICKET RESERVATION FOR RAILWAY

Login
Date

Train name
Train details DB
Check avilability

Reservation type

Fill and submit form

Passenger

make reservation Pay reservation

Passenger DB

Make cancellation Update databse

Issue ticket
CLASS DIAGRAM:
Definition:

Class diagram is also known as static structure diagram. It is a

collection of static modeling elements such as classes and their
relationships. Class diagrams also show the attributes and operations of
the various classes and the constraints that apply to the way objects are
connected.

The various terminologies used in the class diagram are as follows:

Aggregate Relationship:

The aggregate relationship shows a whole and part of

relationship between two classes. The classes at the client end of the
aggregate relationship are sometimes called the aggregate class.

Association Relationship:

An association provides a pathway for communication. The

types of association are:
• Uni-directional
• Bi-directional

Dependency:

A dependency is a relationship between two model elements in

which a change to one model element will affect the other model element.

Generalization:

A generalized relationship between classes shows that the

subclass shares the structure or behavior defined in one or more super
class.

Class Notation:

The UML notation for class is a rectangle divided into 3 parts

 Class Name
 Attributes
  Operations
Interface:

An interface is a variation of a class. An interface shares the

same features as a class. In 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 implementing the
interface.
STATE CHART DIAGRAM:
Definition:

State diagrams are used to help the developers to understand better

any complex/unusual functionalities or business flows of specialized areas
of the system. In short, state diagrams depict the dynamic behavior of the
entire system, or a sub-system, or even a single object in a system. This is
done with the help of behavioral elements.

Behavioral Elements of state diagram are:

Initial state: This shows the starting point or first activity of the flow
denoted by a solid circle. This is also called as a pseudo state where the
state has no variable describing it further and has no activities.

State: It represents the state of the object at an instant of time. In a state

diagram, there will be multiple of such symbols, one for each state of the
object. It is denoted by rounded rectangle with compartments.

Transition: It is a solid line with arrow head indicating the transition of

object from one state to another. Transitions of state that occur after the
completion of some event or action is called guard condition. This guard
condition or event is depicted by square brackets around the description
of the event or action.

History States: A flow may be such that the object goes into a waiting
state and on occurrence of certain event it goes back to the state it was last
active. This is shown by the history state which is denoted by letter H
enclosed in a circle. This is also a pseudo state.

Event and Action: A trigger that causes a transition to occur is called a

event or action. Every 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. An event/action is written above the transition that
causes it.

Final State: The end of the state diagram is denoted by bull’s eye called
final state. A final state is also a pseudo state.
ACTIVITY DIAGRAM:
Definition:

An activity diagram is typically used for modeling the sequence of

activities in a process. It provides a way to model the workflow of a
business process. An activity diagram is basically a special case of a state
machine where most states are activities.

Using Activity Diagrams:

Activity diagram can model many different types of workflows. For

example, a company could use activity diagrams to model the flow for an
payment dispatch.

Understanding Workflows:

Each activity represents the performance of a group of actions in a

workflow. Once the activity is complete, the flow of control moves to the
next activity or state through a transition. If an outgoing transition is not
clearly triggered by an event, then it is triggered by the completion of the
contained actions inside the activity. A unique activity diagram feature is a
swimlane that defines who or what is responsible for carrying out the
activity or state. It is also possible to place objects on activity diagrams.
The workflow stops when a transition reaches an end state.

Activity diagrams cannot reside within the component view it is mostly

attached in use case or logical view.
SEQUENCE DIAGRAM:
Definition:

A sequence diagram is a graphical view of a scenario that shows

object interaction in a time based sequence as what happens first and
what happens next. Sequence diagram establish the roles of objects and
help provide essential information to determine class responsibilities and
interfaces. This type of diagram is best used during early analysis phases
in design because they are simple and easy to comprehend. Sequence
diagrams are normally associated with use cases.

Sequence diagrams are closely related collaboration diagrams and both

are alternate representations of an interaction. There are two main
differences between sequence and collaboration diagram that is sequence
diagram shows time-based object interaction while collaboration shows
how associate with each other object.

A sequence diagram has two dimensions they are:

 Vertical placement representing time

 Horizontal placement representing objects

Tools of sequence diagram:

The following tools located on a sequence diagram toolbox enable

you to model sequence diagram:

 Object
 Message icon
 Focus of control
 Message to self
 Note
 Note anchor
 Swimlane
COLLABORATION DIAGRAM:
Definition:

Collaboration diagrams and sequence diagrams are alternate

representations of an interaction. A collaboration diagram is an
interaction diagram that shows the order of messages that implement an
operation or a transaction.

Using Collaboration Diagram:

Collaboration diagrams show objects, their links and their messages.

They can also contain simple class instances and class utility instances.
Each collaboration diagram provides a view of interactions or structural
relationships that occur between objects and object-like entities in the
current model.

Creating Collaboration Diagram:

The create collaboration diagram command creates a collaboration

diagram from information contained in the sequence diagram. The Goto
sequence diagram and Goto collaboration diagram commands traverse
between an interaction’s two representations.

Collaboration diagram contain icons representing objects. You can create

one or more collaboration diagrams to depict interactions for each logical
package in your model. Such collaboration diagrams are themselves
contained by the logical package enclosing the objects they depict. An
object specification enables you to display and modify the properties and
relationships of an object.

The associated diagrams or specifications are automatically updated.

Design show the semantics of mechanism in the logical view and
Analysis indicate the semantics of primary and secondary interactions.
Thus the collaboration diagrams are used as the primary vehicle to
describe interactions that express your decisions about the behavior of the
system.