How to write performance requirements so that they are actually implemented (and tested)
- Ganna Kaplun
- 17 лют.
- Читати 5 хв
Introduction
As a product becomes more popular, the number of users, orders, API requests, and data increases. At this point, typical problems “suddenly” appear: pages take longer to load, search slows down, checkout freezes, and integrations with partners start returning errors.
Very often, the reason is simple: performance requirements are either missing or written in too general a way (“should work fast”). As a result, it is difficult for the team to understand what exactly is considered success, and for testers to know how to test it.
This article explains how to formulate clear, measurable, and testable performance requirements in a language accessible to business analysts and product owners.
What is system performance — in simple words
Performance is not just “speed.” It is a set of characteristics that describe how predictably and consistently a system operates under high user load and large data volumes.
Key components of performance:
Latency / Response time - how quickly the system responds to an action.
Throughput - how many requests/operations the system can process.
Error rate - how many errors occur under load.
Scalability - how well the system copes with increasing load.
Resource utilization - how much the system "costs" to operate (CPU/RAM, etc.).
Why performance requirements are important
Well-written performance requirements help:
align business and development team expectations;
prepare for peak loads (promotions, seasonality, PR campaigns);
avoid production “fires”;
include performance in the Acceptance Criteria, rather than mentioning it at the end.
One of the most useful practices: consider performance as part of the quality of service, just as important as functionality.
Mini-dictionary
• Response time ( Latency) - how much time passes from user action to result.
• Percentile (Percentile: P95/P99) - “in 95 cases out of 100 it will be faster than X”. This is more accurate than the average.
• Throughput - how many requests/operations are processed per second/minute.
• Concurrency - how many operations/users are “working” at the same time.
• Error rate - the proportion of requests with errors or timeouts.
• Availability - what percentage of the time the system is available.
• Graceful degradation - controlled simplification of functions during peak hours so that the system does not “crash”.
• Service Level Agreement (SLA) - a legally/formally guaranteed level of service (e.g. 99.9% availability).
• Service Level Objective (SLO) - an internal goal (e.g. P95 latency ≤ 500ms), often “stricter” than SLA.
• Service Level Indicator (SLI) - a specific metric that is measured (latency P95, error rate, availability).
Load profile: what is it and why is it needed?
Even a correct requirement like “P95 ≤ 800 ms” will be incomplete if you do not describe the conditions under which it should be fulfilled.
Load profile - a description of how the system is used in real life:
what actions are performed most often (search, browse, checkout);
in what proportions;
how the activity changes over time (growth → peak → decline);
what typical data (for example, basket size or “heavy” queries).
Example of a load profile for e-commerce
During peak hours, users may perform different actions with different frequencies:
35% - browse the catalog
25% - search
20% - view the product
10% - add to cart
10% - place an order
It is also important to describe how the load behaves over time:
Warm-up: gradual increase, for example, 15 minutes
Peak: consistently high traffic, for example, 60 minutes
Decline: return to normal, for example, 15 minutes
This helps to formulate requirements not “in a vacuum”, but in a realistic scenario.
How to formulate performance requirements: simple logic
A good requirement usually answers 4 questions:
1) What do we measure? (scenario)
2) What metric? (speed, throughput, errors…)
3) Under what conditions? (peak, duration, typical data)
4) How is it measured? (client, server, DBMS/E2E logs)
Example of “bad/good”:
Bad: “The system should work fast.”
Good: “For ‘Order Placement’, response time P95 ≤ 800 ms and P99 ≤ 1500 ms during peak load for 60 minutes; error rate ≤ 0.3%.”
That is why it is important to measure P95/P99, not the average.
Confluence/Jira template
Scenario: [Description of the function/scenario]
Why is it important (Business importance): [Business value, impact on the user or process]
Description of the user action (User journey): [Briefly: what the user does and what result is expected]
Expected load (Load profile):
- Peak load (Peak):
- Share among all actions (%):
- Typical data (Data characteristics):
Speed requirements (Response time):
- P95 ≤ …
- P99 ≤ …
Stability (Error rate): - ≤ … %
Throughput: - … requests/sec or … operations/min
Measurement conditions (Conditions):
- Peak duration:
- Data type:
- Environment:
Graceful degradation: [What is allowed to be simplified and what should remain stable]
Measurement/monitoring: [logs, E2E, external monitoring systems]
Template example
Scenario: Checkout
Why it is important (Business importance): Critical stage of sales. Delays affect user conversion and trust.
Description of user action (User journey): User clicks “Checkout” → receives order confirmation.
Expected load (Load profile):
- Peak load: 3000 requests/sec
- Share among all actions: about 10%
- Typical data: cart 3–5 products (P95 - up to 20 products)
Speed requirements (Response time):
- P95 ≤ 800 ms
- P99 ≤ 1500 ms
Stability (Error rate): ≤ 0.3% during peak hours
Throughput: The system must process at least 3000 requests/sec
Measurement conditions (Conditions):
- Peak lasts 60 minutes;
- Production-like environment;
- Realistic datasets (obfuscated production data).
Graceful degradation: Allow for recommendations to be simplified during peak times, but order fulfillment must remain stable.
Metrics/Monitoring: E2E monitoring, server logs
How to write requirements for data processing systems
For products that involve data loading and processing, it’s often not “milliseconds” that matter, but the time to the finished result. This can be described in the most business-like terms.
Three simple categories of requirements:
1) Time to result: “New data should be available in reports/results no later than 30 minutes after loading.”
2) How long the system can withstand under peak conditions: “During peak conditions, the system should accept up to 200 downloads per minute without failures.”
3) Stability: “During peak activity, no more than 0.2% errors are allowed.”
Additionally, if there is a “business deadline”: “Night processing should be completed by 07:00, even if the data volume increases by 2 times.”
Bonus: if the product works with embedded hardware
In systems that interface with devices, it’s not just “fast” that matters, but “always on time.” Here, requirements like:
“A task must be executed every 10 ms; maximum execution time is no more than 7 ms.”
“Signal processing must be stable without TTL skips.”
Checklist: is the requirement well formulated?
There are specific metrics (speed / throughput / errors / time to result)
There are P95/P99 percentiles (not just average)
There is a clear scenario
There are conditions (peak, duration, typical data)
It is stated how the result is measured
It is described what is allowed under the peak (degradation)
Conclusion
To make performance requirements work, a simple rule is enough: numbers + scenario + conditions + measurement method.
BA/PO does not need to delve into technical details. It only needs to correctly describe the product's expected behavior under real-world load and make it part of the acceptance criteria.
If you want to delve deeper into the topic of non-functional requirements, pay attention to the course "Non-Functional requirements(NFR): elicitation and analysis"
Art of Business Analysis training schedule
News and articles on business analysis: