ONLINE BUS TICKET RESERVATION SYSTEM

By

8208E21CSR062-KISHORE KUMAR.R
8208E21CSR032-GUNAL.M
8208E21CSR034-GURUTHECHANMOORTHI. G
of

A report for the mini project 1Submitted to the Department of

COMPUTER SCIENCE AND ENGINEERING

For

The partial fulfillment of the award of the degree

BACHELOR OF ENGINEERING

IN

COMPUTER SCIENCE AND ENGINEERING

E.G.S. PILLAY ENGINEERING COLLEGE (Autonomous),

NAGAPATTINAM
 E.G.S. PILLAY ENGINEERING COLLEGE(Autonomous),

NAGAPATTINAM

BONAFIDE CERTIFICATE

Certified that this project report titled “ONLINE BUS TICKET

RESERVATION SYSTEM ” is the Bonafide work of Mr. Kishore Kumar. R,
Mr.Guruthechanamoorthi. G, Mr. Gunal. M(Registration Number: E21CSR062,
E21CSR034, E21CSR032), who carried out the mini project1 – 1904CS653
Software Prototype Development under the Course Coordinator’s. Certified
further, that to the best of Course Coordinator’s knowledge the work reported here
in does not form part of any other project report or dissertation on the basis of
which a degree or award was conferred on an earlier occasion on this or any other
candidate.

Signature of the Course Coordinator Signature of the HOD

Submitted to Mini Project II Viva voce Examination held on ------------------------

Internal Examiner External Examiner

 ACKNOWLEDGEMENT

We thank GOD, the almighty for end owing his immense blessing that helped us
in each step of our progress towards the successful completion four mini project II.
We wish to express heartfelt thanks to our college Founder (late) CHEV. Dr. G. S.
PILLAY, chairman Mrs. JOTHIMANI G. S. PILLAY, Secretary Shri.S.
SENTHIL KUMAR, Joint Secretary Shri. S. SANKARGANESH, Advisor
CHEV. Dr.S.PARAMESWARAN, Principal Dr.S.RAMABALAN,M.E.,Ph.D..,
Head of the Department of Computer Science and Engineering
Dr.T.GANESAN,M.E.,Ph.D., our Course Coordinators who had always stood as
a moral support and guided me tirelessly with their valuable ideas along with
constant encouragement, throughout the period of study and encouraged me to
shine as a good technologist.
I also thank other Staff Members and Technical Staff Members in our
department for their constant support throughout my project work and encouraged
me to complete this project successfully.
Finally, with a deep feeling of intentness, I thank my parents and friends
who have encouraged me with good spirit by the incessant prayers to complete this
project.
 TABLE OF CONTENTS

CHAPTER TITLE PAGE

NO. NO.

i BONAFIEDCERTIFICATE

ii ACKNOWLEDGEMENT

1 ABSTRACT

2 INTRODUCTION

3 OVERALLDESCRIPTION

4 SYSTEM CONFIGURATION

5 SOFTWARE REQUIREMENT SPECIFICATION

DOCUMENT
6 RESULT
 ABSTRACT
A bus reservation system is a modern and efficient way to streamline the
process of booking and managing bus passes. This system leverages technology to
allow passengers to reserve and purchase bus passes online or through dedicated
mobile apps, reducing the need for physical ticket counters and paper tickets. It
offers numerous advantages, such as convenience, flexibility, and improved
passenger experience. Additionally, bus companies benefit from better resource
allocation and data analytics to optimize routes and schedules. In this era of digital
transformation, a bus pass reservation system is a valuable tool for both passengers
and transportation providers.

The system is a web – based application that allows visitors to check bus
availability, buy and pay bus ticket online. In this paper, the proposed bus
reservation system was developed using Extensible Hypertext Markup Language
(XHTML), PHP Hypertext Preprocessor (PHP), Structure Query Language (SQL),
Ajax, Cascading Style Sheet (CSS), and JavaScript.

