What is a Non Functional Requirements Checklist?

A non-functional requirements checklist is a document that outlines key non-functional criteria that a software system should meet. Non-functional requirements describe how a system should perform rather than what functionalities it should have. Some common non-functional requirements include usability, security, performance, supportability, and reliability. A non-functional requirements checklist enumerates these types of quality attributes and provides a way to evaluate whether a system meets each criterion sufficiently. It acts as a guide for developers and testers to ensure the finished product satisfies critical quality needs. Having a clear checklist enables systematic verification of these elements rather than an ad-hoc approach. A well-defined non-functional requirements checklist is essential for building and releasing a high-quality software system.

What is a Non-Functional Requirement?

Non-functional requirements capture conditions that do not directly relate to the behaviour or functionality of the solution but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have.

In contrast, a functional requirement specifies a function that a system or system component must be able to perform. Therefore, another way to explain ‘non-functional’ requirements is that they specify all the remaining requirements not covered by the functional requirements.

Non-functional requirements specify the system’s ‘quality characteristics’ or ‘quality attributes’. Two products could have the same functions, but their attributes can make then entirely different products.

For example, a BMW has more or less the same functionality as a Mini, but it has many different attributes.

The Business Analyst’s Challenge with Eliciting Non-Functional Requirements

Eliciting non-functional requirements (NFRs) is a complex and often overlooked challenge for business analysts. Unlike functional requirements, which are typically clear and straightforward, NFRs such as reliability, scalability, and security are abstract and harder to articulate. Stakeholders often focus on what the system should do, neglecting how it should perform under strain or adapt to growth. This leaves the BA balancing education and elicitation while trying to avoid critical omissions. Vague statements like “We need it to be fast” lack the measurable detail needed for meaningful solutions.

Even when stakeholders recognise the importance of NFRs, translating vague desires into actionable, measurable criteria can be daunting. Terms like “high availability” sound impressive but are meaningless without quantification. BAs must bridge this gap by collaborating with technical teams, who may also struggle to translate technical specifics into business language. Without clear definitions, these ambiguities can lead to costly rework or performance issues down the line.

NFRs often fall into a grey area between business and technical domains, leading to confusion about ownership. While BAs are expected to lead the process, they must rely on architects, developers, and IT teams for detailed input. This navigation of blurred responsibilities can be exhausting, requiring consensus-building and careful coordination to ensure no details are missed.

Adding to the complexity, NFRs involve diverse stakeholders like compliance officers, security teams, and infrastructure specialists. Early engagement is critical but challenging, as priorities often conflict—balancing security, usability, performance, and budget constraints. The BA must act as a mediator, managing compromises and aligning expectations.

In Agile environments, NFRs are frequently sidelined, with the emphasis on delivering functional user stories. This neglect can create technical debt, with scalability and maintainability issues surfacing later. Advocating for NFRs in Agile processes requires persistence and cultural change, making it an uphill battle for BAs committed to delivering robust systems.

Testing and validating NFRs is equally challenging. Many requirements, such as “user-friendliness” or “system reliability,” are difficult to measure without clear criteria or specialised tools. This can lead to frustration during delivery, with the BA caught between stakeholder expectations and technical limitations.

Ultimately, eliciting NFRs is a balancing act. It requires educating stakeholders, bridging business and technical perspectives, and ensuring that requirements are precise, actionable, and aligned with broader goals. Despite the challenges, this work is rewarding when done well, as it lays the foundation for systems that are not only functional but resilient and reliable.

Categories of Non-Functional Requirements

The following categories are the main areas of attention for non-functional requirements.

• Performance
• Reliability and recoverability
• Security
• Usability
• Interoperability
• Data Migration

Performance

This relates to the speed of transactions for peak and expected growth of business volumes. e.g. throughput, response times.

