“The order page must be fast, available and secure” leaves a team with several unanswered decisions. The team needs to agree which customer journey is being timed, the conditions under which it must work and the actions each person is allowed to perform. A Product Owner can help turn these expectations into conditions the team can examine, test and monitor.
This article uses a hypothetical order page at Mercato to develop measurable examples. The numbers are illustrative proposals for that case, not industry standards or measured results. Choosing actual targets requires evidence about customer needs, current behaviour and the cost of meeting them.
Connect the quality requirement to a specific operation
A functional requirement describes behaviour such as showing a customer's order. A non-functional requirement typically describes a quality or constraint of that behaviour: how quickly the details appear, how reliably the operation succeeds or which conditions apply to its use. Some concerns cross that boundary. Authorization, for example, can be described as a security quality requirement and as specific allowed or forbidden operations.
The classification matters less than the agreement it produces. For Mercato, “fast” applies first to opening the order details after a signed-in customer selects an order. Updating the delivery address is a separate operation, with different dependencies. Combining both in a single average could conceal the fact that one journey works while the other is failing.
Performance: define the journey, the load and the measurement
The team proposes that at least 95% of order-detail openings display the agreed essential information within two seconds in a representative test. To make that statement usable, it must define the start and end of the measurement. Measuring a server response alone omits network delay and browser rendering; a customer-facing measure might instead run from selecting the order to displaying its status, items and delivery information.
The test conditions also belong in the requirement. In this example, the team uses an agreed mobile device and network profile, a production-like environment with synthetic order data and 50 order-detail openings per second sustained for 15 minutes after warm-up. Engineering still needs to assess whether that load represents the expected campaign traffic and how the test models sessions, caching and dependencies. The example is not a complete load-test specification.
The target should be accompanied by a success-rate condition. A fast error response must not improve the latency result while hiding failed openings. The team can define a successful opening as one that displays the required information correctly, report failures separately and review slow requests as well as the 95th-percentile threshold. A passing test under one profile does not demonstrate the same experience on every device or network.
Availability: specify what counts as a successful service
For production, Mercato proposes a service level objective: at least 99.9% of eligible order-detail requests should return the correct order information during a rolling 30-day window. That is a request-based objective, not a percentage of elapsed time. It needs an agreed source of measurements, an explicit definition of eligible requests and a way to identify incorrect responses, not merely successful HTTP status codes.
A valid request for an existing order that fails because a dependency is unavailable should count as a failure of the promised operation. Invalid input and attempts by an unauthorized account need their own expected responses. Those distinctions must be documented before reviewing the numbers, so the definition cannot be adjusted after an outage simply to make the result look better.
A service level objective guides operational decisions; it does not become a contractual service level agreement automatically. Nor can a short pre-release test establish compliance over the next 30 days. Before launch, the team checks the instrumentation and relevant failure behaviour; during operation, it measures the objective and agrees what happens when performance falls short. The article on the nines of availability develops the meaning of these targets and their measurement context.
Permissions: make forbidden access verifiable
“Only the customer can see their order” needs to cover the underlying request as well as the screen. Hiding a button or link does not prevent someone from submitting a request directly. For Mercato, the team can agree that an authenticated customer may read their own orders, while a request for another customer's order must disclose none of its details and must not modify it.
Verification then includes changing the order identifier in a request and checking the denied result, using test accounts with different ownership and permissions. Support access needs an explicit policy of its own, including which roles may view or change an order. These are observable cases within a broader security approach; passing them does not prove that the entire product is secure. The guide to authentication and authorization explains the distinction behind these rules.
A short record that preserves the measurement conditions
The table summarizes the proposed requirements. The underlying item or linked specification must retain the details of the dataset, environment, eligibility rules and evidence. A target copied without those conditions loses much of its meaning.
| Concern | Proposed condition | Evidence |
|---|---|---|
| Performance | At least 95% of openings display essential details within two seconds under the documented test profile; failures are assessed separately. | Journey timing and failure results from the agreed load test. |
| Availability | At least 99.9% of eligible detail requests return correct information over a rolling 30 days. | Production measurement with documented success and eligibility rules. |
| Authorization | A customer cannot read or modify another customer's order, including through direct requests. | Positive and negative permission checks with representative test accounts. |
Place the requirement where it will be used
A quality condition specific to a change can appear among its acceptance criteria, with a link to the agreed verification method. A quality measure that applies to every Increment may belong in the Definition of Done. A production service objective also needs ownership and operational measurement. These locations serve different purposes; recording a number in a ticket does not provide the monitoring needed to evaluate it later.
The Product Owner brings the customer need and the consequence of missing the target. Engineering and QA assess feasibility, cost, test conditions and available evidence. If the desired target is not achievable within the current scope, the team needs to discuss the options explicitly: a smaller rollout, a narrower journey, additional technical work or a different launch date. Requirements affecting security cannot simply be traded away as spare capacity.
The article on technical questions during backlog refinement helps identify these unknowns early. The acceptance criteria examples cover the wording of agreed behaviour. For a broader treatment of quality evidence, see Testing, Bugs, and QA for Product Managers; Security for Product Managers develops access and risk decisions.
References
- Google SRE: indicators, service level objectives and measurement.
- OWASP: checking authorization on requests and resources.
- The Scrum Guide: Definition of Done and quality measures.