See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/366840246

Software Requirements Specifications for Smart Waste Management

Preprint · January 2018

CITATIONS READS
0 367

1 author:

Zain Imdad
National University of Sciences and Technology
3 PUBLICATIONS 0 CITATIONS

SEE PROFILE

All content following this page was uploaded by Zain Imdad on 03 January 2023.

The user has requested enhancement of the downloaded file.

Software Requirements Specifications

for

Smart Waste Management

Prepared by:
Zain Imdad
 Page ii
Software Requirements Specification for Smart Waste Management

Table of Contents
Table of Contents
1. Introduction .......................................................................................................................1
1.1 Purpose ........................................................................................................................................

1.2 Intended Audience and Reading Suggestions ............................................................................. 1

1.3 Overview ……………………………………………………………………………..1
1.4 References ................................................................................................................................... 2

2. Overall Description ...................................................................................................... 2

2.1 Product Perspective ................................................................................................................... 2
2.2 Product Functions ...................................................................................................................... 3
2.3 User Classes and Characteristics ............................................................................................... 4
2.4 Operating Environment ............................................................................................................. 4
2.5 Design and Implementation Constraints ..................................................................................... 4 2.6
User Documentation .................................................................................................................. 4
2.7 Assumptions and Dependencies .................................................................................................. 4

3. External Interface Requirements .....................................................................................5

3.1 User Interfaces .......................................................................................................................... 5
3.2 Hardware Interfaces .................................................................................................................... 8
3.3 Software Interfaces ................................................................................................................... 9

4. System Features (Use Cases) ...........................................................................................10

6. Other Nonfunctional Requirements ...............................................................................18

1 Performance Requirements ....................................................................................................... 18
2 Safety Requirements .................................................................................................................. 19
3 Security Requirements .............................................................................................................. 22
4 Software Quality Attributes ...................................................................................................... 23
7. Other Requirements ........................................................................................................24
Smart Waste Management Page 1

1. Introduction
This section gives a scope description and overview of everything included in this SRS document.
Also the purpose for this document is described and a list of abbreviations and definitions is
provided.

1.1 Purpose
The purpose of this document is to give a detailed description of the requirements for the “Smart
Waste Management System” (SWMS). It will illustrate the purpose and complete declaration for
the development of system. It will also explain system constraints, interface and interactions with
other external applications. This document is primarily intended to be proposed to a customer for its
approval and a reference for developing the first version of the system for the development team.

1.2 Intended Audience and Reading Suggestions

The project is being developed as a prototype and thus the utility of this document currently remains
confined to the university premises. The intended audience of this document are the faculty
supervisors of this project. Also, this document serves as a guideline for the core development team
as well.

1.3 Product Scope

The project basically aims to optimize the current waste collection procedures in an attempt to make
the process, energy and cost efficient. This will help in optimized waste collection where less
resources would be used in a way that collection is most efficient.

The main objectives of the product include automation of solid waste monitoring process using
IOT. Waste bins would be communicating their fill levels and location to a cntral server. Then,
waste bins that need to be emptied would be determined. Optimized routes would then be generated
using optimization algorithms. Routes would utilize minimum waste trucks to save fuel costs as
well as manual labor.

1.4 Overview
The remainder of this document includes three chapters and appendixes. The second one provides
an overview of the system functionality and system interaction with other systems. This chapter also
introduces different types of stakeholders and their interaction with the system. Further, the chapter
also mentions the system constraints and assumptions about the product.
The third chapter provides the requirements specification in detailed terms and a description of the
different system interfaces. Different specification techniques are used in order to specify the
requirements more precisely for different audiences.
The fourth chapter deals with the prioritization of the requirements. It includes a motivation for the
chosen prioritization methods and discusses why other alternatives were not chosen.
Smart Waste Management Page 2

The Appendixes in the end of the document include the all results of the requirement prioritization
and a release plan based on them

1.5 References

• IoT Based Smart Waste Management System for Smart City-Sneha Patil, 2Snehal
Mohite, 3Aishwarya Patil, 4Dr. S.D.Joshi

• http://ieeexplore.ieee.org/document/4063765/
• http://ieeexplore.ieee.org/abstract/document/4537133/
• http://www.smart-cities.eu
• http://epd.punjab.gov.pk/solid_waste
• http://ieeexplore.ieee.org/abstract/document/4665232/
• http://www.ajper.com/admin/assets/article_issue/1464434692.pdf
• https://tspace.library.utoronto.ca/handle/1807/49461
• https://www.arduino.cc/en/Main/ArduinoGSMShield

