COMSATS University Islamabad,

COMSATS Road, off GT Road, Sahiwal, Pakistan

SOFTWARE REQUIREMENTS
SPECIFICATION
(SRS DOCUMENT)

for

VEHICLEWAVE
Version 1.0

By
Student Name 1 CIIT/SP09-BCS-xxx/SWL
Student Name 2 CIIT/SP09-BCS-xxx/SWL
Student Name 3 CIIT/SP09-BCS-xxx/SWL

Supervisor
Mr. Muhammad
Co-Supervisor
Supervisor Name

Bachelor of Science in Computer Science (2020-2024)

 Revision History
Name Date Reason for changes Version

i
 Application Evaluation History
Comments (by committee) Action Taken
*Include the ones given at scope time both in the doc and
presentation

Supervised by

Mr. Muhammad Umar

Signature __________________

ii
 Table of Contents

1. Introduction.........................................................................................................................1
1.1 Purpose........................................................................................................................1
1.2 Scope........................................................................................................................... 1
2. Overall description..............................................................................................................1
2.1 Product perspective.....................................................................................................1
2.2 Operating Environment............................................................................................... 2
2.3 Design and Implementation Constraints......................................................................2
2.3.1 User Interface.............................................................................................................. 2
2.3.2 Data Management.......................................................................................................2
2.3.3 Security........................................................................................................................ 2
2.3.4 Integration................................................................................................................... 2
2.3.5 Compatibility................................................................................................................2
2.3.6 Cost.............................................................................................................................. 2
2.3.7 Time-to-market............................................................................................................3
3. Requirement Identifying Technique....................................................................................3
3.1 Use Case Diagrams.......................................................................................................3
3.1.1 Use Case for Customers...............................................................................................3
3.2 Use Case Description................................................................................................... 4
4. Functional Requirements.................................................................................................. 10
4.1 Customer’s Module....................................................................................................10
4.2 Admin modules..........................................................................................................11
4.3 Driver’s Module......................................................................................................... 11
This module will be made for the drivers specially..................................................................11
5. Non-functional requirement..............................................................................................11
5.1 Usability..................................................................................................................... 11
5.2 Performance.............................................................................................................. 11
5.3 Security...................................................................................................................... 11
5.4 Portability.................................................................................................................. 11
5.5 Reliability................................................................................................................... 11
References................................................................................................................................... 12

iii
 List of Figures
Figure 1 Use case between customer and admin.......................................................................3

iv
 List of Tables
Table 1. Login............................................................................................................................4
Table 2 Customer Registration...................................................................................................4
Table 3 View Routes..................................................................................................................5
Table 4 Enter Details..................................................................................................................6
Table 5 Check Prices..................................................................................................................6
Table 6 Request For Booking....................................................................................................6
Table 7 Sign Agreement.............................................................................................................7
Table 8 Payment.........................................................................................................................7
Table 9 Cancel Booking.............................................................................................................8
Table 10 Tracking......................................................................................................................8
Table 11 Manage Details...........................................................................................................9
Table 12 Manage Shipments......................................................................................................9
Table 13 Manage Drivers.........................................................................................................10

v
1. Introduction
The technology is changing day by day and a lot of facilities are being made for us. Almost
every field in the world is covered by new technologies. A lot of software has been made for
humans. In US, there are a lot of facilities have been made for the people who need to ship
their vehicles. Because it was difficult to negotiate with the driver or find a driver, there was a
lot of issues between the drivers and the customers. So, the government introduced a broker
between them but again there was a lot of issues between them. A lot of broker companies
have been registered and they all approach the customer by text, email or phone call who put
his/her details on webpage. This was so frustrating because there was no proper pricing
system or a tracking system. A lot of scams have been claimed. So, we notice that there is a
need for software that provides a proper booking system of vehicles for customers.
1.1 Purpose
The purpose of this project is to reduce the rush procedure of shipping a vehicle and convert
it into simple and safe method. We will provide a platform where the customers can get the
driver for their vehicles. We will add some tracking features from which the customer can
safely monitor his vehicle. So, our software will work like a broker it finalizes the price for
the customer and help to track and deliver his vehicle. This would be a great addition in the
trucking industry. The main aim of this software is to provide a major platform for auto
transport and carrier companies. The customer can book their shipment and can get the driver
for his vehicle. In future we also aim to add the driver side through which the driver can
check the load board and select his route loads, then he can book these loads for pick up.
Once the driver confirms the information will share between the driver and the customer.
They will also chat with each other.
1.2 Scope
Our application works for customer to ensure him/her that their vehicles are being transport
safely. It will get all personal information automatically when a customer gets registered and
create shipment box depending upon distance. It also automatically updates pricing according
to the load and miles. It also notifies the driver’s current location to the customer. It also
facilitates the customer and truck driver to contact directly by providing a chat box. The Auto
Shipment System focuses specifically on providing a streamlined and secure vehicle
transportation service within the United States. The system aims to simplify the process of
shipping vehicles and ensure their safe and timely delivery from one state to another.

