Your architecture was decided before you opened the schematic

• Software Development
• Product Design
• System Design

Imagine your company wants to ship a new product: a digital thermometer. Here are the requirements the business provided your embedded team with:

1. Consumer-grade indoor device
2. No connectivity
3. Two-year battery life on CR2032 battery
4. Half a degree temperature resolution
5. Updated reading every 10s
6. Four digits 7-segment LCD

Most engineers look at those constraints and think about hardware first. And they are right! Which MCU or which sensor will be used depends on those requirements, especially three of them: battery life suggests low-power MCU. Consumer grade means no redundancy, tight BOM cost. No connectivity means no radio. All fair and necessary observations. But we can go even further with the analysis and question ourselves about the impact those requirements have on the software design, before a chip is selected or a schematic is ready.

Three requirements, one architecture

Requirements in isolation give you constraints your software design must satisfy. Put them together and you are able to decide on most of the key aspects of your architecture. Take the Two-year battery life on CR2032 battery: you know you will need to minimize the power consumption as much as possible. No connectivity implies that there is no network stack, MQTT broker, cloud sync, etc. Finally, Consumer grade tells you that your RAM/Flash budget will probably be very tight and that there is no need to support different sensors.

Based on this analysis, you are now able to formulate key elements of your software architecture:

• No RTOS - this addresses the tight memory budget and the absence of any stack which would necessitate an RTOS.
• Event loop with low power modes - only wake-up the CPU when there is an event to process, like 10 second timer interrupt and sensor reading. Aggressively power down the peripherals and the CPU the rest of the time.
• HAL with free functions: no virtual dispatch, no function pointers, no polymorphism. Because the sensor will never change during runtime.

Typically, engineers treat requirements as a checklist of features to implement. But they also tell you what NOT to build. This is valuable and helps saving time, effort, and money. Keep your architecture simple and most of all in line with the actual business needs.

The same product, different requirements

The easiest way to see how the requirements affect key architectural decisions is to change a few of them and watch how the architecture changes with them. Suppose that the same sensor must connect to an IoT sensor hub. Even though we still do not know if Bluetooth or Wi-Fi will be used for this (hardware decisions are still being discussed in the EE team), we can already assess the impact on the software architecture: our `No RTOS` decision becomes obsolete, because we would need to support some network stacks which we do not write ourselves. Most of the time, these stacks are best used in combination with an RTOS, some are even integrated in the RTOS, like Zephyr. So now the architectural decision is about which RTOS best fits our low-power and stack needs.

The benefits of starting from the requirements

Starting your software design from the requirements, before the hardware is available or even before the schematic exists, forces the right questions: what does this product actually need to do, for whom, under what constraints? There are multiple benefits to this approach. First, you can start your software design while the hardware is still being decided, so you do not start with a time penalty. Second, you focus on building things which are really needed. A HAL designed for polymorphism and runtime sensor swapping is wasted complexity for a single-sensor, consumer-grade device. Every abstraction you add come at a cost. Requirements tell you where to draw the line.Third, software can still influence the requirements in the early stages instead of suffering the consequences months later. A software engineer who has thought carefully about the architecture might realize early on that a small change to the specifications would dramatically simplify the design. And in case this requires a little change to the hardware, it is not too late to implement in the schematic. 

Key Takeaways

• Read requirements together, not in isolation. You only have the full picture when considering them as a whole: their combination drives your architecture.
• Requirements tell you what not to build as much as what to build.
• Engage with requirements before hardware is finalized: that is your only window to influence them.
• Simple architecture aligned with business needs beats clever architecture aligned with nothing.

Where to go from there

In this blog post, I only focused on high level architectural decisions. But we can do more than this to really take advantage of that top-down approach. For instance, design our HAL to closely match what we need from the hardware instead of what the hardware has to offer. Or design the application and let it run in a simulator before the hardware is ready, as well as simplify testing of your software.

These ideas are explored hands-on in my Top-Down Design workshop at the Embedded Online Conference 2026, using the simple thermometer as a complete case study — from requirements through to a host simulator and a real target implementation, all driven by what the application actually needs.

https://embeddedonlineconference.com/session/top_down_design_modernizing_embedded_software_for_business_value 

Sign in