Translating Product to Engineering Requirements with EARS: Hydroponic System Case Study [Part 1]

In this blog post, we’ll walk through how our team transforms client-facing Product Requirements into precise, testable, and traceable Engineering/System and Software Requirements using the EARS (Easy Approach to Requirements Syntax) methodology.

This first post sets the foundation for how we bridge the gap between high-level needs and implementable requirements. Our working example is a hydroponic system, which provides a rich context to demonstrate our approach.

Understanding Product Requirements

Product requirements are typically high-level needs or expectations provided by the customer or product team. They describe what the system shall do, often without dictating how it will be done. For our hydroponic system, the customer defined the following key product requirements:

Product Requirements (with IDs):

• PR-001: Reservoir water level shall be controlled and monitored.
• PR-002: pH, EC (electrical conductivity), and DO (dissolved oxygen) shall be monitored and controlled depending on the plant being grown.
• PR-003: Water temperature shall be monitored.
• PR-004: Air temperature and humidity shall be monitored.

These requirements express intent, but they are not yet precise enough to be implemented directly.

Why Use Requirement IDs?

We assign unique IDs to every requirement (e.g., PR-001, SR-003) to ensure:

• Traceability across the full lifecycle: from product definition to system design, implementation, and verification
• Easier impact analysis when requirements change
• Consistent mapping in tools (e.g., requirements management platforms, traceability matrices, test plans)

Our ID convention:

• PR-xxx: Product Requirement
• SR-xxx: System/Software Requirement

Translating to Engineering Requirements Using EARS

To translate product requirements into system and software requirements, we use the EARS methodology, which provides a structured, natural-language-based syntax. This ensures our requirements are:

• Clear – Easy to understand for all stakeholders
• Precise – Specific enough to eliminate ambiguity
• Testable – Each requirement can be verified
• Traceable – Linked back to product goals using unique IDs

Why EARS?

Using EARS helped us bridge the gap between what the client expects and what engineers need to build. For example:

• Instead of vaguely saying “the system should monitor water levels,” we now specify when, how often, under what conditions, and what should happen.
• This approach improves communication across disciplines (engineering, QA, project management) and lays a clear foundation for design, development, and testing.
• With IDs in place, we can map each engineering requirement back to one or more product requirements — and later link test cases, design elements, and risk assessments.

Example: Engineering/System Requirements (EARS Format with IDs)

Water Level Management

• SR-001: The system shall have two recirculation pump periods: ON and OFF.
• SR-002: Recirculation periods may be configured.
• SR-003: While the recirculation pump is in OFF period, the system shall acquire sensor data.
• SR-004: While the recirculation pump is in OFF period, the system shall monitor the reservoir water level continuously every 1000 ms ±10%.
• SR-005: Minimum and maximum water level thresholds may be configured.
• SR-006: When the reservoir water level is below the minimum threshold, the system shall trigger an alert and activate the water pump to refill the reservoir.
• SR-007: When the reservoir water level is above the maximum threshold, the system shall trigger an alert.
• SR-008: While the reservoir water level is being refilled, the system shall prevent other operations that depend on water flow.
• SR-009: While the reservoir water level is above the maximum threshold limit, the system shall prevent any operation that could increase this level.

Nutrient Solution Monitoring and Control

• SR-010: While the recirculation pump is in OFF period, the system shall monitor pH, EC, and DO levels in the nutrient solution continuously every 1000 ms ±10%.
• SR-011: pH, EC, and DO setpoints and hysteresis may be configured.
• SR-012: When the pH level is outside the configured range, the system shall trigger an alert and activate the pH increase or decrease pump to adjust pH level.
• SR-013: When the EC level is outside the configured range, the system shall trigger an alert and add nutrients or water to adjust the EC level.
• SR-014: When the DO level is below the configured threshold, the system shall trigger an alert and activate the oxygenation pump to adjust DO level.
• SR-015: While pH level is being adjusted, the mixing pump shall be activated.
• SR-016: While EC level is being adjusted, the mixing pump shall be activated.

Environmental Monitoring

• SR-017: While the recirculation pump is in OFF period, the system shall monitor water temperature continuously every 1000 ms ±10%.
• SR-018: Water temperature alert thresholds may be configured.
• SR-019: When the water temperature is outside the configured range, the system shall trigger an alert.
• SR-020: The system shall monitor air temperature and humidity continuously every 1000 ms ±10%.
• SR-021: Air temperature and humidity thresholds may be configured.
• SR-022: When air temperature is outside the configured range, the system shall trigger an alert.
• SR-023: When air humidity is outside the configured range, the system shall trigger an alert.

Guiding Principles for Requirements Engineering

As we wrap up this first part of our series, it’s important to highlight a few guiding principles that shape how we work with requirements:

1. Requirements define what the system shall do – not how it is implemented.
   The implementation details are intentionally left out of the requirements phase and addressed later during the design stage. This separation avoids prematurely locking down design decisions and keeps the focus on behavior, not architecture or code.
2. Each requirement must be traceable and testable.
   • Traceable: Every requirement has a unique ID (e.g., PR-001, SR-004) which ensures it can be tracked across the entire development lifecycle. This is critical for managing changes, verifying coverage, and aligning testing and design.
   • Testable: Good requirements can be validated through acceptance tests that deliver a clear YES/NO result — leaving no room for subjective interpretation.
3. Define measurable tolerances to avoid discrepancies.
   Quantitative thresholds (e.g., “every 1000 ms ±10%”) ensure that the system’s behavior is measurable and consistent across development and testing teams.
   • Example:
     Instead of saying:
     “The system shall monitor temperature continuously.”
     Use:
     “The system shall monitor temperature every 1000 ms ±10%.”
     This prevents conflicting interpretations such as one developer coding it as “every second” and another interpreting it as “as often as possible.”
4. Prioritize requirements to guide development focus.
   Not all requirements have the same impact or urgency. By identifying high-priority requirements (e.g., critical for safety, functionality, or regulatory compliance), teams can focus development and testing resources where they matter most. This also supports iterative development and risk-based testing.

What’s Next: Data Dictates Design

In our next blog post, we’ll move from requirements to software architecture. We'll show how the structure and flow of data defined in our requirements directly influence how we architect the system – a principle we call “Data Dictates Design.”Stay tuned as we start shaping the brains behind our hydroponic system.

Additional Resources

Video: Overview and Insights
A detailed video providing an overview of relevant concepts and techniques.

Research Paper: Ten Years of EARS
An academic publication covering a decade of work on EARS, offering valuable insights and research findings.