BAHIR DAR UNIVERSITY, BAHIR DAR INSTITUTE OF

TECHNOLOGY
FACULITY OF COMPUTING

Software Requirements Specification

For
TRANSPORT AND VEHICLE TRACKING AND MANAGEMENT
SYSTEM
FOR BAHIR DAR INSTITUTE OF TECHNOLOGY

Version 1.8
Prepared by
Group Members I|DNO
---- ----
---- ----
---- ----

Submitted to: ………..

Date: - ……
 Revision History
Date Version Description Authors Major Changes

I
Table of Contents
1. Introduction ..............................................................................................................................1
1.1 Purpose.............................................................................................................................1
1.2 Document Conventions ....................................................................................................1
1.3 Intended Audience and Reading Suggestions ..................................................................1
1.4 Project Scope ...................................................................................................................2
1.5 Definitions, Acronyms, & Abbreviation ..........................................................................2
1.5.1 Definitions....................................................................................................................2
1.5.2 Acronyms and Abbreviations ......................................................................................2
1.6 Overview of the Document ..............................................................................................3
1.7 References ........................................................................................................................3
2. Overall Description ..................................................................................................................4
2.1 Assumptions and Dependencies ......................................................................................8
2.2 Product Perspective ..........................................................................................................4
2.3 Product Features/Functions ..............................................................................................5
2.4 User Classes and Characteristics .....................................................................................6
2.5 General Constraints ..........................................................................................................7
2.6 User Documentation ........................................................................................................7
3. Specific Requirements .............................................................................................................9
3.1 User Requirements ...........................................................................................................9
3.2 System Requirements.....................................................................................................18
3.2.1 Use Case-Diagram .....................................................................................................18
4. External Interface Requirements .........................................................................................32
4.1 User Interfaces ...............................................................................................................32
4.2 Hardware Interfaces .......................................................................................................34
4.3 Communications Interfaces ...........................................................................................34
5. Analysis Models......................................................................................................................35
5.1 Sequence Diagrams ........................................................................................................35
5.2 Activity Diagrams ..........................................................................................................38
6. Appendix .................................................................................................................................43

List of Table

II
Table 1 Definitions of Terms ......................................................................................................... 2
Table 2: acronyms or abbreviation ................................................................................................. 2
Table 3: transport administrator functional requirements .............................................................. 9
Table 4: Managing director functional requirements................................................................... 12
Table 5: driver functional requirement ......................................................................................... 13
Table 6: Costumer functional requirements .................................................................................. 14
Table 7: Auto-mechanical functional requirements ...................................................................... 15
Table 8: Academic director functional requirements.................................................................... 16
Table 9: non-functional requirements ........................................................................................... 17
Table 10 : Actor description ......................................................................................................... 20
Table 11: login use case description ............................................................................................. 20
Table 12 register new vehicle use case description ...................................................................... 21
Table 13: register new vehicle case description .......................................................................... 21
Table 14: Inactive driver information use case description .......................................................... 22
Table 15: prepare Schedule use case description .......................................................................... 23
Table 16: Create account use case description ............................................................................. 24
Table 17: Generate report use case description ............................................................................ 24
Table 18: Inactive vehicles use case description .......................................................................... 25
Table 19: Update schedule use case description ........................................................................... 26
Table 20: Delete schedule use case description ............................................................................ 27
Table 21: Register site use case description ................................................................................. 28
Table 22: Send Request use case description ............................................................................... 29
Table 23: View schedule use case description ............................................................................. 30
Table 24: Logout use case description ......................................................................................... 31

III
 List of Figure
Figure 1: Overview of The existing System .................................................................................. 4
Figure 2: Overview of proposed system ......................................................................................... 5
Figure 3: Use case diagram ........................................................................................................... 19
Figure 4: Home page user interface ............................................................................................. 32
Figure 5: Create account user interface ........................................................................................ 33
Figure 6: Update deriver information user interface..................................................................... 34
Figure 7: Login sequence diagram ................................................................................................ 35
Figure 8: Create account sequence diagram ................................................................................. 36
Figure 9: inactive driver information sequence diagram .............................................................. 37
Figure 10: login activity diagram .................................................................................................. 38
Figure 11: Prepare Schedule activity diagram .............................................................................. 39
Figure 12: View Schedule activity diagram.................................................................................. 40
Figure 13: Create account activity diagram .................................................................................. 41
Figure 14: Inactive deriver information activity diagram ............................................................. 42

IV
1. Introduction
The purpose of this section is to provide general background information to readers about the
Transport and Vehicle Tracking Management System for BiT Transport and Vehicle Tracking
Department.

1.1 Purpose
The purpose of this document is to present the Software Requirement Specification of
Transport and Vehicle Tracking Management System for Bahir Dar institute of Technology
Version 1.0. Transport and Vehicle Tracking Management System is an automated application that
allows registering vehicles with deriver, assign vehicles for each service automatically, prepared
schedule, generate reports and identifying the current location and status of vehicles.

This SRS describes the functions and performance requirements of Transport and Vehicle
Tracking Management System. It will explain the purpose and features of the system, the interfaces
of the system, what the system will do, the constraints under which it must operate and how the
system will react to external stimuli. This document is intended to approve for both the
stakeholders and the developers of the system and will be proposed to the Bahir Dar Institute of
Technology Requirement Specification of Transport and Vehicle Tracking Management
Department.

1.2 Document Conventions

Throughout this document, the following conventions have been used: -

• Font type Times New Roman

• Size 18 for Main Headings
• Size 14 for Sub Headings
• Size 12 for the rest of the document.
• Size 9 and Font type Calibri (Body) for table and picture caption
• Words in Bold are important terms, and have been formatted to grab the attention of the
reader.

