BHAR DAR UNIVERSITY

BAHIR DAR INSTITUTE OF TECHNOLOGY

FUCULTY OF CMPUTING
Industrial Project On:
Web Based Transport Management System for Bahir dar city Bus
Station: The case of Transport Cooperator and Distributor

Submitted to the faculty of computing in partial fulfillment of

the requirements for the degree of Bachelor of Science in
Computer Science
By

Name ID No
Abate Abebaw ------------------------------------------0700851

Getaw Teklie---------------------------------------------0700976

Ashenafi Alelgn-----------------------------------------0700897
Advisor: Hailu Beshada (MSc)

Bahir Dar Ethiopia 2017/2010

 DECLARATION

The project is our own and has not been presented for a degree in any other university and all the
sources of material used for the project have been duly acknowledged.

Abate Abebaw
Name Signature

Getaw Teklie
Name Signature

Ashenafi Alelgn
Name Signature

Faculty: Computing

Program: Degree

Project Title: Web Based Transport Management System for Bahir Dar Bus Station: The case
of Transport Cooperator and Distributor.

This is to certify that I have read this project and that in my option it is fully adequate, in scope
and quality, as a project for the degree of Bachelor of Science.

---------------------------------------------
-------------------------------
Name of Advisor Signature

Examining Committee Member Signature

1. Examiner 1 ____________________________
____________
2. Examiner 2 ____________________________
____________

It is approved that this project has been written in compliance with the formatting rules laid
down by the faculty.

i
 ACKNOWLEDGMENT

First and foremost, we would like to thanks our Almighty GOD for giving all the capabilities to
do things and helped us from the start to the end. Next to GOD We wish to express our sincere
gratitude to the Faculty Of Computing, for providing as an opportunity to perform our project
work on “Web Based Transport Management system for Bahir Dar Bus Station” .We sincerely
thank our project Advisor, Mr. Hailu Beshada for his diligence in advising and guiding us to
through the right path, from the inception until the completion of this document. Additionally we
would to thanks for all class of fourth year computer sciences students and of our friend for
sharing many useful ideas. Finally, we have also a great pleasure for employees of Bahir Dar
City Bus Station especially Mr. Abebaw and Mr. Brhanu for spending their precious time with us
and giving us the information we were searching for.

ii
LIST OF ACRONYM AND ABBREVIATIONS

A: Alternative

Admin: Administrator

AminID: Administrator Identification number

BDBS: Bahir Dar Bus Station

BR: Business Rule

DB: database

DEMID: Distributer Employee Manager Identification Number

Dev’t: Development

DOB: date of birth

DPMID: Development Process Manager Identification Number

FREQ: Functional Requirements

Info: information

MYSQL: standard query language

OPID: Operator Identification Number

PHP: hypertext markup language

UC: Use Case

UML: Unified modeling Language

WAMP: window Apache MySQL php

iii
 LIST OF TABLE
TABLE 2. 1 ACTOR DESCRIPTION...................................................................................................................................21
TABLE 2. 2 LOGIN USE CASE DESCRIPTION...................................................................................................................24
TABLE 2. 3 USE CASE DESCRIPTION OF ACCOUNT DEACTIVATE....................................................................................25
TABLE 2. 4 USE CASE DESCRIPTION OF ACCOUNT UPDATE..........................................................................................26
TABLE 2. 5 CASE DESCRIPTION OF ACCOUNT CREATE..................................................................................................27
TABLE 2. 6 USE CASE DESCRIPTION OF SEARCH...........................................................................................................28
TABLE 2. 7 USE CASE DESCRIPTION OF VIEW REPORT..................................................................................................29
TABLE 2. 8 USE CASE DESCRIPTION OF FORMED MEMBERS..........................................................................................30
TABLE 2. 9 USE CASE DESCRIPTION OF REQUEST INFORMATION..................................................................................31
TABLE 2. 10 USE CASE DESCRIPTION OF ACCEPT MEMBERSHIP REQUEST.....................................................................32
TABLE 2. 11 USE CASE DESCRIPTION OF APPROVE REQUEST........................................................................................33
TABLE 2. 12 USE CASE DESCRIPTION OF REGISTER ASSOCIATION................................................................................34
TABLE 2. 13 USE CASE DESCRIPTION OF PREPARE SCHEDULE......................................................................................35
TABLE 2. 14 USE CASE DESCRIPTION OF UPDATE SCHEDULE........................................................................................36
TABLE 2. 15 USE CASE DESCRIPTION OF UPLOAD AVAILABLE BUS..............................................................................37
TABLE 2. 16 USE CASE DESCRIPTION OF REGISTERED BUS INFORMATION....................................................................38
TABLE 2. 17 USE CASE DESCRIPTION OF VIEW REGISTERED ASSOCIATION...................................................................39
TABLE 2. 18 USE CASE DESCRIPTION OF GENERATE REPORT........................................................................................40
TABLE 2. 19 USE CASE DESCRIPTION OF SEND REQUEST..............................................................................................41
TABLE 2. 20 USE CASE DESCRIPTION OF VIEW..............................................................................................................42
TABLE 2. 21 USE CASE DESCRIPTION OF VIEW AVAILABLE BUS...................................................................................43
TABLE 2. 22 USE CASE DESCRIPTION OF VIEW REQUEST..............................................................................................44
TABLE 2. 23 USE CASE DESCRIPTION OF SEARCH BUS INFORMATION...........................................................................45
TABLE 3. 1 CLASS DESCRIPTION....................................................................................................................................70

LIST OF FIGURE
FIGURE 2. 1 EXISTING SYSTEM WORK FLOW DIAGRAM...............................................................................................11
FIGURE 2. 2 PROPOSED SYSTEM DIAGRAM....................................................................................................................13

iv
FIGURE 2. 3 USE CASE DIAGRAM..................................................................................................................................22
FIGURE 2. 4 USER INTERFACE PROTOTYPE...................................................................................................................46
FIGURE 2. 5 SECURITY LOGIN ACTIVITY DIAGRAM........................................................................................................48
FIGURE 2.6 UPDATE ACCOUNT ACTIVITY .....................................................................................................................50
FIGURE 2. 7 ACTIVITY DIAGRAM OF BUS INFORMATION REGISTRATION.......................................................................51
FIGURE 2. 8 PASSENGER SEARCH FOR AVAILABLE BUS.................................................................................................52
FIGURE 2. 9 PREPARE SCHEDULE ACTIVITY DIAGRAM..................................................................................................53
FIGURE 2. 10 ACCOUNT DEACTIVATE ACTIVITY DIAGRAM...........................................................................................54
FIGURE 2. 11 UPLOAD AVAILABLE BUS ACTIVITY DIAGRAM.......................................................................................55
FIGURE 2. 12 SEND REQUEST ACTIVITY DIAGRAM......................................................................................................56
FIGURE 2. 13 APPROVE REQUEST ACTIVITY DIAGRAM................................................................................................57
FIGURE 2. 14 LOGIN SEQUENCE DIAGRAM....................................................................................................................58
FIGURE 2. 15 CREATE ACCOUNT SEQUENCE DIAGRAM.................................................................................................59
FIGURE 2. 16 UPDATE ACCOUNT SEQUENCE DIAGRAM.................................................................................................60
FIGURE 2. 17 ASSOCIATION REGISTER SEQUENCE DIAGRAM........................................................................................61
FIGURE 2. 18 LOGOUT SEQUENCE DIAGRAM.................................................................................................................61
FIGURE 2. 19 UPLOAD ACTIVITY DIAGRAM..................................................................................................................62
FIGURE 2. 20 VIEW AVAILABLE BUS SEQUENCE DIAGRAM...........................................................................................63
FIGURE 2. 21 SEND REQUEST SEQUENCE DIAGRAM.....................................................................................................64
FIGURE 3. 1 COMPONENT DIAGRAM..............................................................................................................................68
FIGURE 3. 2 DEPLOYMENT DIAGRAM.............................................................................................................................69
FIGURE 3. 3 CLASS DIAGRAM........................................................................................................................................72
FIGURE 3. 4 PERSISTENT DIAGRAM...............................................................................................................................73
FIGURE 3. 5 HOMEPAGE USER INTERFACE....................................................................................................................74
FIGURE 3. 6 LOGIN USER INTERFACE...........................................................................................................................75
FIGURE 3. 7 ASSOCIATION REGISTRATION USER INTERFACE........................................................................................76

