A Report on 'Bus Reservation System'

Document Sample
A Report on 'Bus Reservation System' Powered By Docstoc
					1. Introduction

1.1 Purpose

The purpose of this document is to present a detailed description of the Bus
Reservation System. It will explain the purpose and features of the system, the
interfaces of the system, what the system will do, the constraints under which it
must operate and how the system will react to external stimuli. This document is
intended for both the stakeholders and the developers.

1.2 Project Scope

       This software system will be a Bus Reservation System for a regional Tours
and Travels agency. This system will be designed to maximize the agency’s
productivity by providing tools to assist in automating the ticket issuing and review
process, which would otherwise have to be performed manually. By maximizing
the person’s (who will be working at the counter) work efficiency and production
the system will meet the agency’s needs while remaining easy to understand and
       More specifically, this system is designed to allow an the person who is at
the counter to manage and communicate with the people and easily issue them
tickets as per needed.

1.3 References

IEEE. IEEE STD 830-1998 IEEE Recommended Practice for Software

      Requirements Specifications. IEEE Computer Society, 1998.
2. Overall Description

2.1 Product Perspective
The main perspective of this s/w i.e. Bus Reservation System or the main reason
for its origin is to replace the traditional paper work that was being done during
issuing of the tickets in a regional travel agency. Records were hard to maintain as
it wasn’t feasible for the agency to maintain large databases. Automated ticket
issuing system will help the agency for faster issuing of tickets. Another
perspective is that the employee (and the user).can easily view the destinations the
agency is providing its travelling facility. So the major product perspective is to
automate and fasten at the same time maintaining the simplicity of entire ticketing

2.2 Assumptions and Dependencies

1. The user (one sitting at the booking table/counter) must know how to use a
computer efficiently.

2. It is also assumed here that the computer in use should be windows 98 or higher
version of O.S platform and Microsoft Internet explorer 5.0 or higher.

3. The accuracy of the information is the responsibility of the user.

2.3 External Interface Requirements

2.3.1 User Interfaces

The Bus Reservation System shall be designed as web based that has its main
UI.The format of the main screen shall be standard as well as flexible and
appealing. The system shall be user friendly. Pages shall be connected to each
other in a consistent way. Operations that are done with the system shall be
repeatable. The design of the pages shall allow the users to do this easily.

            As it can be seen from the above screenshot the main interface includes
a Logo, Background image, username and password field, Login button and Sign
up link. If the user clicks on signup the signup page is opened, If user clicks on log
in button after entering username and password the main page for booking the
tickets is retrieved.

There shall be other pages also related to customer operations and admin tool
operations. The example screenshots will be added to the document later.

2.3.2 Hardware Interfaces
There is no need of any hardware interfaces for this Bus Reservation System.
2.3.3 Software Interfaces
1. There are 2 options for viewing.
  A. Microsoft Internet Explorer 5.0 or higher.
PURPOSE: The web browser specified above is required as a container for the
client s/w at the client side on order to execute the client side of the product.
DEFINITION: The Microsoft Internet explorer is a s/w that provides a flexible
and reliable experience with enhanced web privacy features for all users.
B.One can even use Mozilla Firefox which is Microsoft’s competitor.
2. NAME: Apache HTTP Server
   PURPOSE: In order to execute the client side of the reservation system the web
server specified above is required as the provider of the client s/w at the server
   DEFINITION: The Apache HTTP server is an effort to develop an open source
HTTP server for modern O.S. including UNIX and Windows N.T.The goal is
provide secure, efficient and extensible server that provides HTTP services in sync
with the current HTTP standards.
  VERSION: 4.0.
  PURPOSE: In order to build web pages which work with MySQL database and
Apache server
  DEFINITION: PHP is a widely used general purpose scripting language that is
especially suited for web development and can be embedded into HTML.
  VERSION: 5.0
  PURPOSE: Require as a database server.
  DEFINATION: MySQL is the world’s most popular database server. With
superior speed, reliability and ease of use MySQl ahs became the preferred choice
of corporate IT managers as it eliminates major problems associated with
downtime, maintenance, administration and support.
2.3.4 Communications Interfaces
The default communication protocol for data transmission between server and the
client is Transmission Control Protocol/Internet Protocol(TCP/IP).At the upper
level Hyper Text Transfer Protocol(HTTP default Port=80,default of apache port =
8080) will be used for communication between web server and client.
2.3.5 Memory Constraints
There s no specific memory constraint for this Bus Reservation System
2.3.6 Operations
Company database backup and recovery operations should be done by support
team. A full system backup will be done once a month. If any update or
modification required on system like interfaces, new specialties; project group and
the acquirer will make a new meeting. The detailed operations are defined in User
Interfaces chapter.

