Online Tracking/Dispatching System (OTDS) : Software Requirement Specification

SOFTWARE REQUIREMENT SPECIFICATION
Online Tracking/Dispatching System

(OTDS)
VERSION: 1.0 REVISION DATE: 19-08-2008
Approver Name Title Signature Date
SCHOOL OF COMPUTER ENGINEERING

NANYANG TECHNOLOGICAL UNIVERSITY
SOFTWARE REQUIREMENTS
SPECIFICATION
Team Razer v1.0 19-08-2008
Contents
Online Tracking/Dispatching System
(OTDS)...........................................................................................................................................i
1. Product Description

...........................................................................................................................
1
1.1 Product Vision

..............................................................................................................................
1
1.2 Business Requirements

................................................................................................................
1
1.3 Stakeholders and Users

................................................................................................................

1
1.4 Project Scope

................................................................................................................................
1
1.5 Assumptions

.................................................................................................................................
2
1.6 Constraints

...................................................................................................................................
2
2. Functional Requirements

...................................................................................................................
3
2.1 Fleet Controller

............................................................................................................................
3
2.2 Fleet Drivers

.................................................................................................................................
3
2.3 Managers

......................................................................................................................................
3
2.4IT Manager

....................................................................................................................................
3
3. Data Requirements

.............................................................................................................................
4
4. NonFunctional Requirements

...........................................................................................................

6
5. Interface Requirements

......................................................................................................................
7
5.1 User Interfaces

.............................................................................................................................
7
5.2 Hardware Interfaces

.....................................................................................................................
9
5.3 Software Interfaces

.....................................................................................................................
11
11
..............................................................................................................................................................
6. Use Case Model

...............................................................................................................................
12
6.1 Use Case Diagram

......................................................................................................................
12
6.2 Use Case Description

.................................................................................................................

13
7. Glossary

...........................................................................................................................................
24
8. References

........................................................................................................................................
25
9. Revision History

..............................................................................................................................
26
i
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
1. Product Description
1.1 Product Vision

Mission Statement
Malcolm Global Logistic (MGL) is committed to provide an outstanding customer
experience by observing the 3R: Reliable, Responsible and Rapid. MGL is also passionate
about sustainably connecting people and places and improving the quality of life around the
world.
Organizational Objectives
MGL is committed to be a professional and leading logistical company that provides a swift
and steadfast logistical service by excellent planning, coordinating and fast deliveries.
1.2 Business Requirements

The new system should assist the fleet controller in planning and allocating new order
deliveries to a fleet of vehicles. The system will allow the fleet controller to know the
location and priority of the deliveries to be made that working day. The planning of the
deliveries includes the function that allows the fleet controller in allocating deliveries to the
drivers and prioritizes each delivery in real time. This system must also allow the fleet
controller to be able to view in real time the status of each delivery as well as the location of
each vehicle. From the system the fleet drivers will be able to view the deliveries and their
respective location that they have to make.
Overall, this system will help the organization to be more efficient in the planning stage of
the deliveries and at the same time to meet the constant changing demand of customers in
real time.
1.3 Stakeholders and Users

Some of the stakeholder includes the customer who commissioned this project, fleet
controller, drivers, IT and Sales managers. The users who might use this software heavily
will be the fleet controller, who will plan and track the deliveries. The driver of the fleet of
vehicles will also use this system as they need to check their delivery prority according to the
fleet controller as well as update the delivery status through the system in real time.
1.4 Project Scope