Table of Contents
DECLARATION.........................................................................................................................................i
ACKNOWLEDGMENT.............................................................................................................................ii

v
LIST OF ACRONYM AND ABBREVIATIONS......................................................................................iii
LIST OF TABLE.......................................................................................................................................iv
LIST OF FIGURE.......................................................................................................................................v
ABSTRACT.............................................................................................................................................viii
CHAPTER ONE........................................................................................................................................1
1. INTRODUCTION...................................................................................................................................1
1.1 Background of the organization.........................................................................................................1
1.2 Existing system study........................................................................................................................2
1.3 Proposed System................................................................................................................................3
1.4 Objectives of the project....................................................................................................................3
1.4.1 General Objective.......................................................................................................................3
1.4.2 Specific Objectives.....................................................................................................................4
1.5 Scope of the project...........................................................................................................................4
1.6 Limitations of the project...................................................................................................................5
1.7 Significance of the project.................................................................................................................5
1.8 Methodology......................................................................................................................................6
1.8.1 Requirement gathering methods.................................................................................................6
1.8.1 Analysis and design Methodology..............................................................................................6
1.8.3 Implementation Methodology.....................................................................................................7
CHAPTER TWO.......................................................................................................................................9
2. REQUIREMENT ELICITATION AND ANALYSIS.............................................................................9
2.1 Introduction.......................................................................................................................................9
2.2 Existing System.................................................................................................................................9
2.3 Proposed System..............................................................................................................................12
2.4 Requirement Analysis......................................................................................................................13
2.4.1 Functional Requirement............................................................................................................14
2.4.2 Business Rule...........................................................................................................................18
2.4.3 System Use case.......................................................................................................................19
2.4.4 User Interface prototype...........................................................................................................46
2.4.5 Activity Diagram......................................................................................................................47
2.4. 6 Sequence Diagram...................................................................................................................57
2.5 Non-functional requirement.............................................................................................................64
2.6 System Requirement........................................................................................................................66

vi
 2.6.1 Hardware Requirement.............................................................................................................66
2.6.2 Software Requirements.............................................................................................................66
CHAPTER THREE.................................................................................................................................67
3. SYSTEM DESIGN................................................................................................................................67
3.1 Introduction.....................................................................................................................................67
3.2. Architectural Design.......................................................................................................................67
3.2.1. Component Modeling..............................................................................................................67
3.2.2. Deployment Diagram...............................................................................................................68
3.3 Design Class Model.........................................................................................................................69
3.3.2 Persistent Modeling..................................................................................................................73
3.4 User Interface..................................................................................................................................74
3.5 Logic Model....................................................................................................................................77
4. References.........................................................................................................................................80
5. Appendices............................................................................................................................................81

vii
 ABSTRACT

This document is written to give detail information about Transport Management System of
Bahir Dar Bus Station. It is intended to describe the general operations of the bus station that are
being performed daily. It is also aimed to describe the general approaches to be followed to
automate the existing manual system to a computerized system. We are developing a web based
transport management system for the bus station. It is done using the object oriented approach
for development of the project. For the ease of understanding of the document, we have
structured it into three chapters.

The first chapter is a general introduction and overview of the proposed system (proposal). The
second chapter onwards, we have given detail descriptions for the existing and the newly
proposed systems, about requirement elicitation processes that include the functional, non-
functional and system requirements, use case diagram with description, sequence and activity
diagram also include in this chapter.

The third chapter is about system design. It includes different diagram such as component,
deployment, persistent and design class model diagram. The document is done by all the
members of the group and we attached the interview and questioner questions used while data
collection as appendix at the end.

viii
 CHAPTER ONE

1. INTRODUCTION

Transportation is a process of moving people and objects from one place to other places. It has
different type of transportation such as air transport through the air, water transport trough lakes,
rivers, seas or oceans and land transport trough the land spaces.

1.1 Background of the organization

The idea of modern land transportation in Ethiopia was first started during the time of Menilik II
in which he brought a single vehicle from abroad. The idea then developed by emperor
Hailesilassie and grown into many services. From that time onwards people of Ethiopia tried to
replace the transportation on the back of animals to modern means such as vehicles and the use
of these vehicles became the part of the people’s life.

Likewise modern transportation from Bahir Dar was also started during emperor Hailesilassie
after 1955 E.C. Although there was transportation by that time, its amount was very less and
there was no an organized bus station for later 17 years. Now there are more than eight one (81)
towns connected to Bahir Dar Bus station.

This proposal is about Bahir Dar Bus Station transport management system. It is aimed to make
the activities involved in the bus station computerized. The current system is being undergone
manually and even if it is able to do its task well, its tasks are tedious and time consuming to be
performed by human beings. Therefore, before going in detail about the project, lets discus about
the background of the bus station.

Bahir Dar bus station (BDBS) is located at the central part of Bahir Dar city under Amhara,
region of Ethiopia 565 kms west of Addis Ababa. It has its roots from Bahir Dar city
administration. Under Bahir Dar city administration, there is a government structure called the
Road Transport Development Administration which has a part named Transport Supply and

1
Cooperation Major Team. The Transport Supply and Cooperation Major Team are comprised of
four major categories. The first category is the Transport Efficiency Qualifier who measures and
checks the quality and efficiency of the transportation system provided to the society. The
second category is the Transport Cooperator and Distributor (Simirit Yesira Hidet) who performs
all the activities involved in the bus station. The third category is the Human Resource who
manages and controls all the human resources that exist at the transportation system. The final
category is the Road Transport Security Authority that manages all the security issues that
occurred during transportation. Therefore, Bahir Dar Bus Station is under the Transport
Cooperator and Distributor category of the Transport Supply and Cooperation Major Team.

1.2 Existing system study

In fact, Bahir Dar Bus station is doing its intended tasks and achieving its goals by following the
manual approach. But, since some tasks are being performed manually .it has several problems.
These are:

 They are assigning turns and destination places manually. This process is a great task that
requires much time and effort to accomplish. Turns and places are being assigned once for a
month and they are expected to assign for all destination areas. Therefore, doing this task
manually is time consuming and tedious. In addition to this, doing this task manually is also
prone to errors and biases.
 They are recording information about buses and Associations (Mahiberat) manually in paper
