On line Railway Reservation

System
Abstract
In this emerging world of computers all most all manual system automated and
computerized but maximum of them are so complex and a common user is unable
to operate that software system. We are developing the Online Railway Reservation
System to model the present system and to remove the drawbacks.
This project explores how computer technology can be used to solve the problem of
user. We specifically props way to computerize the administration and engineering
offices of Indian Railway Online. A high speed communication network needs to be
developed for interconnecting the offices of railways. This same communication
network can be used to provide high speed internet connection to the public and
leas out network capacity to internet service providers.
Railway Reservation System

TABLE OF CONTENTS
1. INTRODUCTION
a. Current system
b. Need of proposed system
2. SYSTEM DEVELOPMENT LIFE CYCLE
3. ANALYSIS
a. Requirement analysis
b. Requirement Specification
4. DESIGN
a. System Flow Diagram
b. Modules identified
c. Database Design
i. E-R Diagram
5. IMPLEMENTATION
a. Platform Used
i. Hardware Platform
ii. Software Platform
 b. Implementation
c. Testing
i. Testing Technique used
6. CONCLUSION
a. Important Features
b. Limitations
c. Future Work
Railway Reservation System

Introduction
Railway Reservation System

1. Introduction
1.1 Current System
India is the 7th largest country in terms of geographical size. This means there is a
need for efficient means for long distance transportation. The long distance road
network is very poorly developed in most parts of India. Bulk of long distance traffic
is carried by the Indian Railway as a result Indian railways. Therefore forms a
backbone of public transport in India. The efficiency of the railway will increase
result of computerization due to dramatic reduction in communication time among
geographically dispersed offices. For the reservation of the ticket a person go to
ticket counter of the railway reservation office and expend its valuable time in
standing queue. Now to save that time we have a facility of Online Reservation now
we can book cancel or search other train information just by click on computer.
1.2 Need of proposed system
To reduce complexity of existing system. Effective management of time. To make
work easy, simple and error free. Effective utilization of available resource. To
enhance the efficiency and diversification of services activities. User friendly.
Interactive graphical user interface.
The scope of project define the project feasibility the technology , finance , time and
resources best define in technology weather the defects can be reduced in the
project and up which level financially, weather the overall project cost is affordable.
Time describe the weather the projection finishing point will be achieve on time or
before time resources required should be available at the rate of cost and time.
Railway Reservation System

System Development Life Cycle

2. System development life cycle
2.1 Definition
A software process model or a software engineering is an abstract representation of
a software process. It is a software development strategy that encompasses the
process, methods and tools layers plus the generic phases namely definition phase,
development phase and support phase. A process model is chosen based on the
nature of the project and application, the methods and tools to be used and the
controls and deliverables that are required.
2.2 Spiral Model

The spiral model, also known as the spiral lifecycle model, is a systems
development lifecycle model used in information technology (IT). This model of
development combines the features of the prototyping model and the waterfall
model. The spiral model is favored for large, expensive, and complicated projects.
The steps in the spiral model iteration can be generalized as follows:
1. The system requirements are defined in as much detail as possible. This usually
involves interviewing a number of users representing all the external or internal
users and other aspects of the existing system.
2. A preliminary design is created for the new system. This phase is the most
important part of "Spiral Model". In this phase all possible (and available)
alternatives, which can help in developing a cost effective project are analyzed and
strategies to use them are decided. This phase has been added specially in order to
identify and resolve all the possible risks in the project development. If risks indicate
any kind of uncertainty in requirements, prototyping may be used to proceed with
the available data and find out possible solution in order to deal with the potential
changes in the requirements.
3. A first prototype of the new system is constructed from the preliminary design.
This is usually a scaled-down system, and represents an approximation of the
characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
1. Evaluating the first prototype in terms of its strengths, weaknesses, and
risks;
2. Defining the requirements of the second prototype;
3. Planning and designing the second prototype;
4. Constructing and testing the second prototype.
Analysis:
3. Analysis
3.1 REQUIREMENT ANALYSIS:
Requirements are a feature of a system or description of something that is capable
of doing in order to fulfill the systems purpose. It provides the appropriate
mechanism for understanding what the customer wants, analyzing the needs,
assessing feasibility, negotiating a solution, specifying the solution unambiguously,
validating the specification and managing the requirements as they are translated
into an operational system. Requirement Analysis is a task done under software
engineering and software design. While requirements engineering specifies
softwares operational characteristics i.e. function, data behavior, indicates
softwares interface constraints, requirements analysis let the software engineer
(called analysis) to refine the software allocation and construct models of data,
functional and behavioral domains. Moreover, requirements analysis provides
software developer with a representation of data, function and behavior that can be
converted to data, architectural, interface and component-level designs. At last, we
can say that the requirement specification makes available, the developer and the
customer, a means to assess quality, once the software has been built.
Software requirements analysis can be categorized into four areas of effort, as
follows-

