On April 24, 2026 in Dev Tools, General, IoT, Maker, Open Source by Mike Parks

Starting a new embedded electronics project can be both exhilarating and overwhelming. It’s an opportunity to learn new techniques, explore new components, and build something tangible. But before the first line of code is written or the first printed circuit board (PCB) trace is routed, a significant amount of groundwork must be done. Requirements need to be defined, architectures planned, budgets and schedules agreed upon.

There are entire textbooks on product development, so the goal of this blog is not to be exhaustive. Instead, it provides a practical framework for low-volume embedded devices, such as a gadget retailing for around $100USD. By keeping scope and complexity constrained, we can focus on the essential steps required to move from concept to prototype to small-batch production.

Step 1: Requirements define the what and why

Though it is tempting to jump straight into wiring sensors to a development board, successful projects begin with clear requirements. These requirements become the foundation for every decision that follows.

Identify the problem and use case

Start by identifying the problem and use case. Ask, “What is the device meant to do, and who will use it? A consumer device demands simplicity, safety, and polish. A tool for trained technicians can assume more technical knowledge and tolerate complexity. The intended user strongly influences interface design, durability, documentation, and support expectations.

Define functional requirements

Once the problem and use case are clearly understood, the next step is to translate that understanding into concrete capabilities the device must deliver. List the core capabilities the device must provide, such as sensor ranges and accuracy, update rates, battery life, physical size, operating environment, cost targets, and any communications needs. Environmental factors matter—outdoor use implies temperature and moisture concerns, while industrial settings may require electrical noise tolerance.

Consider non-functional requirements

Beyond what the device does, it’s equally important to define how well it must do it. This is where non‑functional requirements come into play. These include safety expectations, reliability goals, aesthetics, regulatory constraints, maintainability, and upgrade paths. Examples include “operate continuously for one year without reboot” or “support field firmware updates.”

Plan for verification early

Because each requirement should be testable, verification planning should happen in parallel with requirements development. If you specify eight hours of battery life, plan a discharge test. If operating down to 0 °C is required, plan a cold test. Thinking about validation early often reveals hidden needs, such as calibration procedures or diagnostic indicators.

For critical projects, a lightweight failure mode analysis can be invaluable. Asking “what happens if this fails?” often leads to additional requirements such as fail-safe behavior or user alerts.

Document your requirements—whether in a formal document or a notebook—and ensure each one ties back to a purpose and a verification method. Clear requirements prevent scope creep and keep development focused.

>>Click to read the entire article at Mouser

About the Author

Michael Parks, P.E. is the co-founder of Green Shoe Garage, a custom electronics design studio and embedded security research firm located in Western Maryland. He produces the Gears of Resistance Podcast to help raise public awareness of technical and scientific matters. Michael is also a licensed Professional Engineer in the state of Maryland and holds a Master’s degree in systems engineering from Johns Hopkins University.