One-sentence summary
A requirements list is a plan where we write down exactly what a project must do, using clear and measurable items, and where we separate the "must-haves" from the "nice-to-haves."
Why does it matter?
In the previous lesson we picked a topic and did some research. Now we have an idea. But the sentence "I'm going to build an automatic night light" is not a plan. When should the light turn on? How bright should it be? Will it run on batteries?
If we don't answer these questions at the start, we keep changing our minds in the middle of the project. One day we say "it should turn on with sound," the next day we say "no, it should turn on with a button." A project like that never gets finished.
A requirements list prevents this confusion. When we write the goal as clear items before we start, we know what we are building and we can check whether we succeeded once the project is done. Engineers and software developers begin their real work in exactly this way.
Short definition: A requirement is the name we give to a single, clear thing that a project must satisfy.
What is a requirement and how do we write one?
A requirement is a short sentence describing a feature the project must have. A good requirement talks about one single thing and can be checked.
It must be measurable
The most common mistake is writing a requirement vaguely. The sentence "the light must be bright" cannot be measured. How bright? Bright according to whom?
Instead, we use numbers and units:
- Vague: "The light should turn on in the dark."
- Measurable: "When the surrounding light drops below a set level, the light should turn on within 2 seconds."
We can verify a measurable requirement when the project is finished, using a ruler, a stopwatch, or a simple test.
It must talk about one thing only
A requirement should not contain several wishes at once. "The light should turn on in the dark and recharge itself in the morning" is really two separate requirements. If we write them on separate lines, we won't mix them up while testing one.
Two everyday examples
The idea of requirements does not belong only to robotics projects. We use it in daily life without noticing.
Example 1 — A birthday cake. If you ask your grandmother for "a nice cake," the result is a surprise. But if you say "make it chocolate, put 12 candles on top, no hazelnuts," those are three clear requirements. Having no hazelnuts might be a "must-have" because of an allergy; being chocolate is only a "nice-to-have."
Example 2 — A school presentation. When your teacher says "prepare a 5-minute presentation, use at least 3 sources, include a cover page," they have given you a requirements list. The time and the number of sources are measurable items. If you meet them, you have completed the task.
Must-have or nice-to-have?
Not every requirement is equally important. Some are essential; without them the project is useless. Others only make the project nicer. That is why we sort requirements into two groups.
Must-haves
These items are the foundation of the project. If even one is missing, the project fails to do its job. For our night light, "turning on automatically in the dark" is a must-have. A night light that doesn't turn on is not a night light.
Nice-to-haves
These items improve the project, but it still works without them. "Being able to change the light's colour" is a nice feature, but the light does its job without it. We come back to these if we have time.
The biggest benefit of this split is this: when time runs short during the project, you finish the "must-have" items first. The "nice-to-have" items are left for the end. That way you always have a working project in your hands.
Some teams use a third group as well: won't-haves. These are things we deliberately choose not to do. For example, saying "the light will not connect to the internet" draws a boundary around the project and protects us from unnecessary work.
The requirements table
The most practical way to keep requirements is in a table, not in plain text. Below is an example table for the automatic night light project. Each row has a number, a description, a priority, and an acceptance criterion.
| No | Requirement | Priority | Acceptance criterion (how do we test it?) |
|---|---|---|---|
| R1 | The light must turn on automatically when the room goes dark | Must-have | The light turns on within 2 seconds after the room is darkened |
| R2 | The light must turn off when the room gets bright | Must-have | The light turns off within 2 seconds after the light is switched on |
| R3 | It must run on batteries, with no need for a wall socket | Must-have | It runs for at least 4 hours while unplugged |
| R4 | There should be a manual on/off button | Nice-to-have | Pressing the button changes the light's state |
| R5 | The brightness should be adjustable | Nice-to-have | At least 2 different brightness levels can be selected |
| R6 | It will not connect to the internet | Won't-have | The project contains no wireless module |
The beauty of this table is this: when the project is done, you read the table row by row, test each acceptance criterion, and mark it "done" or "missing." That way you know whether the project is truly ready through checking, not guessing.
Mini activity
Write a requirements list for a small project of your own choice. If you have no idea, pick one of these:
- A line-following robot
- An automatic plant-watering system
- A simple alarm or reminder
- A catch game in Scratch
Steps:
- Write the goal of the project in one sentence.
- Think of at least 4 "must-have" requirements.
- Add at least 2 "nice-to-have" requirements.
- Write 1 "won't-have" item (draw the boundary).
- Place them all in a table like the one below and add an acceptance criterion to each row.
| No | Requirement | Priority | Acceptance criterion |
|----|-------------|----------|----------------------|
| R1 | | | |
| R2 | | | |After writing each requirement, ask yourself: "Can I verify this item with a test?" If the answer is no, make the requirement more measurable.
Common mistakes
Writing vague requirements
Sentences like "it should be fast," "it should look nice," or "make it useful" cannot be tested. Turn them into numbers: "it should respond in less than 3 seconds."
Marking everything as a must-have
Beginners mark every wish as a "must-have." Then the priority split loses its meaning. Ask yourself honestly: "Does the project still do its job without this feature?" If the answer is yes, that item is a "nice-to-have."
Squeezing several wishes into one item
"It should turn on in the dark, run on batteries, and change colour" is three requirements in one line. Split them so you can test each one separately.
Forgetting the acceptance criterion
A requirement you cannot test is a promise you cannot prove finished. Add the answer to "how do I check this?" for every item.
Safety note
Don't forget to write safety items into your requirements list too; they are usually "must-haves." For projects with batteries, motors, or lamps, you can add requirements like: "The circuit will not be connected to mains electricity," "No hot surface will be left exposed," "Connections will be checked together with an adult." If you write safety as a requirement from the very start, you won't forget it at the end of the project.
Lesson summary
- A requirements list states what a project must do, using clear and measurable items.
- A good requirement talks about one single thing and can be verified with a test.
- "Must-have" items are the foundation of the project; "nice-to-have" items improve it.
- Writing "won't-have" items draws the project's boundary and prevents unnecessary work.
- Adding an acceptance criterion to each requirement shows, through checking, whether the project is truly done.
Check questions
- Why is "the light must be bright" not a good requirement?
- What does it mean for a requirement to be "measurable"?
- What is the difference between a "must-have" and a "nice-to-have"?
- What does a "won't-have" item add to a project?
- Why should an acceptance criterion be written next to every requirement?
Answers
- Because "bright" cannot be measured and varies from person to person. Without a criterion like how many lumens or within how many seconds, it can't be verified when the project is done.
- It means the requirement is stated with a number, unit, time, or clear threshold, so that it can be checked at the end as "met / not met" through a test.
- Without "must-have" items the project fails to do its job; "nice-to-have" items improve the project, but it still works without them.
- It draws the project's boundary, states what we deliberately won't do, and protects us from unnecessary, time-wasting work.
- Because without an acceptance criterion we can't prove whether a requirement was met; a testable criterion shows the project is finished through checking, not guessing.
Source and verification note
For “The Requirements List”, verification focuses on whether the relationship between What is a requirement and how do we write one? and It must talk about one thing only remains consistent across examples. A project page should make a result claim only when it is supported by a real prototype, test record or observation. Numbers such as cost, duration and success rate must be labelled clearly when they are estimates.
Next lesson
Solution Alternatives: We learn how to think of more than one way to meet the same requirements and how to choose the most suitable one among them.