1.3 Intended Audience and Reading Suggestions

This document is denoting for all stockholder (developers, users, project managers, testers,
document writer and technician) of the system. The SRS document aims to explain in an easy
manner, the basic idea behind the system and how the developers aim to achieve their goals. It
also aims to introduce to the users the main features of the system.

1
1.4 Project Scope

The scope of this project is developing automated Transport and Vehicle Tracking Management
System for BiT Transport and Vehicle Tracking Management Department. This system helps the
BiT Transport and Vehicle Tracking Management Department to work without any barrier of
bad actions. This system will be designed to maximize the transport services by preparing
automated schedule to assist in automating vehicle scheduling and controlling vehicles.
Specifically, this system is designed to allow BiT transport and vehicle tracking
department to manage the transport service system. The system will facilitate communication
between users, system managers, transport and vehicle tracking manger, and the deriver via web
based interface. The system also contains preformatted request and reply forms are used in every
stage of the vehicle services progress through the system to provide a uniform process.

1.5 Definitions, Acronyms, & Abbreviation

1.5.1 Definitions
Table 1 Definitions of Terms

Keyword Definitions

Bahir Dar University One of the famous higher governmental education institute of Ethiopia which is
find in Bahir Dar city.
Bahir Dar Institute of Bahir Dar university branches which offering higher education in the field
technology of engineering and technology.
Transport and Vehicle Bahir Dar institute of technology case team which organized to transport
Tracing Management management activities established under the law of BDU and, which is managed
Department by Managing Director.

1.5.2 Acronyms and Abbreviations

Table 2: acronyms or abbreviation

Acronym or Definitions
Abbreviation

BDU Bahir Dar University

BiT Bahir Dar Institute of Technology
TVTMD Transport and Vehicle Tracking Management Department
TMS Transport Management system
SRS Software Requirements Specification
REQ Functional Requirement
NFREQ Nonfunctional Requirement
SFR System Functional Requirement
SQL Structural Query Language
JDK Java Development Kit
UML Unifying Modeling Language

2
1.6 Overview of the Document

The next chapter, the overall description section, of this document gives an overview of the
functionality of the product. It describes the informal requirements and is used to establish a
context for the technical requirements specification in the next chapter.
The third chapter, Requirements Specification section, of this document is written primarily
for the developers and describes in technical terms the details of the functionality and
nonfunctional requirement of the system.
The fourth chapter describe the logical characteristics of each interface between the software
product and the users, software and hardware components and connections between this product
and other specific software components (name and version), including databases, operating
systems, tools, libraries, and integrated commercial components.
All sections of the document describe the same software product in its entirety, but are
intended for different audiences and thus use different language.

1.7 References

I. SRS template adopted by Esublaew (Ass. Prof.)

II. IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications. IEEE Computer Society, 1998.

3
2. Overall Description
2.1 Product Perspective

Bahir Dar Institute of Technology (BiT) at Bahir Dar University is the pioneer institute of
technology offering higher education in the field of engineering and technology. BiT TVTMD is
organized in to transport management system established under the law of BiT for managed
transport and vehicle affairs. The BiT TVTMD existing system worked with manual which is
inefficient and time consuming, i.e. scheduling, vehicle request and replay, vehicle tracking and
reporting, all are done manually. And also the application to be developed has no product family
as this system was entirely manual. It will be a standalone system and therefore there will be no
interfacing with any other systems.

Figure 1: Overview of The existing System

The proposed system will be replacing the manual system used by the BiT Transport
Management System (TMS) for Transport and Vehicle Tracking Management Department
(TVTMD).

4
 Figure 2: Overview of proposed system

2.2 Product Features/Functions

The main purpose of the automated TMS is to maximize user utility. The system prioritized
services based on importance of jobs, request’s position and levels of emergency. Thus the job
details submitted by the user will include transport service prioritization criteria: the allocated
transport service and the deadline required by the user, enabling the scheduler to maximize
vehicle utilization.
The system will allocate transport service based on the parameters, which are service
specifications submitted by the user with the vehicle service scheduling, including:
• Type of vehicles
• Level of users positions
• Levels of jobs urgent
• The numbers of sits of vehicles
• According to the distance of destination
The system will control the status of vehicle based on specific parameters, including
• Current location of vehicle
• Whether the vehicle is functional or not
• Models of vehicles is recent or not
• Based on fuel consumption

5
 The system will generate report based on specific parameters, including
• Fuel consumptions
• Status of vehicles and drivers
In general system should embody the following features and functions:
• Should be able to enforce vehicles allocations according to user-centric priorities
• Should be dynamic, and not static
• Should be scalable
• Should provide administrative security
• Should provide at least a basic level of transport vehicle accounting, to aid in
scheduling policies
• Should ideally provide a GUI for all components, such as for users to submit request
and for administrators to oversee scheduling.
• Should generate different types of report based on given parameters

2.3 User Classes and Characteristics

The possible user classes in this system are:

1. Transport administrator
• Frequency of use: The administrator class will have a usage level between the
user and the classes. The only one with access to the system allowing him to alter
data in the database in the case of errors or necessary changes and will also be
capable of using the system’s features.
• Technical Expertise: Knowledge of computer specially in-depth knowledge on
databases and internet
• Privilege Levels: Can use, control and assign privilege to all available functions of
user classes once logged into the system as an administrator.
2. Managing director
• Frequency of use: The managing director class will have a usage level between
the user and the classes. The general tasks of managing director is control the
financial and human resource transactions.
• Technical Expertise: Knowledge of computer specially in-depth knowledge on
databases and internet
• Privilege Levels: Can use, view and generate reports, accept and reject fuel and
maintains requests to all available functions of user classes once logged into the
system as a managing director.

3. Auto-mechanic
• Frequency of use: The auto-mechanic class will have a usage level between the
user and the classes. The general tasks of auto-mechanics are control the vehicle
physical part and fuel consumption.

6
 • Technical Expertise: Knowledge of computer specially in-depth knowledge on
internet
• Privilege Levels: Can use, accept and reject fuel and maintains requests to all
available functions of user classes once logged into the system as an auto-me chic
4. Driver
• Frequency of use: The deriver class will have a usage level between the user and
the classes. The general tasks of drivers are given service according to the
schedules and ask vehicle infrastructure if any.
• Technical Expertise: Knowledge of computer specially in-depth knowledge on
internet
• Privilege Levels: Can use, view schedule, send fuel and maintains requests to all
available functions of user classes once logged into the system as a driver.
5. Academic director
• Frequency of use: The academic director will have a usage level between the
user and the classes. The general tasks of academic director accept or reject user’s
service request.
• Technical Expertise: Knowledge of computer specially in-depth knowledge on
internet
• Privilege Levels: Can use, view schedule, reject or accept users request to all
available functions of user classes once logged into the system as a academic
director.
6. Customers
• Frequency of use: user class is the most common one as it is the one most often
used as during the usage of the system, specially to get services from system will
have to be logged onto the application in order to use the systems features.
• Technical Expertise: should know the basic operation of a computer application.
• Privilege Levels: Can use, view schedule and send service requests only certain
functions once logged into the system as a user for system.

2.4 General Constraints

The current constraints on the system are related to the provision of hardware resources to
indicate the current GPS positions of the vehicle. The network running with Linux server
operating system and a larger number of dedicated workstations would be beneficial. For testing
purposes, a simulating tool needs to be used which may have to be specially designed if a generic
one is not readily and freely available.

2.5 User Documentation

User manuals for administration, configuration and system usage are to be provided in
digital format, which is portable documents and video for each description. In the application

7
itself it would be preferable to have some help guidelines integrated for ease of use. All
documents should be easy to understand according to the documents audience.

2.6 Assumptions and Dependencies

Numbers of factors that may affect the requirements specified in the SRS include:
• The workability of the automation transport management system modules such as those
dealing with process scheduling policies provided by the transport scheduler is
assumed.
• There may be failures of network connection.
• It is assumed that the users of the finished system will provide all the necessary
hardware components and loaded with the necessary software to run application.

8
 3. Specific Requirements
In software development phase requirement specification is mandatory activity.
Requirement specification is an agreement between the end user and the system developer.
Therefore this requirement specification was the agreement made with BiT Transport and Vehicle
Tracking Management Department stockholder that needs to have automated transport management
system and system developer.

3.1 User Requirements

User requirement is a document that defines what a proposed system must be capable of
doing to solve the problems which defined by potential users of the system. The user
requirements specification should be independent of any solution-oriented bias and must use
terminology from the problem domain of the users. These requirements are classified into
functional requirement and non-functional requirements.

3.1.1. Functional User Requirements

This section is organized by the processes and features encapsulated in Transport and
Vehicle Tracking Management Department. The system should provide what the system should
react to particular inputs, and how the system should behave in particular situations. It specifies
the software functionality that the developers must build into the product to enable users to
accomplish their tasks. The system functional requirement grouped in to transport administrator,
managing directors, drivers, Auto mechanics technical and customers.

Grouping 1: Transport Administrator

Table 3: transport administrator functional requirements

Requirement ID REQ-1
Requirement The system should allow transport administrator to login to the system using his/her
username and password.
Description This requirement describes how the transport administrator to login into system.
Source Developer
Priority High

Requirement ID REQ-2
Requirement The system shall allow transport administrator to create new user account
Description This requirement describes how to create new user account. This requirement
contains the following attribute to create account: UserId, FirstName, LastName and
Role.
The password length not less than 8 character and contains numbers, letters and
Special symbol.
Source Developer
Priority High
Requirement ID REQ-3

9
Requirement The system shall allow transport administrator to edit account.
Description This requirement describes how administrator edit account
Source Developer
Priority Medium

Requirement ID REQ-4
Requirement The system shall allow transport administrator to register new drivers
Description This requirement describes how administrator register new drivers
Source Stockholder (managing director)
Priority High

Requirement ID REQ-5
Requirement The system shall allow transport administrator to response request.
Description This requirement describes how administrator to send response request
Source Developer
Priority Medium
Requirement ID REQ-6
Requirement The system shall allow transport administrator to update drivers’ information
Description This requirement describes how administrator update derivers’ information
Source Developer
Priority Low

Requirement ID REQ-7
Requirement The system shall allow transport administrator to Inactive driver’s information from
the system
Description This requirement describes how administrator inactive derivers’ information
Source Developer
Priority Low

Requirement ID REQ-8
Requirement The system shall allow transport administrator to register new vehicles
Description This requirement describes how administrator register new vehicles
Source Developer
Priority High

Requirement ID REQ-9
Requirement The system shall allow transport administrator to update vehicle information
Description This requirement describes how administrator update vehicle information
Source Stockholder
Priority Low

Requirement ID REQ-10
Requirement The system shall allow transport administrator to inactive vehicles information
Description This requirement describes how administrator inactive vehicle information
Source Stockholder
Priority Medium

Requirement ID REQ-11
Requirement The system shall allow transport administrator to prepare schedule
Description This requirement describes how administrator prepare vehicle information
Source Transport administrator
Priority High

10
Requirement ID REQ-12
Requirement The system shall allow transport administrator to edit schedule
Description This requirement describes how administrator edit schedule
Source Transport administrator
Priority Medium

Requirement ID REQ-13
Requirement The system shall allow transport administrator to delete schedule
Description This requirement describes how administrator delete schedule
Source Transport administrator
Priority Medium

Requirement ID REQ-14
Requirement The system shall allow transport administrator to assign drivers for emergency case
Description This requirement describes how administrator assign drivers for emergency case
Source Transport administrator
Priority High

Requirement ID REQ-15
Requirement The system shall allow transport administrator to view schedule
Description This requirement describes how administrator to view schedule
Source Transport administrator
Priority High

Requirement ID REQ-16
Requirement The system shall allow transport administrator to views all assigned drivers
Description This requirement describes how administrator to view assigned drivers
Source Transport administrator
Priority High

Requirement ID REQ-17
Requirement The system shall allow transport administrator to add new sites (fermata)
Description This requirement describes how administrator add new sites
Source Transport administrator
Priority High

Requirement ID REQ-18
Requirement The system shall allow transport administrator to delete site
Description This requirement describes how administrator delete site
Source Transport administrator
Priority High

Requirement ID REQ-19
Requirement The system shall allow transport administrator to identify the locations of the vehicle
Description This requirement describes how administrator to identify the current locations of
vehicle using GPS.
Source Transport administrator
Priority High

Requirement ID REQ-20
Requirement The system shall allow transport administrator to logout

11
Description This requirement describes how administrator logout
Source Developer
Priority High

Grouping 2: Managing Director

Table 4: Managing director functional requirements

Requirement ID REQ-1

Requirement The system should allow managing directors to login to the system using their
username and password

Description This requirement describes how the managing directors login into the system.

Source Developer

Priority High

Requirement ID REQ-2
Requirement The system should allow managing directors to change their own password.

Description This requirement describes how to change the managing director password in the
system.

Source Developer

Priority High

Requirement ID REQ-3
Requirement The system should allow managing directors to generate reports

Description This requirement describes how the system is generating reports by authorized users
called managing director.
Source Managing director

Priority High

Requirement ID REQ-4

Requirement The system shall allow managing directors to view schedules

Description This requirement describes how the available schedule in the system is shown by
managing director.
Source Managing director

Priority Medium

12
 Requirement ID REQ-5

Requirement The system shall allow managing directors to send request for giving service outside
Bahir Dar

Description This requirement describes how the managing directors login into the system.

Source Managing Director

Priority High

Requirement ID REQ-6

Requirement The system shall allow managing directors to logout

Description This requirement describes to logout managing directors from the system.

Source Developer

Priority High

Grouping 3: Drivers
Table 5: driver functional requirement

Requirement ID REQ-1
Requirement The system shall allow drivers to log in to the system using their username and
password.
Description This requirement describes how the driver to login into system.
Source Developer
Priority High

Requirement ID REQ-2
Requirement The system shall allow drivers to change their own password.
Description This requirement describes how the drivers to change their password
Source Developer
Priority Medium

Requirement ID REQ-3
Requirement The system shall allow drivers view all available drivers to the system.
Description This requirement describes how drivers see other necessary driver information
Source Developer
Priority Low

Requirement ID REQ-4
Requirement The system shall allow drivers view schedule.
Description This requirement describes how the drivers view the schedule
Source Transport Administrator
Priority High

Requirement ID REQ-5
Requirement The system shall allow drivers to send request.
Description This requirement describes how the driver send request about the required materials

13
 of vehicle using the system
Source Developer
Priority High

Requirement ID REQ-6
Requirement The system shall allow drivers to view request.
Description This requirement describes how the driver view request about the required
materials of vehicle using the system
Source Developer
Priority High

Requirement ID REQ-7
Requirement The system shall allow drivers to logout.
Description This requirement describes how the driver logout after using the system
Source Developer
Priority High
Grouping 4: Customers
Table 6: Costumer functional requirements

Requirement ID REQ-1
Requirement The system should allow customers to login to the system using their username and
password
Description This requirement describes how the customers to login to system
Source Developer
Priority High

Requirement ID REQ-2
Requirement The system shall allow customers to view schedules.
Description This requirement describes how the customers to view the schedule.
Source Developer
Priority High

Requirement ID REQ-3
Requirement The system shall allow customers to send request for get service.
Description This requirement describes how the send request to transport administrator
Source Developer
Priority Medium

Requirement ID REQ-4
Requirement The system shall allow customers to view request for get service.
Description This requirement describes how the view request to transport administrator.
Source Developer
Priority Medium

Requirement ID REQ-5
Requirement The system shall allow Customers to change their own password.
Description This requirement describes how the customers to change their password
Source Developer
Priority Medium

14
 Requirement ID REQ-6
Requirement The system should allow customers to logout.
Description This requirement describes how the customers to logout from the system after
finished.
Source Developer
Priority High

Requirement ID REQ-6
Requirement The system should allow customers to logout.
Description This requirement describes how the customers to logout from the system after
finished.
Source Developer
Priority High

Grouping 5: Auto-Mechanical
Table 7: Auto-mechanical functional requirements

Requirement ID REQ-1
Requirement The system should allow auto-mechanical to login.
Description This requirement describes how the auto-mechanical to login the system.
Source Developer
Priority High

Requirement ID REQ-2
Requirement The system should allow auto-mechanical to change their password.
Description This requirement describes how the auto-mechanical to change their password
Source Developer
Priority Medium

