CSI473 ASSIGNMENT PART ONE: FLEET

MANAGEMENT SYSTEM
System Analysis and Design
Authors

Introduction
The Fleet Management system is meant to replace the manual system of keeping track
of all the operations. The Institution of Higher learning in Tlokweng does not have
any system to help with the management of their fleet. Our team will designed a
system that will solve this problem. The designed system will be able to register and
maintain all the cars that are to be hired by the staff and students. This system will
also provide a platform for easy management of users and tracking of cars that have
been hired or reserved
Current system
The institution of higher learning in Tlokweng has a fleet of cars which consist of
combis, vans, sedans, buses, and trucks. These vehicles are under the control of the
department of Fleet Management within the institution. This department does not
have any system to help with the management of their fleet. The department use a
manual system to keep track of the borrowed cars. The details of this system are
recorded in a file based system. This is problematic because it takes time to find
records in this type of system due to it being cumbersome. Another problem in that
there is no backup of the data.

The cars are under the Fleet Management department can be used by both staff and
students when going on official trips. Car borrowers only need be a registered staff or
student to borrow a car. An individual can only borrow one car at a time.

Proposed system
Overview
The proposed system must be web-based. The car borrowers should be able to use
their student or staff ID to hire a car in the new online system. This system should
allow for the registration of vehicles by the system administrator.

Functional requirements
1. The system should allow for registration of cars into the system by the
Administrator
2. The system should keep a record of the maintenance(repairs and services)
done on each car
3. The system should allow for the hiring of cars by the student and staff
4. The system should approve the hiring of cars depending on the availability of
cars.
5. The system should provisionally accept or reject hiring based on the
availability of the cars.
6. The system should provide cost estimate when a user hires a car.
7. On returning the car, the system should calculate the actual amount owed
based on the distance travelled.
8. The system should remove retired cars and cars on repair from the available
cars list.

Non-functional requirements
The system should be:
● Secure
● reliable
● easy to use
● extensible
● maintainable
● Scalable.
Constraints

System Models

Use Case Model

Textual Explanation Main Use Cases

Detailed Specification: Hire Car

Name Hire Car

Participating Actors Car Borrower

Entry Conditions 1. The Use Case starts when a car

borrower wants to hire a car by
selecting the Hire Car function.

Flow of Events 1. The car borrower provides

requested information
 2. They check whether or not there
are any cars available which suit
their needs via the system
retrieving a list of available cars
through the Check If Car
Available function and the
results are displayed to the car
borrower. The user then selects
the desired car to rent.
3. The car borrower then selects the
Estimate the Cost function in
order to view the estimated
amount of money it would take
to rent the particular car.
4. The system then assigns the car
to the car borrower and this
signifies that the car has been
hired.
5. If the car is not available, the
system then gives the car
borrower a provisional
acceptance to signify that the car
is not there but they reserve the
car if conditions are favourable.
If the situation is otherwise then
the car borrowers’ request is
rejected..

Exit Conditions 1. The use cases terminates when

the system issues a message
which conveys that the car is
successfully hired or the hire
request has been rejected.

Exceptions ● Available car catalogue is

unavailable

Special Requirements None

Detailed Specification: Return Car

Name Return Car

Participating Actors Car Borrower

Entry Conditions 1. The use case starts when the

system administrator wishes to
update the availability status of a
 formerly hired car by selecting
the Return a Car function.

Flow of Events 1. The cars’ condition is checked to

ensure it is in an acceptable
condition.
2. If the condition is not acceptable,
the damage is appraised and the
value of it is calculated.
3. The system checks the date on
which the car was supposed to be
returned versus the date on which
it was actually returned. If the car
was returned on date later than
its due date, fines are calculated
for it.
4. The system then creates a total
amount to be paid after taking
into account the charges
associated with the total mileage,
the fines if there are any and
damage costs if there are any.

Exit Conditions The use case terminates once the system

