Requirements and success criteria

In brief

Ask a client what they want and you will often hear "make it strong" or "make it fast." Both sound like instructions, and neither one can be checked. Strong compared to what, under what load, measured how? A requirement is the tool engineers use to turn that kind of sentence into one that can be tested against a real object: "the bracket must support 50 kilograms without permanent deformation." Notice what changed. The new sentence says what the bracket must do and gives a number a stranger could measure, but it says nothing about the material, the shape, or the manufacturing process. That silence about how is not an omission, it is the entire point. A requirement states WHAT must be true and leaves HOW open, because collapsing the two together is the single most common way a design gets locked into a bad choice before anyone had the chance to compare alternatives.

The full treatment

A requirement is not a design decision in disguise

Compare two sentences: "the door must open using no more force than a typical adult hand can apply" and "the door must have a lever handle." The first is a requirement. It names an outcome, force under a stated threshold, and it leaves every mechanism open: lever, knob, push plate, foot pedal, automatic sensor, all remain candidates. The second sentence looks similar but has already chosen a mechanism, foreclosing every alternative before anyone compared them. This is the most common failure in specification writing: dressing a design choice up as a requirement. The test is simple and mechanical. If the sentence names a component, a material, or a specific mechanism, it is implementation. If it names an outcome and a way to measure it, it is a requirement.

Making a requirement measurable

A requirement that cannot be checked is not a requirement, it is a hope. "Comfortable," "durable," and "user friendly" fail this test on their own; they need a number and a method attached. Take "durable" for a hinge and turn it into something checkable: the hinge must survive 100,000 open close cycles under a 2 kilogram load without visible wear affecting closure force by more than 10 percent. Every measurable requirement has the same skeleton: a subject (the hinge), a condition (under a 2 kilogram load), a metric (closure force change), a threshold (10 percent), and a test method implied or stated (a cycling rig). Strip any one of the four away and the requirement stops being verifiable, which means two engineers could each believe they met it while building incompatible things.

Requirements expose contradictions before metal is cut

Once wants are written as measurable requirements, they can be checked against each other on paper, which is far cheaper than discovering the conflict in a prototype. Suppose a device must weigh under 200 grams and must run for 24 hours on battery. Known battery energy density puts a floor on the mass needed for 24 hours of runtime at the device's power draw; if that floor exceeds 200 grams, the two requirements are not jointly satisfiable and no amount of clever engineering will rescue both as stated. Finding this on paper, by comparing two numbers, is the entire value of writing requirements before designing: the contradiction is now a decision to make, relax the runtime, relax the weight, or improve the power draw, rather than a surprise discovered after the prototype is built and does not work.

Requirements versus success criteria

A requirement is written before the work; a success criterion is the same statement read afterward, as a pass or fail test. "The bracket must support 50 kilograms without permanent deformation" is a requirement while the bracket is being designed and a success criterion once the finished bracket is tested against it. Keeping the wording identical across both moments is what makes the whole process honest: if the acceptance test uses different numbers or conditions than the original requirement, the team has quietly moved the goalposts, and no one can say with confidence whether the design actually met what was asked of it.

Lineage

Naming what a structure must do before choosing how to build it is at least as old as written contracts for construction: ancient building codes, including Hammurabi's code, state consequences tied to performance, a house that collapses and kills its owner, rather than tied to a specific building method, which shows an implicit separation of required outcome from chosen technique. The deliberate, systematic version of the practice, writing requirements as a distinct engineering document, checkable and independent of implementation, was formalized through twentieth century systems engineering, driven by large aerospace and defense projects where hundreds of contractors had to build interoperating pieces against a shared, unambiguous specification. That formalization is now codified in professional references such as the INCOSE Systems Engineering Handbook, and it is taught in product design courses through the more everyday language of customer needs and target specifications.

The strongest case for it

Writing requirements this way earns its place because it moves the discovery of a contradiction to the cheapest possible moment, before any material or labor is committed. A requirement that is measurable can be checked mathematically or logically against another requirement without building anything, which is exactly how conflicts like the weight-versus-runtime example above get caught early. The practice also produces an auditable record: when a finished design is challenged, the requirement document is the agreed standard against which "did it work" can be settled without argument, because both sides can point to the same number and the same test. Across large projects with many contributors, this shared, checkable language is what allows components designed by different teams, sometimes years apart, to fit together on the first attempt rather than the fifth.

The strongest case against it

Requirements writing has real limits, and pretending otherwise causes its own failures. First, over-specification is common: an author writes "must use a stainless steel bracket" when they meant "must resist corrosion," smuggling a design decision in as a requirement and quietly removing cheaper or lighter alternatives from consideration without anyone noticing the choice was made. Second, requirements can be individually measurable and still incomplete: a device can pass every stated test and still fail in the field because a real condition, humidity, vibration, an unusual user, was never written down as a requirement at all. No requirement document can claim completeness with certainty; it can only claim to cover what was anticipated. Third, in genuinely exploratory work, where no one yet knows what outcome is even achievable, writing precise numeric requirements too early can foreclose discovery, freezing a target before enough is known to set it sensibly. The tool is for bounding a design problem, not for replacing judgment about when a target is still unknown.

Where it stands now

The practice of separating measurable requirements from implementation is broad consensus in professional engineering and is formally codified in systems engineering standards used across aerospace, automotive, medical device, and software industries. Debate that remains active is not about whether to write requirements this way, but about how to manage large, evolving requirement sets over a long project without losing traceability, and about how to write requirements for systems whose behavior depends on interacting with unpredictable environments or users, where a fixed numeric threshold is harder to defend in advance.

Test yourself

You have been asked to build "a chair that's really comfortable and doesn't cost much." Write three measurable requirements that replace this sentence, each with a subject, a condition, a metric, and a threshold, and each free of any named material, shape, or manufacturing method. Then check your own three requirements against each other for a possible contradiction, the way the weight-versus-runtime example was checked above, and state whether you find one. If you do, say which requirement you would relax and why. If you do not, say what additional, currently unstated requirement could still expose a hidden conflict.