IoT-based Smart Aquaponic Farm

Final Year Project SRS

(BS IT)
By
S# Name Registration #/Roll #/Section Mobile # E-Mail

1. Hammad Arif Fa-19/BS IT/043 (B) 03435285073 fa-2019-bsit-043@lgu.edu.pk

2. Asjad Abbas Fa-19/BS IT/054 (B) 03474714005 fa-2019-bsit-054@lgu.edu.pk

Assigned Project ID: Proj/BSIT/Fa19/B/18

Supervised by: Lec Salahudin Ayubi ____________ (Signature)

Department of Information Technology

Lahore Garrison University

1|Page
 Contents
Chapter 1..............................................................................................................................................5
Introduction.........................................................................................................................................5
1.1. Introduction.........................................................................................................................5
1.2. Motivation............................................................................................................................5
1.3. Problem Statement..............................................................................................................5
1.4. Goals and Objectives...........................................................................................................6
1.5 Project Scope........................................................................................................................6
1.6 Process Model......................................................................................................................6
1.5. Proposed Solution................................................................................................................7
1.6. Nature of Project..................................................................................................................7
1.7. Overview...............................................................................................................................7
Chapter 2..............................................................................................................................................8
Background and Existing Work.........................................................................................................8
2.1. Introduction.........................................................................................................................8
2.2. Domain Knowledge..............................................................................................................8
1.2.1 Aquaponics..........................................................................................................................8
1.2.2 Water quality parameters..................................................................................................8
1.2.3 Bacteria................................................................................................................................8
1.2.4 Sensors and monitoring systems........................................................................................8
1.2.5 Plant and fish selection.......................................................................................................8
1.2.6 System design and management........................................................................................9
2.3. Existing Studies....................................................................................................................9
2.4. Comparison of Existing Systems.........................................................................................9
2.5. Summary............................................................................................................................10
Chapter 3............................................................................................................................................11
Requirements Specification..............................................................................................................11
3.1. Introduction.......................................................................................................................11
3.2. Interface Requirements.....................................................................................................11
3.2.1. Hardware Interface Requirements...........................................................................11
3.2.2. Software Interface Requirements.............................................................................12
3.3. Functional Requirements..................................................................................................13
3.3.1 Aquaponic System Design and Setup..............................................................................13
3.3.2 Monitoring and Control System......................................................................................13
3.3.3 Feeding System..................................................................................................................13
3.3.4 Harvesting and Maintenance System..............................................................................13

2|Page
 3.3.5 Data Management and Analysis System.........................................................................13
3.4. Use Case Model..................................................................................................................14
3.4.1 Use Case 1........................................................................................................................14
3.4.2 Use Case 2........................................................................................................................14
3.5. Use Cases............................................................................................................................15
3.5.1 Use Case 1..........................................................................................................................15
3.5.2 Use Case 2........................................................................................................................16
3.5.3 Use Case 3........................................................................................................................17
3.5.4 Use Case 4........................................................................................................................18
3.5.5 Use Case 5........................................................................................................................19
3.5.6 Use Case 6........................................................................................................................20
3.5.7 Use Case 7........................................................................................................................21
3.5.8 Use Case 8........................................................................................................................22
3.5.9 Use Case 9........................................................................................................................23
3.5.10 Use Case......................................................................................................................24
3.5.11 Use Case......................................................................................................................25
3.5.12 Use Case......................................................................................................................26
3.5.13 Use Case......................................................................................................................27
3.5.14 Use Case......................................................................................................................28
3.5.15 Use Case.........................................................................................................................29
3.6 Non-functional Requirements.................................................................................................30
3.6.1 Performance......................................................................................................................30
3.6.2 Reliability..........................................................................................................................30
3.6.3 Security..............................................................................................................................30
3.6.4 Consistency........................................................................................................................30
3.7 Resource Requirements...........................................................................................................30
3.7.1 Hardware Tools and Technology.....................................................................................30
3.7.2 Software Tools and Technologies....................................................................................31
3.7.3 Human Effort....................................................................................................................31
3.8 Database Requirements...........................................................................................................31
3.9 Project Feasibility....................................................................................................................31
3.9.1 Technical Feasibility.........................................................................................................31
3.9.2 Operational Feasibility.....................................................................................................32
3.9.3 Legal and Ethical Feasibility............................................................................................32
3.10 Summary................................................................................................................................32
3.11 Reference................................................................................................................................32

