Chapter Two: Description of Existing System

2.1. Introduction
In this chapter we will discuss the user class and its characteristics, business rules, proses model,
activities of current system bottlenecks and practices to be preserved.
Existing system refers to the system that is being followed till now. The existing system requires
more computational time, more manual calculations, and the complexity involved in Selection of
features is high. The other disadvantages are lack of security of data, Deficiency of Data
accuracy, Time consuming etc. To avoid all these limitations and make the working more
accurately the system needs to be computerized. Here in the Electronic bus ticketing, a detailed
study of existing system is carried along with all the steps in system analysis.

2.2. Organization Structure

2.3. User Class and Characteristics
User class
System administrator
Passengers
Deriver
User class
System administrator

User class Characteristics

-Responsible for manage and
control the whole system of
Wolkite bus ticketing system

Passenger

Who uses the system for

travel by bus
-Responsible for deriving the
bus by schedule

Deriver

Technical skill
-Has ability and experiences
on different system
-Familiar for any software
engineering discipline
-Should have computer skill
for internet service
-Should have computer skill
for internet service
-Ability to work on different
automobiles and certified

2.4. Business Rule

The customer should have valid legal bank account for payment of ticket.
Double ticketing is needed i.e. one ticket for one person.

2.5. Business Process Model

2.6. Current System Activity
Book ticketing

Activity name
Description

Actors

Preconditions
Trigger
Flow of events

Post condition
Personal
information

Book ticketing
In this business process passenger buy ticket
by going to bus station office then make
travel to reach destination.
Primary actors are:
Administrator
Passenger
Deriver
Passenger present in station
When passenger wants for travel by bus
Passenger present in bus station
Ask for bus ticket
Fill the manual form
Get seat number
Wait for schedule
Make travel on schedule
Deriver see the schedule
Administrator manage booking
Passenger reach destination
The personal information includes:
Full name
Address
Phone number
Destination
Sex

2.7. Bottlenecks of the existing system

2.7.1. Performance
The existing system as it is manual system it has no such speed and response time.
It takes a time for passenger to buy ticket because they must be go to bus station to buy
ticket paper.
Data stored in paper so it is do not good storing techniques.

2.7.2. Input and Output

The input and output of the system it is not current.
During input they use pen or pencil that enter wrong form. i.e. it may be unreadable or
difficult to understand. The output peas of paper that may tire or lost.

2.7.3. Security and Controls

The system has administrator signature and sell for security.
Only main manager or administrator has responsibility to do ticketing activity.

2.7.4. Efficiency
The data stored in manual documents that is efficient and it takes so much to write and read for
updates.

2.8. Practices to be preserved

Chapter Three: Proposed System
3.1. Proposed Solution for the new system that address
problems of the Existing system
A new system is helpful to both administers as well as the customers. New system provides help
to the customer as they can inquire about the Bus model, its Ticket price, available Seats, facility
of the bus etc. and they dont need to walk to the office. There is login and password service for
administers and Regular customers to use this system on internet based way.

3.2. Requirements of the proposed system

3.2.1. Functional Requirements
3.2.1.1. Performance Requirements
Search Bus category or information wise and has immediate response.
After any activity the system give feedback.
3.2.1.2. Process Requirement
First of all, in our website any user or visitor are view our system and also search the bus and how
many User can also registered its own seats in bus this website .User can post a comment

on different Bus Services. But user can compulsory registered first in the system.
3.2.1.3. Input related requirements
The system has a functions that allow administrator to add the new schedule the
destination to the driver.
In this system admin can maintain all the Bus information and
also maintain Bus category, comments etc.
In this system admin can maintain the registered users, manage news.
3.2.1.4. Output related requirements
The system has a function that allows the driver to view the schedule that assign by the
administrator according to their name so the driver can know when and what time they
should drive the bus from one destination to another destination.
3.2.1.5. Storage related requirements
The system able to store the information of traveler till out of date and able to update for
new status.

3.2.2. Non Functional Requirements

 Performance
Creating this new system can bring a lot convenient to customer and staff. E.g, if
customers need to book the bus ticket, they no need to go to the bus station to
booking or buying the ticket especially the person who are staying very far to bus
station. They can direct use this bus services booking via internet. It also brings
convenient to people who are buy, so they can online booking at any time.
Availability
The system work by schedule so it is available at planed time
The user checks the availability of the bus through bus schedule by searching it.
Improve efficiency
The process time of the current system are time consuming because the current
system are using paper work to record down all the information. It is take a lot of
time to serve the customer when the staff searching the available time and seat.
The purpose of create this system is to improve the efficiency time of process. It
can let the staff search the information faster and easier and maintain the data
faster and reduce the paperwork.
Usability
Made reservation using online method can attract more customers because made
reservation online can save a lot of time for the customer. If can let the customer
feel convenient, so that they will come to our company buy the bus ticket more
often when they want to go somewhere around Wolkite so we can earn more
income from them.
Scalability
The system is scalable that if the number of the user and seat increase the system
is work as its size.
Security
The system services the authenticated users that registered legally.
Programming for the Internet requires programmers to consider different security
issues that may not necessarily be a problem when programming for single
machine programs.

