When you are sitting down to write NFRs for a system and someone throws terms like RTO, IaaS, or containerisation into the room, the conversation stalls if the definitions are not shared. This non-functional requirements glossary is built for that moment. Use it while you are drafting, reviewing, or getting sign-off on NFRs, not as something to read once and file away. I have pulled together every term that has come up repeatedly across projects in government, health, utilities, and enterprise environments, along with example NFR statements you can adapt directly.
If you are still building out your approach to capturing NFRs more broadly, the Non-Functional Requirements Checklist is a strong companion to this glossary. But right now, let us get into the terms.
A worked example first: why terminology caused a real problem
On Project X, a public sector data platform migration, I was three weeks into requirements workshops when the infrastructure lead began specifying “99.9% availability” as a given. The business sponsor heard this and assumed it meant the system would be available continuously, with no planned downtime. The infrastructure lead meant something technically precise: an allowance of roughly 8.7 hours of downtime per year, which still permitted scheduled maintenance windows.
Nobody had defined availability in writing. When I introduced a shared glossary into the workshop pack, the sponsor pushed back hard. They felt the infrastructure team had been misleading them. It took an additional session just to rebuild trust, and the availability NFR had to be renegotiated to include a specific clause excluding pre-approved maintenance windows. The lesson I took from that project is that undefined NFR terminology is not just a documentation problem. It is a stakeholder relationship problem waiting to happen.
Core performance and reliability terms
- Availability: The proportion of time a system is operational and accessible, typically expressed as a percentage such as 99.9% (three nines) or 99.95% over a defined measurement period. Example NFR: “The system must achieve an uptime of 99.95% over any 30-day period, excluding pre-approved maintenance windows.”
- Latency: The time delay between a user action and the system’s response. Example NFR: “The system must respond to user actions within 2 seconds 95% of the time under normal load conditions.”
- Capacity: The maximum load a system can handle in terms of concurrent users, transactions, or data volume while maintaining acceptable performance. Example NFR: “The system must support 10,000 concurrent users during peak hours without performance degradation.”
- Fault Tolerance: The ability of a system to continue operating when one or more components fail. Example NFR: “The system must operate with no more than a 5% degradation in performance following the failure of a single node in the cluster.”
- Load Testing: A type of performance testing that evaluates system behaviour under expected or peak user loads. Example NFR: “The system must maintain response times under 500ms with a concurrent load of 5,000 users.”
- Operational Resilience: The ability of an organisation or system to anticipate, prepare for, respond to, and adapt to disruptions while maintaining continued operations. Example NFR: “The system must maintain 80% of core functionality during unplanned network disruptions.”
Security and data terms
- Confidentiality: The security attribute that ensures sensitive information is protected from unauthorised access. Example NFR: “All sensitive data must be encrypted in transit using TLS 1.2 or higher.”
- Data Integrity: The assurance that data is accurate, consistent, and unaltered during storage, transmission, or retrieval. Example NFR: “The system must validate all data inputs against predefined schemas to ensure consistency.”
- Data Retention: The policies governing how long data is stored and the processes for securely archiving or deleting it. Example NFR: “All user data must be retained for a maximum of five years and securely deleted thereafter in accordance with applicable regulations.”
- Compliance: Adherence to laws, regulations, and standards such as GDPR, HIPAA, or ISO/IEC standards. Example NFR: “The system must ensure data handling practices comply with GDPR Article 5 for data minimisation.”
Resilience and recovery terms
- Disaster Recovery: The strategies and measures in place to restore operations and data following a catastrophic event such as a server failure or cyberattack. Example NFR: “Full data recovery must be achievable within 4 hours of a major outage.”
- Business Continuity Planning (BCP): A strategic process ensuring critical business operations can continue during and after a disruption. Example NFR: “The system must support failover to a backup data centre within 30 minutes of a major disruption.”
Deployment model terms: a comparison
Deployment model terminology is where I see the most confusion in workshops, particularly when the project team includes people from different technical backgrounds. The table below covers the most common models and how they differ.
| Deployment Model | What It Means | Typical NFR Focus |
|---|---|---|
| On-Premise | All hardware, software, and infrastructure are hosted within the organisation’s own facilities. | Network isolation, internal dependency, physical security |
| Public Cloud | Computing resources are delivered over the internet by a third-party provider and shared across customers. | Scalability, cost efficiency, data sovereignty |
| Private Cloud | Cloud infrastructure is dedicated to a single organisation, hosted either on-premise or by a provider. | Control, compliance, security isolation |
| Hybrid Cloud | A combination of public and private cloud resources, allowing organisations to balance scalability with control. | Data synchronisation, failover, latency between environments |
| Multi-Cloud | The use of multiple cloud providers to meet diverse business or resilience needs. | Traffic routing, provider redundancy, interoperability |
| Community Cloud | Infrastructure shared among multiple organisations with similar requirements or regulatory obligations. | Shared governance, data classification, compliance alignment |
| Edge Computing | Computation and data storage brought closer to data sources such as IoT devices to reduce latency and bandwidth use. | Local processing speed, bandwidth constraints, device availability |
Example NFR for hybrid cloud: “Data must synchronise between private and public cloud environments within 5 minutes of a change event.” Example NFR for multi-cloud: “The application must route traffic to a secondary cloud provider within 2 minutes of a primary provider failure.”
Cloud service model terms
- IaaS (Infrastructure as a Service): A cloud model providing virtualised computing resources such as servers, storage, and networking over the internet. Example NFR: “The system must auto-scale IaaS resources to support a 50% increase in traffic within 10 minutes.”
- PaaS (Platform as a Service): A cloud model where a provider delivers hardware and software tools as a service, enabling development and deployment without managing infrastructure. Example NFR: “The platform must support continuous integration pipelines to deploy updates within 15 minutes.”
- SaaS (Software as a Service): A cloud-based software delivery model where applications are hosted by a provider and accessed over the internet. Example NFR: “The SaaS application must be available globally with a latency of less than 200ms.”
- Serverless Computing (FaaS): A model where developers write and deploy discrete functions and the cloud provider handles all infrastructure provisioning and management. Example NFR: “Each serverless function must execute within 300ms under a load of 1,000 concurrent invocations.”
Architecture and integration terms
- Containerisation: A lightweight approach to deployment where applications and their dependencies are packaged together in containers, typically orchestrated using tools like Kubernetes. Example NFR: “All application containers must be deployed using an orchestration tool to ensure availability and scalability.”
- Virtualised Environments: The use of virtual machines to emulate physical hardware, allowing multiple systems to run on a single physical machine. Example NFR: “Virtual machines must achieve at least 95% uptime with minimal resource contention.”
- Interoperability: The ability of a system to interact with and exchange data effectively with other systems or components. Example NFR: “The system must support data exchange in JSON and XML formats to integrate with external partner systems.”
- API (Application Programming Interface): A set of rules and tools allowing different software applications to communicate with each other. NFRs for APIs commonly address performance, security, and scalability. Example NFR: “The API must handle 1,000 requests per second with a maximum latency of 100ms.”
Usability and maintainability terms
- Accessibility: The degree to which a system can be used by people with varying levels of ability or disability, including visual, auditory, physical, cognitive, and neurological impairments. Example NFR: “The application must meet WCAG 2.1 AA accessibility standards to ensure usability for users with visual impairments.”
- Maintainability: The ease with which a system can be modified to correct defects, improve functionality, or adapt to a changing environment. Example NFR: “All code changes must pass automated tests achieving at least 90% code coverage before deployment.”
If you are working on a project where NFRs need to be formally documented, the Non-Functional Requirements Template gives you a structured format to capture each of these terms as testable, agreed requirements. For a broader look at requirements types and how NFRs sit alongside functional and business requirements, the article on Business vs Functional vs Non-Functional Requirements is worth a read before your next workshop.
The real value of a shared glossary is not that it prevents disagreements, it is that it moves disagreements to the right moment. On Project X, the availability dispute was painful precisely because it surfaced during sign-off rather than during scoping. When every person in the room is working from the same definitions, the friction shifts from “what does this word mean?” to “what do we actually need?”, and that is a much more productive conversation to be having.
Frequently asked questions
What is a non-functional requirement?
A non-functional requirement defines how a system performs rather than what it does, covering qualities like availability, security, scalability, and maintainability. Unlike functional requirements, NFRs apply across the whole system rather than to a specific feature or user action. They are often harder to elicit but just as critical to project success.
What is the difference between availability and fault tolerance in NFRs?
Availability measures the proportion of time a system is operational and accessible, typically expressed as a percentage such as 99.9% uptime. Fault tolerance describes the system’s ability to continue operating when one or more components fail, even if at reduced capacity. Both are related but distinct NFRs that should be specified separately.
What is the difference between IaaS, PaaS, and SaaS?
IaaS provides virtualised infrastructure such as servers and storage, leaving software and platform management to the organisation. PaaS adds a software platform on top, allowing developers to build and deploy applications without managing underlying infrastructure. SaaS delivers a fully managed application over the internet, with the provider handling everything from infrastructure to updates.
What does RTO mean in non-functional requirements?
RTO stands for Recovery Time Objective and defines the maximum acceptable length of time a system can be offline after a failure before it must be restored. It is a key metric within disaster recovery NFRs and directly influences infrastructure and backup investment decisions. A typical NFR might state that the system must be restored within 4 hours of a major outage.
How do I write a testable non-functional requirement?
A testable NFR includes a measurable target, a defined condition, and a clear metric so that pass or fail can be objectively determined. For example, stating that the system must respond to user actions within 2 seconds 95% of the time under a load of 5,000 concurrent users is testable, while saying the system must be fast is not. Linking each NFR to a specific test type such as load testing or penetration testing strengthens traceability and accountability.
Try Ash, Your Virtual BA
If this glossary has helped you get clearer on NFR terminology, Ash can take you straight from definition to documentation. Ash is built specifically for business analysis work, so when you are ready to turn these terms into properly structured, testable NFR statements for your project, Ash can guide you through the process and help you produce a draft you can take straight into review. It understands the difference between availability and fault tolerance, between IaaS and SaaS, and between a vague quality attribute and a requirement someone can actually sign off on. Try Ash Virtual BA and see how quickly you can move from glossary to documented requirement.
Further reading
- Beyond Functionality: The Critical Role of Non-Functional Requirements | Exclusive Articles for IIBA Members
- Non-functional Requirements | Scrum.org
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.