Keywords: Online Tourism Industry, Privacy, Attractiveness, Receptiveness, E-

Services.
 1.INTRODUCTION
The Online Bus Ticket Reservation System is a web-based application that
allows visitors check bus ticket availability, buy bus ticket and pay the bus ticket
online (Asaad, Ayad and Hayder, 2012). This system is established for all the
home/office users after gaining access from the administrator. According to
Invaderzim (2011), Online Bus Reservation System provides bus transportation
system, a facility to reserved seats, cancellation of seats and different types of
enquiry which need an instant and quick reservation. This system can be used by
the users in performing online reservation via internet for their all business
purposes. Users can use this program directly on their websites and no need to
install it.

OBJECTIVEOFTHEPROJECT
Bus Ticket Reservation System enables the customer to buy bus ticket, make
payment, and ask for information online easily. Furthermore, staff can sell bus
ticket using Bus Ticket Reservation System after check bus ticket availability for
the customer and print the bus ticket to the customer that queue up in the counter.
The method to solve this problem is to create an online buying bus ticket system.
Customer can buy the bus ticket over the Internet, 24 hours a day, 7 days a week
and the bus ticket can't be lost, stolen or left behind. In addition, the online system
lets the customers check the availability of the bus ticket before they buy bus ticket
(Wee, 2007). Furthermore, customers no need to pay cash to buy bus ticket
because they can pay the bus ticket by using deposit slip number order by bank.
 OVERVIEW

Online Bus ticketing system web portal is a total internet ticketing

operations offering the benefit of total in-house management of bus schedules,
ticket bookings, ticket sales, report generation, and other business functions
associated with ticket sales (Melisa, 2007). It also offers the power of decision
making to customers to make a ticket booking through bus operators’ popularity,
performance and ranking.stated the basic components of an Online Bus Ticketing
System web portal that provides enhanced service to the bus operators and
customers consist of the following:
* Capture of customer information such as name, address, phone number
and e-mail address
* Price list
* Bus operators ranking
* Seating chart
* Loyalty Points/Redemption
* Search engine
* Payment information
* Organization's advertisement/slogan, phone number, fax number, and
address
 OVERALL DESCRIPTION

Problem Statement:

The system that is used by the staff at the counter currently is an internal
system and just used to sell bus tickets at the counter. The customer has gone to the
counter to buy the ticket or ask for the bus schedule. Furthermore, customers need
to pay cash when they buy bus tickets and sometimes, need to queue up for a long
time to get the bus ticket. Besides that, customers are also not allowed to buy the
bus tickets through telephone and the bus company’s telephone always busy line.

Solution:

The method to solve this problem to create an online booking bus ticket
system. Customer can buy the book ticket over the internet system, 24 hours a day,
7 days a week and the bus ticket can’t be lost, stolen or behind.
 In additionally, the online system lets the customer check the availability
of the bus ticket before they buy bus ticket. Furthermore, customers no need to pay
the bus ticket on the travelling time.

Scope:

A bus reservation system is a mobile or web software solution designed to

provide customers with a personalized easy-to-utilize user experience for booking
and purchasing tickets online. It stores customers’ personal data records, scheduled
routes, frequent trips, drop points, and other information.

Performance:

 Accuracy
 User friendly
 Efficiency
 Availability
 Reliable
 Durable
 SYSTEM CONFIGURATION

HARDWARE CONFIGURATION:

Computer Processor: Pentium4(min)

Hard Disk : 50gb(min)
RAM : 512MB(min) or more

SOFTWARE CONFIGURATION:

Operating System: WINDOWS XP or above

Language used : python, JSP, CSS
Data Base : My-SQL
Server : Apache tomcat6.0
SOFTWARE REQUIREMENT SPECIFICATION DOCUMENT

For

ONLINE BUS TICKET RESERVATION SYSTEM

1.INTRODUCTION
The introduction of the Software Requirements Specification (SRS)
provides an overview of the entire SRS with purpose, scope, definitions,
acronyms, abbreviations, references and overview of the SRS. This is SRS
document for Online Bus Ticket Reservation System. The objective of Online
Bus Ticket Reservation System is to manage buses, their routes, fare and
passenger and also provide the comfort to both organization and Passenger.
1.1 Document Purpose
The purpose of this document is to describe the requirements for the
Online Bus Ticket Reservation System (OBTRS). The intended audience
includes all stakeholders in the bus reservation system. These include, but are
not necessarily limited to, the following: Administrative Staff, Drivers,
Passengers.
Developers should consult this document and its revisions as the only
source of requirements for the project. They should not consider any required
statements, written or verbal, as valid until they appear in this document or its
revision.

1.2 Product Scope

The proposed software product is the Online Bus Ticket Reservation

System (OBTRS). The system will be used to get the information from the
passenger and then store that data for future usage. The current system in use
is a paper-based system. It is too slow and cannot provide updated lists of
passengers within a reasonable timeframe. The intentions of the system are to
reduce overtime pay and increase the number of passengers that can be
treated accurately. Requirements statements in this document are both
functional and non- functional.
1.3 Intended Audience and Document Overview
The intended audience includes all stakeholders in the potential system.
These include, but are not necessarily limited to, the following: Administrative
Staff, patients and developers.
The objective of this document therefore is to formally describe the system’s high-
level requirements including functional requirements, non-functional requirements
and business rules and constraints. The detail structure of this document is
organized as follows:

 Section 2 of this document provides an overview of the business

domain that the proposed Online Bus Ticket Reservation System
(OBTRS) will support. These include a general description of the
product, user characteristics, general constraints, and any assumptions
for this system. This model demonstrates the development team's
understanding of the business domain and serves to maximize the
team's ability to build a system that truly does support the business.

 Section 3 presents the detailed requirements, which comprise the domain

model.
Table: Reading Suggestions for the SRS document.

S.NO Section Name Intended For Relevance

1 Overall Customer and Gives Overview
Description Developer of specification,
the Online bus
Ticket
Reservation
System will
provide to
passengers.
2 External Developer Lists all types of
 Interfaces interactions that
Requirements the routes must
support
3 System Features Customer and Gives a top level
Developer overview of
requirements for
features that the
OES will have.
4 Other Non Developers How the Product
Functional will look for the
Requirements passengers?
5 Other Non Developers Other
Functional requirements not
Requirements covered elsewhere
in the SRS
including database
requiremets,legal
Requirement,reuse
objects for the
project
Appendix A Glossary Customer Define words the
reader may not
know
Appendix B Analyze Developer Gives description
of system and
design model such
as ER diagram,
data flow diagram
etc.

1.4 Definitions, Acronyms and Abbreviations

 OBTRS – Online Bus Ticket Reservation System

  BN - Bus Number
 PIN - Passenger Identification Number
 Report – account of particular Bus
 Front-desk staff - administrative staff that work at reception desk
 Logon ID - a user identification number to enter the system
 Password - a word that enables one to gain admission into the system
 Web-based application - an application that runs on the Internet
 MySQL - a query language to interrogate the system
 GUI - Graphical User Interface
 SRS - Software Requirements Specification

1.5 Document Conventions

In general, this document follows the IEEE formatting requirements. This
document contains Verdana template font size 11 throughout. We have used italics
for comments. The document text is single spaced and has 1” margins. The
sectional heading uses Arial Heading 1 with font size 18 and Subsection titles
follow the Arial Heading 2 with font size 14.

1.6 References and Acknowledgments

1.IEEE SRS Template
2. SRS Online Shopping System www.scribd.com/doc/60703226/Srs-.-
Shopping-System

2. Overall Description
2.1 Product Perspective

This OBTRS is a self-contained system that manages activities of the travels as

Passengers Info. Various stakeholders are involved in the Online Bus Ticket
Reservation System.

2.2 Product Functionality

The system functions can be described as follows:

 Registration:

When a passenger asks for a seat reservation, the front-desk staff

checks to see if the passenger is already registered with the hospital. If he is,
his/her Passenger Identification Number (PIN) is entered into the computer.
Otherwise, a new Passenger Identification Number will be given to this
passenger. The passenger's information such as date of birth, address and
telephone number is also entered into the computer system.
 Sit Reservation:
When the passenger login with his/her Login Id and Password then he/
she is asked about the sours and destination of his/her journey, root, date and time
of journey and type of but i. e. Normal or Ac. The seat is checked for availability
in database on proposed time, if the sit is available then the reservation is done by
taking the e-payment and the sit no. And bus no., date and time of bus is sent to
passenger along with blueprint of ticket. If the seat or bus is not available, then the
passenger is given all other alternatives. Even if the passenger completes his
journey, then administrative staff should not delete his PIN from the system. So
that database about regular passengers can be maintained and special discount
offers or them can be given.
 Report Generation:
The system generates reports on the following information: List of detailed
information regarding the buses run by travel companies and passengers.

2.3 Users and Characteristics

The system will be used in the Travel agency. The administrators, front-desk
staff and passengers will be the main users. Given the condition that not all the
users are computer-literate. The system is also designed to be user-friendly. It uses
a Graphical User Interface (GUI).
Table 3: different user classes and their characteristics
S.no USER CHARACTERISTICS DESCRIPTION
1. Admin  ID Admin also manages and
 Name maintains and the passengers
 Login Id record and database. Every
 Email Id administrator has basic
 Address computer training.
 Contact no
 Gender

2 passenger  Name The passenger user class

 Login Id has limited access to the
 Email Id system. The passenger
 Address dose booking of seats and
 Contact no need little bit knowledge
about computer and
Internet.

3 Assistant  Id The assistant system admin

system  Name user class has a management
admin  Login Id role.
 Email Id
 Address
 Contact no
 Gender
4 Customer  Id This team User Class has a
support  Name moderate access to the system.
team  Login Id
 Email Id
 Address
 Contact no
 Gender

5 places  Name In place Record contain the

Record  Source place information about such as date,
 Destination & price,timing,availability seats
Price for travelling source to
 duration destination , duration, credit.
 credit
 Features
  Time

2.4 Operating Environment

The Online Bus Ticket Reservation System will be installed at the
Information Technology of Travel agency.

2.5 Design and Implementation Constraints

 All bus and passenger records must be protected for all steps.
 In the future, it is possible that the software design will have to incorporate
changes that could take place in other Travel agencies in the same domain.
The bus and passengers record of all Travel agencies in domain should
have the same standard of data format and security of data when
transferring between the agencies is also needed.
 Changes or additions to payment methods can affect the system directly.
 The system must be user-friendly.

2.6 User Documentation

 BRS software manual documents for passengers, drivers,

conductors, helper, mechanic, office staff, patient, agents and
system administrator.
 The development team will go to your Travel agency and perform the
training courses for all classes listed above.
 The development team will service the agency 24 hours for 1 year of
warranty.

2.7 Assumptions and Dependencies

 It is assumed that one hundred IBM compatible computers will be

available before the system is installed and tested.
 It is assumed that the agency will have enough trained staff to
take care of the system
 The system uses licensed third-party software products.
  The system is volatile. If the electric power is lost. The PMS system will go
do.

3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
The user interface for the software shall be compatible with the user which can
access the system. The user interface shall be implemented using any tool or
software package like servlet,asp,jsp etc.

3.1.2 Hardware Interfaces

We would need the Intel Core2Duo system and 1 GB of Memory at the
minimum for the client. The corporate server needs to be a server class machine
with at least 2 GB and Intel Xeon system per rack and 15 TB of storage at the
minimum. And have dedicated links between the server and clients.

3.1.3 Network Interfaces

