First things first!

Click for previous section: Stage 0

Requirements come first in every well-run IoT project — before schematics, before firmware, before the first line of code. You have decided your product idea is a keeper, and the temptation now is to jump straight into building. Resist it. Stage 1 is about gathering the requirements, the foundation for everything that follows. It may not sound as exciting as powering up a new circuit or writing code, but think of it as drawing the map before you set sail. Voyages without maps are adventurous, certainly — they just rarely end well.

In Stage 1: Stakeholder & System Requirements, we gather input from all key players and define exactly what we’re building and why: what the product must do, the conditions it must meet, and the constraints it must obey. Time invested here pays back later. Every design decision, every line of code, and every test down the road will trace back to these requirements — they are the project’s North Star. Charge ahead without them and you risk building the wrong thing, or discovering after months of work that a key feature was overlooked or an assumption was wrong.

In this chapter we break down what it means to capture stakeholder and system requirements: why this stage matters, the types of requirements to consider, and how to document them clearly. We will also share examples that show how nailing down requirements early can make or break an IoT project.

What Exactly Are Requirements?

So what do we mean by “requirements”? In plain terms, they are a detailed description of what your product must do and under what conditions it must do it — the rulebook for the project, capturing everything expected of the device before you build it. If your product were a story, requirements would be the plot outline: they make sure all key elements are defined so the story holds together in the end.

Requirements come in a few flavors, each covering a different aspect of the product:

• Functional Requirements: What the product should do – its features and behaviors.
• Non-Functional Requirements: The qualities and constraints of the product – how well it performs, how long it lasts, and so on.
• Interface Requirements: How the product will interact with other systems and the outside world.

We’ll go through each category in detail. For now, remember that a good requirement is clear, specific, and testable. “The device should be awesome” won’t help your engineering team. “The device shall measure temperature from 0°C to 50°C with ±0.5°C accuracy” will: anyone reading it knows exactly what’s expected, and later you can test whether the device meets it. That’s the level of clarity to aim for.

Functional Requirements

Functional requirements describe the specific features, functions, and behaviors of your IoT product — what the system should do. If someone asks, “What does your device do?”, the answer is a summary of its functional requirements: the actions and services the device provides to the user or to other systems.

For an IoT device, functional requirements often include:

• Data sensing or actions: What data does the device measure, or what actions does it perform? (e.g. measures temperature, opens a valve, tracks location)
• Data accuracy and range: How accurate are the measurements, and over what range? (e.g. measures temperature from 0°C to 50°C with ±0.5°C accuracy)
• Frequency or timing: How often does it perform its function — updates every minute, every hour? How quickly must it respond? (e.g. a reading every 10 minutes, or a response within 2 seconds)
• Data handling: What happens to the data — sent to the cloud, logged to a memory card, shown on a display?
• Specific modes or features: For instance, an alarm mode when a threshold is crossed, self-calibration, or over-the-air firmware updates.

A concrete example. Suppose you’re building a simple IoT temperature sensor for smart home use. Some functional requirements might be:

• The device shall measure ambient temperature from 0°C to 50°C with an accuracy of ±0.5°C.
• The device shall take a sensor reading at least once every 10 minutes (update rate).
• After each reading, the device shall transmit the sensor data to a cloud server within 30 seconds (data latency).
• The device shall blink an LED and send an alert if the temperature exceeds a user-defined threshold.

Each describes something the system does, usually phrased as “The device shall…” followed by a specific behavior. That format makes verification straightforward later: either the device does X as specified, or it doesn’t.

Good functional requirements paint a clear picture of capabilities, so the engineering team knows exactly what to implement. Only then can hardware and software designers think about how to achieve it — what comes first, which is why these requirements are defined now. Without them, you can end up with a product that misses what the user actually needs: an elaborate IoT weather station, say, that ships without a humidity sensor because nobody wrote it down. Defining functional requirements up front captures the must-have features before that happens.

Non-Functional Requirements

Non-functional requirements specify the qualities, conditions, and constraints of the product rather than its features: how well it performs, how robust it is, and which limits it must respect. They set the guardrails for overall quality, and they are just as critical as the features themselves — they keep the device safe, reliable, and practical in the real world.

Common non-functional considerations for an IoT device:

• Power Consumption & Battery Life: How long should the device run on a given power source? For example, “The product shall run on a single AA battery for at least 1 year.” This forces a focus on low-power components and efficient power management.
• Reliability & Longevity: How robust must the device be over time? Often expressed as Mean Time Between Failures (MTBF) or similar — “The device should operate continuously for at least 5 years without a critical failure.” This influences component selection and design margins.
• Security & Privacy: How will you protect data and user privacy? E.g. “All data transmissions shall be encrypted with AES-256” or “User credentials must be stored securely and never transmitted in plain text.” In today’s IoT landscape, security requirements are essential to prevent breaches.
• Environmental & Physical Constraints: The conditions the device must withstand, plus any size and weight limits. “The device shall operate from -20°C to +60°C and be water-resistant to IP67” ensures it survives harsh environments; “The device shall weigh no more than 100 grams and fit within a 10cm x 5cm x 3cm space” keeps it within the required form factor.
• Cost Constraints: You likely have a target cost — “The unit manufacturing cost shall not exceed $50.” This drives trade-offs: a cheaper component here, a dropped feature there.
• Regulatory Compliance: Many IoT products must meet standards or certifications — “The device must comply with CE and FCC regulations for wireless communication”, or “Must adhere to ISO 13849 safety standard” if it’s part of a machine system. These are non-negotiable requirements set by industry and safety standards.

It’s a long list, but think of non-functional requirements as the quality attributes the product must have. They rarely make the marketing brochure, yet ignoring them fails the product in less obvious ways. A sensor can report data perfectly (functional!) and still frustrate every user because its battery dies in a day. A device can perform well in the lab and still fall over at the first attack because security wasn’t built in from the start.

Defining these qualities up front ensures the end product isn’t just feature-rich, but robust, usable, and viable. Non-functional requirements guide component choices, software architecture (reliability, security), mechanical design (durability, size), and even how you’ll test. They work behind the scenes, but they are essential to meeting stakeholder expectations and surviving real-world deployment.

Interface Requirements

Interface requirements define how your product connects and interacts with the outside world — physically and logically. Interfaces are the touchpoints between your device and everything else: other hardware, power sources, enclosures, users, and software systems. This category ensures the device fits into, and communicates properly within, its intended ecosystem.

Aspects covered by interface requirements:

• Electrical Interfaces: Any electrical connections or signals. Does the device need a specific power input (USB-C, battery terminals)? Does it output an analog voltage (a 0-5V signal) or provide a digital interface (I²C, SPI, UART) to other hardware? A requirement might be “The device shall have a USB-C port for power and data connectivity” or “It shall provide a 0-5V analog output proportional to the sensor reading.”
• Communication Interfaces: How the device talks to the cloud, a smartphone, or other devices — networking and protocols. For instance, “The device shall connect to the cloud via Wi-Fi and use MQTT protocol to publish sensor data,” or “It shall support Bluetooth Low Energy (BLE) to communicate with a smartphone app.” If an API is needed, specify that too: “The cloud service shall provide a REST API endpoint for retrieving the device’s data.”
• Mechanical Interfaces: The physical form and fit. How big can the device be, and how is it mounted or enclosed? “The device’s PCB shall be 5cm x 5cm to fit into a standard enclosure,” or “It shall have mounting holes compatible with a GoPro-style mounting bracket.” Water- and dust-proofing is both an environmental requirement and a mechanical interface consideration: “The enclosure shall be rated IP67 for water and dust resistance.” The point is that the device physically integrates wherever it’s supposed to go.
• User Interface (UI) & Controls: Elements the user interacts with — buttons, screens, LEDs. “The device shall include a physical reset button accessible to the user,” or “It shall have an LED indicator that blinks during data transmission.” These define how users get information from the device or send commands to it.

Nailing down interface requirements clarifies how all the pieces plug together. If you’re designing a sensor that attaches to an industrial machine, a mechanical interface requirement specifies the size and screw-hole pattern so it actually fits. If the device is battery-powered, an electrical interface requirement ensures a standard connector so the user can recharge it easily. Miss one, and you get the classic outcome: a perfectly good device nobody can connect to because it lacks the right port.

In short, interface requirements make sure your device works with its environment and its users — whether that’s a smart home, an industrial setup, or a person with a phone. Overlooking them is often the difference between a product that’s compatible and user-friendly and one that causes headaches during integration.

Engaging Stakeholders Early

Where do all these requirements come from? Not from thin air — you gather them from your stakeholders: everyone with a stake in the product’s success. That includes the obvious candidates, end users and customers, but also marketing, sales, engineers from different disciplines (hardware, software, firmware), project managers, and regulatory or compliance experts. Each group has its own needs and concerns, and the requirements should capture every critical perspective.

Identify your stakeholders and involve them early, because they define what “success” looks like. Marketing might say, “It needs to cost under $50 and run a year on one charge — that’s what our customers expect.” End users (or a representative persona) might need setup to be simple and maintenance minimal. The software team might need a robust API to integrate with a cloud platform. The security expert will insist on encryption and authentication. A compliance officer will remind you about FCC radio emission limits or electrical safety standards. All of these inputs become requirements.

Surfacing these needs now is far cheaper than later. Brainstorming sessions, workshops, or simple interviews with each stakeholder group will build a comprehensive list. Don’t do it in a vacuum: a requirement written without stakeholder input can miss the mark. Skip the customer support team and you might overlook “The device shall provide a reset mechanism to restore factory settings” — important for troubleshooting. Skip manufacturing and you might specify a design that’s too costly or too hard to produce in volume.

