Business Requirement
Document for Fleet
Management System
1
Table of Content
Section
Content Description
Number
1
Customer Section
2
Driver Section
3
Vehicle Section
4
Product Section
5
Location Section
6
Booking Section
7
Maintenance Section
8
Inspection Section
9
Dashboard Section
10
IT Section
Page
Number
3–9
10 – 12
13 – 19
20 – 22
23 – 27
28 – 33
34 – 37
38 – 41
42 – 44
45 – 49
2
Customers Section
3
1. Purpose:
Purpose of this section is to capture customer’s information. BVM needs to be able to
create new customer, and amend the existing customer when necessary.
2. Detail Requirement:
i.
Customer Type:
• BVM needs to be able to capture two types of customer being Individual
Customer and Entity Customer.
o Individual Customer is customer who is a legal person.
o Entity Customer is customer who is a legal entity.
ii.
Customer Category:
• BVM needs to be able to categorize the customers, either Individual or Entity,
into three categories being Wholesaler, Dealer, Client.
o Wholesaler is Individual/Entity who is, on a contractual basis, purchase
goods from BVM and distribute to other BVM clients.
o Dealer is Individual/Entity who, on a contractual basis, purchases
goods from BVM for retailing or for use.
o Client is Individual/Entity who, on a non-contractual basis, purchases
goods from BVM for retailing or for use. Client is also referred to
customer who purchases goods from BVM’s Wholesaler; therefore,
when creating Client, the customer may/may not need to be linked to
Wholesaler’s Number (Customer Number of the Wholesaler).
iii.
Required Information:
• For Individual Customer: when selected Individual Customer below should be
the required information fields.
No.
1
2
3
Data Field
First Name
Last Name
Phone Number
Data Input Type
Alpha
Alpha
Numeric
4
Email Address
Alpha Numeric
5
Password
Alpha Numeric
4
Mandatory Data Field Description
Yes
First Name of the customer.
Yes
Family Name of the customer.
Yes
o Phone Number of the customer.
o BVM should be able to add
additional line to input another
phone number should the customer
has. However, the addition is nonmandatory.
No
o Email address of the customer.
o BVM should be able to add
additional line to input another email
address should the customer has.
Yes
o Password which customer uses to
log
into
Customer
Mobile
Application.
o Password must at least have 8
characters which is a combination
of
alpha
character,
numeric
character, and special character.
6
Customer Number
Numeric
Yes
7
Contract Number
Alpha Numeric
No
8
Contract Expiry Date
Date (DD/MM/YY)
No
9
ID Type
List of Value
Yes
10
ID Number
Alpha Numeric
Yes
11
ID Issue Date
Date (DD/MM/YY)
Yes
12
ID Expiry Date
Date (DD/MM/YY)
Yes
13
Credit Term (Days)
Numeric
No
14
Credit Limit (USD)
Numeric
No
15
Gender
List of Value
Yes
5
o The password combination can later
be amended by BVM internal IT team
if necessary.
o Unique number used to identify
customer in the Fleet Management
System.
o Customer number should be
automatically generated when BVM
creates a new customer.
o It should start with 0000001 (six
digits of zero and incremental
number starting from number one).
o This field must not be editable.
o Number referencing to the Sales
Purchase Contract between BVM
and the customer.
o Expiry date of the Sales Purchase
Contract between BVM and the
customer.
o Type of the customer’s Legal
Identification document.
o List of Value should contain 2
values:
o NID (National ID)
o Passport
o NID or Passport number of the
customer.
o Issue date of the customer’s NID or
Passport.
o Validation Requirement: this date
cannot be postdated.
o Expiry Date of the customer’s NID or
Passport.
o Validation Requirement:
o This date cannot be
backdated.
o This date cannot be
earlier or equal to ID
Issue Date.
o Maximum credit repayment term of
the customer.
o Maximum credit limit of the
customer.
o Gender of the customer.
o List of Value:
o Male
o Female
16
Address Line 1
Alpha Numeric
No. Data Field
1
Entity Name
2
Representative
Name
3
Phone Number
Data Input Type
Alpha Numeric
Full Alpha
17
18
19
20
21
22
23
4
o Customer’s house number and
street number.
Address Line 2
Alpha Numeric
Yes
o Khan or District
Address Line 3
Alpha Numeric
Yes
o Sangkat or Commune
Address Line 4
Alpha
Yes
o City/Province
Billing Address
Alpha Numeric
No
o Billing address of the customer
which is to be filed on the invoice.
o There should be a button called
“Same as Customer’s Address”
which allows user to click to copy
customer address line 1 to line 4 into
bill address. Formula should be:
“Address Line 1” + “,” + “space” +
“Address Line 2” + “,” + “space” +
“Address Line 3” + “,” + “space” +
“Address Line 4”.
Wholesaler’s CID
Numeric
No
o Wholesaler’s Customer Number that
needs to be linked with the Client
category customer.
o A validate button need be created
next to this field to allow user to
validate their input.
o When
clicked,
Wholesaler’s Full Name
should be displayed.
Refer to below.
Wholesaler’s Name
Alpha
No
o Wholesaler’s
Full
Name
(Wholesaler’s
Last
Name
+
Wholesaler’s First Name) retrieved
automatically after user clicks
Validate Button in the above
requirement.
Customer Location
Alpha Numeric
No
o Customer location code in BVM’s
Code
current accounting system.
• For Entity Customer: when selected Entity Customer below should be the
required information fields.
Email Address
No
Numeric
Alpha Numeric
6
Mandatory Data Field Description
Yes
Full Name of Entity Customer
Yes
Full Name of the entity customer’s
representative.
Yes
o Phone Number of the customer.
o BVM should be able to add
additional line to input another
phone number should the customer
has. However, the addition is nonmandatory.
No
o Email address of the customer.
5
Password
Alpha Numeric
Yes
6
Customer Number
Numeric
Yes
7
Contract Number
Alpha Numeric
No
8
Contract Expiry Date
Date (DD/MM/YY)
No
9
Registration Number
Alpha Numeric
Yes
10
11
Patent Number
Representative Legal
ID Type
Alpha Numeric
List of Value
Yes
No
12
Representative’s
Legal ID number
Representative’s ID
Issue Date
Alpha Numeric
No
Date (DD/MM/YY)
No
Representative’s ID
Expiry Date
Date (DD/MM/YY)
No
13
14
7
o BVM should be able to add
additional line to input another email
address should the customer has.
o Password which customer uses to
log
into
Customer
Mobile
Application.
o Password must at least have 8
characters which is a combination
of
alpha
character,
numeric
character, and special character.
o The password combination can later
be amended by BVM internal IT team
if necessary.
o Unique number used to identify
customer in the Fleet Management
System.
o Customer number should be
automatically generated when BVM
creates a new customer.
o It should start with 0000001 (six
digits of zero and incremental
number starting from number one).
o This field must not be editable.
o Number referencing to the Sales
Purchase Contract between BVM
and the customer.
o Expiry date of the Sales Purchase
Contract between BVM and the
customer.
o Registration number of the entity
customer.
o Number of the Patent.
o Type of the representative’s Legal
Identification document.
o List of Value should contain 2
values:
o NID (National ID)
o Passport
o NID or Passport number of the
representative.
o Issue date of the representative’s
NID or Passport.
o Validation Requirement: this date
cannot be postdated.
o Expiry Date of the representative’s
NID or Passport.
o Validation Requirement:
This date cannot be
backdated.
o This date cannot be
earlier or equal to ID
Issue Date.
o Maximum credit repayment term of
the customer.
o Maximum credit limit of the
customer.
o Customer’s house number and
street number.
o Khan or District
o Sangkat or Commune
o City/Province
o Billing address of the customer
which is to be filed on the invoice.
o There should be a button called
“Same as Customer’s Address”
which allows user to click to copy
customer address line 1 to line 4 into
bill address. Formula should be:
“Address Line 1” + “,” + “space” +
“Address Line 2” + “,” + “space” +
“Address Line 3” + “,” + “space” +
“Address Line 4”.
o Wholesaler’s Customer Number that
needs to be linked with the Client
category customer.
o A validate button need be created
next to this field to allow user to
validate their input.
o When
clicked,
Wholesaler’s Full Name
should be displayed.
Refer to below.
o Wholesaler’s
Full
Name
(Wholesaler’s
Last
Name
+
Wholesaler’s First Name) retrieved
automatically after user clicks
Validate Button in the above
requirement.
o Customer location code in BVM’s
current accounting system.
o
15
Credit Term (Days)
Numeric
No
16
Credit Limit (USD)
Numeric
No
17
Address Line 1
Alpha Numeric
No
18
19
20
21
Address Line 2
Address Line 3
Address Line 4
Billing Address
Alpha Numeric
Alpha Numeric
Alpha
Alpha Numeric
Yes
Yes
Yes
No
22
Wholesaler’s CID
Numeric
No
23
Wholesaler’s Name
Alpha
No
24
Customer Location
Alpha Numeric
No
Code
iv.
Customer’s Reference Requirement:
• Customer’s reference(s) is required to be uploaded by BVM for both individual
or entity customer, when creating new customer. Customer reference
document to be uploaded shall be:
o Image file or PDF file
8
v.
o Mandatory
• Multiple files or references are allowed to be uploaded.
• When uploading new files or references, the new upload should override the
older version.
Other Rules:
• Customer, once created, cannot be deleted from the system.
• Used customer number cannot be recycled.
• Maker/checker principle must be applied to all customer creation and
amendment.
• Once record is submitted, second confirmation must be sought from user to
request user to double check the record before submitting for approval or
approving the record.
• Before approving the record, approval must be able to check every point of
data input by the maker.
9
Driver Section
10
1. Purpose:
Purpose of this section is to capture driver’s information. BVM needs to be able to create
new driver, and amend the existing driver when necessary.
2. Detail Requirement:
i.
Required Information: When creating driver, below should be the required
information fields.
No.
1
2
3
Data Field
First Name
Last Name
Gender
Data Input Type
Alpha
Alpha
List of Value
4
Assigned Vehicle
List of Value
5
Phone Number
Numeric
6
7
License Number
License Type
Alpha Numeric
List of Value
Mandatory Data Field Description
Yes
First Name of the driver.
Yes
Family Name of the driver.
No
o Gender of the customer.
o List of Value:
o Male
o Female
No
o Vehicle which the driver is assigned
to.
o All trucks created in the system
should appears in the list.
o When not selected, value should be
“Null” meaning the driver is a spare
driver.
Yes
o Phone Number of the driver.
o BVM should be able to add
additional line to input another
phone number should the customer
has. However, the addition is nonmandatory.
Yes
Driving license number of the driver.
Yes
o Type of driver’s driving license.
o List of Value should be:
o A1
(ក1)
o A2 (ក2)
o B (ខ)
o C (គ)
o D1 (ឃ2)
o D2 (ឃ2)
o BE (ងខ)
o CE (ងគ)
o DE (ងឃ)
11
8
License Issue Date
Date
Yes
9
License Expiry Date
Date
Yes
10
Password
Alpha Numeric
Yes
11
Employment Status
List of Value
Yes
i.
vi.
o Issue date of the driver’s driving
license.
o Validation Requirement: this date
cannot be postdated.
o Expiry date of the driver’s driving
license.
o Validation Requirement:
o This
date
cannot
be
backdated.
o This date cannot be earlier or
equal to License Issue Date.
o Password which driver uses to log
into Driver Mobile Application.
o Password must at least have 8
characters which is a combination
of
alpha
character,
numeric
character, and special character.
o The password combination can later
be amended by BVM internal IT team
if necessary.
o Status to show if driver is still in
service with BVM or not.
o List of value should be “In service”,
“Resigned”, or “Dismissed”.
Driver’s Reference Requirement:
• Driver’s driving license is required to be uploaded by BVM for when creating
new driver.
• Multiple files or references are allowed to be uploaded (Optional).
• When uploading new files or references, the new upload should override the
older version.
Other Rules:
• Driver, once created, cannot be deleted from the system.
• Maker/checker principle must be applied to all driver creation and
amendment.
• Once record is submitted, second confirmation must be sought from user to
request user to double check the record before submitting for approval or
approving the record.
• Before approving the record, approval must be able to check every point of
data input by the maker.
12
Vehicle Section
13
1. Purpose:
BVM needs to be able to create vehicle in the system so that the vehicle can later on be
used to manage daily goods delivery.
2. Detail Requirement:
i.
Vehicle Type:
• There are two types of truck that BVM is using for daily goods delivery:
o Tanker Truck: Truck which the fuel tank and the truck head is attached
to each other as a single body.
o Prime Mover: Truck which tractor head and the semitrailer tank are
separated from each other as separate components.
ii.
Required Information: Different vehicle type has different fields of information to
captured.
• For Tanker Truck:
No. Data Field
1
Vehicle Type
2
3
4
5
6
7
8
9
10
11
Vehicle Brand
Vehicle Model
Vehicle
Manufacturing Year
Vehicle Registration
ID
Chassis/Frame
Number
Engine Number
Vehicle Weight
Gross Weight
Vehicle Calibration
Inspection Date
Data Input Type
Mandatory
List of Value/
Yes
Radio button
Alpha Numeric
Alpha Numeric
Date (YYYY)
Yes
Yes
Yes
Alpha Numeric
Yes
Alpha Numeric
Yes
Alpha Numeric
Numeric
Numeric
Date
(DD/MM/YY)
Yes
Yes
Yes
Yes
Vehicle Calibration Date
Inspection
Expiry (DD/MM/YY)
Date
Yes
Data Field Description
Type of vehicle to be created in the
system.
List of Value/Choices for selection
should be:
o Tanker Truck
o Prime Mover
Brand of the vehicle to be created.
Model of the vehicle to be created.
Year
in
which
vehicle
is
manufactured.
ID number of the vehicle obtained
after being registered.
Chassis or Frame Number of the
Truck
Engine number of the truck
Weight of the truck.
Maximum gross weight of the truck.
The date in which the vehicle passed
calibration.
Validation Requirement:
o Calibration inspection date
cannot be postdated.
The date in which the vehicle
calibration is expired.
Validation Requirement:
o Calibration inspection expiry
date cannot be backdated or
earlier
than
Vehicle
Calibration Inspection Date.
14
12
13
14
15
16
17
18
19
20
21
License
Number
Maximum
Distance
Plate Alpha Numeric
Delivery Numeric
Transportation
Calibration Date
Date
(DD/MM/YY)
Servicing Status
License plate number of the vehicle
Yes
o The maximum distance in which
the vehicle can deliver goods to
customer.
o This links to Booking in a sense
that breaches the maximum
delivery distance shall now be
allowed and shall required
special approval.
Date which vehicle passed the
transportation
calibration
requirement.
Yes
Transportation
Date
Calibration
Expiry (DD/MM/YY)
Date
Vehicle Road Tax
Payment Date
Fuel Transportation
Vehicle ID Number
Fuel
Vehicle
Transportation
ID
Issue Date
Pump Built-in
Yes
Yes
Date (YYYY)
Yes
Alpha Numeric
Yes
Date (YYYY)
Yes
List
Value/Radio
Button
of
List of Value
Yes
Yes
Fuel Consumption Numeric
Rate/km
Yes
15
Validation Requirement:
o Transportation
Calibration
date cannot be postdated.
Date which the transportation
calibration requirement is expired.
Validation Requirement:
o Transportation
Calibration
expiry date cannot be
backdated or earlier than
Transportation
Calibration
Inspection Date.
Year in which the vehicle road tax is
paid.
Fuel Transportation vehicle ID
number of the truck
Year in which the Fuel Vehicle
Transportation ID is valid.
Determine whether the truck has
built-in pump or not.
List of Value/Choices for selection
should be:
o Yes
o No
Status to show whether the truck is
still in service.
List of Value shall be:
o Active
o Disposed
Fuel consumption rate of the truck.
22
Mileage
23
Insurance
Policy Date (YYYY)
Issue Date
Scheduled
Numeric
Inspection Interval
24
25
Numeric
6
7
8
9
10
11
o
o
For Prime Mover:
No. Data Field
1
Vehicle Type
5
Mileage of the truck.
Mileage
shall
be
automatically updated by
adding the delivery distance
every time a trip is assigned to
the created truck.
Yes
Date which insurance policy of the
truck is issued
Yes
o Interval of mileage in which a
truck
requires
schedule
inspection.
Autogenerated
o Mileage in which scheduled
inspection is due.
o This is to be recalculated after
scheduled maintenance is
created for the truck by
adding Scheduled Inspection
Interval to Inspection Mileage.
Next
Scheduled Numeric
Inspection Mileage
•
2
3
4
Yes
Vehicle Brand
Vehicle Model
Vehicle
Manufacturing Year
Vehicle Registration
ID
Chassis/Frame
Number
Engine Number
Vehicle Weight
Gross Weight
Vehicle Calibration
Inspection Date
Data Input Type
Mandatory
List of Value/
Yes
Radio button
Alpha Numeric
Alpha Numeric
Date (YYYY)
Yes
Yes
Yes
Alpha Numeric
Yes
Alpha Numeric
Yes
Alpha Numeric
Numeric
Numeric
Date
(DD/MM/YY)
Yes
Yes
Yes
Yes
Vehicle Calibration Date
Inspection
Expiry (DD/MM/YY)
Date
Yes
16
Data Field Description
Type of vehicle to be created in the
system.
List of Value/Choices for selection
should be:
o Tanker Truck
o Prime Mover
Brand of the vehicle to be created.
Model of the vehicle to be created.
Year
in
which
vehicle
is
manufactured.
ID number of the vehicle obtained
after being registered.
Chassis or Frame Number of the
Truck
Engine number of the truck
Weight of the truck.
Maximum gross weight of the truck.
The date in which the vehicle passed
calibration.
Validation Requirement:
o Calibration inspection date
cannot be postdated.
The date in which the vehicle
calibration is expired.
12
13
14
15
16
17
18
19
20
License
Number
Maximum
Distance
Plate Alpha Numeric
Yes
Delivery Numeric
Transportation
Calibration Date
Yes
Date
(DD/MM/YY)
Yes
Transportation
Date
Calibration
Expiry (DD/MM/YY)
Date
Vehicle Road Tax
Payment Date
Fuel Transportation
Vehicle ID Number
Fuel
Vehicle
Transportation
ID
Issue Date
Pump Built-in
Semitrailer Model
Yes
Date (YYYY)
Yes
Alpha Numeric
Yes
Date (YYYY)
Yes
List
Value/Radio
Button
of
Alpha Numeric
Yes
Yes
17
Validation Requirement:
o Calibration inspection expiry
date cannot be backdated or
earlier
than
Vehicle
Calibration Inspection Date.
License plate number of the vehicle
o The maximum distance in which
the vehicle can deliver goods to
customer.
o This links to Booking in a sense
that breaches the maximum
delivery distance shall now be
allowed and shall required
special approval.
Date which vehicle passed the
transportation
calibration
requirement.
Validation Requirement:
o Transportation
Calibration
date cannot be postdated.
Date which the transportation
calibration requirement is expired.
Validation Requirement:
o Transportation
Calibration
expiry date cannot be
backdated or earlier than
Transportation
Calibration
Inspection Date.
Year in which the vehicle road tax is
paid.
Fuel Transportation vehicle ID
number of the truck
Year in which the Fuel Vehicle
Transportation ID is valid.
Determine whether the truck has
built-in pump or not.
List of Value/Choices for selection
should be:
o Yes
o No
Model of the semitrailer to be
attached with the prime mover.
21
Semitrailer Brand
Alpha Numeric
Yes
22
Semitrailer
Plate
Number
Semitrailer
Manufacturing Year
Semitrailer
Calibration Date
Semitrailer VIN
Servicing Status
Alpha Numeric
Yes
Date (YYYY)
Yes
Date
(DD/MM/YY)
Alpha Numeric
List of Value
No
23
24
25
26
27
28
29
30
31
Yes
Yes
Fuel Consumption Numeric
Rate/km
Mileage
Numeric
Yes
Yes
Year of manufacturing of the
semitrailer.
Date of the last semitrailer
calibration.
VIN of the semitrailer.
Status to show whether the truck is
still in service.
List of Value shall be:
o Active
o Disposed
Fuel consumption rate of the truck.
Mileage of the truck.
Mileage
shall
be
automatically updated by
adding the delivery distance
every time a trip is assigned to
the created truck.
Yes
o Date which insurance policy
of the truck is issued.
Yes
Interval of mileage in which a truck
requires schedule inspection.
Autogenerated
o Mileage in which scheduled
inspection is due.
o This is to be recalculated after
scheduled maintenance is
created for the truck by
adding Scheduled Inspection
Interval to Inspection Mileage.
Insurance
Policy Date (YYYY)
Issue Date
Scheduled
Numeric
Inspection Interval
Next
Scheduled Numeric
Inspection Mileage
iii.
Brand of the semitrailer to be
attached with the prime mover.
Plate Number of the Semitrailer.
o
o
Load and Compartment:
• All truck must have its loading and compartment information so that
booking can be done in accordance to the truck loading capacity and
compartment arrangement.
• Different truck carries different load and compartment arrangement.
• Information to be captured are:
No. Data Field
1
Total Load
2
Compartment 1
Data Input Type
Numeric
Numeric
18
Mandatory Data Field Description
Yes
Maximum load of the truck.
Yes
o Maximum load of compartment
1.
o Additional line of compartment
shall be available so user could
add another compartment.
When
adding
another
compartment,
information
requirement #3 is added. There
is not limit to the number of
compartments that can be
added.
o When adding, information to be
filled is mandatory always.
o In correct addition can be
removed.
Additional compartment maximum
load.
o
3
Compartment 2, 3, n… Numeric
iv.
vii.
Yes
Vehicle’s Reference Requirement:
• Below document are required to be uploaded:
o Fuel Vehicle Transportation ID.
o Transportation Calibration Document.
o Vehicle Calibration Inspection.
o Vehicle Registration ID.
• When uploading new files or references, the new upload should override the
older version.
Other Rules:
• Vehicle, once created, cannot be deleted from the system.
• Maker/checker principle must be applied to all vehicle creation and
amendment.
• Once record is submitted, second confirmation must be sought from user to
request user to double check the record before submitting for approval or
approving the record.
• Before approving the record, approval must be able to check every point of
data input by the maker.
19
Product Section
20
1. Purpose:
BVM needs to be able to create product in the system. Product quantity needs to be
managed to ensure accuracy of booking.
2. Detail Requirement:
i.
Product Type:
• BVM has three types of product:
o DO – Diesel oil
o EA92 – Unleaded 92 gasoline
o EA95 – Unleaded 95 gasoline
ii.
Required Information: All product types should have the same fields of information
below
No. Data Field
1
Product Type
Data Input Type
List of Value
2
Physical Stock
Numeric
3
Stock Booked
Delivery
for Numeric
4
Available Stock
Numeric
5
Reserved Stock
Numeric
6
Physical
Adjustment
7
Adjustment Note
Stock Numeric
List of Value
21
Mandatory
Yes
Data Field Description
o Type of the product
o List of value:
o DO
o EA92
o EA95
Automatic
o This field shall be automatically
calculated using below formula:
Physical Stock = Beginning
Physical Stock + Physical Stock
Adjustment
o Beginning Physical Stock when
product first created is zero.
Automatic This field shall be automatically
calculated. Number should add up
automatically when booking is made.
Automatic This field shall be automatically
calculated using below formula:
Available Stock = Physical Stock - Stock
Booked for Delivery
Yes
Amount of stock reserved for
measurement prior to next stock intake.
No
Amount to be adjusted to Physical
Stock when addition or subtraction is
necessary.
Yes (When
o Reason to justify the Physical
Adjustment
Stock adjustment.
is
o List of value will be:
recorded)
o Addition for customer
o Daily morning stock
adjustment
o Private truck delivery
o Other – when other is
selected a free text input
field shall be provided
for User to type other
reason to justify stock
adjustment.
iii.
iv.
Daily Reconciliation:
• On every T (Day) +1 basis, reconciliation should be done manually where stock
controller will reconcile the daily inflow and outflow of stock. Once
reconciliation is completed, daily settlement should be performed.
• A settlement function is needed to manually perform this settlement. When
settlement function is performed, below activities shall occur:
a. Completed delivery on T (Day) will be settled with Stock Booked for
Delivery.
b. Same amount in (a) will be settled with Physical Stock so that physical
stock will reduce.
Other Rules:
• All Automatically calculated value cannot be manually adjusted.
• Maker/checker principle must be applied to stock adjustment, and
reconciliation.
• Once record is submitted, second confirmation must be sought from user to
request user to double check the record before submitting for approval or
approving the record.
• Before approving the record, approval must be able to check every point of
data input by the maker.
22
Location Section
23
1. Purpose:
BVM needs to be able to manage client’s location by categorizing the locations into cluster
of Division Code, Location Code, and Route. This classification will allow us to effectively
manage customer’s location for accurate delivery, and analytical purposes.
2. Detail Requirement:
i.
Location Division:
• Geographically, Location Division is a section in the system used to define
and manage the unique geographic location of the customer. It determines
exactly which city/province, district, and down to commune level which the
customer is located in.
• All components of the Location Division shall be defined by unique
numerical code. For example:
Example 1
City/Province District/Khan
Sangkat/Commune
Location Name Phnom Penh
7 Makara
Orussey 1
Division Code
12
1225
122504
Example 2
City/Province District/Khan
Sangkat/Commune
Location Name Siem Reap
Angkor Chum
Ta Som
Division Code
17
1745
174507
• The unique numerical code shall be created and uploaded by BVM team.
• Required Information:
No. Data Field
1
Province/City Name
Data Input Type
List of Value
2
Province/City Code
3
District/Khan
4
District/Khan Code
Numeric
5
Commune/Sangkat
List of Value
Mandatory
Yes
Data Field Description
o Name of the province/city.
o List of Value to be uploaded by
BVM and shall be able to be
updated whenever there is
official update by the Royal
Government of Cambodia.
Autogenerated System should automatically retrieve
Province/City Code, which is stored
in the DB (uploaded by BVM team).
Yes
o Name of the District/Khan.
o List of Value to be uploaded by
BVM and shall be able to be
updated whenever there is
official update by the Royal
Government of Cambodia.
Autogenerated System should automatically retrieve
District/Khan Code, which is stored in
the DB (uploaded by BVM team).
Yes
o Name of the Commune/
Sangkat.
o List of Value to be uploaded by
BVM and shall be able to be
updated whenever there is
official update by the Royal
Government of Cambodia.
Numeric
List of Value
24
6
Commune/Sangkat
Code
Numeric
7
Division Code
Numeric
Autogenerated System should automatically retrieve
Commune/Sangkat Code, which is
stored in the DB (uploaded by BVM
team).
Autogenerated Division Code shall be the same as the
autogenerated
Commune/Sangkat
Code.
•
ii.
Other Rules:
o All Automatically calculated value cannot be manually adjusted.
o Maker/checker principle must be applied to Location Division
creation.
o Once record is submitted, second confirmation must be sought
from user to request user to double check the record before
submitting for approval or approving the record.
o Before approving the record, approval must be able to check every
point of data input by the maker.
Station:
• Station refers to station of the customer, which is the location to which
goods is to be delivered.
• Station shall also be identified by unique code which is known as “Location
Code”. Location Code shall be identical to Location Code stored in BVM’s
accounting system.
• BVM already store Location Code in the existing accounting system.
Therefore, in order to speed up station creation, BVM should be able to
upload the station in bulk into Fleet Management System.
• BVM shall be able to upload Location Code to fleet management system
and able to update by creating new location code in the fleet management
system.
• Required Information:
No. Data Field
1
Station Name
2
Location Code
3
4
5
Data Input Type
Alpha Numeric
Alpha Numeric
Maximum
DO
Storage
DO Storage Type
Maximum
Storage
EA92
Mandatory
Yes
Yes
Numeric
No
Radio Button
Yes
Numeric
No
25
Data Field Description
Name of the customer station.
Location Code of the customer
station, which is identical to the
Location Code in BVM’s accounting
system.
Maximum DO storage in customer’s
station.
o Define whether the storage of
the customer is underground
or floated.
o Choices should be:
o Underground
o Floated
Maximum EA92 storage in customer’s
station.
6
EA92 Storage Type
Radio Button
Yes
7
Numeric
No
8
Maximum
EA95
Storage
EA95 Storage Type
Radio Button
Yes
9
Division Code
Numeric
Yes
10
Distance
Numeric
Yes
11
Customer ID
Alpha Numeric
Yes
12
Numeric
Yes
13
Station
Contact
Number
Station Type
List of Value
Yes
14
Premise Type
List of Value
Yes (When
End User is
selected for
Station Type)
15
Route
List of Value
No
16
Mission Allowances
Numeric
Yes
26
Define whether the storage of
the customer is underground
or floated.
o Choices should be:
o Underground
o Floated
Maximum EA95 storage in customer’s
station.
o Define whether the storage of
the customer is underground
or floated.
o Choices should be:
o Underground
o Floated
o Division code linked to the
station.
o The code is to be fetched from
Division Code listing stored
DB.
Distance between BVM warehouse to
and from the customer’s station.
o Customer ID linked to the
station.
o The ID is to be fetched from
customer ID listing stored on
the DB.
o Phone number which can
contacted to reach the station.
o Type of station created.
o List of Value shall contain
three choices:
o BVM Station
o BVM Depot
o End User
When End User is created User
needs to input Premise Type.
o Nature of the end user’s
premises.
o List of value is to be fetched
from list of End User Premise
Type listing in DB (uploaded by
BVM).
o Route linked to the station.
o The code is to be fetched from
Route listing stored DB.
o Mission Allowance to be
provided to driver during the
delivery trip to this location.
o
•
iii.
Other Rules:
o All Automatically calculated value cannot be manually adjusted.
o Maker/checker principle must be applied to station creation.
o Once record is submitted, second confirmation must be sought
from user to request user to double check the record before
submitting for approval or approving the record.
o Before approving the record, approval must be able to check every
point of data input by the maker.
Route:
• Route is a cluster of locations which goods are delivered too.
• Required Information:
No. Data Field
1
Route
Data Input Type
Alpha Numeric
2
Region
Alpha Numeric
Yes
3
Main Road
List of Value
Yes
•
Mandatory
Yes
Data Field Description
Identity of the route to be defined by
BVM.
Region covers within the geographic
boundary of the route.
o National
Road
covered
without the boundary of the
route.
o The list of value is to be
fetched from National Road
listing stored DB (uploaded by
BVM team).
Other Rules:
o All Automatically calculated value cannot be manually adjusted.
o Maker/checker principle must be applied to route creation.
o Once record is submitted, second confirmation must be sought
from user to request user to double check the record before
submitting for approval or approving the record.
o Before approving the record, approval must be able to check every
point of data input by the maker.
27
Booking Section
28
1. Purpose:
BVM needs to be able to use Fleet Management System to help manage daily delivery
booking. Booking is to be able to be created from Fleet Management system itself.
2. Detail Requirement:
i.
Required Information:
No. Data Field
1
Booking Date
Data Input Type
Date
Mandatory
Yes
2
Truck License Plate
Number
Alpha Numeric
Yes
3
Location Code
List of Value
Yes
4
Customer Name
Alpha Numeric
Autogenerated
29
Data Field Description
o Date of the delivery.
o Backdate booking is not
allowed.
o Postdate booking is allowed
for 3 days counting from
today (T) date. That means
booking is allowed for T, T+1,
and T+2.
o Truck license plate number to
deliver goods.
o Truck License Plate Number
shall be fetched from Truck
Listing in DB.
o When fetching the truck
license plate number, user
need to be able to see the
Total Load and Compartment
Arrangement of the truck
(number of compartment and
load for each compartment).
o Code defined location of the
station to which the goods
need to be delivered.
o List of value can be fetched
from Location Code listing
stored on DB.
o BVM should be able to add
additional line to fetch
another location code should
the delivery is to be made to
more than 1 location. When
adding additional location
code, the input is always
mandatory.
o Customer name shall be
automatically generated from
the location code fetched.
o In case more than one
location codes are selected,
additional customer name
shall also be automatically
5
Station Name
Alpha Numeric
Autogenerated
6
Driver Name
Alpha
Autogenerated*
7
Distance
Numeric
Autogenerated
8
Fuel for Mission
Numeric
Autogenerated*
9
Mission Allowance
Numeric
Autogenerated*
10
Allowance Type for
Pump
List of Value
Autogenerated*
11
Allowance for Pump
Numeric
Autogenerated*
30
generated from the additional
location code fetched.
Station
Name
should
be
automatically generated from the
location code fetched.
o Driver Name to be fetched
from Driver Listing.
o Driver assigned to the
selected truck should be
nominated/selected
automatically by the system.
Distance should be automatically
generated from the location code
fetched.
o Fuel required for the delivery
mission.
o Formula for calculation: Fuel
for
Mission
=
Fuel
Consumption/KM multiplied
by Distance.
Distance should be automatically
generated from the location code
fetched.
o Type of fuel to be allowed for
pump.
o List of value are EA92 and DO.
o System shall check the
vehicle selected for mission.
If the Pump Built-in for the
truck is Yes, the value to be
selected is DO. If the Pump
Built-in for the truck is No, the
value to be selected is EA92.
o Extra fuel allowance for pump
in case the offload is to be
done to floating tank.
o System shall check all
customer storage type (DO,
EA92, and EA95) and the
Allowance Type for Pump.
o In case all storages
are
underground,
Allowance for Pump
should be zero
o In case one of the
storages are floating
and product is to be
offloaded
to
that
12
13
14
15
16
Allowance for City
Detour
Secondary
Driver
Name
Extra
mission
allowance
for
Secondary Driver
Specific Offloading
Time
Specific
Number
ii.
Contact
Numeric
No
Alpha
No
Numeric
No
List of Value
No
Numeric
No
particular
tank,
formula in Rule shall
apply.
Extra fuel allowance for city detour.
Secondary driver to be assigned for
the mission.
Extra
mission
allowance
for
secondary driver.
Specific
offloading
time
required by the customer.
o List of value are:
o Day Time Offloading
o Night Time Offloading
Specific contact number that requires
driver to contact for location
information
or
offloading
confirmation.
o
Compartment Arrangement:
• When booking system must allow BVM team to arrange the compartment
arrangement. Below are the tasks that needs to be perform when
performing compartment arrangement:
o Specify which Location Code the product in the compartment is to
be delivered to.
o Specify which product the compartment is loaded with.
o Specify whether the compartment(s) is to be loaded as per its
maximum load or whether the quantity to be loaded may be less
than the maximum compartment storage.
• In case quantity to be loaded may be less than the maximum compartment
storage (Empty Compartment Delivery), dual approval between Operations
Manager and Sales Manager are to be obtained or sole approval from CEO
is to be obtained. Example of compartment arrangement is below:
Example of compartment arrangement for an 8,000 liters truck booking
Compartment Maximum
Volume
Product Location Code Station Name
Explanation
Number
Load (Liter) Load (Liter)
1
2,000
2,000
DO
BVM20.168.77 BVM Station This compartment
Moung Russey is to be delivered to
BVM Station Moung
Russey.
2
2,000
2,000
EA92
BVM20.168.77 BVM Station This compartment
Moung Russey is to be delivered to
BVM Station Moung
Russey.
31
3
4,000
iii.
iv.
3,000
DO
BVM20.168.44
BVM Station This compartment
Ponley
is to be delivered to
BVM Station Ponley.
This delivery needs
to be dual approved
by
Operations
Manager and Sales
Manager or Sole
Approval from CEO
given the Volume to
be loaded is less
than the maximum
load of the 3rd
compartment of this
truck.
Booking Rule:
• Formula for Trip determination:
o If user select night time offloading, automatically this is a 2nd trip
delivery.
o If user select day time offloading, automatically this is a 1st Trip
delivery.
o If user select night time offloading, while 2nd trip had been booked,
validate the Distance Formula. If Distance Formula validation result
is "Okay", automatically this is a 3rd trip delivery.
o If user select day time offload, while 1st trip delivery had been
booked, validate the Distance Formula. If validation result is "Okay",
automatically this is a 2nd trip delivery.
• Distance Formula:
o For 2nd Trip delivery: Distance of the 1st trip delivery does not exceed
162KM or Total distance of the 2 trips (1st and 2nd trip) added
together does not exceed 430KM.
o For 3rd Trip delivery: Distance of the 1st trip delivery does not exceed
100KM or Distance of the first two trips (1st and 2nd trip) added
together do not exceed 170KM and Total distance of 3 trips (1st, 2nd,
and 3rd trip) added together does not exceed 300KM.
Other Rules/requirement:
• All Automatically calculated value with * sign can be manually adjusted and
overridden by Fleet Team with approval from Operations Manager, as long
as it is before the delivery is started.
• Maker/checker principle must be applied to Booking/cancellation creation.
• Once record is submitted, second confirmation must be sought from user
to request user to double check the record before submitting for approval
or approving the record.
• Before approving the record, approval must be able to check every point of
data input by the maker.
32
•
•
•
•
•
When fetching truck to be selecting for booking, BVM should be able to see
a list of trucks available as of date selected and by the order of trip (i.e. 1st
Trip ,2nd Trip, or 3rd Trip).
When booking is record is submitted by maker, email notification should
be sent to approver as an alert for approval needed.
When a truck is booked pending approval, truck shall not be able to be
booked by other user unless after the current booking is not approved.
Daily truck booking listing should be available for BVM to see the list of
booked trucks.
Fleet team has the right to override the trip order after the trip is booked,
as long as it is before the delivery is started. Overridden is to be approved
by Operations Manager.
33
Maintenance Section
34
1. Purpose:
BVM needs to also manage truck maintenance/repair on Fleet Management System.
Maintenance links directly to booking given its direct influence to the availability of the
truck.
2. Detail Requirement:
i.
Maintenance:
• Required Information:
No. Data Field
Data Input Type
1
Truck License Plate
List of Value
Number
2
Request Date
Date
(DD/MM/YY)
3
Truck Broken Date
Date
(DD/MM/YY)
4
Repair Issue
List of Value
5
Maintenance
Description
Status
Free Text Input
Field
List of Value
6
Mandatory
Yes
Data Field Description
o License plate of the truck to be
put under maintenance/repair.
o List of Value should be
fetched from Truck Listing
stored on DB.
Autogenerated
o Date
of
which
maintenance/repair
is
requested.
o Request date should take the
timestamp of the day the
request is recorded. The date
shall not be changed/edited.
Yes
o Date of which the truck had
broken down.
o Validation requirement: Truck
Broken Date shall not be
greater than Request Date.
Yes
o Issue which leads to repair.
o List of value to be retrieved
from Repair Issue listing
stored in DB.
Yes
Description which documents the
reason or root cause of the repair.
Autogenerated
o Status
of
the
maintenance/repair.
o List of value should be:
o Submitted: Request is
submitted
pending
approval.
o Approved: Request is
submitted
and
approved
pending
procurement of the
repair service/required
spare parts.
o Procured:
Procurement part of
the
maintenance/repair is
35
7
Completed
8
Completion Note
Button
No
Free Text Input
Field
No
completed
pending
repair.
o Completed: Repair is
completed. Truck at
this stage should be
moved
back
to
available.
o A button to confirm that repair
is completed.
Note to describe repair action done on
the truck, and other comments from
mechanic.
•
ii.
Other Rules:
o All Automatically calculated value cannot be manually adjusted.
o Maker/checker principle must be applied to maintenance
created/amended.
o Once record is submitted, second confirmation must be sought
from user to request user to double check the record before
submitting for approval or approving the record.
o Before approving the record, approval must be able to check every
point of data input by the maker.
o When maintenance status is anything else besides “Complete”, the
truck shall be automatically be “Under Maintenance” status. When
the maintenance status is “Complete” the truck shall be back to
“Available” status – meaning available for booking.
Repair Issue:
• When creating a maintenance, Repair Issue must be specified in order to
categorize the issue that leads to the maintenance/repair.
• BVM needs to create and maintain Repair Issue for analytical purpose and
to support decision making when maintenance/repair is requested.
• Repair Issue list shall be able to be created entry by entry on fleet
management system, and update live to DB so that it can be, at the same
time, retrieve for use as input in Maintenance record.
• Required Information:
No. Data Field
1
Repair Issue
2
Data Input Type
Alpha Numeric
Mandatory
Yes
Issue Description
•
Data Field Description
Specific
Issue
involving
maintenance
Description of the repair issue.
Free Text Input
No
Field
Other Rules:
o Maker/checker principle must be applied to Repair Issue
created/amended.
o Once record is submitted, second confirmation must be sought
from user to request user to double check the record before
submitting for approval or approving the record.
36
the
o Before approving the record, approval must be able to check every
point of data input by the maker.
iii.
Repair Item:
• Repair Item is to be input when raising new Maintenance/repair.
• Required Information:
No. Data Field
1
Vendor Name
Data Input Type
Alpha Numeric
2
Repair Item
Alpha Numeric
3
4
Unit Cost
Number of Unit
Numeric
Numeric
5
Expense
Numeric
•
Mandatory
No
Data Field Description
Vendor who provides spare parts or
repair service.
Yes
Specific spare part or repair service to
be replaced and repaired to complete
the maintenance/repair.
No
Unit cost of the repair.
Yes
Number of unit(s) of spare part or
service required to complete the
maintenance/repair.
Autogenerated
o Expense of the repair.
o Formula: Expense = Unit Cost
multiplied by Number of Unit
Other Rules/Requirement:
o Repair Item might contain more than one line of item. Therefore,
user shall be able to add additional line of items when necessary.
o User should be able to extract Maintenance report in the form of
PDF so that the document can be used as reference in BVM’s
accounting system.
37
Inspection Section
38
1. Purpose:
BVM conducts vehicle inspection regularly as part of vehicle maintenance regardless of
whether the truck requires maintenance/repair or not. There are two types of maintenance
to be conducted on regular basis which are:
i.
Daily Inspection:
• Daily Inspection is conducted on daily basis before/after the delivery trip in
order to conduct the very basic check of the truck. The aim is to spot the
irregularity of the truck performance before it becomes major repair issue.
• Daily Inspection is to be conducted by the driver and supported by the
mechanic.
ii.
Scheduled Inspection:
• Scheduled Inspection is conducted by the mechanic on scheduled basis,
which is based on the actual usage of each individual truck. Similar to Daily
Inspection, Scheduled Inspection aims to spot more specific irregularity or
physical condition of the truck parts/components to determine if they need
to be replaced before it causes major repair issue.
Fleet Management System needs to be able to capture the result of the inspection for
analytical purposes.
2. Detail Requirement:
i.
Inspection:
• BVM needs to be able to build questionnaire template for both Daily
Inspection and Scheduled Inspection, and keep record of the daily
inspection result and view it in report template for analytical purpose.
• Information Required for Questionnaire Template:
No. Data Field
1
Inspection Type
Data Input Type
List of Value
Mandatory
Yes
2
Questionnaire Group
Alpha Numeric
Yes
3
Inspection Question
Alpha Numeric
Yes
4
Inspection Mileage
Numeric
Yes
• Other Rules for Questionnaire Template:
o Maker/checker principle must be applied to Questionnaire
Template created/amended.
39
Data Field Description
o Type of inspection in which
the template is to be created
for.
o List of Value will have two
choices:
o Daily Inspection
o Scheduled Inspection
Group which the questionnaire
belongs to. Group is to be built in
order to categorize the questionnaire.
Specific question (inspection item) to
be checked and answered during the
inspection within the Questionnaire
Group.
Mileage the as of the inspection date.
•
o Once record is submitted, second confirmation must be sought
from user to request user to double check the record before
submitting for approval or approving the record.
o Before approving the record, approval must be able to check every
point of data input by the maker.
o Questionnaire Template can be amended by adding additional
questions or removing any questions when necessary.
o All questions in the questionnaire template shall be a multiple
choices questions with two radio button options as answer being:
o Okay
o Issue Found – when Issue Found is checked, below shall be
available for input:
a. Mandatory Free text input field is to be added
underneath the questions for user to input the
description of the issue discovered during the
inspection on each and any of the specific
question/item.
b. Multiple input field of Repair Item(s) is to be input.
Information Required for Inspection:
No. Data Field
1
Inspection Date
Data Input Type
Date
(DD/MM/YY)
2
Inspection Type
List of Value
3
Questionnaire
Radio Button
•
Mandatory
Data Field Description
Autogenerated Date of inspection which shall be
automatically the date the record is
created.
Yes
o Type of inspection to be
performed.
o List of Value shall be:
o Daily Inspection
o Scheduled Inspection
Yes
Questionnaire to be available for user
to complete as per the selected
Inspection Type, and shall follows the
Questionnaires Template rules.
Other Rules for Inspection:
o Maker/checker principle must be applied to all Inspections record
created.
o Once record is submitted, second confirmation must be sought
from user to request user to double check the record before
submitting for approval or approving the record.
o Before approving the record, approval must be able to check every
point of data input by the maker.
o Report shall be able to be generated to see result of any specific
inspection or consolidated result of any specific truck(s).
o In case any of the questions in the questionnaires is/are checked
as “Issue Found”, system should check if the user would like to raise
Maintenance request to fix the issue immediately.
40
o
o
When user confirms as “No”, questionnaire/inspection shall
be submitted for approval.
When user confirms as “Yes”, questionnaire/inspection
shall be submitted for approval, and Maintenance screen
shall pop-up for user to complete the Maintenance request.
Repair Items listed in the questionnaire/Inspection record
shall be automatically populated in the Maintenance screen
to avoid duplication of work.
41
Dashboard Section
42
1. Purpose:
Dashboard will help BVM monitor the information efficiently. There are two dashboards
that is required to be available at Fleet Management System.
i.
CEO Dashboard: provides one of the major parts of the executive summary of the
business to the top management.
ii.
Operations Dashboard: provides the insight for Operations Manager to have an
overview of the critical parts of the daily operations.
2. Detail Requirement:
i.
CEO Dashboard:
• Data Presentation:
o Delivery Fact:
- Total volume in liter of DO delivered (1)
- Total volume in liter of EA92 delivered (2)
- Total volume in liter of EA95 delivered (3)
- Total volume in liter of delivery (1+2+3)
- Total Number of Empty Compartment Delivery case
- Total number of delivery trips
- Total distance of deliver in kilometer
- Total number of delivery location
o Truck:
- Total Number of truck on delivery/idle
- Total Number of Maintenance case
- Total Number of Inspection cases
o Delivery Mission Consumption:
- Total Fuel for Mission in liter (4)
- Total Fuel allowance for city detour in liter (5)
- Total Fuel allowance for pump as DO (6)
- Total Fuel allowance for pump as EA92 (6.1)
- Total Fuel consumption (4+5+6+6.1)
- Total Mission Allowance in KHR currency
o Stock:
- Total DO consume for Addition for Customer (7)
- Total EA92 consume for Addition for Customer (8)
- Total EA95 consume for Addition for Customer (9)
- Total Product consumption for Addition for Customer
(7+8+9)
- Total DO Daily Morning Stock Adjustment (10)
- Total EA92 Daily Morning Stock Adjustment (11)
- Total EA95 Daily Morning Stock Adjustment (12)
- Total Product Daily Morning Stock Adjustment (10+11+12)
- Total DO Private Truck Delivery (13)
- Total EA92 Private Truck Delivery (14)
- Total EA95 Private Truck Delivery (15)
- Total Private Truck Delivery (13+14+15)
- Total DO Stock Outflow (1+4+5+6+7+13) or (a)
43
ii.
- Total EA92 Stock Outflow (2+6.1+8+14) or (b)
- Total EA95 Stock Outflow (3+9+15) or (c)
- Total Stock Outflow (a+b+c)
o Booking Arrangement:
- Number of booking cancellation
- Number of booking amendment
• Filtering Options: information shall be filterable by:
o Province
o Truck License Plate Number
o Date Range
o Product
o Driver Name
o Customer Location Code
o Customer Name
o Sales Representative
Operations Dashboard:
• Data Presentation:
o Truck:
- Number of Truck on Mission
- Number of Truck returning from mission
- Number of Truck Idle
- Number of Truck Under Maintenance
- Number of Truck Under Inspection
o Maintenance:
- Number of Truck Repair Day Count
- Number of Truck Inspection Due in less than 500KM
- Number of Truck Inspection Overdue
- Number of Truck Calibration Due in 30 Days
- Number of Transportation Calibration Due in 30 Days
- Number of Truck Road Tax Expiry Due in 30 Days
- Fuel Vehicle Transportation ID Expiry Due in 30 Days
o Driver:
- Number of Driver assigned to Truck
- Number of Driver not assigned to Truck
- Number of Driver License Due in 15 Days
- Number of Driver License Expired
o Task:
- Number of Delivery Pending Confirmation
• Filtering Options:
o Date
o Date Range
o Route
44
IT Section
45
I.
High level of business requirement of User Management
Functionality
Description
User Management
⚫
⚫
Role and access
Right
⚫
⚫
⚫
⚫
Data Management
⚫
⚫
⚫
⚫
⚫
⚫
System Management
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
⚫
Fleet user management
 1- Create user group
 2- Verify user authorization
 3- System terminate user 15min stand by
 4- Moving user from HQ to WH
 Other existing functions