3|Page
Table 1: Use Case Table 1..................................................................................................................09
Table 2: Use Case Table 2..................................................................................................................14
Table 3: Use Case Table 3..................................................................................................................15
Table 4: Use Case Table 4..................................................................................................................16
Table 5: Use Case Table 5..................................................................................................................17
Table 6: Use Case Table 6..................................................................................................................18
Table 7: Use Case Table 7..................................................................................................................19
Table 8: Use Case Table 8..................................................................................................................20
Table 9: Use Case Table 9..................................................................................................................21
Table 10: Use Case Table 10..............................................................................................................22
Table 11: Use Case Table 11..............................................................................................................23
Table 12: Use Case Table 12..............................................................................................................24
Table 13: Use Case Table 13..............................................................................................................25
Table 14: Use Case Table 14..............................................................................................................26
Table 15: Use Case Table 15…………………………………………………………………………27
Table 16: Use Case Table 16…………………………………………………………………………28

Figure 1: Process Model.......................................................................................................................6

Figure 2: Use Case Diagram...............................................................................................................13
Figure 3: Use Case Diagram...............................................................................................................13

4|Page
 Chapter 1

Introduction
1.1. Introduction
Aquaponics is being related to the combination of both hydroponics (plant
framing) and fish farming with reuse of water. It can also be referred as Organic
farming because it doesn’t contain any chemical fertilizer instead of that it uses the
bacteria and waste of fish as fertilizer through the water. Ammonia in fish waste is
broken down by bacteria and converted into nitrites and then nitrates to be used as
fertilizer for the plants. Our project implements an IOT system in Aquaponics to
check the parameters of water so that it can be used for nourishing the plants and
the fishes growing in them. The one of important parts is the bacteria which
converts the fish waste into manure for plants. The entire system is monitored as
variation in the levels of from optimum range will lead to the death of plants and
fish. The project includes Arduino mega, Sensors like, PH sensor, water level
sensor, salinity sensor, turbidity sensor, temperature, humidity sensor, and light
sensor for transmitting data over the internet. The value transmitted by the
microcontroller is shown on LCD as well as on mobile application can control the
water pump, cooling fan and light for plant monitoring and fish feeding through it.
The detected value is sent as a message to the farmer.

1.2. Motivation
Technology always facilitates the people around the world by simplifying human life.
Smart Aquaponics farming, using concepts of Information Technology also simplify
modes of action in Aquaponics system. By searching and analyzing the problems, our
team realized that all of these problems can be resolved by using modern technology
tools and concepts. This smart Aquaponics farm consists of electrical and electronics
components but main components are ESP32 Wi-Fi module, sensors, servo motors
PVC pipes and fish tank.

1.3. Problem Statement

The purpose of the project is to build and design a smart aquaponics system. There are
some problems during the development of the system. For the excessive of the
ammonia, it is very dangerous to the aquatic life because that toxic can affect the fish.
Many people that own a pet at home have their busy time with their work. This
problem will lead to forgetfulness or absent to do regular care about their pet. The fish
need to give their food at regular intervals. This device automatically set their time by
the owner to give the food for the fish according to the fish feeding schedule. Other
than that, the plant that in the process of growing need regular attention to avoid from
dying. Therefore, the maintenance of these plant is done in an inappropriate method.

5|Page
Thus, the smart aquaponics system will be implemented to control the watering in
regular time. In the next few years, the population of the world rapidly increase when
the development of the building rises in the cities that will lead to dependence on the
clean water and scarcity of the green food. A major problem when the ecosystem in
the cities is unbalanced that accidentally make the soil not fertile for growing of the
plant. By using Nutrient Film Technique (NFT), this type of farming can be placed
everywhere and require small space to grow the plant.

1.4. Goals and Objectives

 The main target of this project is to invent a smart system that can monitored through
smartphone and view pH value which is one of the main factor that effect the growth of a
plant.
 To make sure there's no climate changes and weather related problems which stops plants
from getting enough water to grow
 To reduce the land utilization which means only less amount of land is needed to grow
plants, compared to traditional farming method
 To develop a system that gives no harm to the environment and people around by
providing clean, disease-less and also healthier products for a better life.

 Introducing automatic feeding to the fishes at regular intervals to prevent food waste
and water contamination.
 This research project aims to combine the physical aspects of a fish farm with the help
of sensors and collect data in order to monitor the processes in real time.

1.5 Project Scope

This project scope is to design the smart aquaponics system both in hardware part and
software part. For the hardware, it is required to design and build the prototype that
sustainable with the environment. Target audience in Pakistan as well as international level
such as India, Bangladesh, and Iran etc. Fulfil our food security needs in our country. It is
Scalable.

1.6 Process Model

For this project, we will use the Scrum model which is a category of agile methodology. The
ability to manage tasks in an organized way and have the planning necessary to reach them
makes it a crucial tool to save time and money.

6|Page
 Figure 1 : Process Model

1.5. Proposed Solution

