Non-functional requirements describe how well a system must behave, not just what it must do, and they are the most common reason software that passes every test still disappoints the business. The non-functional requirements gap is the distance between a system that works correctly and one that is fast, secure, available, accessible and dependable enough to be used in real life.
Every business analyst has seen it. The new portal does exactly what the specification says. Every feature is ticked off, every test case passes and the project is declared a success. Then launch day arrives, the pages crawl, the audit team asks where the logs are and a customer using a screen reader cannot complete a payment. Nothing is technically broken. The software simply fails the business. This guide explains why that happens and how to close the gap.
| Quick answer
The non-functional requirements gap appears when a project documents features in detail but leaves speed, security, reliability, usability and other quality expectations vague or unwritten. Close it by capturing quality needs early, turning each one into a measurable target, agreeing how it will be tested and treating it as part of done. |
What Are Non-Functional Requirements?
Non-functional requirements, often shortened to NFRs, are the quality standards and constraints a solution must meet. Where a functional requirement says what the system does, such as “the customer can submit a claim,” a non-functional requirement says how well it must do it, such as “the claim form saves within two seconds, even at peak load.”
They are also called quality attributes or “-ilities,” because many end in that suffix: availability, reliability, scalability and maintainability. For a clear overview of the concept, see the entry on non-functional requirements, and for a structured model of software quality, the ISO/IEC 25010 quality model groups these attributes into categories such as performance efficiency, security, usability and maintainability.
Functional vs Non-Functional Requirements: A Simple Comparison
| Functional requirements | Non-functional requirements | |
| Answers the question | What must the system do? | How well must it do it? |
| Typical example | User can reset a password | Reset email arrives within one minute; link expires after 15 minutes |
| Who usually raises it | Business users and product owners | Often nobody, unless someone asks |
| How it is tested | Feature and acceptance tests | Performance, security, accessibility and recovery tests |
| Risk if missing | Feature does not exist | Feature exists but is slow, unsafe, unusable or unstable |
Both types matter. A system with perfect features and poor quality is a polished product nobody can rely on. A system with excellent quality and missing features solves the wrong problem.
The Non-Functional Requirements Gap: A Story Most Teams Recognise
Picture a Sydney insurer launching a new online claims portal. The business analyst has written detailed user stories. The testers have verified each one. The sponsor signs off, and the portal goes live on a Monday.
By mid-morning, a marketing email has sent thousands of customers to the site at once. Pages slow to a crawl and submissions time out. Later that week, the compliance team asks for an audit trail of who changed each claim, and discovers none was built. A month later, a disability advocacy group points out that parts of the form cannot be used with a keyboard.
Every one of those problems was a missing non-functional requirement. Nobody had written down expected concurrent users, audit logging or accessibility. Everyone had assumed someone else would think of it. (This scenario is an illustration, not a real case.)
Why the Non-Functional Requirements Gap Keeps Appearing
- Stakeholders talk about features. Ask a business user what they want and they describe screens and tasks. Quality expectations feel too obvious to mention until they are missing.
- They sound technical. Business people assume speed and security are the technology team’s job. Technology teams assume the business would have said if it mattered.
- Nobody owns them. Functional requirements have a clear champion. Non-functional requirements often belong to everyone and therefore to no one.
- They are hard to quantify. “Fast” and “secure” feel impossible to measure, so teams leave them vague.
- User story formats favour behaviour. Agile stories describe what a user wants to do, which makes it easy for quality needs to slip through.
- Test environments do not match reality. Performance and recovery problems stay hidden until real users and real data arrive.
- They are discovered late. By the time a quality problem shows up, the architecture is set and changing it is expensive.
Examples of Non-Functional Requirements by Category
A category checklist is one of the best ways to prompt the right conversations. Here are common categories with weak and measurable versions of the same requirement.
| Category | Weak requirement | Measurable requirement |
| Performance | The system should be fast | 95 percent of search requests return within two seconds at 500 concurrent users |
| Availability | The system should always be up | 99.9 percent availability each month, excluding planned maintenance windows |
| Security | Data must be secure | Personal data is encrypted in transit and at rest; access is role-based and logged |
| Usability | It should be easy to use | A new user completes a claim in under ten minutes without help in testing |
| Accessibility | It should be accessible | Meets WCAG 2.2 level AA on all customer-facing pages |
| Recoverability | We need backups | Service restored within four hours; no more than 15 minutes of data lost |
| Scalability | It should grow with us | Handles three times current volume with no redesign |
| Auditability | We need a record of changes | Every change to a claim records who, what and when, retained for seven years |
The numbers above are examples only. Your real targets should come from your business, your risks and your obligations. For accessibility, the Web Content Accessibility Guidelines are the widely used reference. For availability and reliability targets, Google’s chapter on service level objectives explains how to set targets people can actually measure.
What the Non-Functional Requirements Gap Costs the Business
Rework that arrives late and expensive
Quality problems found after launch usually cost far more to fix than those caught during analysis, because they often touch architecture, data design and infrastructure.
Reputation and customer trust
Customers do not distinguish between a missing feature and a slow, unreliable one. Both feel like a broken promise.
Compliance and legal exposure
Privacy, security, accessibility and record-keeping obligations are often non-functional by nature. Missing them can mean regulatory attention, not just unhappy users.
Blame and broken relationships
When software meets the specification but fails the business, the argument starts. The business says the delivery team should have known. The delivery team says it was never in the requirements.
Lost confidence in business analysis
A business analyst who captures only features risks being seen as a note-taker. One who surfaces quality needs early becomes a trusted partner.
How to Capture Non-Functional Requirements: A Seven-Step Method
You do not need a heavy process. Work through these steps on your next project.
- Start from business outcomes and risks. Ask what the business cannot afford to have go wrong, such as downtime during peak season, a data breach or a failed audit.
- Use a category checklist. Walk through performance, availability, security, usability, accessibility, recoverability, scalability, auditability and compliance with each stakeholder group.
- Ask “what would make this unacceptable?” People find it easier to describe failure than to describe quality in the abstract.
- Make every requirement measurable. Give each one a metric, a target and the conditions that apply, such as load, device or time of day.
- Agree priorities and trade-offs. Higher availability, stronger security and faster performance all cost money and time. Make the trade-offs visible and get them signed off.
- Define how each one will be tested. If you cannot say how a requirement will be verified, it is probably still too vague.
- Build them into acceptance criteria and the definition of done. Revisit them as the solution evolves rather than parking them in a document nobody reads.
The Business Analysis Body of Knowledge from IIBA treats requirements, including quality attributes, as a core discipline, and you can explore it through the BABOK Guide introduction. The International Requirements Engineering Board also publishes widely used guidance on requirements practice.
Questions a Business Analyst Can Ask in Every Workshop
- How many people will use this at the same time on our busiest day?
- What happens to the business if it is unavailable for an hour? For a day?
- Who must not be able to see or change this information?
- Who needs to prove what happened, and for how long must we keep the evidence?
- What devices, locations and abilities do our users have?
- How quickly do we need to recover after a failure, and how much data can we afford to lose?
- How will this need to grow in the next two to three years?
These questions are simple, but they turn invisible assumptions into written requirements. They also give testers, architects and developers what they need to build the right thing the first time.
Working with Non-Functional Requirements in Agile Projects
Agile teams sometimes assume non-functional requirements do not fit. In fact, they fit very well when handled deliberately.
- Treat key quality needs as constraints on every story. Add them to the definition of done so every increment respects them.
- Write specific stories for larger quality work. Load testing, disaster recovery and accessibility remediation can be backlog items with clear acceptance criteria.
- Test early and often. Run small performance and security checks every sprint rather than saving them for the end.
- Keep the conversation alive. Review quality targets in refinement and retrospectives as the product and its users change.
Business Analysis Courses That Build Requirements and Quality Skills
Spotting and writing non-functional requirements is a learnable skill. These programs at Business Analysis Courses are a strong fit.
- IREB Requirements Engineering Foundation (CPRE-FL) focuses on eliciting, documenting and managing requirements, including quality needs.
- Business Analysis Techniques Course builds practical tools for analysing problems, processes and requirements.
- Agile Business Analysis (AgileBA) Foundation introduces agile principles for business analysis practice.
- Agile Business Analysis (AgileBA) Practitioner deepens your ability to apply agile analysis in real projects.
- ISQI Agile Business Analysis Certification develops a practical understanding of agile business analysis concepts.
- BCS Business Change Foundation covers structured approaches to managing organisational change.
- BCS Business Finance Certificate helps you connect solutions to costs, benefits and business cases.
See every program on the business analysis courses page, explore the BCS business courses, browse the full course list, learn more about us or read more on the Business Analysis Courses blog.
Business Analysis Training Across Australian Cities
Demand for analysts who can bring clarity to requirements is strong in every major market. Training is available through live online and classroom options across Australia.
- Melbourne: finance, health, retail and government projects. See business analysis courses in Melbourne.
- Sydney: banking, insurance and technology programs with demanding quality targets. See business analysis courses in Sydney.
- Brisbane: growing infrastructure, resources and public sector delivery. See business analysis courses in Brisbane.
- Perth: mining, energy and engineering projects with strict reliability needs. See business analysis training in Perth.
- Adelaide: defence, health and education digital programs. See business analysis courses in Adelaide.
- Canberra: federal agencies with strong governance, security and accessibility expectations. See business analysis courses in Canberra.
Not sure which course or format suits you? Contact the team and an advisor will help you choose.
Frequently Asked Questions About Non-Functional Requirements
What are non-functional requirements?
Non-functional requirements define how well a system must perform and the constraints it must respect, covering qualities such as performance, security, availability, usability and maintainability.
What are examples of non-functional requirements?
Examples include response time under load, system availability, data encryption, accessibility to a recognised standard, recovery time after failure, audit logging and the ability to handle growth in users.
What is the difference between functional and non-functional requirements?
Functional requirements describe what a system does. Non-functional requirements describe how well it does it and under what conditions.
Who is responsible for non-functional requirements?
Responsibility is shared. Business analysts usually lead elicitation and documentation, architects and engineers advise on feasibility and design, and business owners decide priorities and trade-offs.
How do you make a non-functional requirement measurable?
Give it a metric, a target value and the conditions under which it applies, then agree how it will be tested. “Fast” becomes “95 percent of searches return within two seconds at 500 concurrent users.”
Do non-functional requirements apply to agile projects?
Yes. Agile teams typically include them in the definition of done, as constraints on stories or as dedicated backlog items with clear acceptance criteria.
Which course teaches requirements gathering?
The IREB Requirements Engineering Foundation and the Business Analysis Techniques Course are strong places to start.
Final Thoughts: Close the Non-Functional Requirements Gap Early
The non-functional requirements gap is rarely about carelessness. It is about assumptions. Everyone assumes the system will be fast, safe and reliable, and nobody writes it down until the day it is not.
Ask the uncomfortable questions early, put numbers on quality, agree how you will test it and keep it visible all the way to release. When you do, software that works correctly also works for the business. If you would like structured, practical training in requirements and business analysis, speak with an advisor at Business Analysis Courses on 1300 649 299, or explore the full course list to find your starting point.