Requirement ID REQ-3
Requirement The system should allow auto-mechanical to approve drivers requests.
Description This requirement describes how the auto-mechanical to approve the request
Source Developer
Priority Medium

Requirement ID REQ-4
Requirement The system should allow auto-mechanical to reject driver request.
Description This requirement describes how the auto-mechanical to reject driver request
Source Developer
Priority Medium

Requirement ID REQ-5
Requirement The system should allow auto-mechanical to logout.
Description This requirement describes how the auto-mechanical to logout from system
Source Developer
Priority High
Grouping 6: Academic Director

15
Table 8: Academic director functional requirements

Requirement ID REQ-1
Requirement The system should allow academic director to login.
Description This requirement describes how the academic director to login the system.
Source Developer
Priority High

Requirement ID REQ-2
Requirement The system should allow academic director to change their password.
Description This requirement describes how the academic director to change their password on
system.
Source Developer
Priority Medium

Requirement ID REQ-3
Requirement The system should allow academic director to approve users’ requests.
Description This requirement describes how the academic director to approve users request
Source Developer
Priority Medium

Requirement ID REQ-4
Requirement The system should allow academic director to reject user request.
Description This requirement describes how the academic director to reject users request
Source Developer
Priority Medium

Requirement ID REQ-5
Requirement The system should allow academic director to logout.
Description This requirement describes how the academic director to logout from system
Source Developer
Priority High

16
 3.1.2. Non -Functional Requirements

Non-functional requirements are requirements that are not directly concerned with the
specific services delivered by the system to users. Non-functional requirements are related to the
product of system properties and qualities. Alternatively, they define constraints on the system
implementation such as the capabilities of I/O devices or the data representations used in
interfaces with other systems. The non functional requirements which concerned in this system
are listed below:-
Table 9: non-functional requirements

Requirement ID NFREQ-1
Requirement Usability
Description • The system provides a help and support menu in all interfaces for the user to
interact with the system.
• The system shall be used after two hour training.
Source Developer
Priority High

Requirement ID NFREQ-2
Requirement Security
Description • The system provides username and password to prevent the system from
unauthorized access.
• The system shall authenticate server side users.
• Passwords should be stored in encrypted form.
Source Developer
Priority High

Requirement ID NFREQ-3
Requirement Performance
Description The system response time for every instruction conducted by the user must not
exceed more than a two second.
Source Developer
Priority High

Requirement ID NFREQ-4
Requirement Availability
Description The system should always be available for access at 24 hours, 7 days a week.
Source Developer
Priority High

Requirement ID NFREQ-5
Requirement Portability
Description • The system shall be server platform independent.
• The system should support accessing by most known browsers, such as
Mozilla, chromes and internet explorer.
Source Developer
Priority High

17
Requirement ID NFREQ-6
Requirement Reliability
Description The system shall not fail one hour per a day.
Source Developer
L8Priority Medium

Requirement ID NFREQ-7
Requirement Maintainability
Description The system will be maintained by authorized technicians within a day
Source Developer
Priority High

3.2 System Requirements

This section describes the functional and non-functional requirements at a sufficient level
of detail for the designers to design a system satisfying the user requirements and testes to verify
system requirements. The system requirements will be developed through object oriented
analysis and design methods by the use of UML model language. All system requirements will
be uniquely identifiable.

3.2.1 Use Case-Diagram

A use case is a series of related interactions between a user (an “actor”) and a system that
enables the user to achieve a goal. To phrase this definition in another way, a use case describes
the system's behaviour as it responds to a series of related requests from an actor.
A use case is a software diagram and system engineering term that describes how a user uses a
system to accomplish a particular task. A use case diagram is a sequence of actions that provide a
measurable value to an actor. Use case diagram are perhaps the best way to capture functional
requirements of a system. The actor can be a human or an external system. Use case diagram
components are actors, use cases and system boundary.

18
Figure 3: Use case diagram

19
[Link] Actor description
Table 10 : Actor description

Actor Name Description

Customer Include all actors that are login, view schedule, send request, view
response and logout.
Transport A head of BiT TVTD who manage the overall activity of the system.
Administrator
Drivers A person who employed to TVTD to drive vehicles.
Managing Director A person who manage and order general services.
Auto-mechanic A person who maintained, and approve the vehicle status.
Academic Director A person who assigned to manage the activities of academic department.

[Link] Use case Description

1. Use Case Name: Login
Table 11: login use case description

Use case number UC-01

Use case name Login
Priority High
Actors Transport administrator, Managing directors, Customers, Drivers,
Auto-mechanical and academic director.
Description This use case describes how actors to login into the system.
Precondition The actors have an account in TMVT Department database.
Post-condition If the use case is successful, the actors are now logged in to the system.
If not the system state in unchanged.
Basic course of action User action System response
1. The actors are on the home page 2. The system promote the actors
login to the system. enter user name and password.
3. Actors enters user name and 4. The system check and verifies
password and click login button. that all the filled have been filled
out and valid.
5. The system successfully
logged in the system.
6. Use case end.
Alternate course of If all fields are not filled out or not matched to the username and
action password the system display error message and then goes back or
returns to step 3 of basic course of action to enter again.

20
 2. Use Case Name: Register new vehicle
Table 12 Register new vehicle use case description

Use case number UC-02