2. Overall Description
2.1 Product Perspective
The current way of manually monitoring waste in waste bins is a cumbersome process and results in
increased human labor, more time consumption and higher costs. This results in irregular collection
of waste causing a lot of problems like pollution and spread of diseases in humans. As it is a critical
process, it needs to be made efficient. So, to cater these issues we are proposing SMWS.
Smart Waste Management Page 3

SWMS will be a cost-effective implementation of existing smart waste management systems in use.
Data would originate from Smart-Bin(s) as the sensors would constantly detect the level of waste in
the bins along with their location. The data and the location of each bin is then transmitted to a
server. GPRS module is used to determine the location and Arduino module sends the location and
fill level to a server via a GSM module. The data is then processed and routes are generated. The
routes are then displayed to concerned truck drivers on an android application. The Smart Waste
Bins can be installed on the regular pick up sites being used by the municipal authorities and the
mobile application will be made simple so it can be understood by the truck drivers.

2.2 Product Functions

• Determining Fill-level using ultrasonic sensors
• Determining Bin Location using GPS sensor
• Communication of data from bins to server
• Optimized Route generation based on waste bins to be picked
• Route Communication to each truck driver
• Navigation of routes using Maps

2.3 User Classes and Characteristics

User Importance Requirements

Smart Waste Management Page 4

Pick-Up Truck High Routes accounting for maximum trash bins with the minimum
Drivers distance.

Maintenance Low Location of all the trash bins.

Staff

Administrator Medium An admin portal; a map highlighting the locations of all the pickup
trucks currently en-route as well as the all the pick-up sites.

Table 1

2.3.1 User Classes

2.3.1.1 User Class 1: Smart Bin

This class is responsible for measuring and sending Wastebin data.

ID Use Case
SB 1 Measure Data

SB 1.1 Calculate Fill Level

SB 1.2 Get Location Coordinates

SB 2 Send Data
Table 2 - Smart Bin Use cases

2.3.1.1 User Class 2: Server

Smart Waste Management Page 5

This class is responsible for Data layer operations.

ID Use Case
SR 1 Receive Smart Bin Data

SR 2 Save Smart Bin Data

SR 3 Send Smart Bin Data
Table 3 - Server Use cases

2.3.1.1 User Class 3: Truck Driver

This class is responsible for Truck Driver operations.

ID Use Case
TD 1 Login
TD 2 Get Jobs
TD 3 All Jobs Completed
Table 4 - Truck Driver Use cases

2.3.1.2 User Class 4: Administrator

This class is responsible for user who monitors smart bin data and generates jobs.
ID Use Case
AD 1 Login

AD 2 Monitor Bins
AD 2.1 View Jobs

AD 2.2 Control Jobs

AD 3 Generate Routes

AD 4 Register Truck Driver

Table 5 - Administrator Use cases
Smart Waste Management Page 6

2.4 Operating Environment

Arduino UNO R3 would be used as the microcontroller to help ultrasonic sensors, GPRS and GSM
modules to communicate with each other and send data to server. Central server would use
MongoDB to store data. REST API would be used to expose data to other parts of the application.
Admin portal would be running on Windows Vista and above and would be using routing protocols
and algorithms such as JSprit. The driver application would be an android application running on
android KitKat 4.4.2 and above.

2.5 Design and Implementation Constraints

J-Sprit is used to solve the Vehicle Routing Problem. The overall system is implemented in JAVA.
MongoDB is used as data server to provide efficiency. WiFi not being a feasible option GSM is
used for communication. It uses a modular design where every feature is wrapped into a separate
module and the modules depend on each other through well-written APIs. Android application is
developed using Java and Android Studio. GPRS is used to determine bin locations.

2.6 User Documentation

No manual will be required by the end-user as our product will be android application for them.
However, there will be a manual depicting the component layout of the hardware kit in the trash
bins specifically designed for the maintenance staff. The administrator also will not be needing a
manual as the admin portal would be self-explanatory in all regards.

2.7 Assumptions and Dependencies

• It has been assumed that the weather conditions will remain suitable for the hardware kit to
survive i.e. calamities and harsh weather conditions have not been accounted for.

• It has been assumed that the users will already know how to operate smart phone and the
mobile application.