2. Overall description
An auto shipment and dispatch mobile application is a technological solution designed to
streamline the process of transporting vehicles from one location to another. It serves as a
powerful tool for automating and managing the entire auto shipment and dispatch process,
providing convenience for customers.
2.1 Product perspective
The product is an application-based system implementing a client-to-server model. Its admin
is web-based application. The system provides a strong mechanism for customer to book their
vehicle for shipments online and the admin will monitor the overall work. This product will
be responsive and easy to use. It will develop on flutter which makes this

1
application compatible for android. This application has tracking option as well as feedback
option. To ensure the highest level of service quality, the Auto Shipment System adheres to
strict safety standards.
2.2 Operating Environment
Most of our application runs on the mobile platform on android that handle both static and
dynamic applications. The admin is Web based application which will run on Windows. We
will prefer this application for android as this a flutter-based application. This application
needs few spaces of RAM, hardware and processor. This application will work on android.
On the software side, the application would be built using Flutter, a UI toolkit for creating
natively compiled applications for mobile, web, and desktop. It would also require an
operating system like Android to run on mobile devices.
On the Hardware side, there must be a system hardware that can support our software
requirements. We will use Android mobile hardware to use our project application.
2.3 Design and Implementation Constraints
This system is developed by Flutter framework which is highly secure and compatible. The
admin is web based and will be developed on Django platform. The database is used Firebase
server. All data will be stored in an admin server. It will use authentication to access the
application main areas like the customer and admin side.
Some of the common design and implementation constraints that could impact the
development of the application include:
2.3.1 User Interface
The user interface design must be intuitive and easy to use for dispatchers. The UI must also
be optimized for different screen sizes and devices.
2.3.2 Data Management
The application must be capable of handling large volumes of data, including real-time
tracking of vehicles, delivery status updates, and driver information. The data management
system must be efficient, reliable, and scalable.
2.3.3 Security
The application must be designed with security in mind to protect sensitive information such
as customer data, driver details, and shipment information. The application should be
protected against potential security breaches, including unauthorized access to data, hacking,
and malware attacks.
2.3.4 Integration
The application must integrate seamlessly with third-party services such as Google Maps
API, Firebase Realtime Database, and Twilio API for messaging. The integration should be
easy to implement and must provide reliable data transfer.
2.3.5 Compatibility
The application must be compatible with different operating systems, including Android, and
must work well with various device specifications, such as screen size, processor speed, and
memory.
2.3.6 Cost
The development and maintenance costs must be considered during the design and
implementation of the application.

2
2.3.7 Time-to-market
The development and deployment of the application must be completed within the targeted
time frame to meet the business goals and expectations. The development team must ensure
that the project timeline is achievable while also meeting the quality standards.

3. Requirement Identifying Technique

The requirement identifying technique for creating a use case diagram for an auto shipment
and dispatch system involves stakeholder analysis, use case identification, use case
description, use case relationships, and use case diagram construction.
3.1 Use Case Diagrams
Here we create a visual representation of the use cases and their relationships using a use case
diagram.
3.1.1 Use Case for Customers

Figure 1 Use case between customer and admin

3
 3.2 Use Case Description
The table below indicates a comprehensive use case template filled in with an example
drawn from the Online vehicle shipping management system.
Table 1. Login

Use case id 01
Use case name Login
Actors Admi
n User
Description A user of the System logs into the System.
Trigger User requests to log in.
Pre-condition The user has an account.
Postcondition The actor is now logged into the system.
Normal flow This use case starts when an actor wants to login into the system.
The system requests that the actor enter e-mail/phone no. and
password.
The actor enters-mail/phone number and password.
The system validates the entered e-mail/phone no. and password and
login into the system.
Alternative flow For example, a Valid e-mail/Phone number or an Invalid Password
If in the basic flow the system cannot find the valid e-mail or the
password is invalid, an error message is displayed.
Exceptions Incorrect credentials.
Request to re-enter the login details.

Business rules The system must be connected to the network.

Table 2 Get Registration

Use case id 02

Use case name Get Registration

Actors  Customer
 Admin
Description A user of the System creates an account.

Trigger Select the register link

Pre-condition When the user doesn’t have an account to log in to the system.

Postcondition The user’s details are stored in the database.