The server and client computer must have an NIC card. And must get the
Internet service active from well-known ISP.
3.1.4 Software Interfaces
The client machines require Microsoft Windows XP or better. The corporate
server requires Red Hat Enterprise Linux AS 5 (RHEL 5) and Oracle Database 11g
Enterprise Edition to hold on to all archives. Also both the client and server
computer must have internet browser to work ..
3.1.5 Communications Interfaces
The System will perform the following functions:
 Sophisticated and user-friendly interface for all passengers.
 Individual account or profile for each user related to the system.
 Sophisticated interfaces for all people who are related to the system.
  Implement bus, passenger, driver and staff database systems.
 Implement Account System for managing invoices.
 Each passenger needs only one barcode i.e., PIN and username for
walking through every step.
 Keep secret for all of passenger profiles. Each division can see only
necessary data of each passenger for analyzing.
 Internet connection to work on with the system.
 Emergency help system in case of any accident and any other
technical or non- technical problem or risk.
 Real-time or dynamic service should be given in case of all changes
appearing in the system.

3.2 Functional Requirements

 Registration:

o Add passenger: The BRS shall allow new passengers to add

themselves to the system.
o Assign PIN: The BRS shall allow front-desk staff to give each
passenger a PIN and add it to the passenger's record. This ID shall
be used by the passenger throughout his/her stay in the agency.

 Reserve Ticket:

o Sign In: The passenger first needs to sign in to the system with
the username and password he/she has provided with. The system
needs to check for validation of that username and password and
then only allow his/her to access the system.
o Check Availability: The passenger must be allowed to see all
available options for the journey. And see if the seat is available
or not.
o Reserve Ticket: Then if the ticket is available then the seat should be
booked
with the PIN of that passenger only and it should not be granted
to another passenger again till it gets free.
  Maintain History:

o Maintain PIN: The administrative staff in the ward should not

delete the PIN of the passenger from the system when the journey
is over.
o Add seat to seat-available list: The administrative staff in the ward
shall be allowed to put the seats in the seat-available list when the
journey is over, or the seat is cancelled.

 . Report Generation:
o Bus Information: The BRS shall generate reports on bus about the
following information: Bus Number, daily root, driver name,
cleaner name, conductor name, no. of passengers can travel, type
of bus: Normal or AC list of passengers who have booked their sits
in bus and technical issues occurred in bus also.
o Sit Availability: The BRS shall generate reports on seats
availability about the following information: bus number, sit
number, occupied/unoccupied.

 Database:
o Passenger related Information: Each passenger shall have the
following mandatory information: first name, last name, phone
number, passenger identification number, address, postal code,
city, country, username and password.
o Bus related Information: Each bus should have the following
information: bus number, number of seats, bus type: normal or AC,
driver, engine details.
o Update Passenger Information: The BRS shall allow the
Administrator to update any of the bus information.

3.3 Behavior Requirements

3.1.1 Use Case View
A use case defines a goal-oriented set of interactions between external actors
and the system under consideration. Since sometimes we will not be able to specify
completely the behaviors of the system by just State Diagrams, we use use-cases to
complete it.
ACTIVITY DIAGRAM

This is the Activity UML diagram of Bus Booking System which shows the
flows between the activity of Customer, Ticket, Route, Booking, Bus. The main
activity involved in this UML Activity Diagram of Bus Booking System are as
follows:

 Customer Activity
 Ticket Activity
 Route Activity
 Booking Activity
 Bus Activity
Login Activity Diagram Of Bus Booking System:

This is the Login Activity Diagram of Bus Booking System, which shows
the flows of Login Activity, where admin will be able to login using their
username and password. After login user can manage all the operations on Route,
Customer, Ticket, Bus, Booking. All the pages such as Ticket, Bus, Booking are
secure and user can access these page after login. The diagram below helps
demonstrate how the login page works in a Bus Booking System. The various
objects in the Bus, Route, Customer, Ticket, and Booking page—interact over the
course of the Activity, and user will not be able to access this page without
verifying their identity.
DATA FLOW DIAGRAM (DFD)
A DFD is a process oriented graphical representation of an application
system. A DFD “ is a picture of the movement of external entities and the
processes and the data stores within a system. The components of a typical data
flow diagram are:
 Process
 Data flow
 Data store
 Terminator
