How to tell the two kinds of requirement apart, with worked examples across several domains, the grey areas that resist classification, and why catching a non-functional requirement late costs so much.
Why the distinction matters
Functional requirements define what your software must do. Non-functional requirements define how well it must do it.
Most teams understand functional requirements instinctively. Someone asks for a feature, a user story gets written, and developers build it. The gap appears with non-functional requirements, because they’re easy to defer, and deferring them is expensive.
Here’s a pattern repeated across more projects than I can count. A team builds a photo upload feature. It works perfectly in testing. Then production happens: a user uploads 50MB images from their phone, the page takes 45 seconds to load, the mobile app crashes, and storage fills within a week. The feature technically works but it’s completely unusable.
What was missing were the non-functional requirements: maximum file size, supported formats, compression on upload, performance targets, and progress feedback. Nobody specified them. Nobody built them. The demo looked great. Production was a disaster. When NFRs are missing or vaguely specified, projects fail in expensive ways. Sometimes they end in software dispute litigation.
Non-functional requirements aren’t optional extras. They’re the difference between a demo and a product.
Side by side
A functional requirement describes something the software does. A non-functional requirement constrains how well it must do it. The two almost always come in pairs, and seeing the pairing is the quickest way to internalise the distinction.
| Functional requirement | Non-functional requirement |
|---|---|
| User can upload a photo | Photos must upload within 5 seconds on 4G |
| User can log in | Login must handle 10,000 concurrent users |
| System sends a confirmation email | Email must deliver within 30 seconds |
| Customer transfers money between accounts | Transaction must complete within 3 seconds and roll back automatically if it fails |
| Admin generates a sales report | Report must complete within 30 seconds for datasets up to 100,000 records |
| User resets their password | Reset link must expire after 24 hours; passwords must be hashed using bcrypt |
Notice the pattern. Functional requirements describe an action or capability. Non-functional requirements constrain how that action must perform: fast enough, secure enough, reliable enough to be usable in production.
Cross-cutting concerns
Many non-functional requirements do not belong to any single story. They apply across the whole product. The handbook calls these ‘cross-cutting concerns’ (see Writing Requirements) because they cut across multiple features rather than describing one specific behaviour.
Restating these on every ticket is wasteful and error-prone; leaving them off every ticket is worse. They are properties of the system, and they belong at the system level, captured once and inherited everywhere. The domain examples below show what that looks like in practice — a handful of functional and non-functional pairs for a domain, followed by the cross-cutting requirements that apply to the whole platform.
Real examples by domain
Abstract definitions only take you so far. Here’s how functional and non-functional requirements look together in practice across three common domains.
Ecommerce platform
| Functional requirement | Non-functional requirement |
|---|---|
| User can add items to shopping cart | Cart updates within 1 second |
| System calculates shipping costs by delivery address | Checkout completes within 30 seconds on 4G |
| User receives order confirmation email | Email delivers within 30 seconds of purchase |
| Admin can process refunds | Refunds visible in customer account within 60 seconds |
Cross-cutting non-functional requirements: 99.9% uptime during business hours, PCI-DSS compliance for all payment data, WCAG 2.1 AA accessibility throughout, system handles 10,000 concurrent users during peak periods like Black Friday.
Banking application
| Functional requirement | Non-functional requirement |
|---|---|
| Customer transfers money between accounts | Transaction completes within 3 seconds |
| System validates sufficient funds before transfer | Failed transactions roll back automatically with no partial state |
| Customer views transaction history | Transaction history loads within 2 seconds for 24 months of data |
| System generates monthly statements | Statements generate within 10 seconds regardless of account activity volume |
Cross-cutting non-functional requirements: all data encrypted at rest using AES-256 and in transit using TLS 1.3, full audit trail maintained for 7 years, 99.99% uptime, two-factor authentication required for all account access.
Healthcare system
| Functional requirement | Non-functional requirement |
|---|---|
| Patient books appointment with available clinician | Booking confirms within 5 seconds |
| Clinician views patient medical history | Records load within 2 seconds |
| System sends appointment reminders 24 hours in advance | Reminders deliver with 99.9% reliability |
| Admin generates compliance reports | Reports complete within 30 seconds |
Cross-cutting non-functional requirements: HIPAA compliant data storage, patient data backed up every hour to geographically distributed locations, all data access logged with user, timestamp, and reason.
The full catalogue of non-functional categories — performance, security, reliability, accessibility and the rest — and how to document each, is the subject of Appendix B.
The grey areas
This is where practitioners actually get stuck. Some requirements sit on the boundary, and reasonable people disagree about how to classify them. Four cases account for most of the disagreement.
Security features versus security constraints. ‘User must log in with a username and password’ is functional — it is a feature the user interacts with. ‘Login must use multi-factor authentication’ feels like a feature too, but it is really a constraint on how authentication must work, ie. a quality attribute; classify it as non-functional, apply it system-wide and link it back to the login stories. ‘Passwords must be hashed using bcrypt with cost factor 12’ is unambiguously non-functional — a technical constraint, invisible to the user, that governs how the system performs a function.
Compliance generates both kinds. ‘System must comply with GDPR’ looks non-functional, but it is actually both. It generates functional requirements such as the right to erasure and data export, and non-functional ones such as encryption standards, audit logging and data-retention limits. Treat a compliance obligation as a source of requirements rather than a single requirement, and work out what it produces on each side of the line.
Accessibility cuts both ways. ‘User can navigate the form using a keyboard’ is functional — a specific capability. ‘All interfaces must meet WCAG 2.1 AA standards’ is non-functional — a quality constraint that applies across the entire product. In the UK it is also a legal obligation under the Equality Act 2010, which is a good reason not to leave it implicit.
Error handling splits the same way. ‘User sees an error message when payment fails’ is functional. ‘Failed transactions must roll back automatically with no partial state’ is non-functional — a reliability constraint on how the system must behave under failure conditions.
Two questions settle most cases. When you are unsure, ask first whether the requirement describes something a user does or the system provides; if so, it is functional. Then ask whether it describes a constraint on how well the system must perform, or a quality standard it must meet; if so, it is non-functional. And if it generates multiple requirements across different features — as security, accessibility and compliance obligations all tend to — it is almost certainly non-functional and belongs at the product or system level rather than attached to a single story.
Functional and non-functional requirements in agile teams
In a traditional waterfall project, non-functional requirements usually appear in a system specification document alongside the functional ones, written down before development starts. Nobody misses them.
Agile teams do not always have that document. User stories are the primary vehicle for requirements, and user stories are naturally functional: ‘As a customer, I want to pay by credit card so that I can complete my purchase.’ The non-functional requirements that apply to that story — PCI-DSS compliance, a transaction timeout, encryption standards — do not fit the user-story format. So they get deferred, then forgotten, then discovered in production.
Two approaches work. The first is to capture non-functional requirements at the product level and reference them from individual stories: a set of product-wide quality standards — performance baselines, security baselines, accessibility requirements — that every story inherits without being restated on each ticket. The second is to make non-functional requirements part of the Definition of Ready, so that a story is not ready to start until the relevant NFRs are identified and documented. That forces the conversation before development begins rather than after it ends. The Definition of Ready itself is covered in Reviewing Requirements.
What does not work is assuming developers will apply the right standards without being told what they are. ‘Secure’ means different things to different people. So does ‘fast’. Non-functional requirements exist to resolve that ambiguity before it costs you a production incident.
Why late is expensive
Non-functional requirements often get treated as optional extras — nice to have, something to add later, a post-launch concern. This is almost always wrong and always expensive, because non-functional requirements shape the foundations rather than the finish. Performance targets influence architecture decisions. Security requirements shape data models. Accessibility standards affect design from the first wireframe.
Define them after development and you are often rebuilding from foundations rather than refining a finished product. The order in which these decisions get locked in is the whole problem: a target chosen before the first line of code costs a sentence, while the same target imposed afterwards can cost a rewrite. You will see a team build an entire application on the assumption of unlimited server resources, then meet real production constraints and find the architecture needs a fundamental redesign — six months of work to be done again. The function was never the problem. The constraints on it were, and they arrived too late to be cheap.
Define non-functional requirements before development starts, and include them in your Definition of Ready. A story without its relevant non-functional requirements is not ready to build.