The idea “Smart Aquaponics farm” is an IoT based project. This project is based on the basic
processes of Arduino IDE, ESP, and GSM technologies. Arduino IDE is the environment for
programming and uploading specified codes to the microcontrollers. Moreover, several
sensors and modules are being used in the project assembly. Each component has its purpose
but works on the same technology.
1.6. Nature of Project
Our project is an IoT (Internet of Things) based prototype. This project uses more than one
microcontroller that is used to program the entire project. Moreover, each microcontroller has
its specific purpose and runs some specific devices and sensors. The major components being
used in this project are enlisted below.
 PH sensor
 Temperature sensor
 Turbidity sensor
 Salinity sensor
 Ammonia Level sensor
 Water level sensor for check the water level in plant root
 Light sensor
 Humidity sensor
 Arduino Mega
 ESP 8266 Node MCU (Arduino WiFi module)
 Esp32 Cam module
1.7. Overview
Based on the results of testing and research conducted conclusions can be drawn
that the level of accuracy of the sensors used is quite high with an average success
rate of sensors, pH sensor of 92.353% and temperature of 97.907%. The process
of sending and receiving sensor data to an Internet of Things based server runs well

7|Page
using a WiFi connection. Growth of plant and fish on the smart aquaponics system
ranges from 25 C to 30 C and pond water pH between 7-7.5 with the intensity of
fish feeding 3 times a day.

Chapter 2

Background and Existing Work

2.1. Introduction
Aquaponics is being related to the combination of both hydroponics (plant framing) and fish
farming with reuse of water. It can also be referred as Organic farming because it doesn’t
contain any chemical fertilizer instead of that it uses the bacteria and waste of fish as fertilizer
through the water. Ammonia in fish waste is broken down by bacteria and converted into
nitrites and then nitrates to be used as fertilizer for the plants. Our project implements an IOT
system in Aquaponics to check the parameters of water so that it can be used for nourishing
the plants and the fishes growing in them. The one of important parts is the bacteria which
converts the fish waste into manure for plants. The entire system is monitored as variation in
the levels of from optimum range will lead to the death of plants and fish. The project
includes Arduino mega, Sensors like, PH sensor, water level sensor, salinity sensor, turbidity
sensor, temperature, humidity sensor, and light sensor for transmitting data over the internet.
The value transmitted by the microcontroller is shown on LCD as well as on mobile
application can control the water pump, cooling fan and light for plant monitoring and fish
feeding through it. The detected value is sent as a message to the farmer.
2.2. Domain Knowledge
1.2.1 Aquaponics
Aquaponics is a sustainable farming technique that combines aquaculture (raising fish) and
hydroponics (growing plants in water) in a closed system. The fish waste provides nutrients
for the plants, which in turn filter the water for the fish. This creates a symbiotic relationship
where both the fish and plants benefit from each other, and the water is continually recycled.
1.2.2 Water quality parameters
The success of an aquaponic system relies on maintaining optimal water quality parameters,
including pH, temperature, dissolved oxygen, ammonia, nitrite, and nitrate levels. Monitoring
these parameters is critical for the health and growth of both fish and plants.

8|Page
1.2.3 Bacteria
Bacteria play a crucial role in an aquaponic system by converting fish waste into forms of
nitrogen that can be used by plants. Nitrifying bacteria convert ammonia to nitrite, and then
nitrite to nitrate, which serves as a nutrient for plants.
1.2.4 Sensors and monitoring systems
To maintain optimal water quality parameters, sensors are used to measure various
parameters such as pH, temperature, dissolved oxygen, and ammonia levels. These sensors
are typically connected to a monitoring system that allows for real-time data collection and
analysis. This information can be used to adjust the system as needed to ensure optimal
conditions.
1.2.5 Plant and fish selection
The choice of plants and fish in an aquaponic system depends on various factors, including
climate, water temperature, and nutrient requirements. Some popular plants grown in
aquaponics include lettuce, herbs, and tomatoes, while common fish species include tilapia,
trout, and catfish.
1.2.6 System design and management
The design of an aquaponic system can vary depending on the available space, budget, and
other factors. Systems can range from small-scale hobby systems to large commercial
operations. Effective management of the system involves regular monitoring of water quality
parameters, adjusting feed rates for fish and plants, and maintaining equipment such as
pumps and filters.
2.3. Existing Studies
These systems use sensors to monitor water quality parameters such as pH, temperature, and
dissolved oxygen in real-time. Some of the existing systems also include features such as
automated fish feeding and water pump control to optimize the growth of both the plants and
the fish. Additionally, there are open-source projects and IoT platforms available that can be
used to build and deploy such systems. These tools offer features such as data logging and
visualization, which can help improve the efficiency and effectiveness of aquaponics
systems.
Moreover, there is an online android application developing platform (example of PaaS)
named Blynk. This tool allows users to design and develop app files for embedded
applications coordinating with microcontrollers such as Arduino, Raspberry, AMD, etc.
Blynk allows users to modify android applications according to their personal choices and
access their devices dynamically. Yet, no one has ever tried to create an application working
completely offline connected to an IoT model. Our project is a solution to this.
2.4. Comparison of Existing Systems

