Session 13
Session 13: Develop “Railway Reservation System” as per
specifications given in Sessions 1, 3,
4,5 and 6.
Project Proposal
The Project “Railway Reservation” deals with the automation
of the reservation and enquiry of the railway reservation system. It
maintains all information starting from reservation to cancellation of tickets.
It also acts as an enquiry system about the different trains available. It
gives the details of the distance, arrival time and departure time of the
different trains. The computerization is aimed at job simplification and
reducing the manual work and effective record maintenance.
Introduction
The introduction of the Software Requirements
Specification (SRS) provides an overview of the entire SRS purpose,
scope, definitions, acronyms, abbreviations, references and overview of
SRS.A Software Requirements Specification (SRS) - a requirements
specification for a software system - is a complete description
of the behavior of a system to be developed. It includes a set of use
cases that describe all the interactions the users will have with the software.
Use cases are also known as functional requirements. In addition to use
cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional requirements are requirements
which impose constraints on the design or implementation (such as performance
engineering requirements, quality standards, or design
constraints). The aim of this document is to gather and analyze and
give an in-depth insight of the complete Marvel Electronics and Home Entertainment software system by defining the problem statement in detail. This is
a documentation of the project Railways Reservation System done sincerely and satisfactorily by my
group members. A Software has to be developed for automating the manual Railway Reservation System.
· RESERVE SEATS – Reservation form has to be filled by passenger. If seats are available entries like train name, number, destination are made.
· CANCEL RESERVATION- The clerk deletes the entry in
the System and changes in the Reservation Status.
· VIEW RESERVATION STATUS- The user needs to enter the PIN number printed on ticket.
Objective:
The purpose of this source is to describe the railway
reservation system which provides the train timing details, reservation, billing
and cancellation on various types of reservation namely,
• Confirm Reservation for confirm Seat.
• Reservation against Cancellation.
• Waiting list Reservation.
• Online Reservation.
• Tatkal Reservation.
The basic purpose of Software Requirement Specification (SRS) is to bridge this communication
gap. SRS is the medium through which the client’s and the user’s needs are accurately specified; indeed, SRS forms the basis of software development.
Another important purpose of developing an SRS is
helping the clients understanding their own needs. An SRS establishes the
basis for agreement between the client and the supplier on what the software product will do.
An SRS provides a reference for validation of the final product.
A high-quality SRS is a prerequisite to high quality software and it also reduces the development cost.
Scope:
“Railways Reservation System” is an attempt to
simulate the basic concepts of an online Reservation system. The system enables to perform the following functions:
· Search
for Train
· Booking
of a selected flight
· Payment
· Cancellation
· Freight Revenue enhancement
· Passenger Revenue enhancement
· Improved & optimized service
Glossary:
This should define all technical terms and abbreviations used in the document.
·
NTES – National Train Enquiry System
·
IVRS – Interactive Voice Response system
·
PRS – passenger reservation system
·
DFD– Data Flow Diagram
·
ERD – Entity Relationship Diagram
·
SRS– Software Requirements Specification
·
STD – State Transition Diagram
Description:
Project Functions:
Booking agents with varying levels of familiarity with
computers will mostly use this system. With this in mind, an important
feature of this software is that it be relatively simple to use. The scope of this project encompasses: -
Search: This function allows the booking agent to search for train that are available between
the two travel cities, namely the "Departure city" and
"Arrival city" as desired by the traveler. The system
initially prompts the agent for the departure and arrival city, the date
of departure, preferred time slot and the number of passengers. It then
displays a list of train available with different airlines between the designated
cities on the specified date and time.
¨ Selection: This function allows a particular
train to be selected from the displayed list. All the details of the train are shown:
-
1. train Number
2. Date, time and place of departure
3. Date, time and place of arrival
4. TRAIN Duration
5. Fare per head
6. Number of
stoppages – 0, 1, 2…
¨ Review: If the seats are available, then the
software prompts for the booking of train. The train information is shown.
The total fare including taxes is shown and flight details are reviewed.
¨ Traveler Information: It asks for the details
of all the passengers supposed to travel including name, address, telephone number and e-mail id.
¨ Payment: It asks the agent to enter the
various credit card details of the person making the reservation.
1. Credit card type
2. Credit card number
3. CVC number of the card
4. Expiration date of the card
5. The name on the card
¨ Cancellation: The system also allows the passenger to cancel an existing reservation. This function registers the information regarding a passenger who has requested for a cancellation
of his/her ticket. It includes entries pertaining to the train No.,
Confirmation No., Name, Date of Journey, Fare deducted.
User Characteristics:
·
· TECHNICAL EXPERTISE: - User should be comfortable using general purpose applications on the computer system.
Assumptions and Dependencies:
- Booking Agents will
be having a valid user name a password to access the software.
- The software needs booking agent to have complete knowledge of railways reservation system.
- Software is dependent on access to internet.
Function Requirements:
Performance requirements:
· User Satisfaction: - The system is such that it stands up to the user expectations.
·
·Error Handling: - Response to user errors and undesired situations has been taken care of to ensure that the system operates without halting.
·Safety and Robustness: - The system is
able to avoid or tackle disastrous action. In other words, it should be
foul proof. The system safeguards against undesired events, without human intervention.
·Portable: - The software should not be architecture specific. It should be easily transferable to other platforms if needed.
·User friendliness: - The system
is easy to learn and understand. A native user can also use the system effectively, without any difficulties.
Design Constraints:
There are a number of factors in the client’s environment
that may restrict the choices of a designer. Such factors include
standards that must be followed, resource limits, operating environment, reliability
and security requirements and policies that may have
an impact on the design of the system. An SRS (Software Requirements
Analysis and Specification) should identify and specify all such constraints.
Standard Compliance: - This specifies the requirements for the standards the system must follow. The standards may include the report format and accounting properties.
Hardware Limitations: - The software may have to operate on some existing or predetermined
hardware, thus imposing restrictions on the design. Hardware limitations
can include the types of machines to be used, operating system
available on the system, languages supported and limits on primary and secondary storage.
Reliability and Fault Tolerance: - Fault tolerance requirements can place a major constraint
on how the system is to be designed. Fault tolerance requirements often make
the system more complex and expensive. Requirements about system behavior
in the face of certain kinds of faults are specified. Recovery
requirements are often an integral part here, detailing what the system
should do I some failure occurs to ensure
certain properties. Reliability requirements are very important for critical applications.
Standard Compliance: - This specifies the requirements for the standards the system must follow. The standards may include the report format and accounting properties.
Hardware Limitations: - The software may have to operate on some existing or predetermined
hardware, thus imposing restrictions on the design. Hardware limitations
can include the types of machines to be used, operating system
available on the system, languages supported and limits on primary and secondary storage.
Reliability and Fault Tolerance: - Fault tolerance requirements can place a major constraint
on how the system is to be designed. Fault tolerance requirements often make
the system more complex and expensive. Requirements about system behavior
in the face of certain kinds of faults are specified. Recovery
requirements are often an integral part here, detailing what the system
should do I some failure occurs to ensure
certain properties. Reliability requirements are very important for critical applications.
Hardware Requirements:
For the hardware requirements the SRS specifies the
logical characteristics of each interface b/w the software product and the hardware components. It specifies the hardware requirements
like memory restrictions, cache size, the processor, RAM size etc... those are required for the software to run.
Minimum Hardware Requirements: -
Processor Pentium III Hard disk drive 40 GB RAM 128 MB
Cache 512 kb
Preferred Hardware Requirements: -
Processor Pentium IV Hard disk drive 80 GB RAM 256 MB
Cache 512 kb
Software Requirements:
· Any window-based
operating system with DOS support are primary requirements for software
development. Windows XP, FrontPage and dumps are required. The systems must be connected via LAN and connection to internet is mandatory.
Other Requirements:
Software should satisfy following requirements as well:
-
· SECURITY
· PORTABILITY
· CORRECTNESS
· EFFICIENCY
· FLEXIBILTY
· TESTABILTY
· REUSABILTY
Maintainability:
A commercial database is used for maintaining the database
and the application server takes care of the site. In case of a failure, a
re-initialization of the project will be done. Also the software design is
being done with modularity in mind so that maintainability can be done efficiently.
Supportability:
The code and supporting modules of
the system will be well documented and easy to understand. Online User
Documentation and Help System Requirements.
Security:
The system uses SSL (secured socket layer) in all
transactions that include any confidential customer information. The
system must automatically log out all customers after a period of inactivity. The
system should not leave any cookies on the customer’s computer containing the
user’s password. The system’s back-end servers shall only be accessible to
authenticated management.
Reliability:
The reliability of the overall project depends on the
reliability of the separate components. The main pillar of reliability of the system is the backup of the database which is continuously
maintained and updated to reflect the most recent changes. Also, the system
will be functioning inside a container. Thus, the overall stability of the
system depends on the stability of container and its underlying operating system.
Availability:
The system should be available at all times, meaning the user can access it using a web browser, only restricted by the down time of the server on which the system runs. A customer friendly system which is in excess of people around the world should work 24 hours. In case of a of a hardware failure or database corruption, a replacement page will be shown. Also, in case of a hardware failure or database corruption, backups of the database should be retrieved from the server and saved by the Organizer. Then the service will be restarted. It means 24 x 7 availability.
Comments
Post a Comment