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
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
SOFTWARE REQUIREMENTS SPECIFICATION
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
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
2. Functional Requirements
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
SOFTWARE REQUIREMENTS SPECIFICATION
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
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
Fig 3.2 Class diagram
5
SOFTWARE REQUIREMENTS SPECIFICATION
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.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
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
5. Interface Requirements
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.
7
SOFTWARE REQUIREMENTS SPECIFICATION
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.
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
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
9
SOFTWARE REQUIREMENTS SPECIFICATION
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
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
11
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
12
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
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
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
Use Case ID: OTDS2
Use Case Name: Manage login accounts
Created By: Amy Last Updated By: Amy
Date Created: 27 August 2008 Date Last Updated: 27 August 208
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
SOFTWARE REQUIREMENTS SPECIFICATION
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:
Special Requirements:
Assumptions:
Notes and Issues:
Use Case ID: OTDS3
Use Case Name: Update GPS Coordinate
Created By: Jason Sim Last Updated By: Jason Sim
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
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
SOFTWARE REQUIREMENTS SPECIFICATION
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
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
Use Case ID: OTDS4
Use Case Name: Track Delivery Status
Created By: Huiling Last Updated By: Huiling
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
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
SOFTWARE REQUIREMENTS SPECIFICATION
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
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
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:
Special Requirements:
Assumptions:
Notes and Issues:
18
SOFTWARE REQUIREMENTS SPECIFICATION
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
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
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:
Special Requirements:
Assumptions:
Notes and Issues:
19
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
Use Case ID: OTDS7
Use Case Name: Construct Delivery
Created By: Soon Lai Last Updated By: Soon Lai
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
Actors: Fleet Controller, Manager
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:
Special Requirements:
Assumptions: There is always new orders at the start of the current date
Notes and Issues:
20
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
Use Case ID: OTDS9
Use Case Name: View Delivery List
Created By: Huiling Last Updated By: Huiling
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
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
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
Use Case ID: OTDS10
Use Case Name: Generate Reports
Created By: Soon Lai Last Updated By: Soon Lai
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
Actors: Fleet Controller, Manager
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:
Special Requirements:
Assumptions:
Notes and Issues:
22
SOFTWARE REQUIREMENTS SPECIFICATION
Team Razer v1.0 19-08-2008
Use Case ID: OTDS11
Use Case Name: Backup Data
Created By: Soon Lai Last Updated By: Soon Lai
Date Created: 27 August 2008 Date Last Updated: 27 August 2008
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:
Special Requirements:
Assumptions:
Notes and Issues:
23
7. Glossary
Define all terms and acronyms required to interpret the SRS properly. This is the
(problem) domain dictionary.
24
SOFTWARE REQUIREMENTS
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.
25
SOFTWARE REQUIREMENTS
SPECIFICATION
Team Razer v1.0 19-08-2008
9. Revision History
26