Use case name Register new vehicle
Priority High
Actor Transport administrator
Description This use case describes how the Transport administrator register new vehicle
to the system.
Pre condition There must be a new vehicle.
Post-condition If the use case is successful, the vehicle is now registered into the system
database. If not the system state in unchanged.
Basic course of action User action System response
1. The Transport administrator wants to add a new 3. The system
vehicle. response or displays a
form to be filled out
2. The Transport administrator requests add new for vehicle
vehicle form page. registration.
4. The Transport administrator fills out the field. 6. The system
5. The Administrator clicks or presses on the verifies that all
the fields’ have
Save or insert button. been filled out
Alternate course of correctly.
If all fields are not filled out the system goes back or returns to step 4 of basic
course of action. To fill the invalid or the empty field.
Action 7. Thesystem
displays a
successfullystor
3. Use Case Name: Register new driver ed message.
8. Use case end
Table 13: Register new vehicle case description

Use case number UC-03

Use case name Register new drivers
Priority High
Actor Transport administrator
Description This use case describes how the transport administrator registers new drivers

Precondition to
Thethesystem.
driver must be new driver for BiT TMVT department.
Post-condition If the use case is successful, the driver’s now registered in to the system. If not
The system state in unchanged.

Basic course of action User action System response

21
 1. The transport administrator wants to add a 3. The system response or
displays a form to be
new driver. filled out for driver
2. The transport administrator requests add new Registration.
driver form page. 6. The system verifies that
4. The transport administrator fills out the all the fields have been
filled. filled correctly.

5. The administrator clicks on the save button. 7. The system

displays a
successfully stored
message.
Alternate course of action Ifallfieldsarenotfilledoutthesystemgoesbackorreturnstostep4ofbasic
8. Use case course
end of
[Link] fill the invalid or the empty field.

4. Use Case Name: Inactive driver information

Table 14: Inactive driver information use case description

Use case number UC-04

Use case name Inactive driver information
Priority Medium
Actor Transport administrator
Description This use case describes how the transport administrator inactive driver
Information from the system.
Precondition Driver complete his contact, request withdraw and others from BiT TVTD.

Post-condition If the use case is successful, the driver is inactive from the system. If not the system
state in unchanged.
Basic course of action User action System response
1. The transport administrator wants to 3. The system response or
inactive the driver information from system. displays a form to be filled out
for driver information inactive
2. The transport administrator requests form.
inactive driver information form page.
6. The system verifies that the
4. The transport administrator enters fields have been filled out
the required information in the correctly and check that the
form. driver information have in the
5. The transport administrator clicks or existing database.
presses on the inactive button. 7. The system displays a
successfully change driver
information is inactive
messages
8. Use case end

22
 Alternate course of 1. If the Transport administrator enters incorrect value goes back or returns to
step 4 of basic course of action, to fill the invalid value or the empty field.
Action
2. If the required drivers information have not exist in database the system display
no driver information available message.
5. Use Case Name: Prepare schedule

Table 15: Prepare Schedule use case description

Use case number UC-05

Use case name Prepare schedule
Priority High
Actor Transport administrator
Description This use case describe show the transport administrator prepare schedule in order
to achieve department task.

Precondition The transport administrator wants to prepare schedule.

Post-condition If the use case is successful, there exists a scheduled work. If not the system
state in unchanged.

Basic course of action User action System response

1. The transport administrator wants to prepare 3. The system response or
schedule.
displays a form to
2. The transport administrator click prepare schedule be filled out for
form page. prepare schedule
form.
4. The transport administrator full filled the
required filed. 6. The system verifies
that all the fields
5. The transport administrator clicks or presses on have been filled out
the submit or prepare schedule button. correctly
7. The system
displays
successfully
prepare schedule
message.
8. Use case end

Alternate course of If all fields are not filled out the system goes back or returns to step 4 of
basic course of action. To fill the invalid or the empty field.
Action

6. Use Case Name: Create account

23
Table 16: Create account use case description

Use case number UC-06

Use case name Create account
Priority High
Actors Transport administrator
Description This use case describes how transport administrator creates account for system
Pre condition The
[Link] must be the staff of BiT
Post-condition If the use case is successful, the transport administrator is creating new account or
user
Basic course of action User actionthesystem statein unchanged
[Link] System response
1. The transport administrator on homepage. [Link] system promote the
2. The transport administrator login. sign up form.
3. The transport administrator is on the sign up 7. The system check
home page. and verifies that
all the filled have
4. The transport administrator requests sign up been filled out and
form page. valid.

[Link] transport administrator fill the sign up 8. The system

form and click create button successfully store
created account in to
database.
[Link] case end

Alternate course of If all fields are not filled out or not matched with rules the system replay error
Action message and then goes back or returns to step 6 of basic course of action to enter
again.
7. Use Case Name: Generate Report

Table 17: Generate report use case description

Use case number UC-07

Use case name Generate Report
Priority High
Actors Managing director and transport administrator
Description These use case allow managing director and transport administrator to generate
report.
Precondition Managing director and transport administrator wants to generate report
Post-condition Reports viewed by managing director and transport administrator
Basic course of action User action System response

24
 1. The managing director and transport administrator 2. The system promotes
are on the home page login to the system. the managing director and
transport administrator
3. Managing director and transport administrator enter enters user name and
username and password and click login button. password.
6. Managing director and transport administrator want 4. The system check
to generate reports and verifies that all
7. Managing director and transport the filled have been
administrator select or press generate report filled out and valid.
button. 5. The managing
9. Managing director and transport administrator director and transport
generate the report. administrator
successfully logged
in to the system.
8. The system display
appropriate report.
10. Use case end.

Alternate course of If there is no report then the system display no report is available.
Action .

8. Use Case Name: Inactive vehicles

Table 18: Inactive vehicles use case description

Use case number UC-8