• It is assumed that the phones will have stable internet connectivity.

• It is assumed that the administrator will be learned enough to operate the admin portal
without a learning curve.

• It is assumed that the hardware kits installed in the bins will continue to function properly
for 2-3 years before needing a battery replacement.
Smart Waste Management Page 7

• It has been assumed that all the trash bin locations have cell-signal reception as it operates
on a GSM module.

3. External Interface Requirements

This section provides a detailed description of all inputs into and outputs from the system. It also
gives a description of the hardware, software and communication interfaces and provides basic
prototypes of the user interface.

3.1 User Interfaces

Upon opening the mobile application, the user (driver) should see the login page as shown in
Figure# 1.

Figure 1
Smart Waste Management Page 8

The user can then view the jobs assigned to him for that day. The jobs being the garbage collection
routines. See Figure # 2.

Figure 2

Upon selection of a job, the application will then display an optimized route to the driver indicatin g
pickup points and his own location. As shown in Figure # 3.
Smart Waste Management Page 9

Figure 3

The administrator will have full access to the systems functionalities and he’ll be able to view the
number of trucks currently enroute as well as their estimated time to complete their respective jobs.
The administrator will also be able to view the status of the Smart Bins as they’re being filled, along
with their location. See the figures below.
Smart Waste Management Page 10
Smart Waste Management Page 11

3.2 Hardware Interfaces

Arduino Uno
Arduino Uno R3 is a micro controller board. It has 14 digital input/ output pins, 6 analog inputs,
a 16 MHz quartz crystal, a USB connection, a power jack, an ICSP header and a reset button.
The microcontroller contains everything to support GSM and GPS modules as well as the
ultrasonic sensors.

Ultrasonic Sensor:
The Ultrasonic Sensor sends out a high-frequency sound pulse and then times how long it takes
for the echo of the sound to reflect back. The sensor has 2 openings on its front. One opening
transmits ultrasonic waves, (like a tiny speaker), the other receives them, (like a tiny
microphone).The speed of sound is approximately 341 meters (1100 feet) per second in air. The
ultrasonic sensor uses this information along with the time difference between sending and
receiving the sound pulse to determine the distance to an object.

GSM Shield – SIM900:

Smart Waste Management Page 12

Just like Arduino it has a number of input/output ports and a power jack. It has a cell jacket as
well, with a sim card jacket, to insert sim. It can be powered using Arduino as well as an adapter
or a battery etc.

Breadboard:
This would be used for prototypes. A breadboard is a construction base for prototyping of
electronics. Because the solder less breadboard does not require soldering, it is reusable. This
makes it easy to use for creating temporary prototypes and experimenting with circuit design.

Vero board:
The final product would be made on this. It requires soldering and thus is permanent.

3.3 Software Interfaces

Arduino IDE:
Arduino Inc. provides their own open-source Arduino Software (IDE), which makes it pretty
easy to write and upload code to the board. They have Mac OS X, Windows and Linux versions
available. It has a text editor, serial monitor and other functionalities.

REST API:
RST API is used to modify, get and update data from a DB and process it.

Front end Technologies:

JavaFX:
JavaFX is used to create elegant user interfaces. It is intended to replace SWING for GUIs

Back end Technologies:

JSprit:
Jsprit is a framework based on Java, and is used to solve the Vehicle Routing Problems.

Apache Tomcat:
The Apache Tomcat is an open source software that is an implementation of Java Servlet and
Java Web Socket technologies.
 Smart Waste Management Page 13

4. System Features (Use Cases)

4.1 Use Case Diagram

Following diagram shows Smart Waste Management use cases.
Smart Waste Management Page 14

4.2 Use Cases

4.2.1 Use Case 1

Use Case ID: SB1 Use case Name: Measure Data

Actor: Smart-Bin
Description: This use case includes all kind of operations needed to get data and
information about the Smart-Bin.
Pre-conditions: Internet is connected and working properly and timer has reached the
execution point.
Post-conditions: Smart-Bin will send this information to the central server.
Normal Flow: The normal flow of each process of “Measure Data” will be discussed later.
Alternative Flows: The alternative flow of each process of “Measure Data” will be discussed
later.
Assumptions: Smart-Bin is powered by battery and connections are working properly.
Includes: Calculate Fill Level, Get Location Coordinates

4.2.2 Use Case 2

