Sample Non Functional Requirements: A Complete Guide for Business Owners and DevOps Engineers

Key takeaways

• A non-functional requirement (NFR) states how well a system must do its job, as a number you can test: response time, availability, throughput.
• Vague words like “fast” or “scalable” cannot be verified and get argued about after launch.
• Write each NFR with a target, the load it applies under, and the way you will measure it.

A non-functional requirement describes a quality of the system rather than a feature: how quickly it responds, how often it is available, how much load it carries, how well it protects data. A functional requirement says “the system shall allow user login”. A non-functional one says “95% of logins complete within 2 seconds at 500 concurrent users”. This page gives sample non functional requirements you can adapt, a template for writing your own, and a way to test them.

What are non-functional requirements, and why do they matter?

Features can work perfectly and still fail the people using them, because the system is slow under load, down for an hour a month, or unusable with a screen reader. NFRs are where those expectations get written down before the build, so that architecture, infrastructure and test plans can aim at them.

A requirement that cannot be tested is a wish. “The site must be fast” gives the team nothing to design for and gives the business nothing to hold anyone to. “The checkout API responds within 300 ms for 95% of requests at 200 requests per second” can be load tested, monitored in production and put in an SLA.

Which categories of non-functional requirements exist?

The most widely used catalogue is the product quality model in ISO/IEC 25010. The current edition is ISO/IEC 25010:2023 (the second edition, published November 2023, part of the SQuaRE series, titled “Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Product quality model”). It lists nine characteristics: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety. Compared with the 2011 edition, interaction capability replaced usability, flexibility replaced portability and safety was added. Older documents still use the eight-characteristic 2011 names, so check which edition a requirements document cites.

Performance efficiency is split into time behaviour, resource utilization and capacity. Reliability covers faultlessness, availability, fault tolerance and recoverability. Scalability now sits under flexibility. Those are the sub-characteristics the sample requirements below map to.

Sample non-functional requirements by category

The numbers below are examples to adapt, not recommendations. Derive your own from user expectations, contracts and what your architecture can deliver.

Availability targets translate into a downtime budget, which makes them easier to discuss. In a 30-day month, 99.9% allows 43.2 minutes of downtime, 99.95% allows 21.6 minutes and 99.99% allows 4.3 minutes. Each extra nine usually costs more in redundancy and operations, so ask what an hour of downtime really costs the business before picking one.

What are sample non-functional requirements for an e-commerce site?

An online store has a few NFRs that matter more than the rest, because they sit on the path to revenue. These are illustrative:

• Product pages: p95 server response under 400 ms at the expected daily peak.
• Search: p95 under 600 ms at 300 queries per second, with no more than 0.5% errors.
• Checkout and payment: p95 under 1 second, availability 99.95% in the monthly sales window, no card data stored outside the payment provider.
• Peak events: the system handles 5 times the normal traffic for the length of a sale, with an agreed degradation plan (queue, static fallback) beyond that.
• Accessibility: checkout meets WCAG 2.2 AA.

Pick peak numbers from your own analytics, such as last year’s busiest hour multiplied by expected growth, rather than a rule of thumb.

How do you write a good non-functional requirement?

1. Ask the stakeholders what failure looks like. Business, operations and security each have limits: “checkout must never be down for more than 10 minutes” is a requirement hiding in a complaint.
2. Choose a metric and a statistic. Response time as a p95 or p99, not an average (why percentiles beat averages); availability as a monthly percentage; error rate as a share of requests.
3. State the condition. A latency target means nothing without the load it holds at: users, requests per second, data volume.
4. State the measurement method and place. Measured at the load balancer or in the browser? In staging with production-sized data or in production?
5. Record trade-offs and constraints. Encryption costs CPU, five nines costs money, and a strict latency target can conflict with heavy validation.
6. Review and re-baseline. Traffic and architecture change; revisit the numbers every few months and after major releases.

A reusable template:

