“The website must be fast.” How do you make that a useful requirement?

Everything runs smoothly in the demonstration. After launch, registrations open, users wait and staff struggle to load the request list. Does the system meet the requirements? That is difficult to answer if the only requirement was “fast performance”.

Instead of choosing an arbitrary number of seconds, describe the tasks and situations where responsiveness matters.

Choose important user tasks

These might include opening service information, submitting a form or preparing a report. For each, define what completion means: all content displayed, a request saved or a finished file available.

Separate acknowledging a task from completing it. If a report is prepared in the background, users need to know the request was received and where the result will appear.

Describe the test conditions

Specify the number and types of users performing tasks at the same time, the data volume and exceptional periods such as registration opening. Explain the basis for those assumptions: existing measurements, an event plan or an initial estimate.

Device and connection conditions should be explicit too. A result obtained in one environment does not automatically describe every user's experience. The purpose is to agree a useful test, not to conceal those differences behind a single number.

Agree measurement and responsibility

Ask for proposed measurable criteria, a test environment and a reporting method. Agree them before implementation. Check whether the test includes dependencies on other systems or replaces them for the exercise.

Separate test preparation, improvements and infrastructure costs in the quote. Ask which scale of use would require the plan to be reviewed. This turns “a fast system” into an agreed piece of work with stated conditions, rather than an open-ended promise that neither side can reliably verify.