Bus Booking System Class Diagram

Bus Booking System Class Diagram describes the structure of a Bus Booking
System classes, their attributes, operations (or methods), and the relationships
among objects. The main classes of the Bus Booking System are Bus, Booking,
Customer, Sales, Ticket Booking, Operators.Classes of Bus Booking System Class
Diagram:
 Bus Class : Manage all the operations of Bus
 Booking Class : Manage all the operations of Booking
 Customer Class : Manage all the operations of Customer
 Sales Class : Manage all the operations of Sales
 Ticket Booking Class : Manage all the operations of Ticket Booking
 Operators Class : Manage all the operations of Operators
Bus Booking System Component Diagram

This is a Component diagram of Bus Booking System which shows components,

provided and required interfaces, ports, and relationships between the Customer,
Route, Booking, Ticket and Bus. This type of diagrams is used in Component-
Based Development (CBD) to describe systems with Service-Oriented
Architecture (SOA). Bus Booking System UML component diagram, describes
the organization and wiring of the physical components in a system.Components of
UML Component Diagram of Bus Booking System:

 Customer Component
 Route Component
 Booking Component
 Ticket Component
 Bus Component
Bus Booking System ER Diagram

This ER (Entity Relationship) Diagram represents the model of Bus Booking

System Entity. The entity-relationship diagram of Bus Booking System shows all
the visual instrument of database tables and the relations between Booking, Sales,
Bus, Operators etc. It used structure data and to define the relationships between
structured data groups of Bus Booking System functionalities. The main entities of
the Bus Booking System are Bus, Booking, Customer, Sales, Ticket Booking and
Operators.

Bus Booking System entities and their attributes :

 Bus Entity : Attributes of Bus are bus_id, bus_name, bus_number,

bus_seat_number, bus_ticket, bus_type, bus_description
 Booking Entity : Attributes of Booking are booking_id, booking_title,
booking_type, booking_ticket, booking_date, booking_description
 Customer Entity : Attributes of Customer are customer_id, customer_name,
customer_mobile, customer_email, customer_username, customer_password,
customer_address
 Sales Entity : Attributes of Sales are sales_id, sales_customer_id, sales_ticket
sales_amount, sales_type, sales_description
 Ticket Booking Entity : Attributes of Ticket Booking are ticket booking_id,
ticket booking_type, ticket booking_Date, ticket booking_description
 Operators Entity : Attributes of Operators are operator_id, operator_name,
operator_mobile, operator_email, operator_username, operator_password,
operator_address
Bus Booking System Sequence Diagram

This is the UML sequence diagram of Bus Booking System which shows the
interaction between the objects of Booking, Ticket, Customer, Bus, Route. The
instance of class objects involved in this UML Sequence Diagram of Bus Booking
System are as follows:

 Booking Object
 Ticket Object
 Customer Object
 Bus Object
 Route Object
Login Sequence Diagram Of Bus Booking System:
4 Other Non-functional Requirements

4.1 Performance Requirements

 Response Time: The system shall give responses in 1 second after

checking the patient’s information.
 Capacity: The System must support 1000 people at a time.
 User-interface: The user-interface screen shall respond within 5 seconds.
 Conformity: The systems must conform to the Microsoft Accessibility
guidelines.
 Network Connection: They should be connected to internet 24 X 7.
And the Server must be on all the time.

4.2 Safety and Security Requirements

 Passenger Identification: The system requires the passenger to identify

himself/herself using PIN
 Logon ID: Any user who uses the system shall have a Logon ID and