The system will be a web based application that all the functionality of the system will be
incorporated in it. The system will be driven by Java Server Page (JSP) for the web based
User Interface (UI) as well as the functionalities of the system. Connection to the database
will be driven by MySQL. This system will allow the fleet controller to plan the deliveries by
allocating driver to each vehicle with destination of each delivery listed and marked out in
the portable devices that each driver has. The system will also allow the fleet controller to
change the prority of each deliveries and the system will update the driver via the portable
device. GPS that is on each vehicle will update the OTDS database at a regular interval of 5
minutes to give the coordinates of the vehicle to OTDS, OTDS will then translate the GPS
coordinate onto a map on the system for fleet controller viewing.
1
Team Razer v1.0 19-08-2008
This system will not be involved in the planning of the inventory of the deliveries. A
Customer Service System will handle any new request for deliveries and will update the
OTDS with any new deliveries.
1.5 Assumptions
1) It is assumed that each driver will have at least a vehicle to drive.
2) All vehicles will have all the deliveries pre-loaded into each respective vehicle and
drivers may be assigned a different vehicle each time.
3) That all deliveries location is within Singapore mainland. All destinations are
reachable by the vehicle.
4) All drivers will have 1 device that allows them to access the system, e.g. PDA
phone, ultra-portable computer.
5) In order for drivers to access the system, it is assumed that the whole of Singapore
mainland is covered by wireless network that allowed internet access.
6) All requests of deliveries will only be handled in the morning for each day.
1.6 Constraints
A constraint is a factor that limits developers.
1) Almost all processing must be done server side, because the system will often be
accessed with very low power devices that could not handle a processing load.
2
Team Razer v1.0 19-08-2008
2. Functional Requirements
2.1 Fleet Controller

2.1.1 Fleet Controller must be able to change the sequence and priority of the deliveries
for each driver.
2.1.2 Fleet Controller must be view the status of the remaining deliveries for each vehicle.
2.1.3 Fleet Controller should be able to allocate drivers to deliveries based on
geographical constraint.
2.1.4 Fleet Controller should be able to view the stock/goods that are remaining on each
vehicle.
2.1.5 Fleet Controller should be able to view the location of each vehicle in real time.
2.2 Fleet Drivers

2.2.1 Fleet Driver must be able to check the location of the deliveries that he/she is
assigned to.
2.2.2 Fleet Driver must be change the status of each delivery.
2.2.3 Fleet Driver must be able to view the remaining inventory in the vehicle.
2.3 Managers
2.3.1 Managers must be able to view the delivery progress of the current and previous
days, months and years.
2.4 IT Manager
2.4.1 IT Manager must be able to create a login account for new drivers or fleet
controllers.
2.4.2 IT Manager will be able to sent lost password or login name to user’s email account.
2.4.3 IT Manager will be able to delete a user account.
3
Team Razer v1.0 19-08-2008
3. Data Requirements
Some of the data requirement that we need from the MGL includes:
1) MGL’s customer data structure. E.g. how does MGL structure their customers?
What are the required fields for customers?
2) Delivery data structure. How do MGL sort the deliveries? What are the
required fields for each data entry of delivery?
3) Employee data structure. The data fields that are required for each employee,
the different type of employee.
4) Vehicles that are in the fleets. E.g. The number plate and size of the vehicle.
Fig 3.1 EntityRelation Diagram (Draft)
4
Team Razer v1.0 19-08-2008
Fig 3.2 Class diagram
5
Team Razer v1.0 19-08-2008
4. Non-Functional Requirements
4.1 The system need to be able to update the information whenever there is a change in
the database or locations of the vehicles.
4.2 Graphical User Interface (GUI) must meet all functional requirements.
4.3 GUI must be user friendly and content must be simple.
4.4 System must be easy to maintain.
4.5 The system must be tested and be ready for use during implementation phase.
4.6 The system must be highly reliable and not crash prone.
6
Team Razer v1.0 19-08-2008
5. Interface Requirements
5.1 User Interfaces
5.1.1 Screen Design must be simple and easy to comprehend.
Figure 5.1 Login page
5.1.2 Text and images should not of reasonable size. Simple designs should be used to
prevent unnecessary clattering and thus rendering it more user-friendly.
Figure 5.2 Registration Page
7
Team Razer v1.0 19-08-2008
5.1.3 Instructions displayed on screen for users to follow should be short yet allow users to
fully understand what they should do without additional help.
Figure 5.3 After logging in, the user can simply select the function he need from the software from a dropdown
menu.
5.1.4 Certain confidential information should only be made accessible (displayed

on screen) to rightful authorities.
Figure 5.4 Only after the fleet controller logs in, then can he access information such as the list of drivers/trucks
under the company.
8
Team Razer v1.0 19-08-2008
Figure 5.5 Map showing locations of trucks and destination.
5.2 Hardware Interfaces
9
Team Razer v1.0 19-08-2008
5.2.1 Each Driver has a portable laptop which links to the system.
5.2.2 GPS system will be mounted on each vehicle.
5.2.3 Fleet Controller and Manager has a laptop each which links to the system.
10
Team Razer v1.0 19-08-2008
5.3 Software Interfaces
5.2.1 Mobile Broadband will allow Drivers to log in to razer system.