Use Case ID: SB1.1 Use case Name: Calculate Fill Level
Actor: Smart-Bin
Description: Smart-Bin should measure fill level of waste material.
Pre-conditions: Controller has signaled the sensor to measure fill level.
Post-conditions: Send fill level back to the controller.
Normal Flow: Ultrasonic sensors measures the fill level and send back to the controller
when signaled.
Alternative Flows: In case of multiple sensors all sensors measure fill level and Arduino will
calculate their average
Assumptions: There is solid waste material inside Smart-Bin. The
Smart-Bin is in its standard position.
Includes: -
Smart Waste Management Page 15

4.2.3 Use Case 3

Use Case ID: SB1.2 Use case Name: Get Location Coordinates
Actor: Smart-Bin
Description: Smart-Bin should calculate the geographic coordinates.
Pre-conditions: Controller has signaled the GPRS to get location coordinates.
Post-conditions: GPRS sensor send coordinates back to the controller.
Normal Flow: Controller sends signal to GPRS sensor and it will then calculate the
location coordinates.
Alternative Flows: -
Assumptions: GPRS sensor is powered and working appropriately.
Includes: -

4.2.4 Use Case 4

Use Case ID: SB2 Use case Send Data and Information
Name:
Actor: Smart-Bin
Description: Smart-Bin should send data and info about itself to the central
server.
Pre-conditions: Fill Level and location coordinates has been calculated.
Post-conditions: Server will persist that information.
Normal Flow: Arduino will send the data using POST request to the REST API at
central server.
Alternative Flows: -
Assumptions: REST API is live and listening for requests. Smart-Bin
has access to GPRS.
Includes: -
Smart Waste Management Page 16

4.2.5 Use Case 5

Use Case ID: SR1 Use case Name: Receive Smart Bin Data

Actor: Server
Description: Server should receive the data sent by smart bin using POST request.
Pre-conditions: Server is online.
Post-conditions: Server will persist that information.
Normal Flow: Server will receive the request.
Check the format of data.
If format is right then it will persist the data.
Alternative Flows: Server will receive the request.
Check the format of data.
If format is wrong discard the data.
Assumptions: Power is always available at server.
Includes: -

4.2.6 Use Case 6

Use Case ID: SR2 Use case Name: Save Smart Bin Data

Actor: Server
Description: Server should persist the data sent by smart bin using POST request.
Pre-conditions: POST request is received.
Post-conditions: Server will persist that information.
Normal Flow: Check the Wastebin is already in database or not.
If presents updates its information.
Else if waste bin is not in the database create new waste bin and add its
information.
Alternative Flows: Server will receive the request.
Check the format of data.
If format is wrong discard the data
Assumptions: Database is created.
Includes: -
Smart Waste Management Page 17

4.2.7 Use Case 7

Use Case ID: SR3 Use case Name: Send Smart Bin Data

Actor: Server
Description: Server should send the data of smart bins present in database.
Pre-conditions: Get request has been received.
Post-conditions: Database is consistent.
Normal Flow: Server will receive the GET request from administrator application. Send
the data required in request.
Alternative Flows: -
Assumptions: Power is always available to server.
Includes: -

4.2.8 Use Case 8

Use Case ID: TD1 Use case Name: Login (Android App)

Actor: Truck Driver

Description: Truck Driver should login to app.
Pre-conditions: Application is installed.
Truck Driver is registered.
Post-conditions: Truck Driver will get his pending jobs.
Normal Flow: Truck Driver will open the app.
He will add the credentials.
Login to app.
Alternative Flows: Truck driver will ask the administration to register him.
Truck Driver will open the app.
He will add the credentials.
Login to app.
Assumptions: Truck Driver has enough knowledge to use an application.
Includes: -
Smart Waste Management Page 18

4.2.9 Use Case 9

Use Case ID: TD2 Use case Name: Get Jobs

Actor: Truck Driver

Description: Truck Driver should request the pending jobs for him.
Pre-conditions: Truck Driver is registered and logged in.
Post-conditions: Pending Jobs will be displayed.
Normal Flow: Truck Driver will login to app.
Send request for pending jobs.
He will get the pending jobs.
Alternative Flows: Truck Driver will login to app.
Send request for pending jobs.
Assumptions: Truck Driver has enough knowledge to use an application.
Includes: -

4.2.10 Use Case 10

Use Case ID: TD3 Use case Name: All Jobs Completed

