CHAPTER 3

SYSTEM ANALYSIS
3.1 Requirement Analysis
The Requirement Analysis phase is the critical first step in developing the Smart Health and Air
Quality Monitoring System, serving as the technical and conceptual foundation upon which the entire
IoT ecosystem is built. This phase is essential because it allows the development team to understand
the intricate relationship between environmental variables and physiological responses, which in turn
guides the hardware selection, backend architecture, and frontend dashboard design. The system is
specifically engineered to bridge the gap between "invisible" indoor air pollutants and the user’s
health awareness, addressing the unique challenges of modern workplace wellness.
The key stakeholders in this analysis include corporate employees, students in laboratory
environments, facility managers, and health and safety officers. Each of these stakeholders has
specific needs and expectations from the platform. For the primary users (employees and students),
the core concerns are real-time access to air quality data, the ability to monitor their own biometric
vitals (Heart Rate, $SpO_2$, Stress), and receiving clear, actionable recommendations on when to
relocate to a healthier work zone. Facility managers, on the other hand, require a system that provides
a macro-view of the building's health across 5 distinct stations, allowing them to identify ventilation
"dead zones" and manage the environment more effectively.
A critical aspect of requirement analysis for this IoT system is understanding the hardware-software
synergy and data integrity issues. Since the system relies on multiple sensors (MQ135, DS18B20,
MAX30102, and GSR) connected to an ESP32, the requirement analysis must ensure that the
sampling rates and data transmission frequencies are optimized. The system must be designed to
handle analog-to-digital conversion with high precision using the ADS1115 to ensure that subtle
physiological changes—such as a rise in skin conductance due to environmental stress—are captured
accurately. Furthermore, the backend must be built to work in high-concurrency environments, as the
TiDB database will be receiving constant data streams from five nodes simultaneously.
A comprehensive requirement analysis also involves creating user personas to represent the different
types of users who will interact with the health monitoring platform. These personas help developers
understand the diverse range of environments the system will serve, from high-concentration
engineering labs where chemical vapors (ammonia) might be a concern, to quiet office spaces where
$CO_2$ buildup and thermal comfort are the primary stressors. By capturing the biometric and
environmental needs of these personas, the system can ensure that the recommendation engine offers
relevant, life-improving advice for every individual.
Additionally, requirement analysis needs to identify and prioritize the core functionalities of the
platform. These include real-time sensor data acquisition, distributed data persistence in TiDB,
biometric-environmental correlation logic, and the automated "Relocation Alert" system.
Understanding the hierarchy of these features is essential to developing a robust system that meets the
immediate safety needs of users while leaving room for further development, such as AI-driven
predictive health modeling or integration with smart HVAC actuators in the future.
The final component of requirement analysis is the formal documentation of specifications. This
involves creating detailed technical documents that include functional requirements (e.g., "The system
shall suggest Station 4 if its AQI is 20% better than the current station") and non-functional
requirements (e.g., "The React dashboard shall update within 2 seconds of a sensor change"). This
documentation becomes the foundation upon which the system design, Spring Boot development, and
hardware testing phases are based. It ensures that the expectations for accuracy, speed, and reliability
are met, reducing the risk of system failure in a real-world health-monitoring scenario.
In conclusion, the requirement analysis phase for the Smart Health and Air Quality Monitoring
System is about understanding and aligning the physiological needs of users with the technical
capabilities of IoT and Distributed SQL technologies. This thorough analysis ensures that the platform
is built to cater to the modern workforce, making it an effective tool for maintaining long-term health
and productivity in indoor environments.

3.2 Functional Requirements

Functional requirements define the specific actions that the system must be able to perform in order to
meet the wellness and safety needs of its users. For a Smart Health and Air Quality Monitoring
System, these actions include core functionalities such as real-time sensor data acquisition, biometric-
environmental correlation, automated relocation recommendations, and cloud-based data persistence.
These functionalities are critical to ensure that users can monitor their physical well-being in relation
to their surroundings and make informed decisions about their workspace.
The Real-time Data Acquisition and Processing is the most fundamental functionality of the
system. The ESP32 microcontroller must be able to simultaneously poll data from the MQ135 (Air
Quality), DS18B20 (Temperature), MAX30102 (BPM/$SpO_2$), and GSR (Stress) sensors. This
process involves utilizing the ADS1115 ADC to convert analog signals into precise digital values. The
system must process these raw inputs locally to provide immediate feedback while concurrently
formatting the data into JSON structures for transmission to the backend API.
Once the data is captured, the Multi-Station Monitoring and Comparison functionality allows the
system to manage data from five distinct locations. The backend, powered by Spring Boot, must be
capable of receiving and identifying data packets from each of the five sensor nodes. The system
should maintain a real-time "Environmental Map" of the workspace, comparing the Air Quality Index
(AQI) and temperature of all stations. This allows the system to identify which of the five locations
currently offers the most favorable conditions for human health.
The Intelligent Recommendation and Relocation Logic is a crucial functionality that transforms the
system from a passive monitor into an active health assistant. Based on predefined safety thresholds
(e.g., $CO_2$ levels exceeding 1000ppm or $SpO_2$ dropping below 95%), the system must
automatically analyze the data from all five stations. If the user’s current station is identified as
"Poor," the system must suggest the specific station number (e.g., "Move to Station 4") that currently
holds the "Optimal" status. This logic must be dynamic, updating as environmental conditions shift
throughout the workday.
A key feature of the platform is the Biometric-Environmental Correlation. The system must be able
to map the user’s physiological vitals against the ambient air quality. For instance, if the GSR sensor
detects a high stress level, the system should check if the local temperature or CO₂ levels are also
high, providing a "Wellness Analysis" that explains the likely cause of the physiological change. This
correlation must be visualized on the [Link] dashboard, allowing users to see their heart rate and
stress trends overlaid with environmental pollutant levels.
Real-time Alerts and Feedback are essential to keep users informed without requiring constant
manual checks of the dashboard. The system must support dual-layer notifications:
 Localized Alerts: The ESP32 must update the connected OLED screen instantly with current
vitals and room status.
 Web Dashboard Notifications: The React frontend must trigger visual alerts (e.g., red
flashing indicators or pop-up prompts) when a health or environmental parameter reaches a
critical state, suggesting immediate relocation.
In addition to real-time monitoring, the system must include Historical Data Logging and Analytics.
Utilizing the TiDB distributed database, the system must store every sensor reading with a precise
timestamp. Users should be able to access a "Health History" section on the dashboard to view their
average daily heart rate, $SpO_2$ trends, and the air quality of the stations they occupied. This allows
for long-term health tracking and the identification of "Hazardous Zones" within a building that
consistently suffer from poor ventilation.
Finally, the platform should incorporate a System Configuration and Calibration module. Through
the web interface, administrators or users should be able to set custom thresholds for alerts based on
personal health needs (e.g., a user with asthma might set a lower threshold for air quality alerts). The
system should also support a "Calibration Mode" where the MQ135 and GSR sensors can be zeroed
or baselined to ensure accuracy over time. By allowing these customizations, the platform remains
flexible and reliable for different user profiles and environments.
In summary, the functional requirements for the Smart Health and Air Quality Monitoring System
cover a broad range of features that facilitate environmental sensing, biometric tracking, intelligent
relocation, and long-term data analysis. By ensuring these features are accurate, responsive, and
integrated into a user-friendly dashboard, the platform serves as an essential tool for maintaining
safety and productivity in the modern workplace.

3.3 Non-functional Requirements

Non-functional requirements define the performance, usability, security, and reliability standards that
the system must meet. These requirements focus on "how" the system operates rather than "what" it
does, and they are critical in ensuring that the IoT ecosystem remains effective, scalable, and
trustworthy. For a Smart Health and Air Quality Monitoring System, these requirements are
particularly vital due to the continuous nature of biometric data and the need for high-speed
synchronization between hardware nodes and the cloud backend.
Performance and Real-time Latency are paramount for this system. Users rely on immediate
feedback to make health-related decisions, such as relocating due to poor air quality. To address this,
the system must be optimized for low-latency data transmission. The ESP32 nodes must be capable of
transmitting sensor packets to the Spring Boot API within a sub-second window. On the frontend, the
[Link] dashboard must utilize efficient state management or WebSockets to ensure that visual
gauges and alerts update almost instantly as environmental conditions shift, providing a smooth and
responsive user experience.
Scalability and Data Persistence are critical non-functional requirements. As the system expands
from a single room to an entire building complex with dozens of stations, it must handle the
exponential increase in data traffic without performance degradation. The choice of TiDB as the
distributed SQL database is essential here; its architecture allows for horizontal scaling, enabling the
system to manage millions of rows of historical health data and high-concurrency writes from
multiple IoT nodes simultaneously. This ensures that the platform remains responsive even as the
network of monitored stations grows.
The system must also be designed for High Availability and Fault Tolerance. Since rural or
industrial work environments may have intermittent power or network issues, the hardware must be
designed to reconnect to the Wi-Fi automatically. To ensure high availability, the Spring Boot backend
should ideally be deployed in a containerized environment (like Docker) with load balancing.
Additionally, the system should implement "Graceful Degradation"—if the cloud connection is lost,
the local OLED display on the ESP32 must continue to function, ensuring the user is never left
without basic safety information.
Security and Data Privacy are top priorities, as the platform handles sensitive physiological data
including Heart Rate and $SpO_2$. The system must implement strong encryption protocols such as
SSL/TLS for all communication between the ESP32 nodes, the API, and the React frontend.
Furthermore, the TiDB database must employ data-at-rest encryption to protect stored health logs.
Given the sensitive nature of biometrics, the system should be designed with privacy-first principles,
ensuring that a user’s vitals are anonymized or accessible only through secure, authenticated sessions
to prevent unauthorized access.
Usability and Human-Centric Design are essential, especially for users who may be distracted by
work or have limited technical expertise. The React dashboard should feature an intuitive UI with
high-contrast visual indicators (Red/Yellow/Green) to represent health and air quality status. The
design must be simple, using clear icons for heart rate, stress, and pollutants. Furthermore, the
localized OLED interface must be readable at a glance, providing the most critical data points without
overwhelming the user with technical jargon.
Reliability and Accuracy are fundamental for a system monitoring human health. The sensors must
be calibrated to provide consistent readings over time. The system should be designed to handle
"Noisy Data" from sensors like the GSR or MAX30102 by implementing digital filters in the ESP32
code to prevent false alarms caused by minor movements. Reliability testing must ensure that the
"Relocation Logic" consistently identifies the correct "Optimal Zone" among the 5 stations based on
the most recent and accurate data available.
Lastly, Local Buffer Functionality is an important consideration for environments with inconsistent
internet. The ESP32 should ideally include a basic buffering mechanism where critical alerts are
stored locally and synced to the TiDB database once the connection is restored. This ensures that the
user’s "Health History" remains complete and that no significant environmental spikes are missed
during brief network outages.
In summary, the non-functional requirements of the Smart Health and Air Quality Monitoring System
focus on ensuring the system is fast, scalable, secure, and highly reliable. These requirements are
crucial for transforming raw sensor data into a dependable health-monitoring tool, providing a
seamless and safe experience for the modern workforce.

3.4 Feasibility Study (Technical, Economic, Social)

A feasibility study is a critical step in assessing the practicality of building the Smart Health and Air
Quality Monitoring System. This study evaluates whether the project can be successfully
implemented from technical, economic, and social perspectives. Each of these dimensions is essential
to ensuring that the IoT ecosystem is not only viable as a prototype but also sustainable and scalable
for real-world workplace deployment.
Technical Feasibility
From a technical standpoint, the project’s success relies on the seamless integration of embedded
hardware with a modern full-stack software architecture. The use of the ESP32 microcontroller is
technically ideal due to its integrated Wi-Fi capabilities and dual-core processing, which allows it to
handle sensor polling and cloud communication simultaneously. The inclusion of the ADS1115 16-bit
ADC ensures that the system overcomes the common technical hurdle of analog noise, providing the
high-precision data required for sensitive biometric markers like GSR and $SpO_2$.
On the software side, the choice of Spring Boot and TiDB provides a highly feasible path for data
management. Unlike traditional relational databases that may struggle with the "write-heavy" nature
of 5 continuous sensor nodes, TiDB’s distributed SQL architecture offers the horizontal scalability
needed to maintain performance as more stations are added. [Link] further enhances technical
feasibility by providing a component-based structure for the dashboard, making it easy to visualize
real-time gauges and historical trends. The availability of robust libraries for MQTT or RESTful
communication ensures that the "Hardware-to-Cloud" data bridge is reliable and efficient.
Economic Feasibility
The economic feasibility of the platform focuses on the financial aspects of building and maintaining
a multi-node sensing environment. Initially, development costs are kept low by utilizing cost-
effective, off-the-shelf sensors (MQ135, DS18B20, MAX30102) and open-source software
frameworks. Since Spring Boot, React, and TiDB (Community Edition) do not require expensive
licensing fees, the primary economic investment is redirected toward high-quality hardware
components and cloud hosting.
Long-term economic sustainability can be achieved through a "Wellness-as-a-Service" model.
Corporate offices or educational institutions can implement the system to reduce costs associated with
"Sick Building Syndrome," such as employee absenteeism and decreased productivity. By identifying
poorly ventilated zones, facility managers can optimize HVAC usage, leading to significant energy
savings. Additionally, the modular nature of the ESP32 nodes allows for "Incremental Scaling," where
an organization can start with two stations and economically expand to five or more as their budget
allows, making the system financially accessible for various scales of operation.
Social Feasibility
From a social perspective, the platform has the potential to make a significant positive impact on
public health and workplace culture. By providing "Environmental Transparency," the system
empowers individuals to take control of their own well-being. In a social context where indoor air
quality is often an "invisible" problem, this project creates a "Health-First" mindset. The system’s
ability to recommend a healthier workspace fosters a supportive environment where employee safety
is prioritized over static seating arrangements.
Furthermore, the integration of biometric tracking with environmental data serves as an educational
tool, helping users understand the social and physical costs of poor ventilation. In university labs or
high-density offices, the platform can reduce social anxiety related to air pollutants and heat stress,
contributing to a more comfortable and productive community. The user-friendly nature of the React
dashboard and localized OLED alerts ensures that the system is socially inclusive, catering to users
regardless of their technical background.
Conclusion
In conclusion, the feasibility study demonstrates that the Smart Health and Air Quality Monitoring
System is technically viable, economically sustainable, and socially beneficial. By leveraging
distributed database technology and high-precision IoT sensing, the platform addresses the critical
need for workplace wellness in a manner that is both practical to build and impactful to use.

3.5 Requirements Specifications

The requirements specifications provide a detailed list of the hardware and software components
necessary to design, develop, and implement the Smart Health and Air Quality Monitoring System
effectively. These specifications ensure that the integrated system can handle real-time data
acquisition, cloud processing, and responsive user visualization.
3.3.1 Hardware Requirements
The hardware layer consists of the sensing nodes and the central processing unit responsible for local
data handling and wireless transmission.
  Microcontroller: ESP32 (Dual-core, integrated Wi-Fi and Bluetooth for cloud connectivity).
 Air Quality Sensor: MQ-135 (Used for detecting $CO_2$, Ammonia, and other atmospheric
pollutants).
 Temperature Sensor: DS18B20 (High-precision digital thermometer for ambient and body
temperature).
 Pulse & Oxygen Sensor: MAX30102 (Integrated heart-rate monitor and pulse oximeter).
 Stress Sensor: GSR (Galvanic Skin Response) (Used to measure skin conductivity for
stress level analysis).
 ADC Module: ADS1115 (16-bit high-precision Analog-to-Digital Converter to ensure
accurate sensor readings).
 Visual Interface: OLED Display (SSD1306) (For localized, real-time data feedback at the
station).
 Status Indicators: LEDs (Red, Yellow, Green for immediate environmental status alerts).
 Input Interface: Touch Sensor (For user interaction and toggling display modes).
 Power Management: 5V/2A DC Power Supply or Li-Po Battery with charging circuit for
portability.
3.3.2 Software Requirements
The software stack manages everything from the low-level firmware on the sensors to the high-level
distributed database and user dashboard.
 Development Environment: Arduino IDE (Used for writing and uploading firmware to the
ESP32).
 Programming Languages:
o Embedded C/C++: For sensor calibration and hardware logic.

o Java (JDK 17+): For the backend API development.

o JavaScript (ES6+): For the frontend web application.

o SQL: For database querying and management.

 Backend Framework: Spring Boot (For creating the RESTful API and handling high-
concurrency sensor data).
 Database System: TiDB (Distributed SQL) (For scalable, relational data persistence and
historical health logging).
 Frontend Library: [Link] (For building the interactive web dashboard and real-time data
visualization).
 Communication Protocols: HTTP/REST or MQTT (For data transmission between
hardware and cloud).