A product owner writes four lines on a ticketing ticket for the seat-map page, and the team must pick the one that is a testable non-functional requirement. Which line is it?

What is being tested

Whether you can tell a wish from a requirement. A non-functional requirement is only useful to an architect when someone can run a test that passes or fails against it. The question gives four lines that all sound reasonable and asks which one carries the numbers a design can be built and checked against.

The reasoning

A testable statement answers five things: what is measured (time until the seat map is visible), how it is summarised (p95, meaning 95 out of 100 requests are at least this fast), where (a mid-range phone over 4G, not a developer laptop), under what load (500 active sessions) and against what limit (2 s). Remove any one and two people can read the same line and disagree about whether it was met.

The load clause matters more than beginners expect. A page that loads in 600 ms for one tester can take 4 s when 500 people hold seats at once, because each seat selection queries the same inventory rows and the database queues them. A requirement without a load figure is satisfied by the one situation that never happens in production.

The percentile clause matters for the same reason. An average of 1 s can hide a tenth of customers waiting 6 s. Percentiles describe the slow tail, which is where the support tickets come from.

Why the other options fail

• "Feel fast and responsive for every customer on every device worldwide." This is a wish. "Feel" has no unit, "every device worldwide" cannot be tested, and nothing says how fast is fast enough. It would pass or fail depending on who is asked.
• "Highly available and absorb all expected peak demand without any degradation." It sounds engineering-grade but has no number: how many nines, measured over what window, and what is "expected peak"? "No degradation at all" is also impossible to promise, so the team can never claim to have met it.
• "Uses a well-known framework and follows the coding standard." This is a constraint on how the work is done, not on how the system behaves. A page built exactly to the standard can still take 8 s. Following a practice is not evidence of an outcome.

When this level of precision is the wrong effort

For an internal tool used by six people once a week, writing p95 and session counts is theatre. Write "reports open in under 10 s" and move on. Precision pays when the page is customer-facing, when load is spiky (a popular on-sale), or when a contract or SLO will quote the number back to you.

Common weak answers

• Picking the longest, most formal sentence. Length and tone are not measurement.
• Treating "functional" as the important kind. The seat map's functions are easy to list; its speed under a crowd is what shapes the database, cache and queueing design.

What a strong answer adds

Ask who owns the number and what happens when it is missed. A requirement nobody owns decays into a dashboard nobody reads. Pair it with a load test in the pipeline so a regression fails a build.