Non-Functional Requirements: Types, Examples & Best Practices

Being a certified project management professional, I wanted to share through this article on non-functional requirements in Agile. Before getting into the topic let me explain the difference between Function and Non-functional requirements, Basic difference is Functional Requirements focus on “What” and Non-functional Requirements focuses on “How”. Let us look on to the table below to see the similarities and differences between functional and non-functional requirements. 

Understand the concepts of non-functional requirements through a few examples, Being a certified project management professional, I wanted to share through this article on non-functional requirements in Agile. Before getting into the topic let me explain the difference between Function and Non-functional requirements, Basic difference is Functional Requirements focus on “What” and Non-functional Requirements focuses on “How”. Let us look on to the table below to see the similarities and differences between functional and non-functional requirements. 

Understand the concepts of non-functional requirements through a few examples, acceptance criteria, their impact in solution development and user stories examples, and more.

What is a Non-Functional Requirement? 

Non-functional requirements define how a system should perform rather than what it should do. Unlike functional requirements that specify features or capabilities—such as user login or payment processing—non-functional requirements deal with the quality attributes that make those functions effective and reliable.

Think of Non-Functional Requirements as the expectations around performance, usability, security, scalability, and maintainability. For example, if a functional requirement asks that users be able to upload files, a non-functional requirement might specify that the upload process should not take more than 3 seconds for a 10MB file.

These requirements help set the benchmark for user experience, system stability, and long-term sustainability. They often shape architectural decisions and play a crucial role in risk management and regulatory compliance. In Agile environments, where rapid iteration is key, clearly defined NFRs ensure that speed doesn’t come at the cost of system integrity or performance.

In short, non-functional requirements are the silent drivers of software excellence. While users may not see them directly, they experience the results every time they interact with a system that’s fast, secure, and reliable. 

Non-functional requirements are used to specify various system qualities and attributes such as  

Performance	How fast a system should respond to request
Scalability	How well a system can handle an increase in users or workload
Security	How well a system protects against unauthorized access and data breaches
Usability	How easy a system is to use
Maintainability	How easy it is to update and modify the system

If non-functional requirements such as user stories are not addressed properly, the results can include: 

• Users, clients, and developers are unsatisfied. 
• Inconsistent software.
• Time and cost overrun to fix the software which was prepared without keeping NFRs in mind. 

To summarize, NFRs are those product qualities or attributes that cannot be used as a feature, but without them, you cannot use the feature.

Functional Requirements vs Non-Functional Requirements 

Here is a brief differences between functional and non-functional requirements: 

Characteristics	Functional Requirements	Non-Functional Requirements
1. Source	Scope Document, Stakeholders, end users, Bonds, Agreements etc	Technical Teams, Support Teams, etc
2. Ownership	Product Owner, Key Account manager, Product Manager	Project lead, technical lead, Architect
3. Format	Features, User stories	User Stories, Technical Specification
4. Examples	Examples: specifications of what the system must do, business rules that must be met, steps that the system must take in authentication	availability, reliability, recoverability, maintainability, serviceability, security, regulatory, manageability, environmental, data integrity, usability, interoperability

How to Elicit Non-Functional Requirements? 

When the business analysts elicit requirements from the stakeholders on the functional aspects of the system, they also should understand from the stakeholder what attributes the system should provide in order to meet their business goals. For example, the website must be able to load within 0.5 seconds. 

Eliciting a non-functional requirement is more challenging than the functional requirement, as the stakeholders/users are good at articulating the functional requirements well; while they may not be aware of, or good at explicitly stating non-functional requirements. Business analysts will have to get these requirements from stakeholders by asking the right questions. 

NFRs are implicit by nature, meaning that people assume them to exist without being asked. 

Some of the questions to be prompted that may help the business analyst to ask stakeholders how they want their system to function include the following aspects: 

• Performance – speed of the system e.g., response time, throughput, etc 
• Availability – what is the impact if the system is not available for the customer? 
• Security – ensuring unauthorized access to the system 
• Data Retention - how long should the data be retained in the system for reference? This could be a regulation from the government/country. 
• Usability – easy access for the customer/user while using the system 
• Stability – code/system stability when dynamic changes apply due to business needs 
• Compliance – understanding compliance needs by local laws/regulations 
• Reliability – the probability of system performing without failure 
• Recoverability – the ability of the system to recover from failure 
• Serviceability – ease of system service when necessary 
• Data integrity – accuracy and correctness of data maintained in the system 
• Scalability – the ability of the system to scale when more resources are added 
• Capacity – how much the system can store information 
• Accessibility - how easily people with the widest range of capabilities can use the system. 

Non- Functional Requirements Constrain Backlogs  

Let me elaborate on Non-Functional Requirements Constrain Backlogs, Non- Non-Functional Requirements are associated with backlogs at the same time they are not backlog items. Non-functional requirements in Agile are persistent constraints on the design and development of the system whereas backlog items come and go as they are implemented.

Figure 1. NFRs modelled as backlog constraints 

Types of Non- Functional Requirements