documents. Recording information using paper documents is not reliable since it may be lost
or harmed by certain damages. In addition to this, it is hard and time taking to search and get
specific information from a huge paper document. And if someone wants to get information
after some time, it is hard and sometimes impossible to get this information.
 They are showing much information about the buses, the name and other information of the
driver, initial place, destination place, and other information to passengers by making it
available in the bus itself. Therefore, there is no means for passengers get ultimate
information from the office and assigned workers and most of the buses do not notify these
information and even if they notify, it is nut full and sufficient.
 For a customer to know which bus is ready to go to the place he/she wants, he/she must
search it through the bus station and ask the workers of the buses or hearing callings of the

2
 workers about the available buses. There is no means for the passengers to know which bus
is going to be the turn owner currently easily. This process is also time taking and may also
hazardous for passengers who have many objects to be traveled because theft may also occur
around there.
 The manual system does not allow Associations (Mahiberat) to view all the available
working areas and from Bahir Dar and make a selection based on their requirements. These
Associations simply request the workers of Transport Cooperator and Distributor workers to
give those turns and places. This made the Associations unsatisfied within the services.

1.3 Proposed System

To solve the above problem we are interested to develop web based transport management
system. It can easily solve the problem. So that the proposed system also have the following
scope and functionality with the existing system.

To solve the problem by using database connection update, delete, search, and view data’s easily,
this system can solve the listed problem and save resources. Because the existing system
extravagant for resources. The main function of the proposed system is easily to do their work
for any workers who found in the bus station. And the system administrator can manage easily
forever employee found in the bus station and associations. It used for save time and check the
performance of the bus and save the data confidentially without any disorder and error.

1.4 Objectives of the project

1.4.1 General Objective

The general objective of this project is to develop Web based transport management system for
Bahir Dar City Bus Station.

1.4.2 Specific Objectives

To achieve the general objective, the following specific objectives are identified:
 To analyze and study the state of the art of the transportation system
 To design and model transport management system for Bahir Dar Bus Station
 To study and analyze the limitations of the existing system.
 Record all data related to buses and Associations (Mahiberat)

3
  Specifying functional and non- functional requirements of the proposed system.
 Design proposed system to solve the existing problem
 Implementing the proposed system
 To develop, and implement transport management system for Bahir Dar Bus Station

1.5 Scope of the project

The project is going to be done including the following areas of tasks involved in the bus station
transport coordinator and distributor team (Simirit yesira hidet). These are:

 Involves data registration of vehicles and manipulation of these data

 Involves data registration of associations and manipulation of these data
 Adjusting turns/schedules for the vehicles that are serving the society under BDBS.
 Checking maintenance record to assess quality and performance of vehicles.
 Recorded bus order based on their reach time
 Assign the work place timetable(Merhagbr) for each bus
 Update and delete some recorded data’s
 Register new bus to bus station and assign work place based on owner need and association
permission.
 Passengers can view available bus with their level
The following areas does not included in this scope:
 It does not do actions that are performed outside of the Transport Cooperator and
Distributor team (Simirit Yesira Hidet).
 Not include other vehicles that do transportation of loads and objects.
 Cannot formulate and establish tariffs
 It does not do booking or reserving of tickets for passengers.

1.6 Limitations of the project

There are some limitations within the proposed system those are listed below.
 Unwillingness of some respondents to give a correct answer.
 Respondents cannot respect appointment time.

4
 1.7 Significance of the project

This project is significant for different stakeholders in different aspects. Among these:
i. For Bahir dar Bus Station workers: currently the workers of the bus station are
performing their tasks manually. This way is tedious and time taking and they are
unable to do their tasks without required to spend much effort. Therefore, this project
allow them to perform their activities easily supported by the project.
ii. For the passengers: in the current system, passengers get the information they want
from the bus itself which is not complete and not always available. This project allows
them to get the information they want which is up-to-date and complete easily from one
place.
iii. For Associations (Mahiberat): these Associations are expected to go to the Transport
Cooperator and Distributor team (Simirit Yesira Hidet) and submit their information
and needs using paper format, but cannot easily see which areas are better for work and
not crowded to be occupied and select according to their wishes. But this project allows
them view these better and unoccupied areas through simple DBMS techniques.
iv. For Government officials: in the current system, if someone requests to get specific
information, he/she has to stay and wait until it is found from a huge document. But
using this project, one can get what he/she want within duration of time since it is
equipped with searching techniques.
v. For Group Members of the project: members of this project (students) have getting
and also get much knowledge and experience of system development and problem
solving. Beside this we encourage to solve any other real world problems that face in
daily activity.

5
 1.8 Methodology

1.8.1 Requirement gathering methods

We have undergone different types of data collection mechanisms to get the necessary
information about the project and to understand the nature and working conditions of the existing
system. These are:
a. Interview
An interview was undergone to the two officials of Transport Cooperator and Distributor (Simirit
Yesira Hidet) of Bahir Dar bus station. The two official was selected by stratified sampling
because of we use this type of sampling was good and better than of random sampling and the
selection was based on education level. It was aimed to get detail information about the
functioning of the existing system and general background information about the bus station.
b. Observation
In addition to the interview method, we have deeply observed the functionalities of the bus
station in its natural setting without being known by the workers. Through it also we have got
much idea.
C. Questionnaires
To get more information we select some workers and prepare questions about the system. The
condition occurs by question and answer of few selective workers of the bus station. The
questionnaire are both closed and opened ended questions. To prepare the questioner for only same
peoples by selecting education level. I.e. we used stratified sampling.

1.8.2 Analysis and design Methodology

Object Oriented Approach: the method of system development paradigm we selected is the
object oriented approach because this approach is helpful for us to represent the different phases
of the project through many diagrammatic representations such as activity diagrams, use cases,
sequence diagrams, class diagrams etc. Generally we choose object oriented development design
because of:-
 These techniques have a reusability feature.

6
  These techniques provide greater opportunities for users to participate in the development
process.
 This increases flexibility.
 This also improved quality.
 These techniques are latest, powerful, easy and highly usable.
 Increase domain and design reuse.

Development Approach
In our team we select iterative model approach because , to design our project we are required to
review and redesign in each phase iteratively to meet user requirements.
 To learn from earlier development versions.
 Iterative model is the simplest model of software development tool.
 All the phases of SDLC function one after another cyclic manner.
 To get quick end user feedback &make enhanced system.
 Easily identify missing functionalities.

1.8.3 Implementation Methodology

We use the following programming tools to develop our system.

 Edraw Max uml 8.0 tool: - used to draw different UML that is necessary to design analysis
system and database design.
 Visual Paradigm 14.0 used to draw persistent diagram.
Back end tools
 MYSQL server
We select MYSQL DBMS because
 MySQL database is fast
 MySQL database is free to use
 MySQL database is compatible with php platform.
Front end tools
 HTML
We select HTML because:
 Html is platform independent language that is pre dominantly used the web and web
based application.

7
 PHP
We select php because:

 Php can work a Varity of plat form including window and UNIX. The base part is that
php is the most efficient with the most popular server, which is apache.
 JAVASCRIPT
We select JavaScript because:
 JavaScript is browser independent
 It allowing the creation of interactive web page
 Source code editors
 Notepad++
 Wepserver: apache 2.0
 Web browser: Mozilla Firefox 59.0 or any compatible browser.

8
 CHAPTER TWO

2. REQUIREMENT ELICITATION AND ANALYSIS

2.1 Introduction