4
Normal flow This use case starts when the user is not logged in to the system and
goes to the login page.
The system prompts the user to send an e-mail and password or register
a new account.
User selects the registration option.
The system displays the signup page that allows users to fill in their
username/email address, first and last name, and password.
The user enters their information.
System verifies information and creates an account.
Alternative flow Cancel Registration
The users select the cancel option.
The system returns the user to the home page without the user being
logged in and any information entered has been erased.
Invalid Information Entered
Users can enter information and submit it.
System displays a message to correct invalid information.
The user re-enters the information.
Exceptions If an existing user exists, then a "User already exists" message is
displayed.
If information is missing "Insufficient Information" message is
displayed.
Business rules Active internet access is available.
Table 3 View routes.

Use case id 03
Use case name View routes
Actors  Customer
Description Customers can view all the available routes and select the route of
his/her own choice.
Trigger Users want to request to see the route details.
Pre-condition The actors log in to the system
Postcondition The customer sees the information related to a particular route and
selects the route of his/her own choice.
Normal flow The users log in to the system.
View the routes
Alternative flow The user did not register his /herself and did not view the available
route details.
Exceptions The error occurs in the application.
Server is down
Business rules User registration is required.

5
Table 4 Enter Details

Use case id 04
Use case name Enter details
Actors Customer
Description The customer must enter all the necessary information which includes
personal as well as vehicle details.
Trigger Customers want to book a driver to transport their vehicle.
Precondition Customers must get registered on the app.
Postcondition A confirmation message is received by the customer.
Customers fill out their personal information forms.
Normal flow The customer successfully logs in to the system.
Customers successfully get registered.
Alternative flow Admin does not accept the request.
No driver is available for the route.
Exceptions There is no internet.
Server down
Business rules The request is rejected when the customer does not sign the
agreement.
Table 5 Check Prices

Use case id 05
Use case name Check prices
Actors  Customer
Description Customers can view the prices.
Trigger Users want to request to see the check prices.
Pre-condition The actors log in to the system.
Postcondition The customer sees all available prices.
Normal flow The users log in to the system.
Alternative flow The user has not registered his/herself and has not viewed the available
prices.
Exceptions The error occurs in the application.
The server is down.
Business rules User registration is required.
Table 6 Request for booking

Use case id 06
Use case name Request for booking
Actors Customer
Description After entering details confirm for bookings.
Trigger Customers want to book a driver to transport their vehicle.

6
Precondition The customer must be registered and request bookings.
Postcondition A confirmation message is received by the customer.
Customers fill out their personal information forms.
Normal flow The customer successfully logs in to the system.
Customers successfully book the driver.
Alternative flow Admin does not accept the request.
No driver is available for the requested route.
Exceptions There is no internet.
Server down
Business rules The request is rejected when the customer does not sign the agreement.
Table 7 Sign Agreement

Use case id 07
Use case name Sign agreements
Actors Customer
Description The customer signed the agreement.
Trigger Confirm all checks and sign the agreement.
Pre-condition The customer has pressed the “sign the agreement” button.
Postcondition The agreement has been signed.
Normal flow The customer logs in to the system.
Check routes, enter details and check prices.
Alternative flow The customer cancels the route himself.
Price conflicts between customer and driver.
Exceptions Driver does not reach on destination on time.
Business rules Price may vary by the size of the vehicle.
Table 8 Payment

Use case id 08
Use case name Payment
Actors  Customer
 Admin
Description After signing the agreement, the customer selects payment means
and confirms payment. Admin manages payment and sends a
confirmation mail to the customer and top-ups.
Trigger Customers want to confirm payment.
Admin manages payments.
Precondition The customer must be registered and has access to the user
account.

7
Postcondition The customer can view the updated payment of his vehicle and gets
confirmation emails.
Admin updates the customer table.
Normal flow The customer successfully logs in to the system.
The customer successfully confirms payment.
Alternative flow The customer does not log in.
Hasn’t access to the user account.
Exceptions There is no internet.
The error occurs in the application. Server down.
Business rules The customer only confirms payments after signing agreements.
Table 9 Cancel Booking

Use case id 09
Use case name Cancel bookings
Actors Customer, Admin
Description Customers and admin both can cancel bookings.
Trigger Customers want to cancel the booking.
Admin cancels booking due to lack of
drivers.
Precondition The customer must be registered.
Admin must be registered.
Postcondition Admin can cancel the booking.
Customers can cancel bookings after login into their account.
Normal flow The customer successfully logs in to the system.
The customer successfully cancels bookings.
Alternative flow Admin does not cancel the bookings.
The customer does not cancel the bookings until the admin accepts
this request.
Exceptions There is no internet.
The error occurs in the application.
Server down
Business rules The request is rejected if the customer does not cancel his booking
within 2 days.
Table 10 Tracking
Use case id 010
Use case name Tracking
Actors Customer, Admin
Description Customers and admin both can track the vehicle.
Trigger Customers want to track their vehicles.
Admins manage to track.
Precondition The customer must be registered.
Admin must be registered.

