Your breadboard works. The sensor reads, the light comes on, the thing does the thing. So you go looking for the next step and the internet tells you to pick a microcontroller, and you spend an evening comparing part numbers.
That is the wrong next step, and it is the one I took. My first board started with part numbers and I changed almost all of them later, because I had not written down what the board actually had to do.
The short answer
The requirements for your first circuit board are a plain list of what it must do and what it must survive, written before any part is chosen. Four questions get you most of the way: what should it do, where does it live, how is it powered, and how do you see what it is doing. Each answer rules parts out, which is the whole point. A requirement is useful when it is specific enough to be wrong.
You do not need a template or a document with version numbers. A page of notes is fine. What matters is that the decisions are written down before they turn into parts, because changing a line on a list is free and changing a board is four weeks.
What a requirement is, and what it is not
A requirement says what has to be true. It is not a solution and it is not a part.
- Requirement: it has to run for a week on one charge.
- Not a requirement: use a 2000 mAh LiPo.
- Requirement: I have to be able to read it in sunlight while I am moving.
- Not a requirement: use a 1.3 inch OLED.
The difference matters because the second kind closes the door early. If you write down the part, nobody can tell you there is a cheaper one in stock that also works. If you write down the condition, every part that meets it is still on the table.
The test I use: could this line turn out to be wrong? "It should be reliable" cannot be wrong, so it is not a requirement. "It has to keep working down to minus 10 C" can be wrong, so it is.
Start with four questions
Most of a first board is decided by four answers. None of them are electrical.
1. What should it do?
One sentence, one job, in words a stranger would understand. "It tells me when the garage gets below freezing." Not "environmental monitoring node." The sentence is the thing you will measure everything else against, so if it has an "and" in it, you probably have two projects.
2. Where does it live?
On a desk, in a garage, under a kitchen cabinet, on a bike, in a car, outside. This answer sets temperature, dust, water and vibration, and it sets the case. More on this below, because it is the question people skip.
3. How is it powered?
Wall adapter, USB, or battery. This single answer decides the regulator, the connector, the size of the board, and whether you have to care about sleep current at all.
4. How do you see what it is doing?
A screen on the device, a single light, a phone notification, a web page you can open anywhere. This is the difference between a board with a wireless part on it and a board without one, which is one of the larger cost and complexity forks you will hit.
Power is the requirement that decides the most parts
If you only write down one number, write down the power.
A plain USB 2.0 port is specified to supply 500 mA at 5 V to an enumerated device, and a USB-C port advertises either 1.5 A or 3 A at 5 V through resistors on its CC pins unless the two ends negotiate USB Power Delivery, which steps up through 9 V, 15 V and 20 V profiles (Microchip's developer documentation lays out the profiles). Plugging a motor or a strip of LEDs into a laptop port and expecting 10 W is where a lot of first boards quietly fail.
So write the power requirement as three lines:
- What it runs from: wall, USB, or battery, and at what voltage.
- How much it draws when it is doing its job, roughly, and how much when it is idle.
- How long it has to last between charges, if it has a battery.
You do not need these to be precise. "Under half an amp at 5 V, always plugged in" is a real requirement and it rules out a large number of parts straight away. If there is a battery involved, the runtime line is the one that does the most work, and it is worth reading up on what that actually implies before you commit: we wrote about adding a battery to a hardware product separately, because the charging and runtime maths catches people out.
Where it lives decides more than you think
This is the question that gets skipped, and the one that most often sends a board back for a second run.
Take temperature. The same module name can come in three different temperature grades, and they are not interchangeable. The ESP32-S3-WROOM-1, one of the most common wireless modules on hobby and small-product boards, is specified at minus 40 to 65 C, minus 40 to 85 C, or minus 40 to 105 C depending on the suffix, and the versions with octal PSRAM are the ones capped at 65 C (Espressif's datasheet, section 1.2).
Sixty-five degrees sounds like a lot until you leave a sealed black box on a window sill in July, or in a car, or in a garage in Phoenix. I live here. It is not a theoretical number.
Then dust and water. If the thing lives outside or anywhere near a hose, the useful shorthand is the IP code from IEC 60529. IP65 means dust protected and able to take a 6.3 mm water jet at 30 kPa from any direction for at least three minutes. IP67 means dust tight and able to sit under a metre of water for thirty minutes (the test conditions are set out here). Those are different cases, different seals, different connectors and a different price. Writing "outdoors" on your list and nothing else is how you end up with a board you cannot put anywhere.
So this section of the list is short and concrete:
- The coldest and hottest it will ever sit, not the comfortable range.
- Whether it gets rained on, splashed, hosed, or none of the above.
- Whether it gets knocked, dropped or vibrated.
- How big it is allowed to be, and what it mounts to.
Write down the worst day, not the normal day
Normal days do not break boards. The list that is worth having is the list of things that go wrong:
- Someone plugs the power in backwards.
- The supply spikes when a motor somewhere else switches off.
- A wire comes loose and shorts two pins together.
- The battery runs flat and comes back up slowly.
- It gets unplugged in the middle of writing to memory.
Each of those has a part or a design choice that stops it, and each of them is cheap to add before the board is made and impossible to add afterwards. You do not need to know which part stops which problem. You need the line on the page, so that whoever picks the parts, you or software or a contractor, has to answer for it.
What you are not building
The shortest section and the most useful one. Write down what this board is explicitly not doing, so that it does not creep in at the point where creeping is expensive.
"It does not need to work without WiFi." "It does not need to be certified, it is one unit for my own use." "It does not need a battery, it is always plugged in." Each line you write here can save you a week.
A worked example
Here is the whole list for something I actually built, a speed sensor for my bike.
- Job: show me how fast I am going while I am riding.
- How it measures: a magnet on the spokes, a switch that counts them going past.
- Where it lives: on a bike, outdoors, in Phoenix. Gets knocked and vibrated. Gets hot in the sun. Not submerged, but rain is possible.
- Power: small battery. Has to last a ride and then some, not a month.
- How I see it: a small display I can read while moving, in daylight.
- Size: fits on handlebars or a fork. Light enough that I do not notice it.
- Not doing: no GPS, no phone app, no ride history. Speed, now.
Seven lines, and not one part number. Every part on that board was decided by one of those lines, and the last one, the one about what it is not doing, is the reason it got finished at all.
What to do with the list
Once it is written down, the list has three jobs. It tells whoever designs the board what to design. It is what you check the finished design against, line by line, before you spend money making it. And it is what you hand to the next person, including yourself in six months, when you have forgotten why the regulator is the size it is.
A finished layout in Tovan, from a 12 V to 5 V buck converter build. Every part on a board like this one traces back to a line somebody wrote down before the design started.
If you are going from a dev board to a real one, the step by step version of that move is worth reading next, and it assumes you have done this part.
This is also the part Tovan now does with you. You describe what you want in plain English, and it works out what the board has to survive, writes each line down, asks you the few things only you can answer, and shows the part that handles each one underneath the line, with the numbers behind it. You can argue with any line before anything gets made.
FAQ
How long should a requirements list for a first board be?
One page. If it runs longer than that, you are probably writing a specification for a product rather than requirements for a prototype, and the extra pages will be wrong anyway because you have not built the first one yet.
Do I need to know the voltages and currents before I start?
No. You need to know what it runs from and roughly how hungry it is. "Plugged into USB, drives a few LEDs and a small sensor" is enough to rule out most of the wrong answers. The exact numbers come out of the design, not before it.
What is the difference between requirements and a specification?
Requirements say what has to be true for the thing to be useful. A specification says what the thing is: parts, values, pin assignments, dimensions. Requirements come first and they are written in the language of the problem. The specification is the answer.
Which microcontroller should I write down?
None. That is a conclusion, not a requirement. Write down whether it needs wireless, how much it has to remember, and how long it has to run on a charge, and the shortlist will be short. If you want to see how that shortlist falls out, we compared the common options for a first product with real prices.
What if I get a requirement wrong?
You will get several wrong, and that is fine, because a wrong line on a list costs nothing to change. The expensive version of being wrong is finding out after the boards are made. That is the entire argument for writing them down first.
Where to start
Open a blank page. Write the one sentence that says what it does. Then answer the other three questions, add the list of things that go wrong, and add the list of things it is not. Twenty minutes, and the parts stop being a decision you have to make in the dark.
If you would rather have something work the list out with you, describe what you want to build and Tovan will write the requirements for it, ask you what it needs to know, and show you the part behind every line before anything is made.
0 comments