This chapter contains the requirement of the system and the problem that we are going to solve.
This phase broad and contains many employers, and managers’ activities and tasks that are
extremely important to the overall success of the transport solution. In this phase include
requirement analysis, requirement gathering and description of the current system, problem
analysis and user need, requirement modeling, system analysis, alternative solution, proposed
system description and analysis modeling.

2.2 Existing System

Existing system refers to the system that is being followed till now. The existing system requires
more computational time, 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.    

The station is performing its task manually and there are many activities that are being
performing by using paper documents. The station worker and operators are moving carrying of
documents from one room to other room in the station. The station workers communicate
manually. The major players of the current system are Operator, Passenger, and manager of
Development process, Association and distributer Employees.

The main role of distributer employee’s manager are registered bus information, prepare
schedule of bus, registered order of bus based on reach time and prepare report. The Main role of
operator it must be legal member of association, view prepare schedule, and have legal right to
change the schedule by association permission.

The main role development process manager is control all activity of association, approve the
membership request of association. main role of association manager are accept the membership

9
request of operator and send to development process manager, give permission for operators to
change their schedule. Distributer employee manager has roles of View report and control all
employees found in the bus station.

To do these, the activities follow the following procedures. These are:

1. The operator ask to membership question for association manager.

2. Then the association manager accept membership request if it fulfill the property.
3. And the association after accepting send to development process,
4. The development process approve membership question. After this the operator are
association member then the cooperative and distributer manager to assign work place.
5. If the operator went to change work place to ask the association. If the association to give
permission for operator to change work place or schedule.
6. In every month, officials of Transport Cooperator and Distributor (Simirit Yesira Hidet)
assign the buses that going to specific areas including their leaving time and the buses are
expected to follow this arrangement until the end of the month in which new arrangement
is done.

Diagrammatically the work flows of existing system are like this:

10
 Figure 2. 1 Existing System Work flow diagram

The existing systems are the following limitations, a detailed study of existing system is carried
along with all the steps in system analysis.

 Lack of security of data.

 More man power.
 Time consuming.
 Consumes large volume of pare work.
 No direct role for the higher officials.
To avoid all these limitations and make the working more accurately the system needs to be
computerized.

11
 2.3 Proposed System

By carefully analyzing and observing the problem of existing system we came up with a solution
that the current manual system should be computerized. The computerized system are
eliminate/reduce the problem on time, work load. To develop web based management system. It
can easily solve the problem. So that the proposed system also have the following similar scope
and functionality with the existing system.

To solve the problem by using database connection can upload necessary information, update,
delete, search, and view data’s easily, this system can solve the listed problem and save
resources. Because the existing system extravagant for resources. The main function of the
proposed system is easily to do their work for any workers who found in the bus station. And the
system administrator can manage easily forever employee found in the bus station and
associations. It used for save time and check the performance of the bus and save the data
confidentially without any disorder and error. The system is very simple in design and to
implement. The system requires very low system resources and the system work in almost all
configurations. It has got following features

 Ensure data accuracy.

 Minimize manual data entry.
 Minimum time needed for the various processing
 Better Service
 Minimum time required etc.
Diagrammatically the work flow of proposed system are like this:

12
 Figure 2. 2 Proposed system diagram

2.4 Requirement Analysis

The method of requirement gathering we perform this project were observation, interview and
questioner. Since the organization or the bus station is not comfortable to undertake other
requirement gathering methods. We have undergone the above three only. An interview was
performed using semi structured question two official in the office. The two officials are select
based on stratified sampling because of we use this type of sampling was good and better than of
random sampling and the selection was based on education level. It was aimed to get detail
information about the functioning of the existing system and general background information
about the bus station.

13
Observation was also undergone to know the overall functioning of the existing system. This
data gathering method was best for other because easy understand how the existing system
works. We understand more than of interviewing and questioning method.

The other data gathering method was questioners. During this data gathering method was select
some distributer employees and other official based on stratified sampling method. Because we
used this selection method was based on education level. The questionnaires was prepared based
on official and distributer language, then the official and distributer are easily understand the
questionnaires and give correct information about the bus station. This data gathering method
was semi structured. Because to get more information about the bus station the official and
distributer must understand the question and to give correct information.

2.4.1 Functional Requirement

Functional requirements are statement of capability that the system must generate to addressing
the business needs that the system must satisfies. Functional requirements define what a system
is supposed to do. Our system is initiated to perform the following functional requirements:

 User Account Management I.e. create, Activate, deactivate and edit of user accounts.
 Login and logout into the system.
 Searching information some system users can search different information if it is
necessary.
 Registering new buses and Associations (Mahiberat)
 Can View different information and requests.
 Upload available bus and its information’s.
 Accepting and approving of the membership request.
 Send request and formed members.
 Prepare schedule and update it
 Approve request
We specify our system functional requirements based on the following requirements.

Level of functional requirements: - this is FREQ. n when n is 1, 2, 3….

Requirement:-general statement of the system requirement

14
Description:-brief description about the requirement.

Category:-types of actors that use this requirement functionality.

Priority: - Values of the requirement, it may be high, medium or low.

Based on this measurement we describe in detail our Web Based Transport Management
System functional requirements as follow.

FREQ 1.
Requirements: the system shall to allow the system administrator can handle or manage
all system users’ account.
Description: This task is done and manipulated by the system administrator. Therefore,
the system administrator can create user account, deactivate user account, update user
account information and change the privileges of the users. Account update is not only
manipulated by system administrator but also other system users can manipulate except
passenger.
Category: System Administrator.
Priority: high

FREQ 2.
Requirements: the system shall to support all system uses to login and logout to the
system except to passenger.
Description: when the system users need to use this system must login to the system.
Login to the system user name and password is required. After login to perform its task
and logout to the system.
Category: all system users except to passenger.
Priority: high

FREQ 3
Requirements: the system shall to support some system user to search different
information.
Description: different system users can search different information if it is necessary
such as system Administrator can search during deactivate, updating user account and

15
 access different information. And the distributer employee manager also search different
information during to view association information.
Category: System Administrator, Distributer Employee manager, passenger.
Priority: medium

FREQ4.
Requirements: the system shall the registered different information such as new buses
and Associations (Mahiberat):
Description: when new buses and Associations enter to the bus station as a member, the
system should allow users record all information regarding these buses and Associations
(Mahiberat). This is helpful for data manipulation and management.
Category: for bus information Distributer Employee Manager and for Association
Development Process Manager.
Priority: high

FREQ 5
Requirements: the system shall to some system users can view same necessary
information.
Description: the system users can view detail of different information such as bus
information, association information, prepared schedule, available bus and other
information are viewed by different system users based on their function.
Category: all system users see different information
Priority: high

FREQ 6
Requirements: the system shall to upload some available bus and its information.
Description: the distributer employee manager upload different available bus with their
tariff and other information.
Category: Distributer Employee Manager
Priority: high

FREQ 7

16
 Requirements: the system shall to support the association manager to accept and
development process manager to accept and approve request.
Description: this task is done and manipulated by the association manager and
development process manager. The association manage accepts the membership request
of operator and send to development process manager and the development process
manager is approve the membership request.
Category: Association Manager to accept and Development process manager to accept
and approve.
Priority: high

FQRE 8
Requirements: the system shall to support the operator to send request and the
association manager formed their members.
Description: this task is also done and performed by the operator and association
manager. The operator send membership request to the association manager then the
association manager view and formed members.
Category: Operator to send request and Association Manager.
Priority: high