“Under a load of X, the system shall achieve metric Y (at most or at least Z) for P% of requests, with an error rate of at most N%, measured by method M.”

How do you test non-functional requirements?

Each category has a matching check. Load testing measures response time and error rate at expected and peak load, and stress testing finds where the system breaks. Failover drills and chaos experiments test recoverability. Security scans and audits check encryption and access rules, and accessibility audits plus usability sessions check interaction requirements. The types of performance testing are a good map of what to run for which requirement.

Link requirements to what you monitor. A requirement such as “99.95% of checkout requests complete under 300 ms in a month” becomes a service level objective, with the measured latency and error rate as the service level indicators. Run the load test before release and the same measurement continuously in production, for example with API monitoring, so the number you promised and the number you see are the same one.

Example: turning an NFR into a pass or fail test

This scenario is illustrative, not a customer result. Suppose a signup API must handle 2,000 signups per minute, which is about 33 requests per second on that endpoint. The NFRs are: p95 response under 250 ms, errors under 1%, and CPU below 80% on every node during the test.

In a k6 script the first two become thresholds, so the test itself fails when the requirement is missed:

import http from 'k6/http';

export const options = {
  scenarios: {
    signups: {
      executor: 'constant-arrival-rate',
      rate: 34,            // about 2,000 per minute
      timeUnit: '1s',
      duration: '10m',
      preAllocatedVUs: 50,
      maxVUs: 200,
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<250'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  http.post('https://staging.example.com/api/signup',
    JSON.stringify({ email: `user${__VU}-${__ITER}@example.com` }),
    { headers: { 'Content-Type': 'application/json' } });
}

The CPU requirement comes from your host metrics for the same time window. If the run misses a target, you tune (connection pooling, caching, indexes) and rerun until the thresholds pass; the NFR then works as an engineering goal rather than a paragraph in a document.

LoadFocus runs JMeter and k6 scripts from 25+ cloud regions, so a script like this one can run against a staging environment from where your users are, without setting up load generators. Each run can also produce an AI analysis of bottlenecks (loadfocus.com/load-testing, October 2026).

What mistakes should you avoid with non-functional requirements?

• Writing requirements that cannot be measured (“the system must be fast”).
• Quoting an average instead of a percentile, or a target with no load attached.
• Skipping the trade-off conversation between security, cost and performance.
• Never revisiting the numbers as the product grows.
• Leaving ownership unclear, so no team is responsible for a missed target.
• Testing once before launch and never again.

Frequently Asked Questions

What is a sample non functional requirement?

It is a measurable statement about system behaviour, such as “95% of search queries return within 300 ms at 200 queries per second”. It names the metric, the target and the load.

Who defines non-functional requirements?

Product owners, architects, DevOps and operations, QA and security usually define them together. Each group brings different limits: users’ patience, infrastructure cost, recovery needs and compliance rules.

What is the difference between functional and non-functional requirements?

Functional requirements say what the system does (“a user can reset a password”). Non-functional requirements say how well it must do it: how fast, how reliably, how securely and for how many users.

What questions help gather non-functional requirements?

Ask how many users and requests at the busiest hour and how that will grow, how long a user will wait before leaving, how much downtime the business can tolerate and how much data it can afford to lose, which regulations apply, and which devices, browsers and accessibility levels must be supported.

Can non-functional requirements change over time?

Yes. User numbers, architecture and regulations change, so re-check the thresholds every few months and after major releases.

Sources

• ISO/IEC 25010:2023, Systems and software engineering, SQuaRE, Product quality model: iso.org/standard/78176.html (characteristics checked against secondary summaries, October 2026).
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2: w3.org/TR/WCAG22.
• Grafana k6 documentation, thresholds and constant-arrival-rate executor: grafana.com/docs/k6.
• LoadFocus, cloud regions and supported scripts: loadfocus.com/index.md (October 2026).

Related reading

• Software Performance Engineering: A Complete Guide
• Top Cloud Testing Challenges and How to Fix Them