Use Cases to Tasks

A use case is all the ways of using a system to achieve a particular goal for a particular user that can be measured or observed in a specific way

Recap from Use-Cases

In our previous article use-cases we started deriving Kelly’s Automatic Gardener into the first use-case

Use Case

Use-case 1: As a gardener I want my sprinkler system to peridoically measure the moisture level of soil and turn on a water pump when the soil is dry, then turn it off when it gets too wet.

This use-case can then be sliced into a couple more use cases. The additional use-cases can also be broke out to include:

Use-case 1.1: As a gardner I want to be able to change the frequency the soil moisture of my are checked.

This is going introduce a configuration variable and a timer.

Use-case 1.2: As a gardener I want my sprinkler system to record the historic sensor data.

This is going to introduce a data model and some type of data storage such as a database.

which we then broke down into an initial set of requirements:

Requirements

  1. Periodically measure soil moisture levels

  2. If the moisture level drops below a certain level start watering

  3. Turn water off when the moisture hits a high point

  4. Configurable moisture levels

  5. Historic data storage

Acceptance Tests

This set of requirements can now be validated by with these acceptance tests:

  1. Verify the water pump is not active when moisture level is below threshold

  2. Verify water pump activates when moisture crosses the dry threshold

  3. Verify Water pump de-activate when moisture crosses the damp threshold

  4. Verify periodic

Busting out the Tasks

This is the point that we start moving from the user POV to the development side of the project. We are going to start breaking out the above requirements and acceptance test into high level tasks that I will need to develop.

We will still use high level language and not yet get into actual programming languages, libraries or software systems. As matter of fact this level of breaking out tasks could applied to just about any hardware, language or sub-systems.

Find a Soil Moisture Sensor

TODO: point to article about soil moisture sensors

We are going to need some type of sensor that we stick in soil to read the level of moisture in the soil. The soil moisture sensor we choose comes from the wonderful Adafruit’s I2C Capacitive Moisture Sensor

Find a Pump to send water

TODO show the pump we picked and how to wire it up

Turn Pump on and Off

TODO GPIO library to control pump

Read Data from Soil Moisture Sensor

For this particular sensor we are going to read data from it using and I2C data bus. You can read about I2C here and look at the I2C Adafruit driver we wrote HERE:

TODO: pointer to I2C article

TODO: pointer to our Adafruit SeeSaw library driver.

Timer to periodically read data

We are going to need a driver to periodically read data from the I2C driver.

TODO: pointer to our article with Go timers

Local Storage

We are going to cache this data locally for the Soil Moisture data.

TODO: create an article about data models

MQTT Data Broadcast

We are going to publish the soil moisture data via MQTT and the channels, the moisture data will then subscribe to the published data to determine when to turn on and off the pump.

A subscriber will also record the data levels in a time series data base of sorts.

TODO: pointer to MQTT article

Configuration variables

We need configuration variables for the following tasks:

  1. Frequency to read soil moisture data
  2. The dry water mark
  3. The damp water mark
  4. Location to store local data
  5. MQTT channel to advertise data on

Adding tasks to our Kanban Board

We are now ready to add our tasks to our todo list. We will also add our acceptance tests as part of our todo list.

This bring us to our next major article about Kanban boards and todo lists.