Early involvement also creates buy-in. When people see their concerns addressed in the requirements, they support the project, and fewer surprises surface later. Stakeholders bring experience — using it now saves painful changes down the road.

As these inputs accumulate, the picture of the necessary functional, non-functional, and interface requirements takes shape. This stage is essentially bridging the gap between a promising idea and a clearly defined product: fuzzy wishes (“It should be cheap! It should be secure! It should do X and Y!”) become precise requirements engineers can work with, by talking to the right people and asking the right questions.

Requirements gathering is a team sport. Get the key players in the room — literally or figuratively — and hash out what the device must do. The more viewpoints you incorporate now, the fewer blind spots you carry into the later stages.

Documenting and Tracking Requirements

Once gathered, requirements need to be written down clearly and organized. A well-structured record keeps everyone on the same page and ensures nothing gets lost. In practice, teams use different methods:

• Formal Requirements Document: Many projects create a System Requirements Specification (SRS) or Product Requirements Document (PRD) — a structured document (sometimes following standards like IEEE 29148) where each requirement is listed, often with a unique identifier (e.g. REQ-001: Device shall do X). Formal documents suit industries where strict traceability is needed: aerospace, automotive, medical devices.
• Agile Backlog (User Stories): Some teams, especially agile ones, capture requirements as user stories, epics, or items in a tool like Jira or a wiki. For example: “As a homeowner, I want the sensor to alert me when my house temperature goes above 30°C so that I can turn on the AC.” A story like this breaks down into specific requirements for the engineering team (a functional requirement for an over-temperature alert, for instance). Agile formats are more free-form, but the underlying requirements still need to be specific and testable.

Whichever format you choose, keep every requirement unambiguous and testable. Avoid vague words like “optimal”, “user-friendly”, or “sufficient” without quantification; use concrete numbers or clear criteria. Instead of “battery life should be long”, write “battery life shall be at least 12 months on a single charge with hourly data uploads.” That’s a target designers can work to, with no guesswork.

Another useful habit: tag each requirement with how you will verify it later — think ahead to how you’ll prove the product meets it. Common verification methods:

• Test: Directly test the device against the requirement. (E.g. measure how long it runs on a battery to verify the 12-month battery life.)
• Analysis: Use calculations or simulations. (E.g. analyze the encryption algorithms against the security requirements, or calculate power consumption to estimate battery life.)
• Inspection: Verify by observing or measuring the finished product. (E.g. measure the device’s dimensions with calipers against the size requirement, or inspect the PCB for conformal coating applied for water-proofing.)
• Certification/Demonstration: Verify through certification or demonstrated compliance. (E.g. send the device to a lab to certify it meets FCC/CE regulatory standards, or run a water ingress test to demonstrate the IP67 requirement.)

Tagging the verification method up front — some teams add a “Verification Method” column to the requirements document — forces each requirement to be phrased so it can be proven later. It also spares you the testing-phase moment where someone asks, “Wait, how do we check whether we achieved this vague goal?”

Finally, keep the requirements document up to date. As the project evolves you may refine or add requirements (ideally not too many, if the early work was thorough). An organized, version-controlled list — even a simple spreadsheet or living document — keeps everyone aligned on the current agreed requirements, and helps new team members get up to speed on what the product is supposed to do.

In short: don’t scribble requirements on sticky notes and hope for the best. Write them in a clear, structured way — a formal document or a well-maintained backlog. Clarity now prevents confusion later, and planning verification early paves the way for a smoother testing phase.

Wrapping Up Stage 1

One more time, before moving on: changing a requirement late is like deciding to add an extra bedroom after the house is built — possible, but painful and expensive. In IoT, “painful and expensive” can mean a full PCB redesign because a sensor was forgotten, or a major firmware overhaul because a use case wasn’t considered. It can mean delays, budget overruns, or, at worst, a product that fails its users and stakeholders.

Investing the effort now to capture clear stakeholder and system requirements gives the project its blueprint and roadmap. The requirements become the reference point for everyone involved:

• Hardware engineers use them to choose components and design circuits that meet the specs.
• Software and firmware developers write code to implement the specified functions and performance.
• Testers create test plans directly from the requirements — every verifiable requirement translates naturally into one or more test cases.
• Project managers track progress by checking off fulfilled requirements and making sure nothing critical is dropped.
• Stakeholders get a transparent view of what the product will — and won’t — do.

When disagreements or new ideas appear later, the requirements document is the North Star that keeps the team aligned. If someone proposes feature creep halfway through development, you can ask: “Is that in scope according to our agreed requirements? If not, what do we trade off to add it?”

So take the time to get Stage 1 right. Bring in the stakeholders, think through the functions and constraints, write everything down clearly, and double-check that it holds together. Iterating on a specification is far cheaper than iterating on a physical device or a codebase. Do this stage well, and you set up every stage that follows.

With a solid set of stakeholder and system requirements in hand, you’re ready to move forward to designing and building something that meets them. And as you do, you carry the map with you — first things first, done right.