Evaluation and synthesis

Modeling
Specification
Review

The analyst starts with the studies of system specification and the software project
plan. It is then important to understand the software in a system context. Also, the
review of the software scope, used to generate planning estimate, is necessary.
Next, communication for analysis must be established, so as to ensure problem
recognition. The reason behind is to recognize the basic problem elements
perceived by customer.
The next major area of effort for analysis is problem evaluation and solution
synthesis. The engineer (or analyst) must define all data objects that are extremely
observable. He must evaluate the content and flow of information. Also, he must
define and describe all software functions, understand software behavior in the
context of the system affected events, establish the characteristics of system
interface, and uncover additional design constraints.
After evaluating the current problems and desired information (i.e., input and
output), the engineer and analyst synthesizing one or more solutions. Initially, the
data objects, processing functions and the system behavior are defined in detail.
Once establishing this information, the analyst then considers basic architectures
for implementation. Thus the process of evaluation and synthesis proceeds until
both analyst and the customer are sure that software can be adequately specified
for subsequent development steps.
During the evaluation and synthesis activity, the analyst creates the system model
so as to better understand data and control flow, functional processing, operational
behavior and the information content. The model provides a base for software
design and the creation of specifications for the software.

3.2 REQUIREMENT SPECIFICATION:

A Software Requirements Specification (SRS) is a complete description of the
behavior of the system to be developed. It includes a set of use case that describes
all the interactions that the users will have with the software. Use cases are also
known as Functional Requirements. Non-Functional Requirements are requirements
which impose constraints on the design or implementation (such as performance
requirements, quality standards, or design constraints).

3.2.1 FUNCTIONAL REQUIREMENTS:

In software engineering, a functional requirement defines a function of a software-
system or component. A function is described as a set of inputs, the behavior and
outputs. Functional requirements may be calculations, technical details, data
manipulation and processing and other specific functionality that show how a use
case to be fulfilled.
Typically, a requirements analyst generates functional requirements after building
use cases. However, this may have exceptions since software development is an
iterative process and sometime certain requirements are conceived prior to the
definition of the use case. Both artifacts (use cases documents and requirements
documents) complement each other in a bidirectional process.
A typical functional requirement will contain a unique name and number, a brief
summary, and a rationale. This information is used to help the reader understand
why the requirement is needed, and to track the requirement through the
development of the system.
The core of the requirement is the description of the required behavior, which must
be a clear and readable description of the required behavior. This behavior may
come from organizational or business rule, or it may be discovered through
elicitation sessions with users, stakeholders and other experts within the
organization. Software requirements must be clear, correct unambiguous, specific
and verifiable
Detailed Description of Functional Requirements:
Purpos a description of the functional requirement its reason(s)

e
Inputs what are the input; in what form will they arrive; from what
sources can the input come; what are the legal domains of each
input

Process Describes the outcome rather than the implementation;

includes any validity checks on the data, exact timing of each
ing operation (if needed), how to handle unexpected or abnormal
situations

Output The form, shape, description and volume of output; output

timing; range of parameters in the output; unit measure of the
s output; process by which the output is stored or destroyed;
process for handling error message produced as output

Template for describing functional

requirements.

3.2.2 NON FUNCTIONAL REQUIREMENTS:

In systems engineering and requirements engineering, non-functional
requirements are requirements which specify criteria that can be used to
judge the operation of system, rather than specific behaviors. Nonfunctional
requirements are often called qualities of a system. Other terms for non-
functional requirements are constraints, quality attributes, quality
goals and quality of service requirements . Qualities, i.e. non-functional
requirements can be divided into 2 main categories:
1. Execution qualities, such as security and usability, are observable at
runtime.
2. Evolution qualities, such as extensibility and scalability, embody in the
static structure of the software system.
The nonfunctional requirements in our projects are:-
Time:-
The project should be completed within the stipulated time period.
 Cost:-