Criteria Existing Systems Smart Aquaponics Farm

Main Purpose Old system works manually. With the help of this system, we can give
our commands through internet.

Cost Existing system cost too much due This system is cheap as compared

9|Page
 to fertilizer expense. existing system.

Mobile Phone We do not use Mobile phone in We control this system through mobile.
existing system.

Monitoring and Manually Monitor and Control. We can control and monitor it through
control mobile.

Experience Rely on the farmer's experience to Farmer can remotely monitor and adjust
ensure plants and fish grow the system through mobile app.
properly.

Use Resources Inefficient use of resources. More efficient use of resources.

Table 1: Comparison of existing system

2.5. Summary
Aquaponics and IoT are technologies that can be used together to build systems for growing
plants and fish. There have been several studies and systems developed that use sensors and
other devices to monitor and control water quality parameters, automate feeding, and provide
web-based dashboards for monitoring and control. Open-source projects and IoT platforms
also exist that offer resources for building and deploying these systems. These tools can help
optimize aquaponics systems and make them more efficient.

10 | P a g e
 Chapter 3

Requirements Specification
3.1. Introduction
A Software Requirement Specification (SRS) is a depiction of a product framework to be
created. It spreads out functional and non-functional requirement, and may incorporate an
arrangement of utilization cases that portray client connections that the product must give.
The aim of this document is to gather and analyze and give an in-depth insight of the
complete Smart Aquaponic Farm by defining the problem statement in detail. Nevertheless, it
also concentrates on the capabilities required by stakeholders and their needs while defining
high-level product features. The detailed requirements of Smart Aquaponic Farm are
provided in this document.
The software requirement specification detail archive enrols enough and vital necessities that
are required for the venture advancement. To drive the necessities, the designer needs clear
and exhaustive comprehension of the items to be created or being produced. This is
accomplished with detailed and continuous communication with the project team and
customer till the completion of the software.
Nowadays, it can also be referred as Organic farming because it doesn’t contain any chemical
fertilizer instead of that it uses the bacteria and waste of fish as fertilizer through the water.
Aquaponics is being related to the combination of both hydroponics (plant framing) and fish
farming with reuse of water.
3.2. Interface Requirements
An important component of the overall system architecture for a Smart Aquaponic Farm is
the interface requirements. These specifications outline the elements that are required and
how they should work together to make the system work as planned.

11 | P a g e
3.2.1. Hardware Interface Requirements
For a Smart Aquaponic Farm, the following hardware interface requirements are necessary:
a. GSM Module: For the system to be able to communicate with the mobile network and
accept user commands, a GSM module is required. In our system, we have proposed to
use the SIM900A GSM Modem. This modem uses a quad-band network interface
working on 4G VOLTE technology.
b. Microcontroller: The different elements of the smart aquaponic farm, such as lighting,
Colling fans, and other appliances, should be controlled by a microcontroller. In our
project, we have used the Arduino Mega 2560 PRO 16U2-based microcontroller
development board. Technical details will be discussed in section 5.3.
c. Sensors: Sensors for detecting changes in the farm, such as those in temperature,
humidity, and turbidity, should be included in the system. Temperature & Humidity
Sensor, PH Sensor, Salinity & Ammonia level Sensor, and other sensor details will be
discussed later.
d. Power Supply: For the system to be able to run continuously without interruption, it
needs a dependable power source. For instance, we might use a solar power supply, a
battery, and a dc-generator, all running at the same time might be able to drive the system
smoothly.
e. Communication Interface: A communication interface must be present in the system for
the microcontroller to be able to send and receive data to and from the GSM module.
Hence, to make the GSM module communicate with the Arduino.
f. Sensor Interface: For the microcontroller to be able to receive data from the sensors, the
system should have a sensor interface. Similar to the GSM interface, sensors also have
specified input and output pins that are connected to one of the data pins of the Arduino
board.
The Smart aquaponic farm, many parts are connected and successfully interact thanks to
these hardware interface specifications. They make sure the system works as it should,
offering a dependable and effective aquaponic farm solution.
3.2.2. Software Interface Requirements
To make sure that a Smart aquaponic farm performs as planned and offers an effective and
dependable solution for aquaponic farm, it is crucial to understand the software requirements.
A Smart aquaponic farm needs the following essential software components, among others:
a. User Interface: Users should be able to manage their Aquaponic Farm using the system's
user-friendly interface on their smartphones. Hence, in this system, no complex interface
is required. Only the smartphone’s built-in messaging application is enough to control the
entire system.
b. Database Management: The system should have a database to store information about
the various appliances and devices in the Farm. Moreover, the database will store data
received from each sensor (either digital or analogue) in a pattern that we want it to do.
c. Fault Detection: The system should be able to detect faults or malfunctions and send
alerts to the user to ensure that issues are addressed promptly. Hence, if we create systems
that generate alerts, we might have control over malfunctions and hazardous situations.
d. Security: This system works on Mobile Networks. Mobile networks are linked to each
other at different levels. While, if we use an encrypted system, there will be fewer

