Write a system NFR as a measurable metric — a response-time percentile under a given load, availability as a percentage and as minutes of downtime — and map it to an ISO/IEC 25010 quality characteristic.
NFR: metric, threshold, load, period
NFR: metric, threshold, load, period
The BA course had a rule: an NFR is written without the word “fast”, with a number. A systems analyst pins the number down: which metric, which threshold, under what load, over what period and where it is measured.
Response time. An average hides slow requests, so requirements use a percentile. p95 = 300 ms means: 95% of requests complete in 300 ms or less, and 5% may be slower. p99 watches the tail: the slowest requests, the very ones customers complain about.
Load is the number of requests per second (RPS), usually at peak. A response-time requirement without a load is incomplete: the same service responds fast in a quiet hour and slowly at peak.
Availability is the share of time the service is up. 99.9% over a 30-day month: 30 × 24 × 60 = 43,200 minutes, and downtime is 0.1% of them, that is, 43.2 minutes. Each extra “nine” cuts the allowed downtime tenfold and costs noticeably more.
Template: “95% of GET /orders/{orderId} requests are processed in 300 ms or less under a load of up to 200 requests per second; measured from server logs over a calendar month.”
Quality characteristics come from the ISO/IEC 25010:2023 model, which has 9 of them. The ones an SA meets most often are in the table below. The rest: functional suitability, interaction capability (formerly usability), flexibility (formerly portability) and safety for people and the environment (new in 2023).
Availability and downtime
A month is 30 days, a year is 365 days.
| Availability | Downtime per month | Downtime per year |
|---|---|---|
| 99% | 7.2 h | ≈ 3.65 days |
| 99.9% | 43.2 min | ≈ 8.8 h |
| 99.95% | 21.6 min | ≈ 4.4 h |
| 99.99% | ≈ 4.3 min | ≈ 53 min |
Quality characteristics (ISO/IEC 25010) in Romashka's NFRs
| Characteristic | Question | Example |
|---|---|---|
| Performance efficiency | how fast, and how much load it can take | p95 ≤ 300 ms at 200 RPS |
| Reliability | how often and for how long it is unavailable | 99.9% per month |
| Security | who has access to what | you can't open someone else's order, even if you know its number |
| Compatibility | whether it works well with other systems | accepts orders in the partners' shared API format |
| Maintainability | how easy it is to change | a new payment method is added without changing the rest of the code |
Lesson notes
NFR: metric, threshold, load, period
The BA course had a rule: an NFR is written without the word “fast”, with a number. A systems analyst pins the number down: which metric, which threshold, under what load, over what period and where it is measured.
Response time. An average hides slow requests, so requirements use a percentile. p95 = 300 ms means: 95% of requests complete in 300 ms or less, and 5% may be slower. p99 watches the tail: the slowest requests, the very ones customers complain about.
Load is the number of requests per second (RPS), usually at peak. A response-time requirement without a load is incomplete: the same service responds fast in a quiet hour and slowly at peak.
Availability is the share of time the service is up. 99.9% over a 30-day month: 30 × 24 × 60 = 43,200 minutes, and downtime is 0.1% of them, that is, 43.2 minutes. Each extra “nine” cuts the allowed downtime tenfold and costs noticeably more.
Template: “95% of GET /orders/{orderId} requests are processed in 300 ms or less under a load of up to 200 requests per second; measured from server logs over a calendar month.”
Quality characteristics come from the ISO/IEC 25010:2023 model, which has 9 of them. The ones an SA meets most often are in the table below. The rest: functional suitability, interaction capability (formerly usability), flexibility (formerly portability) and safety for people and the environment (new in 2023).