UDF Management
 Allow Admin User to add user define field or dynamic values
User management in the system
Admin can set any form for any role
Admin can set any button in form to access(Ex:
Edit,Delete,Save,Search,List,…)
Admin can active/deactive role
Data Backup and Recovery
Data Update
Scalability of Data Storage
Data Retention
Legislation
Data Architecture
 Data Resilience
 Data Standards and Policies
 Concurrency
 Metadata
 Data Partitioning
 Replication of Data
 Model Extensibility
 DBMS
 Transformation
Service Levels
Availability Management
Change Management
Configuration Management
Capacity Management
Performance Management
Scheduling Management
Storage Management
Business Continuity
Exception Management
Event Management
Incident and Problem Management
Software Distribution
System Support Issues
46
II.
No
1
2
3
Data fields (User fields)
Field name
Log-in Name
Display Name
Start Date
4
Expiry Date
5
Password Validity
6
Start time
7
End Time
8
9
Role
Mobile Phone1
Description
Define Log-in Name
Define Display Name
Define Start Date of this
user profile
Define Expiry Date of
this user
Define the expiry date
of the password and
the frequency
of password change.
Define the Start time for
the user.
Define the End time for
the user.
Define the user Role
Define phone number 1
10
11
Mobile Phone 2
Email
Define Phone number 2
Define email
12
Active
Format fields
YYYYMMDD MMMDD Example:
20150830 PP0615
Syntax : HH:MM
Syntax : HH:MM
xxx-xxx-xxx(x)
099-977-756
Length string@xxxx.com/com.kh
Ex:seang.chhay@bvmpetroleum.com
Define if user active.
“Yes” or “No”. If set to
“No” user could not
access the system.
13 Menu
Define the Menu that
user will use s/he log-in
14 Attempts
Indicate the number of
attempt this user has.
15 Access
Define Office ID in
All, WH,HQ
place(WH,HQ)
which this user can
access. Multiple
office separated by
Space. Type “ALL” for
all Office(WH,HQ)
16 Restrict Office
Define Office ID in
which this user could
transact to.
III. Functionality Requirement
No.
Requirement Function
Feature Description
I
User Login
1. Login
User must login so that that the system can determine
his access level.
2
Basic Flow
- The use case starts when a user indicates that
he wants to login.
47
1. The system requests the username and
password.
2. The user enters his username and
password.
3. The system verifies the username and
password against all registered users(4).
4. The system starts a login session and
displays a welcome message based on
the user's preferences.
3
Alternative Flows:
4
Business Rules
1
2
Register User
New register
Basic Flow
II
5. if username is invalid, the use case goes
back to requestion username &
password.
6. if the password is invalid the system
requests that the user re-enter the
password. When the user enters another
password the use case continues with
step 4 using the original username and
new password.
Some data and functions are restricted to certain types
of users or users with a particular access level.
a new user must register a username and password.
- The use case start when a user indicates that he
wants to register.
1. The system requests a username and
password.
2. The Admin enters a username and
password.
3. The system checks that the username
does not duplicate any existing registered
usernames.
4. The system requests a name (*), phone
and email address. Items marked by (*)
are required.
5. The Admin enters the information.
6. The system determines the user's
location and access level and stores all
user information.
7. The system executes use case Register
Preferences.
8. The system starts a login session and
displays a welcome message based on
the user's preferences.
48
Alternative Flows
-
If the username duplicates an existing username
the system displays a message and the use case
goes back to step 2.
If the user does not enter a required field, a
message is displayed and the use case repeats
step 4.
49