• Table of contents
• Introduction
  • Purpose
  • Scope
  • Glossary
  • Overview
• Overall Description
  • Product Perspective
    • System Interfaces
    • User Interfaces
    • Hardware Interfaces
    • Software Interfaces
    • Communication Interfaces
  • Product Functions
    • Data Entry Subsystem
    • Prediction of Future Water Quality
    • Visualization of Measurements
  • User Characteristics
  • Constraints
  • Risks
  • Assumptions and Dependencies
• Requirements Specification
  • External Interface Requirements
    • User Interfaces
    • Hardware Interfaces
    • Software Interfaces
    • Communications Interfaces
  • Functional Requirements
    • Administrator Use Case
    • Data Entry Operator Use Case
    • Decision Maker Use Case
  • Performance Requirements
    • Response Time
    • Workload
  • Software System Attributes
    • Availability
    • Security
    • Maintainability
    • Usability
• References

The following subsections are an overview of the entire Software Requirements Specification document of Water Quality Prediction and Monitoring System (WQPMS) for The Ministry of Environment and Urban Planning.

The purpose of this document is to provide the technical description of all software requirements of this system. It explains interfaces and the usage of the system. In addition, the document describes in what conditions the system will work.

Water Quality Prediction and Monitoring System will be a web based system that is intended to be used by employees of The Ministry of Environment and Urban Planning. Its goal is to visualize water quality parameters from water sample readings entered to the system by data entry operators. The data visualized by the front-end will facilitate the decision making process for the employees of the agency.

WQPMS will also be able to predict the future water quality parameters using previously gathered data using machine learning algorithms. Thereby, it may reveal hidden patterns and maximizing work efficiency.

The Agency	The Ministry of Environment and Urban Planning
WQPMS	Water Quality Prediction and Monitoring System
SEPA	Special Environmental Protection Areas
WQP	Water Quality Prediction
ML	Machine Learning
GUI	Graphical User Interface

This document is prepared in accordance with the IEEE Std 1016-2009 [1], IEEE Recommended Practice for Software Requirements Specifications [2].

The Water Quality Monitoring system is created for the use of decision-makers at the agency. They will be the main users of the software and therefore the software will be hosted on the agency’s servers.

The system is self-contained and independent from other software.

The previous workflow of decision making related to water quality was a manual workflow, by this we mean, water quality readings were provided to the decision makers at the agency and a report including charts of the readings were produced manually. The system described in this document is the automated alternative to this workflow.

Since the software is entirely self-contained, there are no external system interfaces needed.

There will be three different user interfaces for different types of users. The types are the administrator, decision-maker, and the data entry operator.

The administrator will be able to add users, remove users, and update permissions of a user.Administrators may add new location information for “Data Entry Operators” may enter the values of newly added locations. Also, they might be able to change the current value of previously entered data.

The data entry operator will be able to enter new water quality readings to the system, but will not be able to see past readings.

The decision-makers will be able to see the water quality readings in the system, both by examining the raw data provided by the data entry operators and the visualizations automatically generated by the software. They will also be able to access the future water quality predictions provided by the ML subsystem.

For users, there are no hardware interfaces required to run the software other than a computer capable of serving and displaying web pages because parameter prediction will be handled by a server.

For the server, a CUDA capable GPU is needed to make predictions as quickly as possible.

The system depends on PostgreSQL 13.1 for persistent data storage. For serving web pages and communicating with database Django Framework version 3.1 is used. The system will include a SQL definition file that describes data tables for the first time setup that will be performed by the agency’s database admin.

An internet connection is required to run the data entry subsystem of the software. The prediction and visualization subsystems can be accessed through a local network connection.

The water quality measurement survey is not directly conducted by the agency employees. A company is contracted to do the survey travels around Turkey, taking measurements and inserting all the measured data inside a Microsoft Access database. This workflow has some disadvantages.

The first disadvantage is that the data provided by the contractor company is not always validated, sometimes more than a few entries in the database can be missing. The second disadvantage is that the data is sent to the agency only 1 or 2 times a year, not at the time they’re taken. By creating a data entry subsystem for the contractors to use, we’ll be able to make sure the data entered will be on time and up to standards.

The data entered to the system by data entry operators will be used to forecast the future water quality by running a ML model in the background. The decision makers will be able to access these predictions through their visualizations GUI.

The decision makers will mainly use the system for visualizing the data obtained by measuring several water sources across Turkey. To be able to decide how to treat water in each source, the users need visualizations of different measurements such as pH value, dissolved oxygen, total coliform, fecal coliform, temperature and so on.

The users in decision maker and data entry operator user groups must have basic computer knowledge, such as knowing how to operate a computer and a web browser.

The administrator is expected to have knowledge of database systems and servers, since the setup of the system will require these skills.

Users should open the system using a web browser.

The database should have enough space to hold data and have enough space for future data entries.

Prediction must be done in accordance with The Regulations of Water Quality Management.

Due to missing, redundant and noisy data, the dataset should be cleaned before training the model. After cleaning, some information is lost. In machine learning, more data is usually better with a well implemented machine learning algorithm. Therefore, with less data, the trained model’s prediction accuracy could be lower than expected and lower prediction accuracy on training sets always results in poor performance in real-world situations.