Chapter Four: System Analysis

4.1. System model
It mainly described by use case diagram.

4.1.1. Scenarios
4.1.2. Use case model
The use case diagram describes the system model of the bus ticketing system

4.1.3. Use case description

User Activities
The most common activities carried out by user are illustrated bellow.
The user can search for the seat
The user can sign up/do registration with the system
The registered user can login to the proposed system
The user can check for the available seat on the proposed system
The user can print receipt on the system as evidence of payment
Administrator activities
The most common activities carried out by the administrator are illustrated bellow.
The administrator will verify all the registered use , and allow them to login the
system
The administrator give acknowledgement to any payment user made on the
system
The administrator can add vehicle, driver and generate report as well

4.1.4. Object model

4.1.4.1. Data Dictionary

The data dictionary is descrbes data base storage tables form that how it stores the information.
Table Name: Registry
Primary Key: Reg_id
Foreign Key: Description: The information about Registration of the costomer
N
o
1

Field Name

Data type

Reg_id

int

First_Name

Last_Name

Email_id

Address

City

7
8

Pincode
contacNo

Nvarchar(30
)
Nvarchar(30
)
Nvarchar(20
)
Nvarchar(20
)
Nvarchar(20
)
Nvarchar(6)
Numeric(10)

Constraint
s
Primary
key
Not Null

Description

Not Null

It stores Customers last name.

Not Null

It stores the email_id.

Not Null

It stores customer address.

Not Null

It stores customer city.

Not Null
Not Null

It stores customer pincode.

It stores customer contact
number

It store Registration id.

It stores Customer First name.

Table Name:login
Primary key: user_id
Foreign key: -- Description: The information about login
No
1
2

Field Name Data type Constraint

Description
User_id
int
Primary key It is store user id.
Username
varcar(30 Not Null
It store username
)
3
Password
varcar(20 Not Null
It store password
)
4
Type
varcar(10 Not Null
It store type of admin or user
)
Table Name:Booking
Primary key: tiket_id
Foreign key: Reg_id, Bus_id
Description:The information about booking ticket detail
N
o

Field Name

Data type

constraint

Description

1
Book_id
int
2
Reg_id
int
3
Bus_id
int
4
Fname
Varchar(30)
5
Lname
Varchar(30)
6
Email
Varchar(30)
7
ContactNo numeric(10)
8
Address
Varchar(20)
9
City
Varchar(20)
10 SeatNo
Varchar(20)
11 Date
Varchar(20)
Table Name:Bus
Primary key: Bus_id
Foreign key: -

Primary key
Foreign key
Foreign key
Not Null
Not Null
Not Null
Not Null
Not Null
Not Null
Not Null
Not Null

It stores booking id.

Gives references to Registory.
Gives references to Bus.
It stores first name.
It stores last name.
It stores E-mail id.
It stores mobile number.
It stores customer address.
It stores city.
It stores bus seat number.
It stores travelling date.

Description: The information about bus ticket price.

No Field Name Data Type
Constraints
1
Bus_id
int
Primary key
2
BusNumber Varchar(20) Not Null
3
BusType
Varchar(20) Not Null
4
TotalSeat
int
Not Null
Table Name:feedback
Primary key: fb_id
Foreign key: Reg_id
Description: The information about feedback.

Description
It stores bus id.
It stores bus number.
It stores bus type.
It stores total seat of bus.

N
o
1

Field Name

Data Type

Constraint

Description

Fb_id

int

It stores feedback id.

2
3
4
5

username
Feedback
Date
Time

Varchar(30)
Varchar(50)
date
time

Primary
key
Not Null
Not Null
Not Null
Not Null

It stores user name.

It stores feedback.
It stores date of given feedback.
It stores time of given feedback.

4.1.4.2. Analysis level Class Diagram

4.2. Dynamic model

It described by the sequence diagram, activity diagram, state diagram etc. as illustrated bellow

4.2.1. Sequence Diagram

Sequence diagram

 Sequence diagram for user

4.2.2. Activity Diagram

Activity diagram for admin

 Activity diagram for user

4.2.3. State Diagrams

4.2.4. User interface
4.2.5 Supplementary Specifications