12 | P a g e
 security issues and higher efficiency. For this purpose, we will need authority and
approval from PTA (Pakistan Telecommunication Authority) to use end-to-end encrypted
mobile systems.
e. Remote Access: The system should allow users to access the smart aquaponic farm
remotely, such as when they are away from Farm. This factor is important because
traditional smart aquaponic farm work using the internet, and in some cases. If a person
has no internet connection and is far away from home, GSM technology is essential for
such purposes. Because the lowest possible connection among devices is the GSM 2 nd
Generation network. Hence, using our system, a person could have a hold on to the entire
system remotely even without the internet.
f. Customization: The system should be customizable to allow users to set their
preferences for various appliances and devices. Therefore, this system is designed taking
into consideration all the necessities and common uses of common people. Thus, as the
requirement changes, so does the working of the system.
g. Compatibility: The system should be compatible with various appliances and devices
commonly found in Aquaponic Farm. This specification is for domestic use only. While,
for commercial and industrial use, the system could be designed depending on the user’s
requirements.
These software requirements ensure that the system is user-friendly, secure, and customizable
while providing an efficient and reliable solution for Smart Aquaponic Farm. The
requirements ensure that the system functions as intended and provides a seamless and
intuitive user experience.
3.3. Functional Requirements
Functional Requirements are the requirements of a system that usually affect efficiency,
reliability, user experience, etc. The functional requirements of our project are enlisted below.
3.3.1 Aquaponic System Design and Setup
A setup that allows for the growth of both aquatic animals and plants. A water circulation
system to ensure water is properly circulated. A filtration system to ensure the water is free of
toxins and waste. A lighting system to ensure plants receive adequate light. A temperature
control system to maintain optimal temperature conditions for both plants and animals. An
oxygenation system to ensure adequate oxygen supply for the aquatic animals.
3.3.2 Monitoring and Control System
A sensor system to monitor water quality, temperature, pH levels, and oxygen levels. An
automation system to control water flow, temperature, and lighting. A remote monitoring
system that allows the farmer to monitor the system from a remote location. A notification
system that alerts the farmer in case of any anomalies or issues.
3.3.3 Feeding System
A feeding system that automatically feeds the aquatic animals on a schedule. A feeding
system that can be remotely controlled. A feeding system that can adjust the amount of feed
depending on the size of the fish and the stage of growth.
3.3.4 Harvesting and Maintenance System
A system that facilitates easy harvesting of the aquatic animals and plants. A system that
automatically removes any waste or debris from the system. A maintenance system that

13 | P a g e
facilitates cleaning of the system components. A maintenance system that can detect and
repair any faults in the system.
3.3.5 Data Management and Analysis System
A system that collects and stores data on water quality, temperature, and feeding schedule. A
system that can analyze the data to provide insights on the performance of the system. A
system that can provide recommendations on how to optimize the system for better
performance.

3.4. Use Case Model

3.4.1 Use Case 1

Figure 2: Use Case Diagram

14 | P a g e
3.4.2 Use Case 2

Figure 3: Use Case Diagram 2

15 | P a g e
3.5. Use Cases
3.5.1 Use Case 1

Table 2: Use Case Table 1

User Login
Use Case ID UC-01

Use Case Summary User can login after registration and also get notification by
Admin.
Pre-condition User should have internet connection and must be login on
app.

Scenario Notes

Step # Scenario

1 The use case starts when the user login on this application.

2 Authentication.

3 View list of information and get notification.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The user is allowed to view information either he/she is registered to Blynk App.

Post Conditions

Step # Description

1 The user will be registered and have access this application.

Non-Functional Requirements
1. None
Use Case Cross References

Includes Login (email, password)

Extends Incorrect email or password and can view information and get notification.

16 | P a g e
3.5.2 Use Case 2
Table 3: Use Case Table 2

User Sign-up

Use Case ID UC-02

Use Case Summary User can sign-up and also get notification by Admin.

Pre-condition User should have internet connection and must be sign-up on

app.

Scenario Notes

Step # Scenario

1 The use case starts when he/she signup on this application.