issues a message about the clearing of all
associated payments with said car.

Exceptions Car unregistered

Car Catalogue is unavailable

Special Requirements None.

Detailed Specification: Register Car

Name Register Car

Participating Actors System Administrator

Entry Conditions 1. The use case starts when a

System Administrator wishes to
register a car by selecting the
Register Car function.

Flow of Events 1. The system administrator inputs

the requested information.
2. The system administrator
submits the completed
registration.
Exit Conditions 1. The use case terminates when the
system issues a message about
the successful registration of the
car in the Car Catalogue.

Exceptions ● Car Catalogue is unavailable

Special Requirements None

Detailed Specification: Authorise Car Service

Name Authorise Car Service

Participating Actors System Administrator

Entry Conditions This use case starts when the System

Administrator wishes to put a car in for
service by selecting the Authorise Car
Service function.

Flow of Events 1. The system administrator enters

pertinent details regarding the car to
be serviced including specifying the
particular service to be performed.
2. The information is reflected in the
maintenance records of the particular
car.
3. The changes are also reflected in the
Car Catalogue to show that it is
unavailable.

Exit Conditions 1. The system reflects that the car

has received authorization for it
to be serviced.

Exceptions None

Special Requirements None

Sequence Diagrams

Hiring a car
Return Car

Register car
Class diagram
State Chart Diagram

Car hire
Return car
Activity Diagrams

Add car
Car hire

Return car
System design
Architectural Design

Overview
The architectural design to be used is the 3-Tier Architecture. This architecture will
comprise of seven subsystems. There will be a user interface that will be generally
responsible for all the displaying of information to the user. There will also be the
payment subsystem that will be responsible for capturing all the payments made by
the car borrower. There shall also be the billing that will calculate the cost for car hire
and any other car borrower costs. Car hire subsystem will be responsible for enabling
car borrowers to actually hire cars. Report subsystem will compile reports for the
system administrator. Maintenance subsystem will be responsible for the keeping
track of all the repairs and services done on all the cars in the system. Then lastly
there will be the database to store all the information produced by the subsystems in
the Application logic section.

Subsystem Decomposition
User interface Subsystem:

This subsystem will be the means through which users communicate with the system
and output will be given through it. It will allow for users to carry out their tasks in an
effective manner through utilizing the functionalities provided by the system.

Payment subsystem
The payment subsystem will deal with all the activities involved in the paying of
funds from a customer to the institution for services rendered (hiring a car). It will
also provide facilities through which customers can also pay for any damages which
their hired vehicle may have come across. It will deal with all such financial
transactions between customers and the Institution.

Billing Subsystem

The billing subsystem will deal with the calculation of the total amounts owed to the
institution by customers who have hired cars. Given all the pertinent information it
will calculate the amount of money a customer is supposed to pay given the mileage
which they clocked up during the rental period. It will also include any amounts
related to damages if the hired vehicles received damage during their use by
customers in the total amount due.

Car hire subsystem

This subsystem holds domain over all the activities which are involved in the process
of hiring a vehicle from the institution. It will deal with activities such as discerning
the type of vehicle which a customer wants to hire and whether that type of vehicle is
available for hire. It is the subsystem which actualizes the entire process of a customer
hiring a car.

Report subsystem

The report subsystem deals with all the reports which are needed by the institution. It
deals with the management of relevant reports which are utilized. It also generates all
these reports.

Maintenance subsystem

The maintenance subsystem has to do with keeping track of all maintenance related
activities which are needed in order to ensure that all cars which belong to the
institution are in suitable condition to be hired out to customers. It deals with the
keeping of relevant maintenance reports for each vehicle. These reports detail the
history of each individual vehicle, they also include details such as the date of the last
service the car went through, its accident track record and the likes.

Database Subsystem

The database is the storage for the entire system. It is where the car catalogue is
stored, all the records regarding the cars.
Software Architecture