Non-functional requirement examples

Published 19 October 2026

Non-functional requirements say how well software must do what it does — how fast, how secure, how available, how easy to use — as targets you can measure. Functional requirements say what it does. Below are examples by type, examples for a web application and a mobile app, the list of types, a checklist, a template, and how to write them so they can be tested.

Non-functional requirements… How does the system fulfill business needs? Always has the -abilities … reliability, interoperability, maintainability, and qualities such as supported browsers, security, performance, etc.

— r/businessanalysis, 2025

Non-functional requirements examples

The examples come from one project: a customer portal where business customers see and pay their invoices. Each has a number, and the conditions under which it must hold.

Performance

• The payment page responds within 2 seconds for 95% of requests, with 500 customers using the portal at once.
• Search results appear within 1 second for 95% of searches.
• An export of 10,000 invoices to CSV is ready within 30 seconds.

Capacity and scalability

• The portal handles 2,000 customers signed in at once with the response times above.
• It stores 5 million invoices with the same response times.

Availability

• The portal is available 99.9% of each calendar month, not counting maintenance announced three days ahead and done on Sundays between 02:00 and 04:00 CET.

Reliability and recovery

• A backup is taken every hour, so no more than one hour of data can be lost.
• After a failure, the portal is back within 4 hours.
• 99% of receipts arrive by email within 5 minutes of the payment.

Security

• All traffic is encrypted (HTTPS only).
• Card details never reach the portal’s servers; payments go through the payment provider’s page.
• Sign-in is locked for 15 minutes after 5 failed attempts.
• The penetration test before go-live leaves no open high or critical findings.

Privacy and data

• Personal data is stored in the EU.
• A customer’s personal data is exported, or deleted, within one month of a request.
• Invoices are kept for the period the client’s accounting rules require — ten years in this project — and then deleted.

Usability and accessibility

• Four of five first-time users find and pay an invoice without help, in under 3 minutes.
• The portal meets WCAG 2.2 level AA, checked by an audit before go-live.
• Every action can be done with a keyboard alone.

Compatibility

• The portal works in the latest two versions of Chrome, Edge, Firefox and Safari, and on screens from 360 pixels wide.
• Paid invoices reach the accounting system within 5 minutes.

Maintainability

• A developer new to the project can run the portal and its tests on their machine within an hour, following the README.
• Automated tests cover the payment code and run on every change.

Monitoring and support

• Every failed payment is logged with the invoice number and the bank’s reason.
• Support is alerted within 5 minutes when more than 5 payments fail in 10 minutes.

Functional vs non-functional requirements

A functional requirement says what the software does; a non-functional one says how well it must do it. The same feature usually has both:

Software can do everything the functional requirements say and still fail: too slow to use, down at month-end, or open to attack. Functional and non-functional are two of several types of requirements.

The line between the two is not always sharp. “Lock sign-in after 5 failed attempts” is a security rule, and also a behaviour you test like a feature. Where it is filed matters less than that it is written down, with a number, and linked to what it applies to. One commenter:

So, functional and NFRs are related, and relating them helps everyone on the team make sense of them and make feasibility, prioritization and trade off decisions.

— r/businessanalysis, 2025

More on writing the functional side: the functional specification template.

Types of non-functional requirements

The ISO standard for software product quality, ISO/IEC 25010:2023, describes it with nine characteristics (listed on arc42’s quality site):

Functional suitability is about whether the software does the right things; the other eight describe how well it does them. The 2023 edition renamed usability to interaction capability and portability to flexibility, and added safety (summary of the changes).

Non-functional requirements checklist

Decide each of these before the build, or write down why it does not apply:

• Performance: response times for the main tasks, as a percentage of requests, under a stated load.
• Capacity: users at once and data volumes, today and in two years.
• Availability: service hours, uptime per month, maintenance windows.
• Recovery: how often backups are taken, how much data may be lost, how fast service returns.
• Security: sign-in, roles, encryption, and the testing before go-live.
• Privacy: where personal data is stored, how long it is kept, how it is exported and deleted.
• Usability: which tasks new users must manage without help, and how fast.
• Accessibility: the standard and level, such as WCAG 2.2 AA.
• Compatibility: browsers, devices, screen sizes, and the systems it must work with.
• Maintainability: tests, documentation, and how a new developer gets started.
• Monitoring: what is logged, who is alerted, and how fast.
• Languages and formats: languages, dates, numbers, currencies and time zones.

To find the numbers, ask the people who will use and run the system — the requirements gathering questions include a set for non-functional requirements.

Non-functional requirements template

One requirement per block. Square brackets are yours to fill in; in a spreadsheet, each field is a column.

NFR-[nnn]  [type]
The [system or feature] shall [quality],
[measured how], [under which load or
conditions].

Applies to:   [FR-n, or "whole system"]
Source:       [BR-n, or who asked]
Priority:     [must / should / could]
Verified by:  [load test, audit, ...]

Filled in, for the customer portal:

NFR-007  Performance
The payment page shall respond within
2 seconds for 95% of requests, with 500
customers using the portal at once.

Applies to:   FR-014 pay by card
Source:       BR-03 shorten the time
              invoices stay unpaid
Priority:     Should
Verified by:  Load test before go-live

In a full software requirements specification, these sit in their own sections next to the functional requirements.

How to write non-functional requirements

1. Start from what a user does, not from a category. “How fast should the customer see the payment confirmed?” gets a better answer than “what are your performance requirements?”
2. Put a number on it, with the conditions: how many requests, how many users at once, over what period.
3. Say how it will be checked: a load test, an accessibility audit, a penetration test, a usability test with five users.
4. Link it to what it applies to: one functional requirement, a set of them, or the whole system.
5. Ask what each target costs. A higher target can take more to build and run; the downtime table below shows what each step in availability means.
6. Get them signed off with the rest of the requirements — the requirements sign-off template has the wording.

Vague words cannot be tested. Replace them with a number:

Availability is easier to picture as downtime. In a 30-day month:

Non-functional requirements for a web application

• Pages show their main content within 2.5 seconds for 75% of visits, on phones and on desktops — the threshold Google gives for a good Largest Contentful Paint.
• The site works in the latest two versions of Chrome, Edge, Firefox and Safari, and on screens from 360 pixels wide.
• It meets WCAG 2.2 level AA.
• It is served over HTTPS only.
• It is available 99.9% of each calendar month.
• A session ends after 30 minutes without activity.

For security, OWASP’s Application Security Verification Standard (ASVS) is a numbered list of security requirements for web applications that your own requirements can point to.

Non-functional requirements for a mobile app

• The app runs on the two latest major versions of iOS and Android.
• It opens to the start screen within 2 seconds on the test phone named in the specification.
• Without a connection, it shows the invoices last loaded, and when they were loaded.
• The download is under 50 MB.
• At least 99.5% of sessions end without a crash.
• It works with the phone’s screen reader and its largest text size.

Non-functional requirements in agile and user stories

I prefer to think of non-functional requirements as “constraints” we put on the system.

— Mike Cohn, Mountain Goat Software

In a backlog, they go in one of three places:

1. In the definition of done, when they apply to every story — “every page meets WCAG 2.2 AA”, “no new high-severity security findings”. SAFe’s guidance ties them to it as well: “NFRs are persistent qualities and constraints typically revisited as part of the definition of done (DoD) for each Iteration, PI, or release” (SAFe). See the definition of done.
2. As acceptance criteria, when they belong to one story — “Then the receipt arrives within 5 minutes”. See the acceptance criteria template.
3. As a story of their own, when they need work of their own — setting up load tests, or a second server. Cohn’s example: “As a user, I want the site to be available 99.999 percent of the time I try to access it, so that I don’t get frustrated and find another site to use.” More on the format: the user story template.

Writing them down is half of it; the other half is not treating them as optional. One commenter, on performance and security work:

Those user stories aren’t done unless those other items are also done, period.

— r/agile, 2019

Non-functional requirements and AI agents

When an AI coding agent writes the code, a target that is not in the spec — a response time, an accessibility level, a list of browsers — is not one it can check its work against. Put them in the spec it reads, as requirements with numbers, and name the test or command that checks each one. The spec.md template shows the format.

Some of them are harder to check than others. In a thread about having AI define success conditions for its changes, one commenter replied:

Functional requirements can be handled easily that way, yes. Maintainability however is about non-functional requirements like low complexity / decoupling.

— Hacker News, 2026

When the system is an AI agent, it needs non-functional requirements of its own: how long an answer may take, what one task may cost, which actions need a person’s approval, and what is logged for review.

Where Specroot fits

This is the problem Specroot works on: non-functional requirements kept next to the features they apply to, in the version that was signed off, so that a change to one shows what it affects in the other. Specroot for agencies and consultancies.