2 Authentication.

3 View list of information and get notification.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The user is allowed to view information either he/she is registered to Blynk App.

Post Conditions

Step # Description

1 The user will be registered and have access on this application.

Non-Functional Requirements
1. None
Use Case Cross References

Includes Sign-up (name, email, password, address, phone number)

Extends None.

17 | P a g e
3.5.3 Use Case 3
Table 4: Use Case Table 3

User view information

Use Case ID UC-03

Use Case Summary User can view information.

Pre-condition User should have internet connection and must be login on

app.

Scenario Notes

Step # Scenario

1 The use case starts when the user login on this application.

2 Authentication.

3 View information about Hardware.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The user is allowed to view information either he/she is view data about Hardware.

Post Conditions

Step # Description

1 The user will be registered and have access to get any notification in this
application.
Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends Can view information.

3.5.4 Use Case 4

Table 5: Use Case Table 4

18 | P a g e
 User can control system

Use Case ID UC-04

Use Case Summary User can control system.

Pre-condition User should have internet connection to control system by

using app.

Scenario Notes

Step # Scenario

1 The use case starts when the user login on this application.

2 Authentication.

3 User can control a fully system.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The user is allowed to control system either he/she is registered to Blynk App.

Post Conditions

Step # Description

1 The user will be registered and have access to get any notification in this system.

Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends Can Control system.

3.5.5 Use Case 5

Table 6: Use Case Table 5

User can View Water Quality

19 | P a g e
 Use Case ID UC-05

Use Case Summary User can view water quality.

Pre-condition User should have internet connection to view PH value by

using app.

Scenario Notes

Step # Scenario

1 The use case starts when the user login on this application.

2 Authentication.

3 User can view water quality.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The user is allowed to view water quality either he/she is registered to Blynk App.

Post Conditions

Step # Description

1 The user will be registered and have access to get notification in this system.

Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends Can view water quality.

3.5.6 Use Case 6

Table 7: Use Case Table 6

User can control Feeding System

Use Case ID UC-06

20 | P a g e
 Use Case Summary User can control feeding system.

Pre-condition User should have internet connection to control feeding

system by using app.

Scenario Notes

Step # Scenario

1 The use case starts when the user login on this application.

2 Authentication.

3 User can control feeding system.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The user is allowed to control feeding system either he/she is registered to Blynk App.

Post Conditions

Step # Description

1 The user will be registered and have access to get notification about feeding system.

Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends Can control feeding system.

3.5.7 Use Case 7

Table 8: Use Case Table 7

User can control pump, Colling Fan & Lights

Use Case ID UC-07

Use Case Summary User can control pump, Colling Fan & Lights.

21 | P a g e
 Pre-condition User should have internet connection to control these
function by using app.

Scenario Notes

Step # Scenario

1 The use case starts when the user login on this application.

2 Authentication.

3 User can control pump, Colling Fan & Lights.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The user is allowed to control pump, Colling Fan & Lights system either he/she is
registered to Blynk App.
Post Conditions

Step # Description

1 The user will be registered and have access to get notification about these system.

Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends Can control pump, Colling Fan & Lights.

3.5.8 Use Case 8

Table 9: Use Case Table 8

22 | P a g e
 User Logout
Use Case ID UC-08
Use Case Summary User can logout after checking notification and information.
User should have internet connection and must be login after
Pre-condition
this he/she can be logout.
Step # Scenario
1 The use case starts when the user wants to logout from this application.
2 Authentication.
After checking notification and information he/she click the logout button to
3
logout from the app.
4 This use case ends.
Alternate Scenarios: : Incomplete/Incorrect Information
None.
Exceptions / Alerts
The user is allowed to logout after checking the notification and information from Blynk App.
Post Conditions
Step # Description
The user will be registered and have access to get any notification in this application
1
after that he/she will be logout.
Non-Functional Requirements
1 None
Use Case Cross References
Includes None
Extends None
3.5.9 Use Case 9
Table 10: Use Case Table 9

Admin Sign-up

Use Case ID UC-01

Use Case Summary Admin needs to sign-up on this app.

Pre-condition Admin should have internet connection and must be signup

on app.

Scenario Notes

Step # Scenario

1 The use case starts when the admin sign-up on this application.

2 Authentication.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts

23 | P a g e
 1. The admin is allowed to view list of vaccination when he/she is registered to Blynk App.

Post Conditions

Step # Description

1 The admin will be registered and have access on this application.

Non-Functional Requirements
1. None
Use Case Cross References

Includes Sign-up (name, email, password, address, phone number)

Extends None.

3.5.10 Use Case

Table 11: Use Case Table 10

Admin Login

Use Case ID UC-02

Use Case Summary Admin can login after registration and view all details.