Actor: Truck Driver

Description: Truck Driver should complete pending jobs.
Pre-conditions: There are pending jobs.
Post-conditions: All jobs will be completed.
Normal Flow: Truck Driver pick waste from all bins. Press
all jobs completed button.
Alternative Flows: -
Assumptions: Truck Driver has enough knowledge to use an application.
Includes: -
Smart Waste Management Page 19

5. Other Non-functional Requirements

5.1 Performance Requirements

The requirements in this section provide a detailed specification of the user interaction with
the software and measurements placed on the system performance.

5.1.1 Displaying Smart Bins’ data in table view

ID: QR1
TITLE: Displaying Smart Bins’ data in table view
DESC: The results displayed in the table view should be user friendly and easy to understand.
Selecting an operation (CRUD) should only take one click.
RAT: In order to allows the administrator to view the status of Smart Bins.
DEP: none

5.1.2 Usage of the result in the map view

ID: QR2
TITLE: Usage of the result in the map view
DESC: The results displayed in the map view should be user friendly and easy to understand.
RAT: In order to allow the drivers to navigate their course.
DEP: none

5.1.3 Efficient response time

ID: QR3
DESC: The response time for all fetch operations to and from the database should take minimum
time.
MUST: No more than 2 seconds 100% of the time.
WISH: No more than 1 second 100% of the time.

5.1.4 System dependability

ID: QR4
DESC: The fault tolerance of the system.
MUST: The system must be able to recover from invalid inputs, loss of connection to internet
and GPS.
Smart Waste Management Page 20

5.2 Security Requirements

ID: QR5

TAG: Communication Security

DESC: Security of the communication between the system and server.
Rationale: The messages should be encrypted for log-in communications, so others cannot get
username and password from those messages.
MUST: 100% of the Communication Messages in the communication of a log-in session should
be encrypted.

ID: QR6

TAG: Administrator Login Account Security

DESC: If an administrator tries to log in to the web portal with a non-existing account then the
restaurant owner should not be logged in. The restaurant owner should be notified about log-in
failure.
MUST: 100% of the time.

ID: QR7

TAG: Admin Account Security

DESC: An IP address should not be able to log-in for a certaitime period after
three times of failed log-in attempts.
MUST: The locking period should be half an hour, and during that period the log-in function is
disabled.

5.3 Software Quality Attributes

3.5.1 Reliability

ID: QR8
TAG: System Reliability
DESC: The reliability of the system.
SCALE: The reliability that the system gives the right result on a search.
METER: Measurements obtained from 1000 searches during testing.
MUST: More than 98% of the searches.
PLAN: More than 99% of the searches.
WISH: 100% of the searches
Smart Waste Management Page 21

3.5.2 Availability

ID: QR9
TAG: System Availability
DESC: The availability of the system when it is used.
MUST: More than 98% of the time.
PLAN: More than 99% of the time.
WISH: 100% of the time.

ID: QR10
TITLE: Internet Connection
DESC: The application should be connected to the Internet.
RAT: In order for the application to communicate with the database.
MUST: More than 98% of the time.
PLAN: More than 99% of the time.
WISH: 100% of the time.
DEP: none

ID: QR11
TITLE: GPS Connection
DESC: The application should be connected to the GPS device.
MUST: More than 98% of the time.
PLAN: More than 99% of the time.
WISH: 100% of the time.
RAT: In order for the application to get the users location, the map and to calculate the distance.

3.5.4 Maintainability

ID: QR12

TITLE: Application extendibility

DESC: The application should be easy to extend. The code should be written in a way that it
favors implementation of new functions.
RAT: In order for future functions to be implemented easily to the application.
DEP: none

ID: QR13

TITLE: Application testability

DESC: Test environments should be built for the application to allow testing of the
applications different functions.
RAT: In order to test the application.
DEP: none
 Smart Waste Management Page 22

3.5.5 Portability

ID: QR14

TITLE: Application portability

ESC: The application should be portable with iOS and Android.
RAT: The adaptable platform for the application to run on.
DEP: none

6. Other Requirements
The project requires the approval of the relevant municipal authority for deployment in a
particular area.
The system requires the end-users(Driver and Administrators) to have a level of literacy that is
sufficient to comprehensively understand and use the Android application and the Admin portal.
The project requires sound infrastructure already in-place for successful operation of the system.

View publication stats