Functional vs Non-Functional Requirements#

Every electronics project has two kinds of requirements, and the ones most often skipped are the ones that cause the most failures. Functional requirements describe what the system must do. Non-functional requirements describe how well it must do it. A circuit that “works” on the bench but can’t survive a hot car or draws too much current for its battery has met its functional requirements and failed its non-functional ones.

Functional Requirements: What the System Must Do#

Functional requirements are the capabilities the system must provide. They’re the easiest to identify because they directly answer the question “what does this thing do?”

Examples of functional requirements:

• Measure temperature with a thermistor and display the value on an LCD
• Transmit sensor data wirelessly to a base station every 60 seconds
• Amplify an audio signal from a microphone to line level
• Convert 12V DC input to 3.3V DC output
• Detect a button press and toggle an LED

These are binary — the system either does them or it doesn’t. They form the checklist for basic functionality, and they’re what most hobbyists and learners focus on. Which is understandable, because a circuit that doesn’t perform its basic function is obviously broken.

The problem is that functional requirements alone are not enough to describe a working system.

Non-Functional Requirements: How Well It Must Behave#

Non-functional requirements specify the quality attributes of the system’s behavior. They’re harder to identify, harder to test, and almost always the reason a “working” prototype fails in real use.

Non-functional requirements are where the real design tradeoffs live. A temperature sensor project is straightforward if the only goal is to “read temperature.” It becomes a design challenge when the requirement is to read temperature to 0.1 degree accuracy, in an environment from -40 C to +85 C, running from a coin cell for two years, fitting in a 20 mm diameter enclosure.

Where Most Designs Fail#

I’ve noticed a pattern: the circuit “works on the bench” but fails in deployment. The bench is a controlled environment — stable temperature, clean power, short wires, no vibration, no EMI. The real world is none of those things.

Common non-functional failures:

• Power consumption too high. The prototype runs from a USB port, so nobody notices it draws 15 mA continuously. In the field, that kills a CR2032 in days instead of months.
• Noise sensitivity. The ADC reads clean values on the bench, but in an enclosure near a motor driver, the readings jump around by 20 counts.
• Temperature drift. The voltage reference is stable at 25 C but drifts 50 ppm/C, which at 60 C puts the measurement outside its accuracy spec.
• Startup behavior. The system works after a clean power-on, but brown-outs in the field cause the MCU to hang in an undefined state.

These failures are invisible if only functional requirements are tested.

Capturing Requirements#

Requirements don’t have to be formal documents. For personal projects, a simple table or bulleted list is enough — the point is to make implicit assumptions explicit.

A useful format for each requirement is:

The verification column is especially valuable. If there’s no way to describe how a requirement would be tested, it’s probably too vague to be useful. “The system must be reliable” is not testable. “The system must operate continuously for 30 days without reset in a 40 C environment” is testable.

Must Have vs Nice to Have#

Not all requirements are equal, and treating them as equal leads to over-design or analysis paralysis. A simple priority scheme helps:

• Must have. The project fails without this. Non-negotiable. These define the minimum viable product.
• Should have. Important and expected, but the system is still useful without it. These are included if they don’t compromise must-have requirements.
• Nice to have. Would be good, but not worth significant cost, complexity, or schedule impact.

This prioritization is especially important when requirements conflict — and they will. “Low power” and “fast response” often pull in opposite directions. “Small size” and “low cost” compete when expensive tiny packages are needed. Knowing which requirement wins the conflict requires knowing which is “must have” and which is “nice to have.”

Requirements That Look Non-Functional but Are Actually Functional#

Some requirements appear to be quality attributes but are actually hard functional requirements in disguise:

• Safety. “The system must not present a shock hazard” isn’t a quality attribute — it’s a binary pass/fail requirement that drives specific design features (isolation, fusing, creepage distances).
• EMC compliance. Meeting radiated emission limits isn’t optional for any device intended for sale or deployment. It’s a functional requirement with specific, measurable criteria.
• Regulatory compliance. UL listing, CE marking, RoHS compliance — these are not soft preferences. They determine whether the product can legally be used.
• Data integrity. “The system must not lose stored measurements during power loss” is a functional requirement that demands specific implementation (non-volatile storage, write completion detection, journaling).

Misclassifying these as “nice to have” non-functional attributes leads to late-stage surprises when the design can’t meet them without fundamental changes.

Tips#

• For each requirement, write a verification method before starting the design — if a requirement can’t be tested, it’s too vague to guide decisions
• Assign every requirement a priority (must have, should have, nice to have) so that when requirements conflict, the tradeoff resolution is already documented
• Capture non-functional requirements in measurable thresholds (e.g., “below 50 uA average”) rather than subjective terms like “low power” or “efficient”
• Revisit non-functional requirements after selecting key components — datasheets often reveal constraints (thermal limits, noise floors) that refine or invalidate earlier assumptions

Caveats#

• Unstated requirements are still requirements. If the project will live outdoors, temperature and humidity tolerance are requirements whether documented or not — the environment doesn’t care about documentation habits
• “It works” is not a requirement. Without defined acceptance criteria, there’s no way to know when to stop tweaking — define what “works” means quantitatively before starting
• Non-functional requirements dominate cost. A temperature sensor that works at room temperature costs $0.50; one that works from -40 C to +125 C with 0.1 degree accuracy costs $5.00 — the functional requirement is identical, but non-functional requirements drive a 10x cost difference
• Requirements change — track the changes. As understanding deepens, requirements will evolve, and that’s healthy — what’s not healthy is changing requirements without re-evaluating their impact on the design
• Copying requirements from similar projects blindly is risky. Every project has different constraints, and a requirement critical for a previous project (like -40 C operation) might be irrelevant here but still drive unnecessary cost and complexity if copied without examination
• Test the requirements, not just the circuit. A requirement that can’t be verified is just a wish — for each requirement, define how compliance will be measured, ideally before design begins