• What is the acceptable time taken to load (render) the full screen (with all images and buttons) of the application after clicking the icon, link or button?
• What is the acceptable time the GUI can take to respond to action performed by user, e.g. click button to go to next screen?
• What are the hours of operation for the system?
• What are the peak hours of operation for the system when most people will be using it?
• What is the total number of system users?
• What is the number of users likely to use the system at any one time?
• What is the total number of concurrent system users during peak hours?
• How does this vary day to day? i.e. are there more users at the end of the week/month?
• What is the number of users in each geographical location that the system is used?
• What is an acceptable response time to perform an action? (to be edited per application where applicable). For example, login, query, update, upload.
• What is the impact of not meeting this requirement?
• What is the likelihood of the increase in volume of transactions in: 6 months, 1 year, and 5 years?
• What is the likely increase of the number of users in: 6 months, 1 year, and 5 years?
• Under normal business conditions, when is the start of day and end of day?
• What is the current database data volume?
• How is this expected to grow over the next: 1 year? 5 years?
• What is the user load mix? i.e. users/roles and the main actions they perform.
• What is the impact if the data presented on screen is out of date or inaccurate?
• What are the business processes and user journeys that are most critical (and should therefore be emulated in the tests)?
• Are there any user journeys that are particularly complicated from a technical perspective i.e. making external calls, complex/multiple queries, or high volumes?
• Can you provide any architectural diagrams?

Reliability and recoverability

How reliable is the system and can it recover if it fails in any way? How correct/accurate is the data?

• Could unavailability of information or system result in directly attributable loss of business?
• Could unavailability of information or system result in additional costs being incurred?
• Could unavailability of information or system cause a backlog of processing which could not be handled either manually or when the system recovers?
• Could unavailability of information or system adversely affect key management decision making?
• If the system fails, what is the importance of being able to recover information?
• Are there any beginning or end of day/week/month/year processing cycle / batch jobs that occur?
• If yes, is there a deadline for when that job must complete and what is that time?
• If yes, what is the earliest that the job can start?
• What is the impact if the job does not complete by this time?
• Does the processing cycle differ on any particular dates? e.g. end of month, end of quarter, end of year.

Security

The prevention of unauthorised access to programs and data.

• Could unauthorised changes to, or errors in information, adversely affect key business decision making?
• Could unauthorised addition, deletion or modification of information result in fraudulent diversion of goods or funds?
• Could unauthorised changes to or errors in information result in disruption to the operation of the business?
• Could unauthorised changes to or errors in information result in additional costs being incurred?
• Could unauthorised changes to or errors in information breach legal, regulatory or contractual requirements?
• Could any damage be caused by co-worker viewing information they are not supposed to have access to?
• Could any damage be caused by unauthorised person/public viewing information they are not supposed to have access to?
• Does the system contain business critical information?
• Does the system contain data that could be used maliciously or sold by a third party?

Usability

How easy it is for a person to learn, use or interface with the system.