Password.
 Modification: Any modification (insert, delete, update) for the
Database shall be synchronized and done only by the administrator
in the ward.
 Front Desk staff Rights: Front Desk staff shall be able to view all
information in BRS, add new buses to BRS but shall not be able to
modify any information in it.
 Administrators' Rights: Administrators shall be able to view
and modify all information in BRS.
4.3 Software Quality Attributes

Maintainability:
 Back Up: The system shall provide the capability to back-up the Data
 Errors: The system shall keep a log of all the errors.
Reliability:
 Availability: The system shall be available all the time
5.2TESTING
Testing is a process of executing a program with the interest of finding an error. A
good
test is one that has high probability of finding the yet undiscovered error. Testing
should
systematically uncover different classes of errors in a minimum amount of time
with a
minimum amount of efforts. Two classes of inputs are provided to test the process

E-Ticketing 54
1. A software configuration that includes a software requirement specification, a
design
specification and source code.
2. A software configuration that includes a test plan and procedure, any testing tool
and
test cases and their expected results.
Testing is divided into several distinct operations:
1. Unit Testing
Unit test comprises of a set tests performed by an individual program prior to the
integration of the unit into large system. A program unit is usually the smallest free
functioning part of the whole system. Module unit testing should be as exhaustive
as
possible to ensure that each representation handled by each module has been
tested. All
the units that makeup the system must be tested independently to ensure that they
work
as required.
During unit testing some errors were raised and all of them were rectified and
handled well. The result was quiet satisfactory and it worked well.
2. Integration Testing
Integration testing is a system technique for constructing the program structure
while at the same time conducting tests to uncover errors associated with
interfacing.
The objective is to take unit tested modules and build a program structure that has
been
dictated by design. Bottom-up integration is the traditional strategy used to
integrate the
components of a software system into functioning whole. Bottom-up integration
consists
of unit test followed by testing of the entire system. A sub-system consists of
several
modules that communicated with another defined interface.

The system was done the integration testing. All the modules were tested for
their compatibility with other modules. They test was almost successful. All the
modules coexisted very well, with almost no bugs. All the modules were
encapsulated
very well so as to not hamper the execution of other modules.
3. Validation Testing
After validation testing, software is completely assembled as a package,
interfacing errors that have been uncovered and corrected and the final series of
software test; the validation test begins. Steps taken during software design and
testing
can greatly improve the probability of successful integration in the larger system.
System testing is actually a series of different tests whose primary purpose is to
fully
exercise the computer –based system.
4. Recovery Testing
It is a system that forces the software to fail in a variety of ways and verifies that
the recovery is properly performed.
5. Security Testing
It attempts to verify that protection mechanisms built into a system will in fact
protect it from improper penetration. The system’s security must of course be
tested
from vulnerability from frontal attack.
6. Stress Testing
Stress tools are designed to confront programs with abnormal situations. Stress
testing executes a system in a manner that demands resources in abnormal quantity
and
volume.

7. Black Box Testing

Black box testing is done to find out the following information as shown in
below:
1. Incorrect or missing functions.
2. Interface errors.
3. Errors or database access.
4. Performance error.
5. Termination error.

The mentioned testing is carried out successfully for this application according
to the user’s requirement specification.
8. Test Data Output
After preparing test data, the system under study is tested using the test data.
While testing the system using test data, errors are again uncovered and corrected
by
using above testing and corrections are also noted for future use.

Appendix A – Data Dictionary

This SRS document is used to give details regarding. Online Bus Ticket
Reservation System. In this all the functional and non-functional
requirements are specified in order to get a clear-cut idea to develop a project.

CONCLUSION:
 The OBTRS is provides online reservation of bus availability, no.of. Seats
available, source, route, destination place, amount ,etc..,. And it is user
friendly ,accurate and no hidden cost in fares.

RESULT:
Thus, the main project 1 to develop software prototype for Online bus
ticket reservation System is done successfully with software requirement
specification document.