FREQ 9
Requirements: the system shall to support the distributer Employee manager to prepare
schedule and update it.
Description: the Distributer Employee manager can prepare the bus schedule and update
it if it necessary
Category: Distributer Employee manager
Priority: high

17
 2.4.2 Business Rule

Business rule is statement that expresses some aspects of the business. It is intended to assert
business structure or to control the behavior of the business. It describes the operations,
definitions and constraints that apply to an organization in achieving its goal.

Bahir Dar Bus Station has the following business rules for each component of the bus station.
These are:

For operator: one operator comes to member of association he/she must have:

BR1: he/she have an operator license with their level

BR2: he/she must third party insurance member

BR3: the operator must have business license.

BR4: must have liebry

BR5: after this can ask membership request for association.

For Association: to formed once association:

BR1: must have their own human power.

BR2: must have their own structure

BR3: for level one number of member is greater than 20, for level two greater than 30,and for
level three greater than 40.

BR4: after this to ask the development process then the development process can view and
approve.

BR5: final register associations.

BR6: then this registered association can view distributer employee.

18
BR7: distributer employee see the availability and then register the bus information

BR8: assign to available space.

2.4.3 System Use case

A use case diagram describes how a system interacts with outside actors. It is a graphical
representation of the interaction among the elements and system. Use case identifies the
functionality of a system.

The use case diagram models the user’s expectation for using the system. The people and
systems that interact with the system are called the actors. The features of the system that the
actors use are called the use cases.
 Use cases. A use case describes a sequence of actions that provide something of measurable
value to an actor and is drawn as a horizontal ellipse.
 Actors. An actor is a person, organization, or external system that plays a role in one or more
interactions with your system. Actors are drawn as stick figures.

There are 26 use cases in this System:

Use case 1: Security login

Use case 2: Update Account

Use case 3: Create Account

Use case 4: Deactivate Account

Use case 5: Activate Account

Use case 6: View Report

Use case 7: Search Information

Use case 8: Formed members

Use case 9: Accept membership Request

19
Use case 10: Approve Request

Use Case 11: Register Association

Use Case 12: Remark Association

Use Case 13: Prepare Schedule

Use Case 14: Update schedule

Use Case 15: Upload Available bus

Use Case 16: Register Bus information

Use Case 17: View Registered Association

Use Case 18: Generate Report

Use Case 19: Send Request

Use Case 20: View Association information

Use Case 21: Search Bus information

Use case 22: View registered bus information

Use case 23: View Schedule

Use case 24: Search

Use case 25: View Available bus

Use case 26: Logout

Identified actors that participating in the system are:-

 Administrator
 Distributer Employee Manager
 Dev’t process manager
 Operator

20
  Association manager
 Passenger

Table 2. 1 actor description

Actors Description

System Administrator An employee he Manages user account.

Development process manager An employee in the office who approve association request.

Operator A person who have a bus or owner

Distributer employee manager An employee who performs different activity in the bus
station such as prepare schedule, upload available bus with
its information.

Association manager An employee who formed associations.

Passenger A person who travel from one place to other place.

21
 2.4.3.1 Use Case Diagram

Figure 2. 3 Use case diagram

2.4.3.2 Use case Descriptions

Below are the lists of the use cases that are identified for Bahir dar bus station transport
management System. The system use case description contains:

 Use case name

 Use case identification number
 Actor

22
  Extends
 includes
 Description
 Pre-condition
 Post condition
 Basic course of action
 Alternative course of action

Table 2. 2 Login use case description

Use case Name Login

Use case ID: UC 01

Description: Login used to authenticate and validate system user so that

only validate user can have access to the system.

23
Actor: All user of the system except passenger.

Pre-condition: All users must have an account.

Post condition : Users login to the user’s page

Extends: Logout
Includes:

Basic course of action: 1. User request to login into the system.

2. The system display user interface to login.
3. Users enter user name and password via login form and
submit the form.
4. The system check validation of the user name and password.
5. Users login to the system.
6. Use case end.
Alternative course of Actions: inserted user name and password not valid:
A.1 a system verifies user name/password is not valid.
A.2 The system continue at step 3 of above basic course of
action.

Table 2. 3 use case description of account deactivate

Use case Name Account deactivate

Use case ID: UC 02
Actor: Administrator
Description: The system Administrator can deactivate for users accounts.
Pre-condition The administrator must login to the system.
Post condition: The administrator will be deactivate user account.

24
Extends: UC 05
Includes: UC 01
Basic course of action: 1. The Administrator login to the system.
2. The administrator request to deactivate user account.
3. The system display user interface to deactivate the user
account.
4. The administrator search the user id or name of the employee.
5. The administrator click on deactivate button.
6. The system ask the actor weather he/she sure want to
deactivate.
7. The administrator click the button that shows sureness.
8. The system display that the user account is successfully
deactivate.
9. Use case end.
Alternative course of A. If invalid data entry.
action: A1. The system display the error massage to user.
A2. The system prompt administrator go to step 4 the basic
course of action.

Table 2. 4 Use case description of Account Update

Use case Name : Update account

Use case ID: UC 03
Actor: All system users except passenger.
Description: All system users can update/edit their account except passenger.
Pre-condition: Login to the system.
Post condition: The users update their own account.
Extends: UC 05
Include: UC 01

25
Basic course of action: 1. The user login to the system.
2. User click on update account button.
3. The system display update account form.
4. The users enter all required information for updating
information.
5. The user submit information.
6. The system check the entered information validates.
7. The information is valid then the system autonticate from
database.
8. Authentication is true the system display the account
update successfully.
9. Use case end.
Alternative course of Action: If there is a mistake in the input.
A.1 the system display error message and allow making
correction.
A2. The user go to step 4 for basic course action.
A3. There is no account before.

Table 2. 5 case description of Account Create

Use case Name Account create

Use case ID: UC 04

Description: The system administrator create the user account.

Actor: System Administrator.

Pre-condition: Must login to the system.

Post condition : Create user account.

26
Extends: ________________________________

Includes: UC 01.

Basic course of action: 1. The administrator login to the system.

2. The administrator click on the create account button.
3. The system display create account form.
4. The administrator enter all required information to
create account.
5. The administrator submit the information.
6. The system check validate of the information.
7. The system display message account created
successfully.
8. Use case end.
Alternative course of Actions: If there is a mistake in the input.
A.1 the system display error message and allow making
correction.
A.2 the system admin go to step for and try again.

Table 2. 6 Use case description of Search

Use case Name Search

Use case ID: UC 05

Actor: System Administrator , Distributer Employee Manager and

passenger
Description: System administrators, Passenger and distributer Employee
manager can search different information if it is necessary.
Pre-condition: Users must login to the system.

Post condition : See different information by searching.

27
Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The actor login to the system.

2. The actor click search button.
3. The system display search form and information.
4. The actor enters key identifier of the entity to be
searched.
5. The system performs the intended task.
6. Use case end.
Alternative course of Actions: A. If the searching data was not found.
A1.The system display message the data does not exist.
A2. System actor reenter the data by going to step 3 of the
basic course of action.

Table 2. 7 Use case description of View report

Use case Name View Report

Use case ID: UC 06

Description: The development process manager view generated report.

Actor: Development process manager.

Pre-condition: Must login to the system.

Post condition : View the report.

Extends: ________________________________

Includes: UC 01.