The cost involved in marketing the project should be less.
Usability:-
This requirement is present, as this system will interact with user.
Reliability:-
This system must be highly robust.
Performance:-
It should be fast enough to produce the output.
3.3 USECASE ANALYSIS:
Use Case Analysis is an object-oriented method for designing information
systems by breaking down requirements into user functions. Each case is a
transaction or sequence of events performed by user. Use cases are studied
to determine what objects are required to accomplish them and how they
interact with other objects.
3.3.1 GOALS OF USE CASE ANALYSIS:
Design system from users perspective.
Communicate system behavior in users terms.
3.3.2 CHARACTEISTICS OF USE-CASE ANALYSIS:
USE-CASE: The specific ways in which the system is used.
Each use case expresses a complete thought or end-to-end
transaction.
3.3.3 SOME KEY COMPONENTS OF USE CASE ANALYSIS:

ACTORS: Entities that use or are used by system, typically people, but
could be other systems or devices as long as long as they are outside
the system being specified.
CONNECTIONS: Connections from actors to use cases.
RELATIONSHIPS: Relationships between actors or between use cases
3.4 USE CASE DIAGRAM:
A use is a description of a systems behavior as it responds to a request that
originates from outside of that system. The use case technique is used in
software and system engineering to capture the functional requirements of a
system. Use cases describe the interaction between a primary actor- the
initiator of the interaction- and the system itself, represented as a sequence
of simple steps. Actors are something or someone which exists outside the
system under study, and that takes part in a sequence of activities in a
dialogue with a system, to achieve some goal: they may be end users, other
systems, or hardware devices. Each use case is a complete series of events,
describes from the point view of the actor.
3.4.1 USE CASE NAME:
A use case name provides unique identifiers for the use case. It should be
written in verb-noun format, should describe an achievable goal and should
be sufficient for the end user to understand what the use case is about.
3.4.2 GOAL:
Without a goal a use case is useless. There is no need for a use case when
there is no need for any actor to achieve a goal. A briefly describes what the
user intends to achieve with this use case.
3.4.3 ACTORS:
An actor is someone or something outside the system that either acts on the
system- a primary actor or is acted on by the system- a secondary actor. An
actor may be a person, a device, another system, or time. Actors represent
the different roles that something outside has in its relationship with the
system whose functional requirements are being specified. An individual in
the real world can be represented by several actors if they have different
roles and goals in regards to a system.
3.4.4 PRECONDITIONS:
A preconditions section defines all the condition that must be true (i.e.,
describes the state of the system) for the trigger to meaningfully cause the
initiation of the use case. That is, if the state describes in the preconditions,
the behavior of the use case is indeterminate
3.4.5 POSTCONDITION:
The post conditions section describes what the change in the state of the
system will be after the use case completes. Post conditions are guaranteed
to be true when the use case ends.

4. DESIGN
4.1 SYSTEM FLOW DIAGRAM:
A System Flow Diagram (SFD) shows the relationship between the, major
components in the system. It is a systematic representation of an algorithm
or a process. The steps in a process are shown with symbolic shapes, and the
flow of the process is indicated with arrows connecting the symbols.
In order to improve a process, it is first necessary to understand its operation
in detail. Describing this in text lacks the clarity of a pictorial diagram, where
individual steps are more easily seen. The flowchart is a simple mapping tool
that shows the sequence of actions within a process, in a form that is easy to
read and communicate. The mapping of what follows what is shown with
arrows between sequential action boxes, as in the illustration. This also
shows the boxes for process start and end points of which there are normally
one each.
Process becomes more complex when decisions must be made on which, out
of an alternative set of action, must be taken. The decision is shown in a
flowchart as a diamond shaped box containing a simple question to which
the answer is yes or no.

5. IMPLEMENTATION
5.1 Platform Used
5.1.1 Hardware Platform:
Client side:
Processor: 166 MHz or above
RAM: 64 MB
Hard Disk Space: 100 MB
Server side:
Processor: 166 MHz or above
RAM: 64 MB
Hard Disk Space: 300 MB
5.1.2 Software Platform:
Operating System: - Windows Xp
Front End: - Microsoft Visual Studio 2005
Back End: - Sql Server 2005
1.2 Implementation Level Details:
Database table being used is: