Requirements, constraints and measures of success

A requirement needs a clear test of meaning

A requirement states something the solution must do or satisfy. A constraint limits the choices available, such as an agreed cost limit or a shelf that cannot be replaced. The terms overlap: a constraint is often recorded as a mandatory requirement. What matters in a comparison is knowing which conditions must pass and which qualities can be traded.

A measure gives a way to describe performance: width in millimetres, cost in euros, or successful returns out of a defined set of attempts. A target says what result is acceptable. ‘Easy’ supplies neither a method nor a threshold. A statement with a number still needs a reason and relevant conditions.

In this invented brief, the shelf opening has a measured clear width of 400 mm. The team chooses a maximum tray width of 380 mm. At that maximum, the unused width is 400 − 380 = 20 mm in total, or 10 mm on each side if centred. Those are illustrative choices; they do not establish adequate clearance for another shelf.

For this arithmetic, treat the supplied dimensions as exact. A real fit decision must also consider measurement uncertainty, variation in the tray and shelf, depth, height and any obstructions. Width clearance answers only the width question.

Write the checking method beside the requirement

For the width requirement, inspect the finished tray using the agreed measurement method. For an invented €30 material limit, add the recorded prices of all included materials. For returning tools, define which people, tools, instructions and starting arrangement belong in the trial.

Keep the reason beside each statement. The width limit reserves room within this shelf opening. The cost limit comes from this project's budget. Neither number becomes a general engineering rule because it appears in a neat table.

Check the requirement with the people whose task it represents. If the team measures return time while volunteers care mainly about tools ending up in the correct places, a fast result could reward the wrong behaviour.

Build a statement from the task

Start with the need: volunteers should leave tools where the next person can find them. “Finish quickly” is only a possible measure of that need. Someone could finish quickly by putting every tool in the nearest empty space. A better first outcome is a correct return without help; time could be recorded separately if delay also matters.

Now make the trial reconstructable. For the invented organiser brief, list ten return tasks, each naming one tool and its intended position. Use the agreed tool set, starting arrangement and neutral instructions with the intended volunteers. Count a task as successful only when the tool ends in its listed position without a hint; record any wrong placement or help as well as the final count. “Nine of ten” has meaning only with that denominator and rule.

The team can then propose: “In this defined ten-task trial, at least nine tasks shall end with the tool in its listed position without a hint.” In this example the volunteers and team agree that target for an early comparison, accepting one observed failure while investigating errors. It is a project choice to revisit, not a value derived from the width or a universal usability threshold.

Keep the trial sheet and observations as the evidence for that statement. Ask the volunteers whether correct placement captures their need and whether the chosen tasks leave anything important out. This connects the need, measure, conditions, success rule, agreed target and checking method. It also exposes a missing decision: if one particular wrong return has unacceptable consequences, an overall nine-of-ten count cannot conceal it.

A passing result answers the stated question

The ten-task target is a classroom example, not a statistically justified acceptance plan. Nine successes in those tasks would satisfy that stated target. They would not establish that every future participant can use the organiser or that every aspect of the design is suitable.

Checking conformance to specified requirements is verification. Evaluating whether the result serves intended users in its intended setting is validation. A tray can meet a width limit and still be awkward to use. Both questions belong in the design work.

Separate pass conditions from preferences

Candidate A is 376 mm wide and has an included material cost of €28. Candidate B is 388 mm wide and costs €24. The limits in this brief are 380 mm and €30.

A passes these two conditions. B passes cost but fails width by 8 mm. A lower price does not cancel that failure while width remains mandatory.

We still cannot select A from these two numbers alone: its return arrangement has not been checked. If the team wants to reconsider the width condition, it must revisit the shelf use and agree the revised requirement before judging the candidates against it.

Try the reasoning

1. A 380 mm tray is centred in a 400 mm opening. Is the side clearance 20 mm on each side?

   Show the answer and reasoning

   No. The total difference is 20 mm, so centring leaves 10 mm on each side in this simple geometry.

2. Can a preferred colour compensate for failing a mandatory fit condition?

   Show the answer and reasoning

   No. Preferences help compare candidates that satisfy the applicable conditions; they do not cancel a mandatory failure.

3. What is still unknown after nine successful returns out of ten defined tasks?

   Show the answer and reasoning

   Performance outside those tasks and people, the causes of errors, and other requirements remain unknown. The observed result supports a bounded claim.

4. A library team wants returned books to be findable. Its draft says “The return station shall be convenient.” Repair this into a checkable early-trial requirement. State one assumption you must agree before using it.

   Show the answer and reasoning

   One possible proposal is: “In a listed set of eight book-return tasks performed by intended users under the agreed starting arrangement and instructions, at least seven books shall end in their listed destination without a hint.” Record each destination, error and hint. Agree the destinations, task/user scope and whether this illustrative seven-of-eight target is acceptable before the trial. A quick return to the wrong destination would fail; the invented threshold is not a library standard or evidence about all users.

What to carry forward

Pair each important requirement with its reason, conditions and evidence. Decide which conditions are mandatory before comparing candidates.