If you are sitting in front of a blank requirements document right now and trying to make sure you have not missed any quality attributes, this non functional requirements checklist is what you need. I have used versions of it across government, utilities, health, and enterprise programmes over 25 years, and the categories below are the ones that come up repeatedly regardless of sector or technology. Work through each section in order, answer the questions, and you will have the raw material for a solid set of NFRs before your next stakeholder meeting.
Before you start filling anything in, it helps to know who you need in the room. In my experience, no single person holds all the answers. The questions below are designed to be put to a workshop that includes a business SME, an ITS manager, a cyber security consultant, an infrastructure specialist, a solutions architect, and a systems tester. Cyber security and privacy experts in particular must be involved from the start, not consulted as an afterthought. For more on setting up that kind of session, the requirements elicitation questions guide on this site is worth reading alongside this checklist.
The Six Core NFR Categories
The checklist is organised around six categories that cover the quality attributes most commonly required in software delivery. Each category includes the elicitation questions I ask in practice, not a theoretical list. Where a question is not applicable to your system, skip it. Where you are unsure, flag it for the workshop rather than guessing.
1. Performance
Performance relates to speed, throughput, and capacity under expected and peak load. These questions give you the numbers you need to make NFRs testable.
- Screen load time: What is the acceptable time to fully render a screen, including all images and controls, after a user clicks a link or button?
- GUI response time: What is the acceptable time for the interface to respond to a user action such as navigating to the next screen?
- Hours of operation: What are the standard and peak hours when the system will be in use?
- Concurrent users: What is the total number of registered users, and how many are likely to be active simultaneously during peak periods?
- Geographic spread: How many users are located in each region where the system operates?
- Transaction response time: What is the acceptable response time for key actions such as login, search, update, and file upload?
- Volume growth: What is the likely increase in transaction volumes and user numbers at 6 months, 1 year, and 5 years?
- Database growth: What is the current database volume and how is it expected to grow over 1 and 5 years?
- User load mix: What roles exist in the system and what actions does each role perform most frequently?
- Critical journeys: Which business processes and user journeys are most important and should be prioritised in load testing?
- Technically complex journeys: Are there any journeys that make external calls, run complex queries, or handle high data volumes?
2. Reliability and Recoverability
- Business impact of unavailability: Could system downtime result in direct loss of revenue, additional costs, or a processing backlog that cannot be managed manually?
- Decision-making impact: Could unavailability adversely affect key management decisions?
- Data recovery importance: If the system fails, how critical is it to recover data up to the point of failure?
- Batch processing: Are there end-of-day, end-of-week, or end-of-month batch jobs? If so, what is the deadline for completion and what is the impact of missing it?
- Processing cycle variations: Do processing requirements change at end of quarter or end of year?
3. Security
- Data integrity risk: Could unauthorised changes to information adversely affect business decisions or result in fraudulent diversion of funds or goods?
- Regulatory exposure: Could unauthorised changes breach legal, regulatory, or contractual requirements such as GDPR or sector-specific legislation?
- Internal access risk: Could damage be caused by a colleague viewing information they are not authorised to see?
- External access risk: Could damage be caused by an unauthorised external party accessing sensitive data?
- Business critical data: Does the system hold data that is business critical or that could be used maliciously or sold by a third party?
4. Usability
- Consistency with existing systems: Should the system share the look and feel of other applications already in use?
- User documentation: Are user manuals, help facilities, or in-application guidance required?
- Accessibility standards: Must the system comply with accessibility standards such as WCAG?
- Data model documentation: Are detailed descriptions required for all tables and columns in the data model?
- Database naming standards: Should a corporate database definition policy be followed, covering table names, column names, and primary key conventions?
5. Interoperability
- Device compatibility: On what devices must the system operate, for example desktop, tablet, or mobile?
- Browser compatibility: Which web browsers must the system support?
- Operating system compatibility: Which operating systems must the system run on?
- Infrastructure compatibility: Must the system run on physical infrastructure, virtual infrastructure, or both?
6. Data Migration
- Migration requirement: Is data required to be migrated from a legacy or incumbent system?
- Data scope: What specific data elements need to be migrated?
- Cutover window: What is the timeframe within which cutover must be completed?
- Cutover failure impact: What is the business impact if cutover fails or misses the deadline?
- Data quality risk: What is the impact if migrated data is duplicated, missing, or inaccurate?
NFR Checklist Template: Ready to Use
The table below gives you a structured template you can take directly into your requirements document. Each row represents a quality attribute with a default acceptance criterion. Adjust the thresholds to reflect what you have gathered through the elicitation questions above. For a deeper set of NFR examples and worked definitions, the non-functional requirements examples and templates article on this site is a useful companion.
| Category | Requirement | Example Acceptance Criterion | Met? (Y/N/Partial) |
|---|---|---|---|
| Performance | Response time under load | Less than 2 seconds for 90% of transactions under expected load | |
| Performance | Concurrent user capacity | System supports X concurrent users without degradation | |
| Performance | Batch completion | End-of-day batch completes within the defined processing window | |
| Availability | System uptime | 99.9% availability during business hours | |
| Availability | Disaster recovery | Recovery within X hours of a declared incident | |
| Security | Authentication and authorisation | Compliant with organisational security standards; MFA enforced for privileged roles | |
| Security | Data encryption | Encryption at rest and in transit for all personally identifiable information | |
| Security | Audit logging | All access and modification events logged and retained for X months | |
| Usability | Accessibility | WCAG 2.1 AA compliance verified through accessibility audit | |
| Usability | User testing | Usability testing conducted with representative users prior to go-live | |
| Reliability | Mean Time Between Failures | MTBF of at least X hours under normal operating conditions | |
| Maintainability | Modular codebase | System architecture supports component-level updates without full redeployment | |
| Compliance | Regulatory requirements | System meets all applicable regulatory obligations including GDPR | |
| Scalability | Horizontal scaling | Architecture supports horizontal scaling to handle 2x current peak load | |
| Interoperability | API compatibility | All APIs documented, versioned, and tested for compatibility with downstream systems | |
| Data Integrity | Validation and consistency | Data validation rules enforced at input and on migration; zero tolerance for silent data loss |
A Real Example: When the Security Team Pushed Back Hard
On a public sector modernisation programme I worked on, Project X involved replacing a legacy case management system for Organisation B. We ran an NFR workshop with eight stakeholders covering infrastructure, security, business operations, and the solutions architect. Everything was going smoothly until we reached the security section and the cyber security lead reviewed the draft data encryption requirement I had circulated beforehand.
The requirement read: “All data must be encrypted at rest and in transit.” The security lead rejected it immediately. His position was that the statement was untestable and, more importantly, that it did not reflect the organisation’s actual risk classification for different data types. Citizen reference data, he argued, was low sensitivity, while case notes and financial assessments were high sensitivity and subject to legislative controls. A blanket encryption requirement would either be over-engineered for low-risk data or under-specified for high-risk data, and either outcome would cause problems during procurement.
We had to go back to the business SME and the data governance lead to run a separate data classification exercise before the security NFRs could be properly written. That added two weeks to the elicitation phase and delayed the release of the request for proposal. The sponsor was not happy. But the result was a set of security requirements that were specific, auditable, and defensible in a procurement context. The lesson I took from it is that vague NFRs feel faster to write but create expensive problems downstream. Every security requirement needs to reference a data classification or a specific regulatory obligation, not just a general intention to be secure.
Additional Considerations for Cloud and SaaS Solutions
If the solution is hosted off-premise or delivered as a SaaS product, the standard checklist above still applies but needs to be supplemented. These are the questions I have found most useful when engaging with cloud service providers or evaluating SaaS vendors.
- Security assurance: Can the provider supply independent security assurance across the entire supply chain, including applicable certifications and assurance audit reports for each service layer?
- Release model: Can the provider give you a defined release frequency and version control process for software updates?
- Change control: Will the provider notify you of underlying infrastructure changes that could affect the service, even where no end-user impact is expected?
- Vulnerability management: Does the provider conduct at least annual penetration testing and remediate identified vulnerabilities within a defined timeframe?
- Incident response: Does the provider maintain an effective incident response plan and commit to timely notification of suspected cyber security incidents?
- SLA uptime and penalties: What is the guaranteed uptime under the service level agreement and how are breaches handled financially?
- Data portability: What is the process for exporting your data and migrating to an alternative provider if needed?
- Monitoring and audit: What tools or features are available for monitoring, auditing, and logging system usage?
How Much Detail Is Enough?
This is the question I get asked most often by BAs working through this checklist for the first time. The answer depends entirely on where you are in the procurement or delivery cycle. The table below gives you a quick decision guide.
| Scenario | Recommended NFR Depth | Why |
|---|---|---|
| Testing the market / request for information | High-level principles only | Overly specified requirements can lock out vendors before you have enough information to narrow the field |
| Request for proposal / request for quotation | Full measurable NFR set | Vendors need testable criteria to respond accurately and you need them for contract and acceptance testing |
| COTS procurement | NFRs plus architectural principles | Principles guide configuration decisions where exact NFR thresholds cannot be mandated for an off-the-shelf product |
| Custom development | Full detailed NFR set | Development teams need measurable targets to build and test against from sprint one |
| SaaS evaluation | NFRs plus SLA-specific questions | Many NFRs become vendor commitments in the SLA rather than design decisions, so questions need to be framed accordingly |
When you are at the market-testing stage, architectural principles often do more work than detailed NFRs. Principles such as avoiding customisation, designing for mobile users first, automating business processes where possible, and minimising legacy dependency communicate intent without constraining vendor responses. They are worth documenting alongside your NFRs or, at early stages, instead of them. For guidance on how NFRs fit into a broader compliance and performance context, the non functional requirements for bulletproof compliance and performance article covers that ground in detail.
The checklist only delivers value if it is treated as a live document throughout delivery. In Agile environments especially, NFRs are frequently deprioritised in favour of functional user stories, and the debt accumulates quietly until a performance test or a security audit surfaces it at the worst possible moment. I make a point of referencing the NFR checklist at every sprint review and backlog refinement session, not because every item needs revisiting each time, but because the habit keeps quality attributes visible to the team. A well-maintained NFR checklist is not just a requirements artefact; it is the mechanism by which a system earns the right to go live.
Frequently asked questions
What is a non functional requirements checklist?
A non functional requirements checklist is a structured list of quality attributes a system must meet, covering areas such as performance, security, usability, reliability, and interoperability. It gives BAs and project teams a consistent way to elicit, document, and verify NFRs rather than relying on memory or ad hoc conversations. Each item on the checklist should include a measurable acceptance criterion so it can be tested during delivery.
What are the main categories of non functional requirements?
The main categories are performance, reliability and recoverability, security, usability, interoperability, scalability, maintainability, compliance, and data integrity. Some organisations also separate availability and supportability as standalone categories. The categories you prioritise will depend on the type of system being built and the regulatory environment it operates in.
Who should I involve when eliciting non functional requirements?
You need input from a business SME, an ITS or IT operations manager, a cyber security consultant, an infrastructure specialist, a solutions architect, and a systems tester. Cyber security and data privacy experts must be involved from the start, not consulted after the NFRs have already been drafted. Running a dedicated workshop with all of these stakeholders together is the most efficient way to cover the ground without gaps.
How do you write measurable non functional requirements?
Each NFR should specify a quantified threshold, not a general intention. For example, instead of writing that the system should be fast, write that 90% of transactions must complete within two seconds under the expected concurrent user load. Linking the requirement to a specific data classification, user volume, or regulatory obligation makes it testable and defensible in a procurement or acceptance context.
How do non functional requirements differ for SaaS solutions?
For SaaS, many NFRs become vendor commitments documented in the service level agreement rather than design decisions made by your development team. You need to ask specific questions about uptime guarantees, incident notification timelines, penetration testing frequency, data portability, and the release and change control process. The answers determine whether the vendor can actually meet your quality requirements, not just whether they have checked a box in their proposal.
Try Ash, Your Virtual BA
Working through a non functional requirements checklist is one thing. Getting the NFRs written up in a format that stakeholders will actually review and sign off is another challenge entirely. Ash is a virtual BA assistant built specifically for this kind of work. You can use Ash to draft NFR sets, frame elicitation questions for your next workshop, and produce requirements documentation that is structured, measurable, and ready for review. If you have just worked through this checklist and need to turn your answers into a coherent requirements artefact, Ash is the logical next step. Try Ash Virtual BA.
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.