Most Hardware Requirements Aren't Requirements — Here's How to Write Ones You Can Test

Most hardware requirements aren't actually requirements. They're intentions, written in engineering-sounding language.

"It should feel premium." "Accurate in the field." "Ruggedized for real-world use." "Fast enough for the application." Every one of these sounds specific. None of them are testable. And a requirement nobody can test is a requirement nobody can design to — it just gets argued about, repeatedly, at every design review until the product ships.

The three-hour debate with no number in it

This shows up constantly in architecture reviews: a team spends three hours debating a feature, and nobody notices that the requirement driving the entire debate doesn't contain a number. Everyone has a slightly different mental model of what "durable" or "fast" means, and the conversation never resolves — it just gets revisited at the next review under a different feature name.

The difference between an intention and a requirement is concrete:

Intention vs. Requirement

• “Waterproof” → IP54 per IEC 60529

• “Long battery life” → 72 hours of continuous operation at 20°C

• “Durable” → Survives a 1.5 m drop onto concrete per MIL-STD-810

• “Feels premium” → Surface gap tolerances ≤ 0.2 mm; specified material/finish callouts

• “Fast enough” → Completes operation X in ≤ 800 ms at the 95th percentile

Once you write it this way, two engineers looking at the same prototype will agree on whether it passed. That's the entire point.

Why untestable requirements are expensive, not just annoying

Untestable requirements don't stay hidden — they show up at the worst possible time, which is when the first prototype comes back. Half the team thinks it passed. Half thinks it didn't. Both sides are right, because nobody defined what passing actually meant. Now you're not testing a part; you're re-litigating a requirement that should have been settled before the CAD model existed.

The most expensive design work isn't usually caused by a hard engineering problem. It's caused by a requirement everyone agreed on in a kickoff meeting and nobody could actually measure six months later.

How to turn an intention into a requirement

A few questions turn most vague requirements into testable ones in a single sitting:

1. What's the number? If the requirement doesn't have a quantity, threshold, or standard reference, it isn't finished yet.

2. What's the test? If you can't describe — in one sentence — how you'd verify a finished unit meets the requirement, the requirement isn't specific enough to build to.

3. Who measures it, and how? "Looks rugged" depends on who's looking. "Survives X cycles of Y per ASTM Z" doesn't depend on anyone's opinion.

4. What standard already exists? IP ratings, MIL-STD test methods, IEC and ASTM standards exist for a reason — they replace a subjective adjective with a referenceable, repeatable test procedure. Use them whenever the product category has one.

This isn't about adding bureaucracy to early-stage hardware development. It's the opposite — a requirement you can test is one your team can actually move fast against, because nobody has to guess what "done" looks like.

The hierarchy question that usually gets skipped

The other place this bites teams: specs that list several testable requirements as simultaneously non-negotiable, when some of them actively trade off against each other. High accuracy, low power, small size, and low cost rarely resolve at the same time — better accuracy usually needs more sensing and processing, which costs power; smaller size limits battery and thermal headroom; low cost constrains all of it.

A spec that treats all four as fixed sends an engineering team chasing an intersection that doesn't exist. The fix is a five-minute conversation before architecture begins: which of these actually breaks the product if compromised, which is a strong preference, and which is genuinely flexible? Naming that order explicitly doesn't weaken the product spec — it's what makes the architecture decision possible in the first place.

Where to start

You don't need a formal requirements management tool to fix this. Take your current spec document and go line by line: if a requirement doesn't have a number, a standard, or a clear test method attached, flag it. That single pass — done before CAD work starts, not after a prototype comes back — is usually where the biggest, cheapest improvement in a hardware program's timeline comes from.

What's the hardest requirement on your current project to put a number on? That's usually the one worth resolving first.