An interesting fact that I have come across is that non-functional requirements in scrum or Agile have two types of system qualities and Design Constraints. For in-depth understanding I would suggest Agile courses online  

1. System Qualities 

System qualities are more critical among those that pass through the backlog, Figure 2 shows the list of non-functional requirements sources to consider for development. 

• Performance: System performance is the most important quality in non-functional requirements and affects almost all the other preceding ones. 
• Security: Security refers to essential aspects that assure a solution and its components will be protected against unauthorized access or malware attacks. 
• Availability: The amount of time the system is running, the time it takes to repair a fault, and the time between lapses. 
• Usability: Requirements about how difficult it will be to learn and operate the system. The requirements are often expressed in learning time or similar metrics. 
• Portability: The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing. 
• Scalability: Assesses the highest workloads under which the system will still meet the performance requirements. 
• Maintainability: The time required for a solution or its component to be fixed, changed to increase performance or other qualities, or adapted to a changing environment.  
• Reliability: How dependable the system is. 
• Localization: Is the system compatible with local specifics? 
• Compatibility: A system can coexist with another system in the same environment. For instance, software installed on an operating system must be compatible with its firewall or antivirus protection.

2. Design Constraints 

If I put a limit for choosing the design options, then it can be termed as Design constraints.  

some requirements may severely restrict the design. For example, security or safety requirements may reflect directly into design such as the need to 

• Keep certain functions in separate modules 
• Permit only limited communication between some areas of the program 
• Check data integrity for critical variables. 

The project manager can make informed decisions about the system’s design by understanding both Non- Functional Requirements and design constraints. 

Non-Functional Requirements in Agile 

A common challenge for an Agile team is dealing with capturing non-functional requirements in a user story. The non-functional requirements can be written as a user story and made available in the product backlog or sprint backlog.  

For example, “As an e-commerce website user, I want the website to be available for 99.99999%, so that I purchase products whenever I feel like” 

NFR can also be included as Acceptance Criteria in a user story. 

For example, for the following user story, “As an e-commerce website user, I want to search for products, so that I can purchase them”. NFR as acceptance criteria would be “application responds to search request within 5 seconds from the time request is received”. 

Unleash your potential with our PMP certificate course. Enhance your project management skills and soar to new career heights!

Non-Functional Requirements Examples  

For your better understanding I will compare the examples between functional requirements and non-functional requirements. A company called X got a job to do for Company B – Job is to build a website. B has provided various requirements to X for developing the website which includes functional and non-functional requirements. Let us look on to the list below. 

• Performance – funds transfer transaction should not take more than 0.5 seconds 
• Availability – the system should be available for the users to use the system anytime of the week they need 
• Security – payroll data is not visible to all the employees in the organization. Only the authorized personnel should have access to the data 
• Data Retention – all healthcare data should reside in the system for 7 years. Older data can be archived and should be accessible when required 
• Usability – the system navigation is easy for the end user and provides a seamless journey while accessing the system 
• Stability – the code/system is stable when new changes are applied due to dynamic business needs 
• Compliance – HIPAA compliance should be adhered when dealing with patients’ data in USA 
• Reliability – website users should be able to access the system 99% of the time without any failure 
• Recoverability – In case of any major failures, the system should be restored within 48 hours 
• Serviceability – the system should be serviceable immediately when there is a failure 
• Data integrity – the system should not allow phone number to be entered in the data field 
• Capacity – the system should be able to store 1 million records of basic customer information 
• Scalability – the system should be scalable to support unlimited growth of the employees 
• Accessibility - The system shall be accessible to people with disabilities in accordance with the Americans with Disabilities Act  
• Confidentiality – The system shall not display the bank account number in full. It should display only the last 4 digits of the account number while others can be masked 
• Efficiency – The interface between the system and user should not take more than 2 seconds 
• Portability – The system shall be developed for both windows and Mac operating systems platforms 

The Problem with Mixing Non-Functional Requirements and Agile

I truly believe that Agile is a wonderful framework to work on a project and the acceptance criteria for the end user are meeting “definition of done”. How ever non-functional requests cannot meet this criterion. Yet we cannot ignore NFRs, why? Let me give easy explanation!  

Your overall health: Non-functional requirement 

Weight loss: Functional requirement 

If you lose 30 kg in 5 months and you eat mostly red meat including all junk foods, will you consider this as achievement? 

If we (project manager) focus only on Functional requirement and not on non-functional requirements, then we might end up not meeting the business objective. Hence a perfect blend is required when it comes to non-functional requirements in scrum

The Three Steps to Capture NFRs in Sprint Planning 

Non-functional requirements are like faith God, it’s difficult to see and sometimes to define. If the faith gets affected it might affect the entire peace of our family. Non-functional requirements in scrum are the same for a project without them fundamental objectives will be missed in the project. 

Three-step approaches to determine NFRs in sprint planning are 1) Prioritize the non-functional requirements 2) Break the NFR Down 3) Include NFRs in sprint planning. For better understanding of the approach KnowledgeHut Agile courses online 