For the software to run reliably, servers must be able to run docker containers and PostgreSQL. When these requirements are met, the operating system or other software should not affect the operation of the software.

The users must use the latest version of the Google Chrome web browser to be able to reliably operate the user interface of the software.

• Users must have connected to the internet.

• The system should be able to be opened by a web-browser.

• Information of users should be stored in a database.

• The database must be able to store data for the past 15 years and should have enough space for future data entry.

• New users should be able to be created by contacting an admin.

• Data entry operators should have different interfaces than User or Admin.

• Data entry operators should not be able to see previously entered data.

• The system should be able to visualize or show raw data to users in a selected time and place.

• The system should be able to predict a selected value in the selected place.

• New resources should be added if needed.

• The system may show a map where the samples taken from.

Users should be able to open the system using a web-browser. The system should be opened by any operating system.

There are no external hardware interfaces needed.

There are no external software interfaces needed.

There are no external communication interfaces needed.

Actor : Administrator

Use Case:

• Manage Users

  • Create User

  • Delete User

• Manage User Permissions

• Update Data

Diagram:

Figure 1: Management System Use Case Diagram

Brief Description:

Figure 1 shows the management system use case diagram. The administrator has authority to manage the system*.* Administrators are able to add and delete users and manage user permissions.

Initial Step by Step Description:

1. Users can not register.

2. Administrators are able to create users.

3. Administrators can give users specific permissions and prohibitions.

   1. Administrators can assign the user to the data entry operators group or decision makers group.

4. Administrators can delete users.

5. Administrators may update data.

   1. Administrators may add new locations.

   2. Administrators may change the existing values.

   3. Administrators may add delete the locations.

Actor: Data Entry Operator

Use Case:

• Enter Data

  • Validation

  • Save to Database

Diagram:

Figure 2: Data Entry System Use Case Diagram

Brief Description:

Figure 2 shows the data entry system use case diagram. Data entry operators do not have the same permissions as Decision Makers, therefore they can only enter data in appropriate format to aid decision making.

Initial Step by Step Description:

1. Data entry operator can insert data to system
   1. If data is not entered in the proper format, a request will be sent to a user to enter the data in proper format.
   2. If data is in proper format, data can be inserted to the database.

Actor: Decision Maker

Use case:

• Visualize Data
  • Show Graph
    • Export
  • Show Table
    • Export
  • Show Predicted Graph
    • Export

Diagram:

Figure 3: Decision Maker Use Case

Description: Decision Makers are allowed to use the system for visualizing selected samples. The graph of a sample includes, time, water quality parameters and prediction results of the selected sample. As you can see in Figure 3, Decision Makers select which graph they want to see. The system displays the actual and predicted results of a sample. Also, the reports can be exported.

Initial Step by Step Description:

1. Decision Maker log in to the system with username and password.
2. The decision maker can select Visualize Data.
   1. The decision maker can choose parameters to see the graph.
      1. These parameters can be a place, time and value.
      2. If Decision Maker selects “Bar”:
         1. The system shows a bar-chart value over time.
         2. The graph can be exported as an image or pdf.
      3. If Decision Maker selects “Line”:
         1. The system shows a line-chart value over time.
         2. The graph can be exported as an image or pdf.
      4. If decision Maker selects “Table”:
         1. The system shows a table of selected place and time.
         2. The graph can be exported as an image or pdf.
      5. If decision Maker selects “Predicted Graph”:
         1. The system shows a bar-chart value over time that ends with predicted value.
         2. The graph can be exported as an image or pdf.

Response time is highly dependent on internet connection speed. Considering an internet connection with at least 8Mbps, the system should respond to requests in less than 3 seconds.

The system should support at least 15 concurrent users.

The software will run and be available as long as the hardware and the Docker environment it runs on works correctly. In a crashing event such as a system crash, as long as the database is not corrupted, software will run without problems when restarted.

Most subsystems in the monitoring software will not be connected to the internet, since the users will be able to use the software through the local network of the agency.

The data entry system, however, must be connected to the internet so that the contractors are able to enter the new measurements after they’re taken. Since this data entry system can be used as an attack vector, we will validate the user input rigorously using both custom software and Django’s validation module.

Since the database is independent from the server software, administrators are free to update them, as long as they're compatible. The agency will provide a development environment for the testing of WQPMS, this will allow us to make sure the software will work for many years into the future with as little maintenance as possible.

The GUI will be designed to be similar to the previous workflow for both the Data Entry Operators and the Decision Makers. For the decision makers, charts will be designed to be similar to the charts contained in previous years’ reports. For the data entry operators, since the previous workflow involved Microsoft Access, a similar Table-like data entry UI will be produced.

• [1] "IEEE 1016-2009 - IEEE Standard for Information Technology--Systems Design--Software Design Descriptions", Standards.ieee.org, 2020. [Online]. Available: https://standards.ieee.org/standard/1016-2009.html. [Accessed: 01- Dec- 2020].

• [2] "IEEE 830-1998 - IEEE Recommended Practice for Software Requirements Specifications", Standards.ieee.org, 2020. [Online]. Available: https://standards.ieee.org/standard/830-1998.html. [Accessed: 01- Dec- 2020].