5.2.2 GPS will allow Drivers to view their exact location.
5.2.3 GPS will allow Drivers to view their route to the next stated location.
5.2.4 GPS will allow Fleet Controller to view all Drivers’ location.
5.2.5 GPS will allow Fleet Controller to plan out Drivers’ routes for delivery.
11
Team Razer v1.0 19-08-2008
6. Use Case Model
6.1 Use Case Diagram
12
Team Razer v1.0 19-08-2008
6.2 Use Case Description
Use Case ID: OTDS1
Use Case Name: Update Database
Created By: Jason Sim Last Updated By: Jason Sim
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
Actors: Customer System
Description: The customer system interacts with OTDS when customers make a order
of new delivery.
Trigger: Customer places a new delivery order to the company.
Preconditions:
Postconditions: 1. OTDS database will contain information of the new delivery
Normal Flow: 1. Customer places an order of delivery by calling the company.
2. Customer Service Officer will use the Customer System to record the
information like location, date, time and the goods to be delivered.
3. Customer System access OTDS database and update information of a
new delivery.
Alternative Flows: 1.1 Customer places an order through the Online Order Placement
System. OOPS will update the Customer System
Exceptions:
Includes:
Priority:
Frequency of Use:
Business Rules:
Special Requirements:
Assumptions:
Notes and Issues:
13
Team Razer v1.0 19-08-2008
Use Case ID: OTDS2
Use Case Name: Manage login accounts
Created By: Amy Last Updated By: Amy
Actors: IT MANGER
Description: This feature allows the IT MANGER to create new account, modify and
delete existing accounts.
Trigger: IT MANGER accesses this feature voluntarily through Login User
Interface
Preconditions: 1. IT MANGER has to verify himself by logging in using his assigned
Login ID
Postconditions: 1. System will be updated correctly according to the specified
instructions.
Normal Flow: 1.1 IT MANGER clicks on “Create New Account”.
1.2 System will respond by showing the “Create New Account” form
on the User Interface.
1.3 IT MANGER will type in the information of the new driver and
submit the form.
1.4 System will validate all information fields.
1.5 The new account will be added into the system.
1.6 System will prompt the IT MANAGER that the account is being
added.
1.7 IT MANAGER will exit the User Interface.
1.1 IT Manager clicks on “Modify Existing Account”.
1.2 System will respond by showing the “Modify Existing Account”
form on the User Interface.
1.3 IT MANAGER will update the required information.
1.4 System will validate the updated fields.
1.5 The new information will be updated into the system.
1.6 System will prompt the IT MANAGER that the account is being
added.
1.7 IT MANAGER will exit the User Interface.
3.1 IT MANAGER clicks on “Delete Existing Account”.
3.2 System will respond by showing the “Delete Existing Account”
form on the User Interface.
3.3 IT MANAGER will delete the selected driver’s information.
3.4 System will prompt the IT MANAGER for confirmation.
IT MANAGER will exit the User Interface.
Alternative Flows: 3.4.1 If IT MANAGER clicks “Yes”, the selected information will be
removed from the system.
14
Team Razer v1.0 19-08-2008
3.4.2 Else the selected information will not be removed and it will
return to the User Interface.
Exceptions: If there are empty fields or invalid information, system will alert IT
MANAGER to refill again.
IT MANAGER will fill up the required fields and resubmit it.
2.4.1 If there are empty fields or invalid information, system will alert
IT MANAGER to refill again.
2.4.2 IT MANAGER will fill up the required fields and resubmit it.
Includes:
Priority: High
Frequency of Use: 15 times per day
Business Rules:
Assumptions:
Notes and Issues:
Use Case ID: OTDS3
Use Case Name: Update GPS Coordinate
Created By: Jason Sim Last Updated By: Jason Sim
Actors: Global Positioning Satellite System
Description: The GPS System on each of the vehicle will access OTDS database and
update the coordinates of each vehicle.
Trigger: The GPS will update the OTDS database at regular interval
Preconditions: 1. The vehicle set off from the company to make its deliveries
Postconditions: 1. The OTDS database will have the coordinates of the vehicle.
Normal Flow: 1. Driver start engine of vehicle.
2. GPS automatically sent coordinates to OTDS.
3. OTDS will store coordinates in database.
Alternative Flows: 2.1 GPS will update coordinates of that particular vehicle to the OTDS at
regular interval.
Exceptions: 1. GPS for the vehicle is down. OTDS will not be updated with the latest
coordinates of vehicle
Includes:
15
Team Razer v1.0 19-08-2008
Priority:
Frequency of Use: GPS system will update the OTDS at a regular interval of 5 minutes.
Business Rules:
Special Requirements: GPS to be mounted on all vehicles.
Assumptions:
Notes and Issues:
16
Team Razer v1.0 19-08-2008
Use Case ID: OTDS4
Use Case Name: Track Delivery Status
Created By: Huiling Last Updated By: Huiling
Actors: Fleet Controller
Description: The fleet controller to track the order status of each delivery, whether it is
done or not done.
Trigger: When fleet controller click on a “Track Delivery Status” button.
Preconditions: 1. The fleet controller login into the system.
Postconditions: 2. A list of orders with their status will be displayed.
Normal Flow: 1. Fleet Controller sends the request to the system for order status.
2. System sends back all the status of orders in that week.
3. Fleet Controller sends request to system to find orders of that day.
4. System filters the orders and display orders of that day.
5. Fleet Controller sends request to system to sort orders in done/not
done.
6. System sorts the orders and displays them out.
Alternative Flows: 1. Fleet Controller sends the request to the system for order of that day,
while orders are grouped in done/undone.
2. System shows all the order status in sorted list for that day.
Exceptions: a. The database is lost due to unexpected situations; another use case
named “BackupServer” will be executed.
b. Error messages will also be displayed when the system could not find
any order that the actor is finding.
Includes:
Priority: High
Frequency of Use: 2 times per minute
Business Rules:
Special Requirements: The time displaying the results must be fast.
Assumptions: We assumed that there will be orders in the database.
Notes and Issues:
17
Team Razer v1.0 19-08-2008
Use Case ID: OTDS5
Use Case Name: Edit Delivery
Created By: Soon Lai Last Updated By: Soon Lai
Actors: Fleet Controller, Manager
Description: The fleet controller and manager can change the sequence in the order according
to the order priority.
Trigger: The “Edit Delivery” button is clicked.
Preconditions: 1. The database is updated and orders are allocated to the drivers.
2. The undelivered orders will only be displayed.
Postconditions: 1. The drivers are notified of the updated daily orders for the delivery.
Normal Flow: 1. Fleet Controller/Manager requests the system for the allocated order data for
each driver.
2. System sends back the list of drivers which are allocated with orders.
3. Fleet Controller/Manager selects the driver name and requests the display of
the allocated orders for the selected driver.
4. System displays the allocated orders data for the selected driver.
5. Fleet Controller/Manager changes the delivery sequence and sends back the
updated data to the system.
6. System updates the database and notifies Fleet Controller/Manager of the
changes.
Alternative Flows:
Exceptions: 1. In the event that the order is delivered while Actors request the system to
update the order sequence, the system will rejects the update and send back
an error message.
2. When the system is not functioning, the “backupserver” will take over.
Includes:
Priority: High
Frequency of Use: 3 times per hour
Business Rules:
Assumptions:
Notes and Issues:
18
Team Razer v1.0 19-08-2008
Use Case ID: OTDS6
Use Case Name: View Map
Created By: Tim Trefren Last Updated By: Tim Trefren
Actors: Fleet Controller, Drivers
Description: The Fleet Controller needs to be able to view the location of each driver in
real time. The GPS data from the database will be displayed on the map,
with a point for each truck.
Trigger: Fleet Controller opens the map page of the application
Preconditions: 1. User must be logged in to the Fleet Controller account
2. There must be GPS data coming from the trucks (it must be during
working hours and the trucks must be delivering goods)
Postconditions: 1. System information is unchanged. This use case only displays
information, it does not change it.
Normal Flow: 1. Fleet Controller/Drivers opens map page of application
2. System displays map of Singapore.
3. System retrieves most recent driver GPS data from database
4. System retrieves order status and location from database.
5. System displays updated drivers and order location on map.
Alternative Flows: 1.1 Fleet Controller/Drivers leaves map page open
2.1 System retrieves GPS data once per minute and refreshes map with
new locations
Exceptions: 1. If no data is received from a truck during working hours, a
notification pops up. This allows the Fleet Controller to recognize
faulty GPS hardware or slacking drivers.
Includes:
Priority:
Frequency of Use: This functionality will likely be used for the entire day, with a computer
monitor devoted to the map page. So, the use case will be invoked once
per minute for the whole work day.
Business Rules:
Assumptions:
Notes and Issues:
19
Team Razer v1.0 19-08-2008
Use Case ID: OTDS7
Use Case Name: Construct Delivery
Description: It is to allocate and group the orders to the vehicles according to the
delivery location.
Trigger: The “Construct Delivery” button is clicked
Preconditions: 1. Orders have not been allocated to the vehicles.
2. Orders are to be delivered on the same day.
Postconditions: 1. Drivers are notified of the updated delivery list and its location upon
login into the system.
Normal Flow: 1. Fleet Controller/Manager request System for the unallocated orders.
2. System displayed unallocated orders for the current day.
3. Fleet Controller/Manager allocates the orders to the vehicles.
4. System updates the grouped orders into the database.
Alternative Flows: 1. System displayed empty volume of unallocated orders for the current
day.
2. System retrieves the allocated orders data for each vehicle.
Exceptions: 1. When the system is not functioning, the “backupserver” will take
over.
Includes:
Priority: High
Frequency of Use: It is dependable on the numbers of new orders for the current date and the
numbers of available vehicles to load up the orders.
Business Rules:
Assumptions: There is always new orders at the start of the current date
Notes and Issues:
20
Team Razer v1.0 19-08-2008
Use Case ID: OTDS9
Use Case Name: View Delivery List
Created By: Huiling Last Updated By: Huiling
Actors: Driver
Description: Driver wants to view the list of deliveries for that day.
Trigger: When the fleet driver login to the system.
Preconditions: 1. When goods are loaded to the drivers’ vehicles.
Postconditions: 1. A list of deliveries for that driver that day will be displayed.
Normal Flow: 1. Driver sends a request to login into system
2. System will return reply by giving system message ”Login successful”
and display the list of deliveries for that day.
Alternative Flows:
Exceptions: 1.The database is lost due to unexpected situations; another use case
named “BackupServer” will be executed.
2.Error messages will also be displayed when driver type the password
Includes:
Priority: High
Frequency of Use: The list of deliveries displayed will be refreshed every 2 times per second.
Business Rules:
Special Requirements: The refreshing of the list of deliveries must be as frequent as possible.
Assumptions: We assumed that there will be at least one delivery for each driver.
Notes and Issues:
21
Team Razer v1.0 19-08-2008
Use Case ID: OTDS10
Use Case Name: Generate Reports
Description: It is to generate reports as such that the fleet controller can only select
daily report for the order delivery and the manager to select daily, past,
weekly, monthly or yearly report on the order delivery.
Trigger: “Generate Reports” button is being clicked
Preconditions: 1. Fleet Controller/Manager have login into the system
Postconditions:
Normal Flow: 1. Fleet Controller/Manager requests System to generate report on the
order delivery.
2. System determines the types
3. System prompts Actor for the types of status for the order delivery.
4. Fleet Controller/Manager sends back his/her selection to System.
5. System displays the report according to the selection.
Alternative Flows:
Exceptions: When the system is not functioning, the “backupserver” will take over.
Includes:
Priority: Low
Frequency of Use: 2 times per day
Business Rules:
Assumptions:
Notes and Issues:
22
Team Razer v1.0 19-08-2008
Use Case ID: OTDS11
Use Case Name: Backup Data
Actors: IT Manager, BackupServer
Description: It is to allow the IT manager to manually backup the system to
BackupServer or automatically backup by BackupServer.
Trigger: “Backup” button is being clicked
Preconditions: 1. IT Manager have login into system.
2. BackupServer is activated.
Postconditions:
Normal Flow: 1. IT Manager request System to backup the data.
2. BackupServer backups the data.
3. BackupServer displays a “completion” message for the backup.
4. IT Manager receive the message.
Alternative Flows:
Exceptions: When the system is not functioning, the “backupserver” will take over.
Includes:
Priority: Low
Frequency of Use: 2 times per week
Business Rules:
Assumptions:
Notes and Issues:
23
7. Glossary
Define all terms and acronyms required to interpret the SRS properly. This is the
(problem) domain dictionary.
Acronyms Stand for Description