28
Basic course of action: 1. The development process manager login to the system.
2. The manager click on the view report button.
3. The system display report.
4. The manager see all required information.
5. The system passive viewed report.
6. Use case end.
Alternative course of Actions: If the system is display the report.
A1. The manager going to again step 2 in main course of
action.

Table 2. 8 Use case description of Formed members

Use case Name Formed members

Use case ID: UC 07

Actor: Association manager.

Description: Association manager can formed association.

Pre-condition: Login to the system

Post condition : Formed association.

Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The Association manager login to the system.

29
 2. The manager click formed member link.
3. The system display formed member form.
4. The association manager enter necessary information.
5. The system performs the intended task.
6. The system display message association is formed
7. Use case end.
Alternative course of Actions: A. If the association not formed.
A1.The system display error message.
A2. Association manager reenter the data by going to step
3 of the basic course of action.

Table 2. 9 Use case description of Request information

Use case Name Request information

Use case ID: UC 08

Actor: Association manager.

Description: Association manager can send request/ formed association

information to development process manager.
Pre-condition: Association manager must login to the system.

Post condition : Send request to development process manager.

Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The association manager login to the system.

2. The association click request button.

30
 3. The system display request form and information.
4. The association manager send request.
5. The system performs the intended task.
6. The system display the message the data send.
7. Use case end.
Alternative course of Actions: A. If the request is not send
A1. The system display error message.
A2. The association manager rework.

Table 2. 10 Use case description of accept membership request

Use case Name Accept membership request

Use case ID: UC 09

Actor: Association manager.

Description: Association manager accepts every operator request.

Pre-condition: The association manager must login to the system.

Post condition : Accepting operator request.

Extends: UC 21

Includes: UC 01

Basic course of action: 1. The association manager login to the system.

2. The association manager click accept membership

31
 request button.
3. The system display accept membership request form
and information.
4. See and accept the operator request.
5. The system performs the intended task.
6. Send message to operator request accepted.
7. Use case end.
Alternative course of Actions: If request is not accepted
A1. The system display error message.
A2. The association manager rework the above process.

Table 2. 11 use case description of Approve request

Use case Name Approve request

Use case ID: UC 10

Actor: Development process manager.

Description: Development process manager can approve request.

Pre-condition: Development process manager must login to the system.

Post condition : Approve association membership request.

Extends: UC 21

Includes: UC 01

Basic course of action: 1. The development process manager login to the system.
2. Then click the approve request.
3. The system display request information from

32
 association manager.
4. The development process manager click to approve
request button.
5. The system performs the intended task.
6. The system display successful message to approve
request.
7. Use case end.
Alternative course of Actions: A. If is not approve request.
A1. The system display error message
A2. The development process manager reapprove the
request.

Table 2. 12 Use case description of register association

Use case Name Register association

Use case ID: UC 11

Actor: Development process manager.

Description: Development process manager can register association.

Pre-condition: Login to the system.

Post condition : Register association.

Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The development process manager login to the user’s
page.
2. The development process manager click registered
link.

33
 3. The system display register form and information.
4. The manager enter the necessary information.
5. The system authenticate the entered data.
6. Click on submit button.
7. The system display message the data successfully
registered.
8. Use case end.
Alternative course of Actions: If the information is not register
A1. The system display error message data is not registered.
A2. The manager rework/re register.

Table 2. 13 Use case description of prepare schedule

Use case Name Prepare schedule

Use case ID: UC 12

Actor: Distributer employee manager

Description: Distributer employee manager can prepare schedule.

Pre-condition: The distributer employee must login to the system.

Post condition : To prepare schedule.

Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The distributer employee manager must login to the
system.
2. The click schedule button
3. The system display schedule form
4. The manager enter necessary information.

34
 5. System autonticate the entered information.
6. Use case end.
Alternative course of Actions: If the entered information is invalid.
A1. The system display error message.
A2. The distributer employee manager prepare again.

Table 2. 14 Use case description of update schedule

Use case Name Update schedule

Use case ID: UC 13

Actor: Distributer employee manager

Description: Distributer employee manager can update schedule.

Pre-condition: The distributer employee manager must login to the system.

Must have prepared /old schedule
Post condition : To update schedule.

Extends: UC 05

Includes: UC 01

Basic course of action: 1. The distributer employee manager must login to the
system.
2. The click schedule update button
3. The system display update form
4. The manager can enter key identification of the entity

35
 want to update can search.
5. The manager enter necessary information.
6. System autonticate the entered information.
7. The system display success message.
8. Use case end.
Alternative course of Actions: If the entered information is invalid.
A1. The system display error message the entered
information is not valid.
A2. The distributer employee manager re update again.

Table 2. 15 Use case description of upload available bus

Use case Name Upload available bus

Use case ID: UC 14

Actor: Distributer employee manager

Description: Distributer employee manager upload available bus on the web

site.
Pre-condition: The distributer employee manager must login to the system.

Post condition : Upload available bus.

Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The distributer employee manager must login to the
system.
2. The click upload button
3. The system display upload form
4. The manager can select available bus and type their
necessary information.

36
 5. Click to upload.
6. The system display success message.
7. Use case end.
Alternative course of Actions: If the entered information is upload.
A1. The system display error message the entered
information is not upload.
A2. The distributer employee manager re upload again.

Table 2. 16 Use case description of registered bus information

Use case Name Registered bus information

Use case ID: UC 15

Actor: Distributer employee Manager

Description: Distributer employee Manager registered bus information.

Pre-condition: The distributer employee Manager must login to the system.

Post condition : The distributer employee manager registered bus information.

Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The distributer employee manager must login to the
system.
2. The click registered link.
3. The system display registered form
4. The employee manager fill the form/enter the required
information.
5. The system verify the inserted information.

37
 6. The system display success message.
7. Use case end.
Alternative course of Actions: If the entered information is invalid.
A1. The system display error message the entered
information is not valid.
A2. The distributer employee manager go to step 4 of the
main course of action and try again.

Table 2. 17 Use case description of view registered association

Use case Name View Registered Association

Use case ID: UC 16

Actor: Distributer employee manager

Description: Distributer employee manager view registered association.

Pre-condition: The distributer employee manager must login to the system.

Post condition : View registered association.

Extends: UC 05

Includes: UC 01

Basic course of action: 1. The distributer employee manager must login to the
system.
2. The click view button
3. The system display information
4. Use case end.
Alternative course of Actions: If the system is not display information.
A1. The distributer employee manager going to step 2 and
try again.

38
 Table 2. 18 Use case description of generate report

Use case Name Send report

Use case ID: UC 17

Actor: Distributer employee manager

Description: Distributer employee manager generate information and send

to development process manager.
Pre-condition: The distributer employee manager must login to the system.

Post condition : Generate and send report.

Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The distributer employee manager must login to the
system.
2. The click generate button
3. The system generate report.
4. Send the report to the development process manager.
5. Use case end.
Alternative course of Actions: If the system is no generate.
A1. The system display error message.

39
 A2. The distributer employee manager going to step 2 on
the main course of action and try again.

Table 2. 19 Use case description of send request

Use case Name Send request

Use case ID: UC 18

Actor: Operator

Description: Operator send membership request to association manager.

Pre-condition: The operator must login to the system

Post condition : Send request.

Extends: ________________________________

Includes: UC 01

Basic course of action: 1. The operator login to the system.