Use case name Inactive vehicles
Priority Medium
Actor Transport administrator
Description This use case describes how the transport administrator inactive vehicles
from the system.
Precondition Vehicles have already under maintains or out of service with different cases.
Post-condition If the use case is successful, the vehicle is not giving service to transport case
team. If not the system state in unchanged.
Basic course of action User action System response

25
 1. The transport administrator wants to inactive 4. The system response
or displays a form to be
The vehicle information from system. filled out for vehicles
[Link] transport administrator login to his other inactive form.
homepage 7. The system verifies
3. The transport administrator requests inactive that the fields have
been filled out
Vehicles form page. correctly and check
that the vehicles
5. The transport administrator enters the
information has in
required information in the form.
the existing
6. The transport administrator clicks or presses on database.
the inactive button.
8. The system
displays a
successfully in
activated
messages
9. Use case end

Alternate course of 1. If the Transport administrator enters incorrect value goes back or returns to
step 4 of basic course of action, to fill the invalid id or the empty field.
Action
2. If the required vehicles information haven to exist in database the system
display no vehicle information available message.

9. Use Case Name: Update Schedule

Table 19: Update schedule use case description

Use case number UC-9

Use case name Update schedule

Priority High
Actors Transport Administrator
Description These use case allow how the transport administrator, update schedule.
Precondition There must be available scheduled to be updated.
Post-condition Make appropriate schedules.
Basic course of action User action System response

26
 1. The transport administrator are on the home page 2. The system promote
log in to the system. the transport
administrator enter
3. The transport administrator enters user name user name and
and password and click login button. password.
7. The transport administrator updates the 4. The system check
scheduled table. and verifies that all the
filled have been filled
out and valid.
5. The system
successfully
logged in to the
system.
6. The system
generates
schedule table
from database.
[Link] stored
scheduled
information in to
database
9. Use case end.

Alternate course of 1. If the transport administrator enters incorrect use name and password back
or returns to step3 of basic course of action, to fill the invalid value or the
Action empty field.
2. If the transport administrator fills incorrect information in schedule form
back and return to step 7 basic course of action, to fill the correct information.

10. Use Case Name: Delete Schedule

Table 20: Delete schedule use case description

Use case number UC-10

Use case name Delete schedule

Priority Medium
Actors Transport Administrator.
Description These use case allow how the transport administrator delete schedules.

Precondition There must be available schedule to be deleted.

Post-condition Delete appropriate schedules.
Basic course of action User action System response

27
 1. The transport administrator are on the home page 2. The system promote
login to the system. the transport
administrator enter
3. The transport administrator enter user name and user name and
password and click login button. password.
6. The transport administrator click the delete form. 4. The system
8. The transport administrator enter appropriate check and
verifies that all
Value in the field. the filled have
been filled out
9. The transport administrator click delete
and valid.
button.
5. The system
successfully
logged in to the
system.
Alternate course of 1. If the transport administrator enters incorrect use name and password back or
returns to step3 of basic course of action, to fill the [Link]
Thesystem
or the empty
Action field. displaythe delete
filed form.
2. If the transport administrator enters invalid schedule id return to step 8 of
basic course of action, to fill the invalid value or the empty [Link]
field.
deletethe
11. Use Case Name: Register Site schedule.
11. Use case end.
Table 21: Register site use case description

Use case number UC-13

Use case name Register Site
Priority High
Actors Transport Administrator.
Description These use case allow how the transport administrator register site
Precondition New customers are request service from new site or new place.
Post-condition Register new sites
Basic course of action User action System response

28
 [Link] transport administrator is on the home 2. The system promote the
transport administrator enter
Page login to the system. username and password.
3. The transport administrator enters 4. The system check and
username and password and click login verifies that all the
button. filled have been filled
6. The transport administrator is click the out and valid.
register site button. 5. The system successfully
7. The transport administrator fills the site form. logged in to the system.
7. The system generates
register site form.
8. The system checks
and verifies that all
fields are filling
appropriately.
[Link] system stored
scheduled information
in to database
10. Use case end.

Alternate course of 1. If the transport administrator enters incorrect use name and password back
or returns to step3 of basic course of action, to fill the invalid value or the
Action empty field.
2. If the transport administrator fills incorrect information in site form back
and return to step 7 basic course of action, to fill the correct information.

12. Use Case Name: Send Request

Table 22: Send Request use case description

Use case number UC-12

Use case name Send request
Priority High
Actors Customers, drivers, auto-mechanical and academic director. .
Description These use case allow how the customers, drivers, and academic director
request service.
Precondition The customers, drivers and academic director want service.
Post-condition The customers, drivers and academic director get service
Basic course of action User action System response

29
 1. The customers, drivers and academic director 2. The system promotes
are on the home page login to the system. the customers, drivers
and academic director
3. The customers, drivers and academic enter user name and
director enter user name and password and password.
click login button.
4. The system check
6. The customers, drivers and academic and verifies that
director send request form. all the filled have
8. The customers, drivers and academic been filled out
direct or fill the requested form. and valid.

9. Send the request. 5. Successfully logged

in to the system.
[Link] system display
the request form
10. Use case end.

Alternate course of If the transport administrator enters incorrect use name and password
back or returns to step 3 of basic course of action, to fill the invalid value
Action or the empty field.
13. Use Case Name: View Schedule
Table 23: View schedule use case description

Use case number UC-13

Use case name View schedule
Priority High
Actors All login actors.
Description These use case allow how the login actors, view schedules.
Precondition There must be an account and must be login.
Post-condition View schedules.
Basic course of action User action System response

30
 1. The actors are on the home page login to the 2. The system
