If you are sitting down to write the NFR section of a requirements specification and you are not sure what belongs there, this is the guide to work through right now. Whether you are treating this as your go-to non-functional requirements book or looking for a structured approach you can apply immediately, the framework below covers every category worth addressing on most projects, with elicitation tips that work on real stakeholders, not just cooperative ones in training scenarios.
Non-functional requirements describe how well a system does what it does, and under what conditions. A functional requirement says the system must allow a user to submit a leave request. A non-functional requirement says the system must process that submission within two seconds, be available 99.9% of the time, and only be accessible to authenticated users on an approved device. Both are requirements. Both carry risk if missed. But NFRs are harder to elicit because stakeholders think in features, not in performance thresholds, security controls, or compliance obligations. That is the gap you need to close.
Why NFRs Keep Getting Missed
In my experience, there are three patterns that cause NFR coverage to fall short, and they show up on almost every project regardless of size or sector.
- NFRs are not visible the way functional gaps are. A missed workflow step will surface in a walkthrough or demo. A missed performance requirement might not surface until the system is under load in production, by which point it is expensive to fix.
- NFRs sit across organisational boundaries. Security requirements involve the security team. Compliance requirements involve legal or risk. Support and maintenance requirements involve operations. If your elicitation only covers the business unit sponsoring the project, you will miss most of them.
- BAs are not prompted to ask. Without a structured checklist, it is easy to wrap up a requirements workshop feeling confident without having asked a single question about reliability, data retention, or release management.
The fix is straightforward: work from a consistent set of categories on every project, and treat them as a checklist rather than an afterthought.
The Eight Categories Worth Covering on Every Project
Not every category will apply with equal depth to every project. But running through all of them deliberately ensures nothing is missed by accident. Here is what each category covers and why it matters.
- Security and access control. Who can access what, under what conditions, and how is that enforced? This includes authentication, authorisation, role-based access, and audit logging.
- Technology and platform. What environments must the solution operate in? What are the constraints around browsers, devices, operating systems, or infrastructure?
- Reliability and performance. What are the uptime expectations? What response times are acceptable under normal load and peak load? What happens when the system is unavailable?
- Release and change management. How will the system be updated after go-live? What approval processes govern changes? What are the expectations around planned downtime?
- Support and maintenance. Who owns the system after delivery? What are the service level expectations for issue resolution? What documentation is required to support ongoing operations?
- Compliance. What regulatory, legal, or policy obligations apply to this system or the data it handles?
- Data retention and archiving. How long must data be kept? Where is it stored? What are the obligations around deletion or archival?
- Transition requirements. If the project replaces an existing system or process, what are the requirements around data migration, training, parallel running, and cutover?
Working through these categories consistently changes the quality of your NFR coverage, not because you are suddenly smarter, but because you are asking questions you might otherwise have skipped. You can use the published Non-Functional Requirements Checklist to make sure you are covering each one systematically.
Functional vs Non-Functional: A Quick Reference
This comparison is worth keeping close when you are reviewing a draft specification or prepping for a workshop. It is easy for NFRs to be written as functional requirements by mistake, and the table below helps distinguish them cleanly.
| Requirement Type | What It Describes | Example | Risk if Missed |
|---|---|---|---|
| Functional | What the system does | The system must allow a user to submit a leave request | Missing feature, visible in demos and UAT |
| Non-Functional | How well the system does it | The system must process submissions within 2 seconds for 95% of requests | Performance failure, often only visible under load in production |
| Non-Functional | Under what conditions it operates | The system must be available 99.9% of the time, excluding planned maintenance | Outage SLA breach, potential contractual liability |
| Non-Functional | Security and access | The system must restrict access to authenticated users on approved devices only | Unauthorised access, compliance breach |
| Constraint | Imposed condition outside requirements | The solution must be deployed on the existing cloud infrastructure | Design incompatibility, rework during build |
Elicitation That Actually Works
Asking “what are your performance requirements?” usually gets a shrug. Stakeholders do not naturally think in thresholds. What works consistently is framing questions around failure: what would unacceptable look like, what would a bad day look like, what would cause a compliance breach?
For performance, try asking: “If 500 people tried to log in at the same time during your end-of-month processing window, what would unacceptable look like?” That question gets a conversation. An abstract question about performance SLAs does not.
For compliance and data retention specifically, do not rely on the business unit to know the answer. Go directly to legal, risk, or your compliance function. Those obligations exist whether or not anyone in the room can articulate them. I have lost count of the number of times a project team was entirely unaware of a data retention obligation that the legal team had assumed was already captured somewhere.
If you want to sharpen your approach to requirements questioning more broadly, the Requirements Elicitation Questions guide covers the full range of techniques that work across different stakeholder types.
A Worked Example: Where NFRs Fell Apart
On a system replacement project I worked on for Organisation A, a government-adjacent body replacing a legacy case management system, the functional requirements were thorough. We had process maps, use cases, data dictionaries, the works. The NFR section was two paragraphs. It referenced “reasonable performance” and “appropriate security controls” and nothing else.
The problem surfaced during user acceptance testing. The system passed every functional test but took eleven seconds to load a case record. The business had an implicit expectation of under three seconds, based on the legacy system’s performance despite its age. Nobody had asked. Nobody had documented it. The development team had built to a standard they considered acceptable, which was technically not wrong because there was nothing in the specification to contradict it.
What made this harder was the pushback when I raised it. The project manager’s position was that performance was a technical matter, not a requirements matter, and that reopening the specification at that stage was a scope change. I had to make the case that an undocumented assumption is not a scope change, it is a gap, and that the cost of addressing it during UAT was significantly lower than the cost of addressing it post-go-live. We eventually agreed on a performance remediation sprint, but it delayed delivery by three weeks and consumed goodwill that had taken months to build.
The lesson I took from that project was not subtle. A structured NFR category checklist, applied at the start of elicitation rather than at the end of drafting, would have surfaced the performance expectation in the first workshop. The question “what response time would be unacceptable when loading a case record?” takes thirty seconds to ask. The remediation sprint took three weeks.
If you are writing a full requirements specification and want to see how NFRs fit alongside functional and business requirements in a complete document structure, the Business Requirements Document Example shows how that integration works in practice.
How Specific Do NFRs Need to Be?
“The system must be fast” is not a requirement. “The system must return search results within 1.5 seconds for 95% of queries under normal load, defined as up to 300 concurrent users” is a requirement. Wherever possible, define NFRs in measurable terms so they can be tested and verified at acceptance. Vague NFRs get interpreted by the development team, which means they get built to whatever standard the team assumes is acceptable. That assumption may be right. It may also result in a system that is too slow, not secure enough, or unable to meet a compliance obligation that nobody thought to document.
The scale of specificity should match the risk. A low-risk internal tool used by ten people does not need the same rigour as a public-facing transactional system handling financial data. But even small projects benefit from at least a light pass through each category, because the cost of asking is always lower than the cost of missing something.
The discipline of treating NFRs as a structured, category-driven exercise rather than a section to fill in at the end of drafting is what separates specifications that hold up in delivery from ones that generate expensive surprises. Apply the checklist early, ask scenario-based questions, go to the right people for compliance and data obligations, and write every NFR in terms that can be tested. That is the whole framework, and it fits on one page.
Frequently asked questions
What is the best non-functional requirements book for business analysts?
There is no single definitive book, but the most practical approach is to work from a structured category checklist covering security, performance, compliance, data retention, release management, support, and transition requirements. Applying that framework consistently on every project delivers more value than any single reference text. Pairing it with real elicitation practice builds the skill faster than reading alone.
What are the main categories of non-functional requirements?
The core categories are security and access control, technology and platform constraints, reliability and performance, release and change management, support and maintenance, compliance, data retention and archiving, and transition requirements. Not all will apply with equal depth to every project, but running through all of them deliberately prevents accidental omissions. The key is using them as a checklist at the start of elicitation, not as a section to populate at the end.
How do you elicit non-functional requirements from stakeholders?
Scenario-based questions consistently outperform abstract ones. Instead of asking what the performance requirements are, ask what would be unacceptable if 500 users hit the system simultaneously during peak processing. Framing questions around failure, bad days, and compliance breaches unlocks detail that direct questions miss. For compliance and data retention obligations, go directly to legal or risk rather than relying on the business unit to surface them.
What is the difference between a non-functional requirement and a constraint?
A constraint is an imposed condition the solution must operate within, such as a mandated technology platform, a budget ceiling, or a regulatory deadline. A non-functional requirement describes a quality characteristic the solution must exhibit, such as a response time threshold or an availability target. In practice they are closely related and often documented together, but the distinction matters when prioritising and negotiating scope.
What happens if non-functional requirements are left vague or missing?
They get interpreted by the development team, which means the system gets built to whatever standard the team considers acceptable. That assumption may be fine, or it may result in a system that is too slow, insufficiently secure, or non-compliant with an obligation nobody documented. The risk is entirely avoidable with a structured elicitation approach applied early in the project.
Try Ash, Your Virtual BA
If the NFR section of your specification is the part you always leave until last and then rush, Ash is built to fix exactly that. Ash works through every NFR category with you as part of the BRD writing process, covering security, performance, compliance, data retention, release management, and support, so nothing gets missed by default and every requirement comes out in testable, specific language. It is the structured discipline of a 25-year BA practice built into a tool you can use right now. Try Ash Virtual BA.
Further reading
- 10.30 Non-Functional Requirements Analysis
- Beyond Functionality: The Critical Role of Non-Functional Requirements | Exclusive Articles for IIBA Members
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.