• Should the system have the same look and feel as existing applications?
• Are user manuals required?
• Are help facilities required?
• How is the system to be supported?
• Do you require all tables and rows in the data model to have detailed descriptions?
• Should a corporate database definition policy be adhered to (e.g. standards for table names and column names, primary keys, etc.?

Interoperability

The ability for the system to run in different operating environments and with different components.

• On what devices should the system be able to run on?
• What web browsers should the system be able to run on?
• What operating systems should the system be able to run on?
• What infrastructure should the system be able to run on? For example, physical or virtual.

Data Migration

Transferring data from the legacy/incumbent system(s) to the new system.

• Is data required to be migrated to the new system?
• What data elements need to be migrated?
• What is the timeframe in which cutover needs to be executed?
• What is the impact if cutover fails/misses the deadline?
• What is the impact if migrated data is duplicated, missing or inaccurate?

Example Non Functional Requirements Checklist Template

1. Performance

• [ ] Does the system meet the required response time under expected load conditions? (e.g., <2 seconds for 90% of transactions)
• [ ] Can the system handle the maximum anticipated load (e.g., X concurrent users, Y transactions per second)?
• [ ] Is the system tested for scalability (e.g., ability to scale horizontally/vertically)?
• [ ] Are batch processing jobs completed within acceptable time windows?

2. Availability

• [ ] What is the required system uptime (e.g., 99.9%, 24/7 availability)?
• [ ] Are backup and recovery processes defined and tested?
• [ ] Is the failover mechanism implemented and functional in case of system outages?
• [ ] Does the system meet disaster recovery requirements (e.g., recovery within X hours)?

3. Security

• [ ] Are authentication and authorisation mechanisms implemented and compliant with security standards?
• [ ] Is data encryption applied where needed (e.g., at rest and in transit)?
• [ ] Are user sessions managed securely (e.g., session timeout, token validation)?
• [ ] Is the system tested for vulnerabilities (e.g., penetration testing, vulnerability scanning)?
• [ ] Are audit trails and logging mechanisms in place for security monitoring?

4. Usability

• [ ] Is the user interface designed with accessibility standards (e.g., WCAG compliance)?
• [ ] Have usability tests been conducted with real users?
• [ ] Are error messages user-friendly and informative?
• [ ] Does the system support multiple languages or localisation if required?

5. Reliability

• [ ] Does the system meet the required Mean Time Between Failures (MTBF)?
• [ ] Is there a defined process for handling and reporting system failures?
• [ ] Are automated health-check mechanisms in place?

6. Maintainability

• [ ] Is the codebase modular and easy to update or extend?
• [ ] Are coding standards and documentation maintained?
• [ ] Are there automated tests for verifying system functionality during updates?
• [ ] Is the system compatible with future anticipated technology stacks?

7. Compliance

• [ ] Does the system meet legal and regulatory requirements (e.g., GDPR, HIPAA, PCI DSS)?
• [ ] Are there policies in place for data retention and deletion?
• [ ] Are third-party libraries and tools compliant with licensing terms?

8. Scalability

• [ ] Can the system handle increased user demand without significant degradation in performance?
• [ ] Is the system architecture designed for horizontal and/or vertical scaling?
• [ ] Are there resource monitoring tools in place to identify bottlenecks?

9. Supportability

• [ ] Is there adequate documentation for developers and system administrators?
• [ ] Are monitoring and alerting tools in place for incident management?
• [ ] Are there defined SLAs for system support and issue resolution?

10. Interoperability

• [ ] Can the system integrate with other applications or services as required?
• [ ] Are APIs documented and tested for compatibility?
• [ ] Are there mechanisms to handle differences in data formats or protocols?

11. Data Integrity

• [ ] Are data validation and consistency mechanisms in place?
• [ ] Are there measures to prevent data loss or corruption during system operations?
• [ ] Is there a clear process for data migration and transformation?

Here you can view a comprehensive example list of NFRs and also some excellent examples in this glossary.

What if the Solution Being Procured is Hosted Off-Premise or is a Cloud Service?

If the solution is hosted off-premise or is a cloud service, then the following questions relating to security assurance, defined release model, change control, vulnerability management, and incident management may be applicable. Note that these are the main questions I have seen in my experience.

• Can the service provider(s) provide independent security assurance of the entire supply chain?
• Can the service provider(s) provide details of applicable certifications and assurance audit reports for each service layer?
• Can the service provider(s) provide a defined release model and frequency, including version control of software releases?
• Can the service provider(s) maintain robust change control with the customer and notify the customer of any underlying infrastructure changes without expected end-user impact?
• Can the service provider(s) periodically and at least annually vulnerability assess or penetration test (respectively) their service and remediate vulnerabilities in a timely manner?
• Can the service provider(s) maintain an effective incident response plans and provide timely notification of suspected cyber security incidents to the customer?

What if the Solution Being Developed is a SaaS?

These questions help ensure the SaaS solution aligns with technical, operational, and strategic requirements, minimising risks while maximising efficiency and compliance.:

• What is the guaranteed uptime as per the Service Level Agreement (SLA), and how are penalties handled in case of breaches?
• How does the system scale to accommodate increased users, data, or transactions without performance degradation?
• What measures are in place to ensure data security, including encryption, access controls, and compliance with standards like GDPR or HIPAA?
• What is the expected system response time under normal and peak conditions, and how is performance monitored?
• How does the solution integrate with existing tools and systems, and what APIs or connectors are available?
• What disaster recovery and backup mechanisms are in place to ensure business continuity?
• What is the process for exporting data, and how easily can the solution be migrated to another provider if needed?
• How frequently are software updates or patches deployed, and how are they communicated and tested before implementation?
• Does the system support accessibility standards (e.g., WCAG), and how user-friendly is the interface for diverse user roles?
• What tools or features are provided for monitoring, auditing, and logging system usage and activities?

How Much Detail Should I Produce?

The above questions produce a lot of information for a solution. Therefore, it is important to understand the objectives and required outputs of your technology initiative.

• What will your requirements support?
• Is it for identifying a possible solution for procurement?
• Will the requirements be used in a request for information or request for quotation?
• Does the solution require multiple vendors or technologies?
• Is it COTS or custom developed?
• Will it SaaS or internally hosted?
• Are you testing the market or have you already identified your technology approach?

If you are writing NFRs as part of testing the market, then you should keep the requirements at a high-level specification. This is so you can encourage responses from vendors and not inadvertently lock them out due to an overly specified requirement.

Therefore, the use of architectural principles may be a good option in addition NFRs or on their own.

Additional Architectural Principles to Consider

The relevant guiding principles for the solution may look like this:

• Avoid customisation – adopt COTS solutions without customisation and change business practices / processes to match the solution where possible.
• Platform integration – solution options will be evaluated against the long-term vision of implementing an integrated platform.
• Business process automation – automate business processes where possible without solution customisation.
• Ease of use – the solution should feel familiar and be intuitive to the user.
• Adopt best practice – the solution should adopt industry best practice where possible.
• Optimise and automate systems management.
• Office productivity applications must not be used for corporate solutions
• Mobile applications – design for user first, device second
• For core and critical functionality more stable and mature products should be used. However for differentiating or emerging functions newer and less proven solutions may be considered to achieve innovation/optimisation outcomes.
• Reduce cost and complexity by utilising ‘out of the box/vanilla capability of Commercial off the Shelf (COTS) IT solutions and adapt underpinning work practices and processes.
• The organisation should adapt to IT systems and services that are cost effective, efficient and agile.
• The organisation should secure our data and systems aligned to Federal and State requirements (or according to legislation for the relevant region).
• Minimise legacy dependency.

Using a Non Functional Requirements Checklist Template

Using a non-functional requirements template streamlines the process of capturing and documenting critical system attributes such as performance, scalability, and security. It ensures consistency across projects, reduces the risk of overlooking essential requirements, and facilitates clearer communication among stakeholders. By providing a structured format, an NFR template helps business analysts and technical teams focus on measurable, actionable criteria, making requirements easier to validate and align with business goals. Ultimately, it saves time, enhances clarity, and contributes to the delivery of reliable, high-quality solutions.

How do I Elicit Non-Functional Requirements?

1. Stakeholder goals, values, and concerns

• What is important to the stakeholders (including the users)?
• What qualities are must have in order to achieve stated business and organisational goals?
• What are the stakeholders worried about? What are their concerns?

2. Legacy system and/or existing platform constraints

• What are the constraints dictated by the environment into which the new system must fit?
• What are the existing systems with which it must integrate, and the technical platform(s) it must use?

3. Competitive analysis of system qualities

• What additional non-functional requirements can be discovered by analysing the qualities of competing systems?

4. Industry and market trends

• What is the direction the industry or vertical market is taking and identify key trends?

5. Standard non-functional requirements templates and categories

• Are there any standard templates and categories in order to focus on and ask questions about each type of non-functional requirement? See the above categories and questions for guidance.

6. Survey data and reports

• Are there reports that can provide valuable data for estimating current user behaviour and potential growth?

Who Should I Talk to When Eliciting Non-Functional Requirements?

Not just one person will have all of the answers to your questions. A good approach to eliciting and validation non-functional requirements is to conduct a workshop with all relevant technical stakeholders and possibly an SME from the business.

Possible stakeholders for consultation are:

• Business SME – given that they can follow enough of the technical discussions to confirm questions relating to business requirements when asked.
• ITS manager
• Cyber security consultant
• Infrastructure, network, mid-range consultant
• Business applications consultant
• Solutions architect
• IT systems tester
• Enterprise information consultant

Cyber security, and privacy and protection of information is very important. The experts that deal with these aspects absolutely must be involved in developing the non-functional requirements.

Collaborating with Solution Architects

Non-functional requirements (NFRs) are often technical, but the business analyst (BA) plays a vital role in ensuring they align with business goals. Collaborating with solution architects, the BA facilitates discussions to translate high-level needs into actionable requirements, ensuring alignment between technical feasibility and stakeholder priorities.

While NFRs are often led by solution architects, the BA ensures they are aligned with business goals, prioritised, and clearly documented. By bridging the gap between business and technical teams, the BA contributes to delivering scalable, reliable, and high-performing solutions.

Educating Stakeholders

Stakeholders often overlook the importance of NFRs. The BA must educate them on how factors like performance, security, and scalability impact success, using simple analogies and examples. This ensures stakeholders provide meaningful input that reflects real-world needs.

Translating Business Needs

Stakeholders may express vague desires, like “reliability” or “speed.” The BA bridges the gap by refining these into measurable criteria, such as specific response times or uptime percentages, ensuring NFRs are actionable and testable.

Using Frameworks and Templates

Structured frameworks like FURPS+ and customised templates help the BA ensure no critical aspects of NFRs are missed. These tools provide consistency and clarity across projects, simplifying the elicitation process.

Advocating in Agile Processes

In Agile environments, NFRs can be overlooked. The BA integrates them into the Definition of Done and backlog refinement sessions, ensuring they are prioritised alongside functional requirements, avoiding technical debt.

Facilitating Trade-Offs

Conflicts between NFRs—such as security impacting performance—are common. The BA facilitates trade-off discussions, using techniques like MoSCoW to prioritise and balance business and technical needs.

Ensuring Testability

The BA collaborates with QA teams to define testable metrics for NFRs, such as load handling or accessibility compliance. Clear criteria ensure NFRs are validated during testing, reducing the risk of unmet expectations.

Effective Documentation

Organising NFRs into categories like performance or security, and ensuring they include measurable metrics, creates clear, concise documentation. This helps align stakeholders and teams on expectations.

Monitoring Implementation

The BA ensures NFRs are implemented correctly by participating in design reviews and testing. Early identification of gaps minimises costly rework later in the project lifecycle.

Continuous Improvement

The BA reviews lessons learned from each project to refine their approach to NFRs. Updating templates and processes ensures future projects benefit from increased precision and efficiency.

Non-functional requirements define the environmental conditions and quality attributes under which a system must operate effectively, encompassing aspects like performance, reliability, security, usability, and interoperability. Unlike functional requirements that specify system behaviors, NFRs address how a system performs its functions, such as acceptable response times, system availability, and user accessibility standards. For instance, performance NFRs might detail acceptable screen load times and peak user capacities, while security NFRs could outline data protection measures and compliance with regulations. Effectively capturing NFRs involves engaging with various stakeholders, including solution architects and technical experts, to ensure the system meets all necessary quality standards and operates seamlessly within its intended environment.

Recommended Resources