1. Prioritize the non-functional requirements. 

I would like to emphasize that this step is the most important among the three because here we capture the Voice of customers (stakeholders) and understand their requirements for the product. 

2. Break the NFR Down 

In this second step we will be focusing on identifying the most appropriate non-functional requirements as user stories   and then break it down into several actions to address the needs. 

Example: Let us take, we need to increase productivity by 10% every quarter. We can achieve this by increasing the speed and by increasing the resources. If we decide to go ahead with increasing the speed. Next process will be to break down further and determine the at what speed rate each stage will run. 

3. Include NFRs in Sprint Planning 

In this final phase we decided to increase the speed to achieve the non-functional requirements to increase productivity now user stories will be created around the individual steps and include them in sprints.  In the same way if the NFR Agile is performance then the user story we can create to increase the speed of the software. 

The Impact of NFRs on Solution Development  

The business analyst and the project development team understand the customer requirements and expectations well and they are comfortable in converting the requirements into a finished product. The customer also validates the functional part of the requirements and signs off on successful implementation. However, the project's success is dependent on the non-functional requirements as they define the quality attributes of a system.  

Some or all of the types of non-functional requirements that is described above contribute towards the successful implementation of the system. For example, the system should be available all the time with minimal or negligible downtime, security is not compromised, maintaining confidential data/information, not allowing unauthorized users, scalable while the customer business is growing, having enough capacity to maintain product data considering future growth etc. Failure of any of these quality attributes will leave the customer unsatisfied.

The Impact of NFRs on Solution Development   

Effectively handling Non-Functional Requirements is vital to delivering software that performs reliably under real-world conditions. While functional requirements define what a system should do, NFRs ensure the system operates efficiently, securely, and at scale. If neglected, they can lead to performance issues, vulnerabilities, or poor user experience. 

The process begins with identifying NFRs early in the development cycle. This typically happens during sprint planning or backlog refinement, where teams discuss aspects such as response time, system availability, compliance needs, and scalability. It’s important to ask the right questions early on—what kind of load should the system handle? How fast should features respond? Are there any legal or security standards involved? 

Once documented, NFRs should be treated with the same importance as functional requirements. They can be incorporated into user stories, acceptance criteria, or included in the Definition of Done. This keeps them visible throughout the Agile lifecycle and ensures accountability. 

Ongoing validation and monitoring are equally important. Load testing, security reviews, and performance benchmarks should be integrated continuously—not reserved for the end of development. 

Finally, cross-functional collaboration is essential. Developers, QA, DevOps, and business teams must work together to define, interpret, and validate NFRs. Aligning expectations early reduces confusion, rework, and missed goals later. 

Managing NFRs is an ongoing effort. When done right, it leads to robust systems that meet user expectations and stand the test of time. 

Best Practices for Writing Non-Functional Requirements 

• Understand the Voice of Customer - Understanding the end user’s or customer’s functional and non-functional requirements clearly. This will help us to identify the right approach, saving time rather than spending on reworks and results in improving the performance of the product/services. 
• Kaizen in Products / Features - We all know KAIZEN means continuous improvement, which is also applicable for products (hardware, software, services, automobiles etc), which emphasis on keep upgrading your product with new/unique features that increase the product's compatibility. 
• Setting measurable targets -We should always aim to set measurable goals that help in identifying problems and subsequently the potential solutions.  
• Prioritize expectations of the end user – Understanding the requirements is important at the same time prioritizing over others is also equally important which will result in customer satisfaction. 
• Learn from your existing and previous products/process – Based on the learnings from the existing available product or similar products we can learn what kind of non-functional requirements are implemented. 

Implementation Approaches  

In general, the focus of the project team is to provide the functionality that the user has given. The non-functional requirements are looked into towards the end of the project after the customer UAT is complete. The team then focuses on the non-functional quality attributes, and sometimes may not be able to fulfill them as the design of the system may not accommodate the respective implementation. 

It is good to see the trade-off between the quality attributes during the requirements and early in the design stage of the project. Defining the non-functional requirements needs thorough analysis and creativity in the early stages. It is recommended to consider this during the development life cycle of the software development, rather than leaving this to be discussed at the later stage of the project.  

As seen earlier, the elicitation of the non-functional requirements can be carried out by the business analyst by using the prompt list and added as part of the requirements document in traditional project management. These requirements can be specified either as a user story or part of the acceptance criteria of a user story, which enables the team not to miss any of these during the development stage, without leaving it to the end of the project life cycle.

Examine the top trending  Agile Category Courses

CSM Certification	CSPO Certification	Leading SAFe Certification
PSM Certification	SAFe Scrum Master Certification	SAFe SPC Certification
SAFe RTE Certification	SAFe POPM Certification	ICP-ACC Certification

Conclusion

Let me try to summarize the topic of non-functional requirements in Agile here, for any project let it be mechanical, software or electronic, etc., fundamental requirements are the requirements from the customer where the definition of done (DoD) is defined.  DoD includes both functional requirements and non-functional requirements, which results in the successful completion of a project or product or service.