2.3.7 Site Adaption

The Server has requirements to operate PHP scripts Apache Web server with PHP 4.0.

2.3.8 Product Features

1. Login to the system through the 1st page.

2. Should be able to login by using the desired username and password.

3. Book and issue (print) tickets to the customer by filling in their details into the
fields Provided (which is easy).

4. Ticket number (customer id) to be automatically generated by the product

5. See current reservations on different busses along witch the details.

6. Able to view seats available.

7. A calendar should be there to help select the dates easily.

8. The system should automatically show the fares for the seat for that particular

9. The login Id and password should be sent to the mentioned email address if a
new account is created.

10.A calendar should be there which helps the person to select dates. It
should also show the public and nation holidays
11. The administrator of the web site should used an admin tool for customize the
Web site.

12. The system should automatically show the fare for the corresponding seat and
amount of money needs to be pay for selected seats.

13. The admin tool shall handle followings:
a) Shall change the logo
b) Shall add or remove links onto the main bar
c) Shall give options for search tools
d) Shall add, remove or update links on the menu
e) Shall add, remove or update events on the event calendar

f) Shall add or remove Medias in the content menu

14. Logout from the system when not in use.


The user types that would use the OBTRS are as follows

Administrator: Administrators shall usually do anything on the site, in all pages.
Administrator is responsible for updating and the maintenance of the web
site content such as adding/removing information about the company,
adding/removing links onto the main bar, adding/removing medias in the
content menu, adding/removing/updating links on the event calendar and the
menu, changing the logo.

Customer: Customers are people who shall use OBTRS. To use this service people
should have the basic computer using ability. They shall see the buses information
which is belong to current time. User can see all general information,
FAQ can use search.

External Users: External users are people who have not got any user account for
the web site. They shall use the general information, FAQ.

a. Regulatory Policies: There are no regulatory policies.

b. Hardware Limitations: There are no hardware limitations.
c. Interfaces to other Applications: There shall be no interfaces.

d. Parallel Operations: There are no parallel operations.

e. Audit Functions: There shall be no audit functions.

f. Control Functions: There shall be no control functions

g. Higher-order Language Functions: The PHP shall be used for developing
the web pages with the help of Macromedia Dreamweaver. For the database
information, SQL shall be used.

h. Signal Handshake Protocols: This is no signal handshake protocols.
i. Reliability Requirements: Total number of bugs in the system shall not
exceed %1 of the total line number of code, except connection reliability which is
out our range.

j. Criticality of the Application: The server applications shall be available
365 days.

k. Safety and Security Considerations: The password and a valid username are the
security issues. Data protection shall be satisfied by the backup process at the
server side.


The system shall operate 95% of the time. The number of defect should not Exceed
10 per function. In addition, before the submission of the final release the calendar
must be tested in case of the defects over 10 per function.
The availability of the OBTRS is up to the internet connection of the client. Since
this is client-server related web-site, web-site shall be attainable all the time. User
should have an account to enter the system, if user does not have an account;
for the availability of the OBTRS user should sign up to the system by
clicking the sign up link from the home page.

The authorization mechanism of the system will block the unwanted attempts
to the server and also let the system decide on which privileges may the
user have. The system has different types of users so there are different
levels of authorization. There will be also a firewall installed on the server so the
incoming transactions can be filtered. Data integrity for critical variables will also
be checked.

The requirements, modules that are explained in this document are enough to
satisfy the customers‘ needs and wants. In case of a change or addition demand
after completing the system or in development processes of the system, a new
agreement shall be done between the acquirer and FERSOFT Dev Group. The
maintainability shall be easily done by integrating new modules and offering
new software solutions for the system.

The OBTRS is an online service. So, anyone can use the service. One and only the
server of the system must have the required software including MySQL, Apache.

There are no other requirements in this phase. If some extra requirements are
wanted by the customer or acquirer; these are added in this part later

                Use Case of User
Use Case of Admin
Use Case of External User
State Diagrams:

                  State Diagram of Login
State Diagram of Logout

Shared By:
Description: A project report on automated bus reservation system