Pre-condition Admin should have internet connection and then he/she will
be login on app.

Scenario Notes

Step # Scenario

1 The use case starts when the admin login on this application.

2 Authentication.

3 View information and get notification from and users.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The admin is allowed to view list and reports when he/she is registered to Blynk App.

24 | P a g e
 Post Conditions

Step # Description

1 The admin will be registered and have access this application.

Non-Functional Requirements
1. None
Use Case Cross References

Includes Login (email, password)

Extends Incorrect email or password and can view information and get notification.

3.5.11 Use Case

Table 12: Use Case Table 11

Admin can Manage Database

Use Case ID UC-03

Use Case Summary Admin can manage database after registration on this app.

Pre-condition Admin should have internet connection and must be login on

app to manage database.

Scenario Notes

Step # Scenario

1 The use case starts when the admin login on this application.

2 Authentication.

3 After login he/she can manage database on this app.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The admin is allowed to manage Database on Blynk App.

Post Conditions

Step # Description

25 | P a g e
 1 The admin will be registered and have access manage database from this
application.
Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends Email.

3.5.12 Use Case

Table 13: Use Case Table 12

Admin can update sensor data

Use Case ID UC-04

Use Case Summary Admin can update sensor data after registration.

Pre-condition Admin should have internet connection and must be login to

update the sensor data.

Scenario Notes

Step # Scenario

1 The use case starts when the admin login on the database.

2 Authentication.

3 After login he/she can do changes (like delete and insert the sensor data) then
update the data.
4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The Admin is allowed to update the sensor data when he/she is registered on Database.

Post Conditions

Step # Description

26 | P a g e
 1 The admin will be registered and have access to update the sensor data.

Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends None.

3.5.13 Use Case

Table 14: Use Case Table 13

Admin can change sensor

Use Case ID UC-05

Use Case Summary Admin can change sensor after registration.

Pre-condition Admin should have internet connection and must be login to

change sensor.

Scenario Notes

Step # Scenario

1 The use case starts when the admin change sensor.

2 Authentication.

3 After login he/she can do changes (like add or remove sensor) then change
sensor.
4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The Admin is allowed to change the sensor when he/she is registered.

Post Conditions

Step # Description

1 The admin will be registered and have access to change the sensor.

Non-Functional Requirements
1. None
Use Case Cross References

27 | P a g e
 Includes None.

Extends None.

3.5.14 Use Case

Table 15: Use Case Table 14

Admin can change values

Use Case ID UC-06

Use Case Summary Admin can change values after registration.

Pre-condition Admin should have internet connection and must be login to

change values.

Scenario Notes

Step # Scenario

1 The use case starts when the admin change values.

2 Authentication.

3 After login he/she can do changes (like add or sub) then change value.

4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The Admin is allowed to change the value when he/she is registered.

Post Conditions

Step # Description

1 The admin will be registered and have access to change the value.

Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends None.

28 | P a g e
3.5.15 Use Case

Table 16: Use Case Table 15

Admin Logout

Use Case ID UC-07

Use Case Summary Amin can logout after checking notification and information
etc.
Pre-condition Admin should have internet connection and must be login
after this he/she can be logout.

Scenario Notes

Step # Scenario

1 The use case starts when the admin wants to logout from this database.

2 Authentication.

3 After checking notification and information he/she click the logout button to
logout.
4 This use case ends.

Alternate Scenarios: Incomplete/Incorrect Information

None

Exceptions / Alerts
1. The admin is allowed to logout after checking the notification and information from
database.
Post Conditions

Step # Description

1 The admin will be registered and have access to delete insert the data after that
he/she will be logout.
Non-Functional Requirements
1. None
Use Case Cross References

Includes None.

Extends None.

29 | P a g e
3.6 Non-functional Requirements
The features that describe how well a system executes its functions are known as non-
functional requirements. Some of the non-functional needs that are crucial to take into
account for a Smart aquaponic farm include:
a. Performance
b. Reliability
c. Security
d. Consistency

30 | P a g e
3.6.1 Performance
Performance is one important and related concern. Performance is the ability of the system to
always run acceptably. In mission-critical systems, even the smallest delay in processing data
can be unacceptable.
3.6.2 Reliability
Reliability specifies how likely the system or its element would run without a failure for a
given period of time under predefined conditions. Traditionally, this probability is expressed
in percentages. For instance, if the system has 85 percent reliability for a month, this means
that during this month, under normal usage conditions, there’s an 85 percent chance that the
system won’t experience critical failure.
3.6.3 Security
Particularly important where sensitive information such as personal details or financial data is
being handled, security includes other NFRs such as confidentiality and authentication to
ensure this information is protected by default.
3.6.4 Consistency
The model would be able to generalize well and perform consistently regardless to the
variations in the data and the environment in which it is deployed. To ensure consistency in
Smart Aquaponic model, several measures will be taken during the development and
Validation process. These include using high-quality and diverse datasets, including data
from different populations and imaging modalities, performing rigorous cross-validation and
testing on independent datasets, testing the model's performance under different conditions
and Settings, and monitoring the model's performance over time to ensure it remains
consistent and accurate.
3.7 Resource Requirements
3.7.1 Hardware Tools and Technology
 Laptop-(Core i5 5th generation)
 RAM- (minimum 8gb)
 Mobile (Android)
 Fish tank
 Pipes for hydroponics design
 Filter
 LCD 16 x 4
