How to Write Performance Requirements That Are Actually Testable

Most software teams write requirements like "the system should be fast" or "the app should handle high traffic" without realizing those sentences can't be tested.

A tester reading them has no way to know what "fast" means in practice, whether 1 second counts as a pass or 5 seconds does, or how many users "high traffic" is supposed to cover. So the requirement gets tested loosely, based on whatever assumption the tester happens to make, and the real answer only shows up once the system is live and under real pressure.

This is one of the most common gaps in software QA, and it's also one of the easiest to fix once you understand why it happens.

What Is a Non-Functional Requirement?

Requirements generally fall into two categories. Functional requirements describe what a system does, like "users must be able to add an item to their cart." Non-functional requirements describe how well the system does it, covering things like speed, reliability, security, and how it behaves under different levels of demand.

Performance requirements are a specific type of non-functional requirement, focused on speed and behavior under load. Other common non-functional requirements include uptime, security standards, and how many users the system can support at once.

Functional requirements tend to get written clearly because they describe a concrete action. Non-functional requirements are where vague language creeps in most often, because words like "fast," "reliable," and "scalable" feel specific enough in conversation, even though they carry no measurable meaning on their own.

Why Vague Performance Requirements Cause Real Problems

A vague requirement doesn't just make testing harder. It removes the one thing that was supposed to catch a problem before it reached real users.

If a requirement simply says "the checkout must handle heavy traffic," different engineers on the same team will quietly assume different numbers. One might build with 1,000 concurrent users in mind. Another might assume 5,000. Nobody is technically wrong, because nothing specific was ever agreed on, and nobody finds out the assumption was too low until actual traffic exceeds it in production.

This is part of what happened during TSB Bank's 2018 migration failure, where a major system change went live without being tested against clearly defined, agreed-upon performance expectations beforehand.

We cover that case in more detail in our TSB Bank migration article, but the underlying lesson applies far beyond banking: when performance expectations aren't written down as specific numbers, nobody can test against them, and the system's real limits only get discovered by the people using it, at the worst possible time.

A properly written requirement removes that ambiguity. Instead of "should be fast," it states an exact number, under exact conditions, that either gets met or doesn't. That distinction is what makes a requirement testable in the first place.

What Makes a Performance Requirement Testable

A testable performance requirement generally needs four things: a specific metric, a clear threshold, the conditions it applies under, and a way to measure whether it was met.

Take "the API should respond quickly." As written, there's no metric named, no number given, no traffic level specified, and no measurement method described.

Compare that to "the API must return a response in under 300 milliseconds for 99% of requests, under normal daily traffic, measured by our monitoring tool." The second version can be tested directly. Someone can run a load test, check the actual response times, and get a clear pass or fail answer.

This pattern holds across almost every kind of performance requirement. "The system should be reliable" becomes testable once it's written as "the system must maintain 99.9% uptime, measured monthly."

"The system should handle high traffic" becomes testable as "the system must support 10,000 concurrent users with no more than a 1% error rate." In each case, the vague version and the testable version are describing the same underlying goal. The difference is that only one of them can actually be verified.

What a Performance SLA Should Include

A performance SLA, or service level agreement, is essentially a formalized version of these testable requirements, often used when a system's performance is being promised to a customer or another team, not just tracked internally.

A well-written SLA typically names the specific metric being measured, such as response time or uptime. It states a clear threshold, the exact number that separates a pass from a failure, rather than a vague description like "acceptable performance."

It defines the conditions the threshold applies under, since a system's performance during normal traffic and during a major sale are two very different situations. It explains how that metric actually gets measured, including which tool is used and how often. And for external agreements especially, it states what happens if the threshold isn't met.

Leaving out any of these turns the SLA back into a soft promise instead of something either side can actually verify.

Writing Requirements That Hold Up Over Time

Writing a testable performance requirement once is only half the job. Systems change constantly, and a requirement that was accurate a year ago may no longer reflect current usage patterns, current infrastructure, or current customer expectations.

A checkout that handled 5,000 concurrent users comfortably during a smaller company's early growth might quietly become inadequate at 10x that scale, and if nobody revisits the original requirement, nobody notices until performance testing, or worse, real traffic, exposes the gap.

This is also where the discipline of writing testable requirements connects to a broader QA practice.

The same principles that apply to performance requirements apply across other requirement types too, which we cover more generally in how to write testable requirements. Performance requirements simply tend to be where the habit breaks down first, because words like "fast" and "reliable" sound reasonable in a meeting even though they carry no testable meaning.

Once requirements are written this specifically, they can be tracked and verified on an ongoing basis rather than checked once and forgotten.

This is where requirements traceability becomes genuinely useful rather than a compliance formality. A platform like TestMax ties a specific, testable performance requirement directly to an active test, so if a future code change quietly pushes checkout past its 2-second target, that gets flagged before release rather than after a customer notices the slowdown themselves.

The Practical Takeaway

The difference between "the system should be fast" and "checkout must complete in under 2 seconds for 95% of users under normal traffic" isn't just wording. One is a hope.

The other is something a QA team can actually build a test around, track over time, and catch a violation of before it ever reaches a real customer. Writing performance requirements this way takes a little more effort upfront, but it's the same effort that prevents a much larger, much more expensive conversation after something breaks in production.