8
Postcondition Admin can track and send updates to the customer. Customers
can track their vehicles.
Normal flow The customer successfully logs in to the system.
The customer successfully tracks the vehicles.
Alternative flow Admin does not send updates.
The customer does not track the vehicle until the admin accepts this
request.
Exceptions There is no internet.
The error occurs in the application.
Server down
Business rules The request is rejected if the driver does not turn on his location.

Table 11 Manage Details

Use case id 011

Use case name Manage details
Actors Admin
Description Admin can view all data of customer and manage their details. Post
them on the driver’s load board. Delete or update.

Trigger Admin get the details of the customer’s shipment.

Precondition The admin received the details of the customers.
Postcondition Admin manages all the details post and update them on the load
board.
Normal flow Admin successfully manages customer information.
Customer sent all his details.
Alternative flow Admin does not manage customer information.
Customer didn’t share his information.
Exceptions There is no internet.
An error occurs in the application.
Server down
Business rules Admin manages all customer details in proper sequence.
Table 12 Manage Shipments

Use case id 012

Use case name Manage Shipments
Actors Admin
Description Admin can manage all the shipments. He can book and complete
them. So managing all the shipments is the responsibility
Trigger Admin get the details of the customer’s shipment.

9
Precondition The admin received the details of the customers.
Postcondition Admin manages all the details post and update them on the load
board.
Normal flow Admin successfully manages customer information.
Customer sent all his details.
Alternative flow Admin does not manage customer information.
Customer didn’t share his information.
Exceptions There is no internet.
An error occurs in the application.
Server down
Business rules Admin manages all customer details in proper sequence.
Table 13 Manage Drivers
Use case id 013
Use case name Manage driver
Actors Admin
Description Admin manages the drivers that come on the respective load and
select the appropriate one for the load.
Trigger Admin get all the requests from the driver
Precondition Admin checks all the drivers’ requests
Postcondition Admin accepts an appropriate driver and sends it to the customer
Normal flow Admin successfully manages driver.
Alternative flow Admin does not manage driver.
Exceptions There is no internet.
The error occurs in the application Server down
Business rules Admin manages all the drivers in proper sequence.

4. Functional Requirements
These are the following modules that will be included in this system.
1. Customers Modules
2. Admin Modules
3. Driver Module (future goal)

4.1Customer’s Module
 This module is made for customers who want to transport their vehicles.
 This module will take the complete information from them.
 After this, it generates a price for them if the customer accepts the price, then it
adds his load into the shipment box
 The shipment box will contain tracking, driver details and status of his load.
 The customer can also chat with the driver.
 Step by step shipment for a vehicle.

10
 4.2Admin modules
In this module, it manages all the things between the customer and the driver modules. Admin
is the control of our project and is used to monitor and manage info from the driver and the
customer.
In the future we also aim to make a driver module.
4.3 Driver’s Module
This module will be made for the drivers specially.
 The drivers can see their relative loads.
 They can accept or appeal for a price.
 If it is accepted, then the load will be assigned.
 The driver needs to keep updating the vehicle status.

5. Non-functional requirement
Non-Functional Requirements are the quality or abstract qualities that should be in your
system. Non-functional requirements explain the constraints of the system. It identifies the
attributes under which the system is operating. Some of the non-functional requirements
for auto shipping management system are given below.
5.1 Usability
This application will help both the Customer and the driver. This will help in save time. This
system will give the facility to customer or driver also. Very clear and high-quality attributes
will carry out by the system. The system will help the user to pack away from other broker
sites by Admin
5.2 Performance
The performance of the system is very good. It performs all the tasks that are very useful
and provide all the facility that a customer needs and its give result quickly and accurately.
5.3 Security
The system will be very secure. All technologies make it secure from unauthorized access.
 The user is required to log in to it, to gain access to different features.
 It will allow only log-in members that are registered in the system.
 It should have protection against the broker websites.
 The system must have a login option for authorized access.
 The system must have strong security to protect itself from any external threats.
 The system would not allow any unauthorized user to enter the system or create or
edit, this action will maintain and improve the security level of the system.

5.4 Portability
This application should run on every system, Windows, Mac OS, and Linux, and can be
supported by any type of version, server, or browser. This application also works on android
OS and IOS must have a browser and it will be responsive for mobile users.

5.5 Reliability
The system should be accurate and every step of the procedure should be error-free.

11
References
[1] https://superdispatch.com/blog/what-is-a-transportation-management-system/
[2] https://www.selecthub.com/transportation-and-logistics-management/tms-system-
requirements/
[3] https://www.erpsoftwareblog.com/2021/12/5-key-order-management-system-
requirements-for-companies-who-sell-through-distributors/
[4] https://www.techtarget.com/searcherp/definition/transportation-management-
system-TMS

12