3.7.2 Software Tools and Technologies
 Arduino IDE software
 Blynk App

31 | P a g e
3.7.3 Human Effort

3.8 Database Requirements

Large amounts of data are generally produced by our system from multiple sources such as
sensors, controllers, and other devices. A reliable and scalable database is necessary to store,
process, and efficiently retrieve this data. The following are some of the essential database
specifications for Smart Aquaponic Farm:
a. Scalability: The database needs to be able to manage enormous amounts of data
produced by IoT devices and grow with the system. Data partitioning among several
nodes and the use of a distributed database design can accomplish this.
b. High availability: There should be little to no downtime and little inconvenience for the
database. Using redundant hardware and software configurations, such as clustering and
replication, can help achieve this.
c. Quick data retrieval: For the system to access and process the data produced by IoT
devices quickly, the database should be optimised for fast data retrieval. This can be
accomplished by utilising indexing and caching strategies, as well as query optimization.
d. Flexibility: The database should be adaptable to provide simple integration with other
programmes and systems. This can be done via developing APIs and web services, as
well as employing common data formats and interfaces.
e. Analytics and reporting: To enable users to evaluate and display the data produced by
IoT devices, the database should offer analytics and reporting. This can be accomplished
by putting in place data analysis and visualisation tools, supporting data warehousing, and
BI.
3.9 Project Feasibility
3.9.1 Technical Feasibility
The proposed system is technically feasible as it will produce output in given time, response
time would be minimized, easy to communicate and will satisfy the user requirement.
3.9.2 Operational Feasibility
The system would be operationally feasible as it would be operable with less training to
operate the system. It consist of very basic modules which are easily understandable by

32 | P a g e
individuals having less knowledge of technical things or do not come from an Information
Technology background.
3.9.3 Legal and Ethical Feasibility
It's critical to take into account if the solution complies with all applicable legal and
regulatory standards, including those about data protection, security, and intellectual property
rights. Our system is designed to meet the laws and regulations of the telecom authorities
where data privacy and security are kept at the top of the priority list.
3.10 Summary
The Software Requirements Specification (SRS) for Smart Aquaponic Farm outlines the
necessary functional and non-functional requirements, interface requirements, use case
models, use cases, and resource requirements. The interface requirements include front- end
and back-end software, hardware interface requirements, and software interface requirements.
Functional requirements describe the features of the Farm, Aquaponic System Design and
Setup, Monitoring and Control System, Feeding System, Harvesting and Maintenance
System, Data Management and Analysis System. Non-functional requirements include
performance, reliability, security, and consistency. The resource requirements include
Hardware Tools and Technology, Software Tools and Technologies, and Human Effort. The
SRS aims to provide a comprehensive overview of the Smart Aquaponic Farm project,
outlining the necessary features and requirements for successful development and
implementation.
3.11 Reference
[1] Development of Aquaponic System using Solar Powered Control Pump,” IOSR Journal
of Electronics and Electrical Engineering (IOSR-JEEE), vol. 8, no. 6, p. 6, 2013J.
[2] Wang, N. Zhang, and M. Wang, Wireless sensors in agriculture and food industry—
Recent development and future perspective, Computers and Electronics in Agriculture, vol.
50, no. 1, pp. 1–14, Jan. 2006.
[3] Fiona Regan, Ant’oin Lawlor, and Audrey McCarthy, “Smart Coast Project– Smart Water
Quality Monitoring System”, Environmental Protection Agency, Synthesis Report. July.
2009.
[4] Watten B. Busch R. Tropical production of tilapia (Sarotherodonaurea) and tomatoes
(Lycopersiconesculentum) in a small-scale recirculating water system.
[5] Shete AP, Verma AK, Tandel RS, Prakash C, Tiwari VK, Hussain T. Optimization of
water circulation period for the culture of goldfish with spinach in an aquaponic system.
Journal of Agriculture Science 2013; 5(4):26-30.
[6] J. E. Racoky, "Aquaculture- Aquaponics system," Agricultural Statement Experiment,
2003.

33 | P a g e