system. promotes the actors
enter user name and
3. The actors enter user name and password and password.
click login button.
4. The system check
6. The actors ‘select view schedule option. and verifies that
8. The actors view the schedule. all the filled have
been filled out
and valid.
5. The system
successfully logged in
to the system.
7. The system
displays all
available
schedules.
9. Use case end.

Alternate course of 1. If the transport administrator enters incorrect user name and password back
or returns to step 3 of basic course of action, to fill the invalid value or the
Action empty field.
2. If the transport administrator fills incorrect information in schedule form
back and return to step 7 basic course of action, to fill the correct information.
14. Use Case Name: Logout

Table 24: Logout use case description

Use case number UC-14

Use case name Log out
Priority High
Actors All login actors.
Description This use case describes show the logged in actors want to logout from the
system.
Precondition The logged actors went to logout from their home page interface.
Post-condition If the use case is successful, the actors’logoutfromtheirownhomepageand
return to original home page. If not the system state in unchanged
Basic course of action User action System response
1. The actors want to logout. 3. The system returns in to the
original homepage.
2. The actors clicks on logout button
4. Use case end

31
4. External Interface Requirements
External interface define the interaction points between a system and entities that communicate
with the system. Specific areas of interest include user interfaces, hardware interfaces, software
interfaces, and communications interfaces.

4.1 User Interfaces

The user interface to be designed using JAVA must be developed in such a way that the
application is easy to understand the system. The system design must almost be easy to
understand in where what features are located and how to use them. Sample user interface this
system are:

Figure 4: Home page user interface

32
Figure 5: Create account user interface

33
Figure 6: Update deriver information user interface

4.2 Hardware Interfaces

The only hardware device used by this system is GPS tracking devices, which is used to identify the
current vehicle location.

4.3 Communications Interfaces

This system allows users to communicate using send and receive request form and also support common
browser such as Mozilla, Firefox, internet explorer, and chrome.

34
5. Analysis Models
It is a representation of a system that allows for investigation of the properties of the system and,
prediction of future outcomes, such as activity diagram, sequence diagram.

5.1 Sequence Diagrams

A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the instances
participating in the interaction by their “lifelines” and the stimuli that they arranged in time sequence. It
does not show the associations among the objects. In our case we construct a sequence diagram to show
how processes operate with one another and in what order for each use cases. It depicts how actors that
are involved in the scenario and the sequence of messages exchanged between them in the sequential
order that those interactions and involvement occur.
1. Login

Home<<UI>> Login<<UI>> Login:Controler aLogin BiT TMVT:Database

open
Actors home()

Enter username and password Check validity()

Request Login()

Check Authentication()
Please try again

This user is not found in database

Successful login

Figure 7: Login sequence diagram

35
 2. Create account

Home<<UI>> Creat account<<UI>> Account:Controler BiT TMVT:Database

open
Transport home()

Admin Login

Request create account page

Account form

Display account form

Fill acount form

Check Validity()

Please enter again Store create account

Account create sucessfull

Figure 8: Create account sequence diagram

36
 3. Inactive driver’s information

Home<<UI>> Driver search information<<UI>> Controler isDriver BiT TMVT:Database

open
Transport home()

Admin Login

Request inactive driver information

Display Form

Inter driver id

Check Validity()
Fill acount form

Please enter again If exist

Inactive()

Driver information inactive sucess

Figure 9: inactive driver information sequence diagram

37
5.2 Activity Diagrams
An activity diagram is a variation of a state machine in which the states represent the performance of
actions or sub activities and the transitions are triggered by the completion of the actions or sub activities.
It represents a state machine of a procedure itself.
1. Login

Login

Enter username and password

Check username and password

yes

No

Login in to the system

Figure 10: login activity diagram

38
 2. Prepare Schedule

Figure 11: Prepare Schedule activity diagram

39
 3. View schedule

Figure 12: View Schedule activity diagram

40
 4. Create Account

Create account

Transport Admin enters user

Name and password

Check username and password

yes

No

Transport Admin(UI)

Select create account form

File the required field

Check validation

No

yes

Store value in database

Success message

Figure 13: Create account activity diagram

41
 5. Inactive driver information

Inactive driver information

Transport Admin enters user

Name and password

Check username and password

yes

No

Transport Admin(UI)

Select inactive driver information button

Enter driver id
Is driver information exist?
yes
Search driver information by using driver id

Check validation Drive information dispaly

No
No
yes

This driver not exist Check inactive field

Successful inactive

Figure 14: Inactive deriver information activity diagram

42
6. Appendix
Interview questions
Part 1: Overview of the current system
1. What is the current name of your department?
2. Please give a brief description about the current transport management system work
flow?
3. Who are the participants in your department? What are role of the participants of the
system?
4. How many vehicles and drivers are in your department?
5. Have your department have their own rule and regulation?
6. Is there any a manual or document to describe the current system work flow?

Part 2: Problem identification

1. What problems do you run into in your day-to-day work? Is there a standard way of
solving it? Why is this problem?
2. How do you solve the problem today?
3. How would you ideally like to solve the problem?

Part 3: User’s Environment

1. Who will be the users of the system?
2. What level of education or training do the users have?
3. What computer skills do the users have?
4. Are users familiar with this type of IT system?
5. What technical platforms do they use today?
6. Do you know of any plans for future systems or platforms?
7. What other IT systems does the organization use today that the new system will need to
link to?
8. What are your expectations regarding system usability?
9. What training needs do you expect for the future system?
10. What kind of documentation do you expect?
11. What would you think of a solution appears many problems at a time? How would you
prioritize these proposed solutions?
7. Are there any other problems you’re experiencing? If so, what are they?
8. What is yours expectation about the current system to convert automated system?

43