MGL Malcolm Global Logistic (Assumption) The logistical company that
commissioned this project.
OTDS Online Tracking/Delivery The name of the system that the above mentioned
System company has commissioned.
GPS Global Postitioning A transmitting device that aid user to navigation
Satellite and tracking.
JSP Java Server Page A Java technology that allows software
developers to dynamically generate HTML, XML
or other types of documents in response to a Web
client request.
UI User Interface Means where user can communicate with a
particular system. Particularly for input and
output.
PDA Personal Digital Assistant A handheld computer also known as small or
palmtop computers.
OOPS Online Order Placing (Assumption) An online system that MGL have
System for customer to place an order through the
internet.
24
SPECIFICATION
Team Razer v1.0 19-08-2008
8. References
Provide a list of all documents and other sources of information referenced in the
SRS and utilized in developing the SRS. Include for each the document number,
title, date and author.
Document No. Document Title Date Author
25
SPECIFICATION
Team Razer v1.0 19-08-2008
9. Revision History
Identify changes to the SRS.
Version Date Name Description
26

Online Tracking/Dispatching System (OTDS) : Software Requirement Specification

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Tracking/Dispatching System (OTDS) : Software Requirement Specification

Uploaded by

Copyright:

Available Formats

SOFTWARE REQUIREMENT SPECIFICATION

Online Tracking/Dispatching System

VERSION: 1.0 REVISION DATE: 19-08-2008

Approver Name Title Signature Date

SCHOOL OF COMPUTER ENGINEERING

1.1 Product Vision

1.2 Business Requirements

1.3 Stakeholders and Users

1.4 Project Scope

2.1 Fleet Controller

2.2 Fleet Drivers

4.3 GUI must be user friendly and content must be simple.

4.4 System must be easy to maintain.

5.1 User Interfaces

5.1.1 Screen Design must be simple and easy to comprehend.

Figure 5.1 Login page

Figure 5.2 Registration Page

5.1.4 Certain confidential information should only be made accessible (displayed

Figure 5.5 Map showing locations of trucks and destination.

5.2 Hardware Interfaces

5.3 Software Interfaces

5.2.1 Mobile Broadband will allow Drivers to log in to razer system.

6. Use Case Model

6.1 Use Case Diagram

6.2 Use Case Description

Acronyms Stand for Description

Document No. Document Title Date Author

Identify changes to the SRS.

Version Date Name Description

You might also like