2. Click on the send request button.
3. The system display the request form.
4. The operator insert information.
5. Click on send button.
6. The system verifies the inserted information.
7. System display message the request is send.
8. Use case end.
Alternative course of Actions: If the entered information is invalid.
A1. The system display error message the entered
information is not valid.
A2. The operator going to step 4 on the main course of

40
 action and try again.

Table 2. 20 Use case description of view

Use case Name View

Use case ID: UC 19

Actor: Operator

Description: Operator views prepared schedule, updated schedule,

registered bus information and association information.
Pre-condition: The operator must login to the system

Post condition : Vies different information.

Extends: UC 12, UC 13, UC 15.

Includes: UC 01

Basic course of action: 1. The operator login to the system.

2. Click on the view button.
3. Select buttons want to view.
4. The system display the information.
5. Use case end.
Alternative course of Actions: If the system is not display information.
A1. The operator going to step 3 on the main course of
action and try again.

41
 Table 2. 21 Use case description of view available bus

Use case Name View available bus

Use case ID: UC 20

Actor: Passenger

Description: The passenger vies the available bus.

Pre-condition:

Post condition : Vies available bus.

Extends: ___________________

Includes: UC 05

Basic course of action: 1. Visit the system web site.

2. The passenger select city or town.
3. The passenger select the bus level.
4. The passenger click on search button.
5. The system display the available bus types with
information.
6. Use case end.
Alternative course of Actions: If the system is not display available bus,
A1. The passenger going to step 2 on the basic course of
action and try again.

42
 Table 2. 22 Use case description of view request

Use case Name View request

Use case ID: UC 21

Actor: Association manager & Dev’t process manager

Description: The association manager views the operator request to add

association. The development process manager also see the
membership request and approve.
Pre-condition: The operator must login to the system

Post condition : Vies different request information.

Extends: ______________________________

Includes: UC 01

Basic course of action: 1. The Development process and association manager login
to the system.
2. Click on the view request button.
3. The system display the information.
4. Use case end.
Alternative course of Actions: If the system is not display information.
A1. The operator going to step 2 on the main course of
action and try again.

43
 Table 2. 23 use case description of search bus information

Use case Name Search bus information

Use case ID: UC 22
Actor: Passenger
Description: The passenger can search available bus information

Pre-condition: ____________________________

Post condition : Vies different bus information.

Extends: ______________________________

Includes: ______________________________

Basic course of action: 1. The passenger browse the website

2. Click search button
3. enter the city name
4. system display the available bus with their information
5. Use case end.
Alternative course of Actions: If the system is not display information.
A1. The passenger going to step 3 on the main course of
action and try again.

44
 2.4.4 User Interface prototype

User interface Prototype diagram shows the flow or sequence of user interface when the
users of the system interact with the system. User interface prototype diagram also show
which the users that interact with its interface.

Figure 2. 4 User Interface Prototype

45
 2.4.5 Activity Diagram

An activity diagram is used to model a large activity's sequential work flow by focusing on
action sequences and respective action initiating conditions. An activity diagram is represented
by shapes that are connected by arrows. Arrows run from activity start to completion and
represent the sequential order of performed activities. Black circles represent an initial workflow
state. A circled black circle indicates an end state. Rounded rectangles represent performed
actions, which are described by text inside each rectangle.

A diamond shape is used to represent a decision, which is a key activity diagram concept. Upon
activity completion, a transition (or set of sequential activities) must be selected from a set of
alternative transitions for all use cases

Synchronization bars indicating the start or completion of concurrent activities are used to
represent parallel sub flows.

46
 Figure 2. 5 security login activity diagram

47
 Figure 2. 6 activity diagram of create account

48
Figure 2.6 update account activity

49
Figure 2. 7 activity diagram of bus information registration

50
 Figure 2. 8 passenger search for available bus

51
 Figure 2. 9 Prepare schedule activity diagram

52
 Figure 2. 10 Account deactivate activity diagram

53
 Figure 2. 11 Upload Available bus Activity diagram

54
 Figure 2. 12 Send Request Activity Diagram

55
 Figure 2. 13 Approve Request Activity diagram

2.4. 6 Sequence Diagram

Sequence diagram is one kind of interaction diagrams, which shows an interaction among a set
of objects and their relationships. The purpose of the Sequence diagram is to document the
sequence of messages among objects in a time based view. The scope of a typical sequence
diagram includes all the message interactions for a single use case.

56
 Figure 2. 14 Login sequence diagram

57
 Figure 2. 15 Create Account sequence diagram

58
 Figure 2. 16 update Account sequence diagram

59
 Figure 2. 17 Association Register sequence diagram

Figure 2. 18 logout sequence diagram

60
 Figure 2. 19 Upload Activity diagram

61
 Figure 2. 20 view Available bus Sequence diagram

62
 Figure 2. 21 Send Request Sequence diagram

2.5 Non-functional requirement

These are the requirements that are not directly related with system but still are important as
equal as functional requirements to the system. They describe user visible aspects of the system
that are not designed to the functional behavior of the system. The following are some of the
non-functional requirements for our system. These are:

 Security issues: Any of system users shall never login to another system user. This secured
for each system interface from accessing authorized users through authorized the database
table only for those user who have a special privileges.

63
 NB: we use authentication/access limit for providing security for the system.

 Quality issue: The system reliable and accurate in providing information to the users. Since
our system should include functional and non-functional requirements and then it deals with
quality.
 Accuracy: The level of accuracy in the proposed system better due to reduction of error. The
system should give correct output for the users when they want to get services.
 Error handling: When the user makes some mistakes the system responds that error is
occurred using easily understandable messages and allows the user to recover from the error.
In developing our project we use different event and error handling techniques provided by
java script and php to validating data, and hence errors handled and only accepted correct
data.
 Simplicity: The system should be easy to use and also simple to manipulate. This could be
made possible through use of different user- friendly interfaces. Our System is being
developed in php.
 Performance: as much as possible, the system give response to the users in duration of 20
minute without delaying much time.
 Availability: the system has been available at any time for users regarding to the presence of
electric power and intranet. By using redendent server to protect the down time of the system
 Resource: consumes less resource like time, power needed to perform the task.
 Accessibility: the system is accessible to Internet enabled devices.
 User friendly interface: the user interface have attractive color selection,user can easily
input and retrieve their profile and their data.
 Maintainablity:the system is easy to modify and to add functionality without affecting the
general frame work of the system.
 Operating system: the system can be deployed in Windows OS or Linux OS.
 Usability: In this case our system possesses the following regarding to usability:
 Easier to learn: operation can be learned by observation.so it is more
satisfying to use.

64
 2.6 System Requirement

2.6.1 Hardware Requirement

 Computer with specification of Intel(R) core(TM) i5-2120 CPU 3.30GHZ. Used to write our
proposal, documentation, develop web based transport management system in Bahir dar bus
station and used for doing of other things.
 Installed Physical Memory (RAM) 4.00 GB
 Smartphone for data recording during data collection
 8GB Flash, Memory. Used to backup data storage.
 Paper used to prepare quaionary and printing project documents.
 3 Pens used for data gathering, and Darrow use case and other diagrams on paper (blue
print).
2.6.2 Software Requirements

 MS Office 2010 for word processing: to write the project documentations, quaionary.
 MS power point 2010:- to prepare presentation.
 Snapping tool:- used to snapping different project figures
 Adobe Photoshop cs5:- used to design, write and decor different images.

