As I mentor people who are getting into IT, I’ve noticed a gap in the learning resources they tend to use. There are plenty of courses that allow you to follow someone making an application. Unfortunately, following along with someone is not how one usually works. Normally, you get a set of requirements, and from there, you start figuring out a solution that allows the user to achieve their goals.
To give my mentees the possibility to experience a real-world workflow, I give them a description of a simple but useful application. Here, I’ll present an improved project introduction, so you will be able to repeat a similar exercise as well.
Project overview
As a person living through weather catastrophes and energy crises, I want to monitor precisely my electricity usage. I want to create an application with which:
- I set my energy tariff—the fixed monthly cost, and how much is charged for each used unit
- I can record my energy meter value at any time
- the application presents back estimated energy costs for each day or hour, so I can adjust my air conditioner or heating to my budget
Goals
The user of the application should be able to monitor their energy consumption in “real time”. Instead of waiting a month or two for the bill to arrive, they should have a solid estimation of how much energy they’ve used so far. So, when they find themselves in a new situation, such as:
- moving to a new place,
- installing new heating or air conditioning units, or
- tariffs’ change,
they will be able to see and control their spending.
A secondary use case would be to evaluate the cost of using different appliances. So, for example, by controlling what’s running and when, the user could estimate:
- how much it costs to run the washing machine or dishwasher
- keeping a thermostat at different temperatures
- spending a whole day baking like it’s 2020
User stories
User stories describe what the user can do in the application, from their perspective. They remind the programmers about how people will use the application, and they test scenarios that can be used to make sure the application works as expected. The format of user stories is usually somewhat repetitive, as you will see in the examples.
As a user, I want to configure my energy tariff, by setting:
- fixed costs—maintenance, connection‚ or whatever the provider calls the part of the bill that doesn’t depend on the usage
- cost by unit of energy—what is paid based on the consumption
Those values should be saved in the application and be changed only once every few months: when there is change to the tariff.
Record measurements
As a user, I want to record my current readings of the energy meter. I want this data to be stored for later use—so I can create a log of readings that can be used for estimating consumption in a given time. For example:
- I record the value of the meter every morning to create a log of usage on different thermostat settings.
- I record the meter before starting the washing machine, I keep my other usage minimal while it runs, and then I record the value after the program is done.
Review usage and cost estimation
As a user, I want to be able to read cost estimation based on the data I collected. For a start, it could be a simple table of starting time, end time, energy consumption, and cost. In further interactions, it would be great to have some charts with daily or hourly energy consumption.
Deliverables
The first exercise for my mentees was to draw on a piece of paper the interface that they see for this application. It turned out to be a very good idea—apparently, the ‘obvious’ interface I had in mind is everything but obvious, and everybody had slightly different ideas for how to implement it. When you work with a client, it’s important to get their feedback as soon as possible, without wasting time on building stuff they don’t need.
This is an approach I presented earlier in How to Collect Inputs for Your Project. When I have enough examples of different people’s approaches to this project, I’ll share them on the blog as well—but the goal of this exercise is to start with a white piece of paper and requirements. This forces one to imagine an interface that implements the requirement.
Sign up for more
Are you interested in learning how to build projects from requirements to deployed applications? Sign up here to get updates about new articles in this series:
Please share your sketch in the comments if you try it yourself! You will be surprised at the ways the same requirements are interpreted by different people.
P.S. Are you interested in energy efficiency? This application is a poor-man's version of the approach shown in a blog post I read a long time ago—something that would be overkill for most people.