65
 CHAPTER THREE

3. SYSTEM DESIGN

3.1 Introduction

System design is the transformation of the analysis model into a system design model. System
design is the first part to get into the solution domain in a software development. This chapter
provides the design part of the project is discussed. The system design is the building block of
the system. It also transforms the analysis model into system design model. The result of the
system design is the model that includes the clear description of software Architecture,
Deployment diagram, and system persistent diagram. Generally the purpose of this design
phases is to determine how to build the system and the information needed to device the actual
implementation of the project.

3.2. Architectural Design

In this project the team uses a three-tier architecture which has three layers. These three layers
are the Application or Presentation layer, the business layer and the data access layer.
Application or presentation layer is the form which provides the user interface to either
programmer or end user. The business layer is the class which the team uses to write the function
which works as a mediator to transfer data from application layer or presentation layer to data
layer. This layer also has a property layer which is a class where variables are declared
corresponding to the fields of the database which can be required for the application and make
the properties so that the team can get or set the data using these properties into the variables.
The third tire is the data access layer which is also a class to get or set data to the database
queries back and forth. This layer only interacts with the database. The database queries or stored
procedures written here to access the data from the database or to perform any operation to the
database.
3.2.1. Component Modeling

By this Diagram, components of the system wired showing that there is relation among
components; management of the system, owners, database and operations performed on
databases such security issue.

66
 Figure 3. 1 component diagram

3.2.2. Deployment Diagram

The Deployment Diagram also helps to model the physical aspect of an Object-Oriented
software system. It models the run-time configuration in a static view and visualizes the
distribution of components in an application. In most cases, it involves modeling the hardware
configurations together with the software components that lived on. The Deployment Diagram
also helps to model the physical aspect of an Object-Oriented software system. It models the run-
time configuration in a static view and visualizes the distribution of components in an
application. In most cases, it involves modeling the hardware configurations together with the
software components that lived on. Deployment diagram of our system shown blow.

67
 Figure 3. 2 deployment diagram

3.3 Design Class Model

Design class modeling is used to model the static structure of how the software is built. In
particular, class modeling shows classes, their internal structure, and their relationships. And also
shows a collection of (static) declarative model elements, such as classes, interfaces, and their
relationships, connected as a graph to each other and to their contents. It provide a graphical
notation for modeling classes and their relationship. They are concise, easy to understand, and
work well in practice. Class diagrams are the backbone of almost every object-oriented method
including UML.

68
 Table 3. 1 class description

Class Name Attribute Data Method Return Role Multiplicity

Type
System Id Int 1…M with
Administrator Manages Account
Association Id Int Update 1…1 with account
Manager Accept 1….M with
Formed Request
1…M Association
Dev’t Process Id Int Update 1…1 with account
Manager Register 1…M with
Association
Approve 1…M with
Request
View 1…M with Report
Distributer Id Int Update 1…1 with Account
Employee 1…M with
Manager View Association
Generate 1…M with Report
1…M with Bus
Register/upload Info
1…M with
schedule
Prepare
Operator Id Int Update 1…1 with account
M…M with
View Association
1…M with
Schedule
M…M with bus
information
1…1 with request
Send
Employee Fname String Login Void
Sname String Logout Void
Lname String
Sex Char
Phone No Double
Department String
Status String
Kebele String
dateofborth data
Account User Name String Activate Void
Password string Deactivate Void
Create Void
Update Void

69
Report Id Int Generate Void
Prepared date Date View Void
Not String
Reported by String
request Id Int View Void
Requested Data Accept Void
date String Request Void
Bus level String Approve Void
Note String Send Void
Reported by
passenger Name String View M…M with bus
Address String information
Sex String
Association Id Int -Register
Name String association
Formed Date Date -Request Void
No members Int info
Bus level String View
No set Int association

schedule Id Int Prepare

Work place string Update
Prepared date Data View void
Driver Name String
Assistance String
Name
Owner name String
Bus info side No Int Upload Void
board No Int Register Void
level String View Void
schedule String
Driver Name String
Assistance String
Name Int
No sets

70
 Figure 3. 3 Class diagram

71
 3.3.2 Persistent Modeling

Persistence models are used to design the schema of your database. You typically need to draw a
Persistence model whenever you are using a relational database to store your objects in. The
strength of Persistence models is that data entities are conceptually the same as the tables of a
relational database and that attributes are the same as table columns.

Figure 3. 4 Persistent Diagram

72
 3.4 User Interface

The design of user interfaces for this system for the purpose of designing how the interface
seems like with the focus on maximizing the user experience. The goal of user interface design is
to make the user's interaction as simple and efficient as possible, in terms of accomplishing user
goals what is often called user centered design.

Figure 3. 5 Homepage user interface

73
 Figure 3. 6 Login User Interface

74
 Figure 3. 7 Association Registration user interface

75
 3.5 Logic Model

---------For Login……………..

Login ()

Insert username and password on the login form

Check the matching username and password

If (match)

Display “the Perspective user page”

Else

Display “error message, and try again”;

----------------For Deactivating Account----------------------

Deactivate _Account ()

Login ()

Insert User Id on search form

Check for filled correctly

If (Correct)

Check for user existence

If (Exist)

Display User Information

Then deactivate user

76
 }

Display “Not found, try again”

-----------------------------For View Request-----------------------------

View _Request ()

Login ()

Check for the presence of request

If (exist)

Display “list of requests”

Else

Display “No request have been sent”

---------------------For _ giving Approval-----------------------------

Approve ()

Login ()

If (View_Request! =Null)

Then manager give approval for the request

Else

Nothing is done

77
 -----------------For Registering Bus info----------------------------

Reg_Bus ()

Insert Bus Id, level, Owner, Work place, Address, Number of set coordinates on Bus
Registration Form

Check if the form filled correctly

If (correct)

Display “Successfully Registered”

Else

Display “Error message, try again”

Check for Existence of Bus

If (Exist)

Display “The Bus Info Is already exist in the system”

78
 4. References

[1] Object-Oriented Software Engineering using UML, Patterns, and Java Third Edition by
Bernd Bruegge and Allen H. Dutoit.

[2]Http:// www.historical development of transport|ethiopian economy:

[3] Background and biography of Bahir dar city, www.google.com November 3, 2017

[4], Faculty of computing (2009), industrial project template, Bahir dar. Bahir Dar University

[5], group 2(2009), fundamentals of software engineering group assignment proposal, Bahir

Dar. Bahir Dar University

[6] http://www.w3school.com

79
 5. Appendices
We are final year students of the faculty of Computing in Bahir Dar University. We are
doing/developing industrial project on the transport management of Bahir Dar Bus Station to
automate it into a computerized system. Therefore, we need your positive attitude towards giving
us the general working of the bus station for not more than 30 minutes.

Interview Questions

1. What are the basic tasks that are performed in the bus station?
2. What are the different actors present in the bus station?
3. How do you arrange buses in the bus station?
4. How do you adjust turns/ assign schedules for the vehicles?
5. How often do you adjust the schedule of a vehicle for a month?
6. Can you tell us something about tariff formulation and assignment?
7. Is there any means that you are following to announce information to passengers?
8. Is there any computerized system developed for the bus station before?
9. Do you think the computerized system will be helpful for you?
10. Is there anything you think is better to be included in the project?
11. Finally, if you have something you want to say us?

Questioner

80
81
82