Nonfunctional Requirements in Software Engineering: Examples, Types, Best Practices

Imagine you’re buying a motorcycle. What do you expect from it? Do you want it to travel at 170 miles an hour and not fall apart? Can you attach a sidecar to it or expand luggage space by hooking up a pull-behind trailer? And let’s not forget about security systems. While these requirements don’t directly describe the vehicle’s primary function – delivering a person from point A to point B – they are still important to satisfy your needs as the driver.

Like motorcycles or any other kind of machinery, software products have their own nonfunctional requirements. Be it a website, a mobile app, or a desktop system, it should have a set of quality attributes to meet the end user’s needs.

What are nonfunctional requirements: NFR meaning

Nonfunctional requirements, or NFRs, are a set of specifications that describe the system’s operation capabilities and constraints. These are basically the requirements that outline how well it operates, including things like speed, security, reliability, data integrity, etc.

Sometimes NFRs are referred to as quality attributes or software quality requirements as they describe different aspects of how the product works. But NFRs are just one category of requirements in software engineering. So before we start a more detailed discussion, let’s say a few words about the other important group you’ll most likely have to deal with – functional requirements.

Functional vs nonfunctional requirements

Both functional and nonfunctional requirements describe specific characteristics that a product must have to meet the needs of stakeholders and the business itself. But, as you can tell from the name, they focus on different things.

• Functional requirements define what a software product must do: its features and functions. An example of a functional requirement for a messenger will be something like, “A user must be able to edit messages after they are sent.” (Well yeah, Meta, the system must provide this functionality. Just so you know.)
• Nonfunctional requirements specify how the system must perform. Continuing our messaging platform example, a nonfunctional requirement can be the speed with which a system must perform editing to satisfy user expectations, e.g., “The message must be updated for all users in a chat within 0.1 seconds, given that all users are online and have LTE connection or better.”

If you want a more detailed comparison, we have a separate post on the differences between functional and nonfunctional requirements.

All the solution requirements are usually documented in a software requirements specification (SRS) and a product requirements document (PRD). They contain descriptions of functions and capabilities that the product must provide, as well as a list of constraints and assumptions.

Check our posts about software requirements specifications and a product requirements document to learn how to write them and what to include. Also, if you need a general recap on software documentation and planning to get an even broader picture, check out our video.

Now that you have a general understanding of the software requirements realm, let’s go into more specifics and look at the main types of nonfunctional requirements.

Nonfunctional requirements examples and types

The most common groups of NFRs are performance, scalability, portability, compatibility, reliability, availability, maintainability, security, localization, and usability. In addition to these, Wikipedia suggests quite a few other types that can make it to your checklist too.

Performance. How fast does the system return results?

Scalability. How much will performance change with higher workloads?

Portability. Which hardware, operating systems, and browsers, along with their versions, does the software run on?

Compatibility. Does the system conflict with other applications and processes?

Reliability. How often does the system experience critical failures?

Maintainability.  How much time does it take to fix the issue when it arises?

Availability. How long is the average system downtime?

Security. How well are the system and its data protected against attacks?

Usability. How easy is it to use the system?

Let’s now take a closer look at each type of NFRs one by one, with examples and tips on how to approach them.

Performance requirements

Performance defines how fast a software system (or its component) responds to certain users’ actions under a certain workload. It’s the core type of nonfunctional requirements no system can do without.

In most cases, the performance metric explains how long a user must wait before the target operation happens (the page renders, a transaction is processed, etc.) given the overall number of users at the moment. But it’s not always like that. Performance requirements may describe background processes invisible to users, e.g., backup. But let’s focus on user-centric performance.

Examples of performance requirements

The landing page supporting 5,000 users per hour must provide a 6-second or less response time in a Chrome desktop browser, including the rendering of text and images over an LTE connection.

Product search results should be displayed within 3 seconds for 90% of the searches under normal conditions.

The system must be capable of ingesting data streams at a minimum rate of 1 million records per minute from various sources without loss of data.

For real-time dashboard updates, the system should refresh and display updated analytics within 10 seconds of receiving new data.

How to approach performance requirements

Start with Google recommendations for regular web pages. Google is very sensitive about desktop and mobile speed load times. So, if you're looking for performance guidance for regular web pages that all users have access to, check Google’s Page Speed Insights.

The search engine considers multiple scenarios, including the type of connection, mobile or desktop load, and type of content that gets displayed. Based on the sum of factors, it suggests different performance scores that you can estimate for your website. This is especially important if you set up the requirements for landing pages, as Google might rank your page lower in consideration of its speed.

Check basic response time recommendations. Back in 1993, Jakob Nielsen outlined 3 main metrics for response time. While these parameters may seem ancient, they are still meaningful as they are generally based on the way human attention works:

• 0.1 second – the limit after which the system reaction doesn’t seem instantaneous;
• 1 second – when the user will notice the delay, but the flow of thought won’t be interrupted;
• 10 seconds – when the user’s attention is completely lost.

Usually, you don’t want to reach this 10-second threshold, as about 55 percent of users will abandon a website after 3 seconds. According to an updated study by Portent, “A site that loads in 1 second has a conversion rate 3x higher than a site that loads in 5 seconds.” You might have heard this before: Time is money.

Specify the measurement scenario. Does your metric include browser rendering or only the time it takes to deliver data to a browser? If different types of content load at different speeds, you may have different time constraints for text, images, and videos.

Specify the current workload for a measurement. Since you may have, say, 5,000 users on average during the day and 1,000 at night, define which load scenarios you need to document. Maybe you document both, maybe you want to set up the highest threshold.

Don’t include the time it takes to deliver results by third parties. If your operation depends on calls that return data from a 3rd party API, your development team won’t be able to take responsibility for that.

Acknowledge the architectural constraints. If developers are dealing with an enterprise solution or a legacy system, there may be very few ways to improve performance without reworking the entire architecture.

Scalability requirements

Scalability assesses the highest workloads under which the system will still meet performance and usability requirements. Importantly, scalability refers to the capacity of the system to handle growth in terms of both data volume and user load.

There are two ways to enable your system to scale as the workloads get higher: horizontal and vertical scaling.

• Horizontal scaling is provided by adding more machines to the pool of servers.
• Vertical scaling is achieved by adding more CPU and RAM to the existing machines.

So the main point of scalability requirements is that the system must remain stable and maintain performance with more users, data, business processes, or modules.

Examples of scalability requirements

The website must be scalable enough to support 1,000,000 visits at the same time while maintaining optimal performance.

The ERP system should be capable of scaling data processing and storage capabilities as the company grows, potentially handling a tenfold increase in transaction volumes over five years.

The real-time locating system should be able to scale from managing 10,000 to 500,000 IoT devices without loss of data fidelity or monitoring capabilities.

The eCommerce website should be able to scale to accommodate a 300 percent increase in user traffic during holiday seasons or promotional events without any degradation in response time or service availability.

How to approach scalability requirements

Define your scalability expectations from a business perspective. First, assess the current average volume of users, data, transactions, or other workloads the system handles. Then, define the business growth forecast. Consider how many users you plan to accommodate, which new markets you want to enter, or which additional modules you might need in the future.

Consider industry specifics. Scalability requirements are often industry-dependent. For example, for an eCommerce website, gaming platform, or video streaming platform, the number of users is of the biggest importance. Meanwhile, say, for a banking app, consider the number of transactions it can handle and the additional products you plan to include. In the case of an IoT-based system, the data volume is most critical.

Quantify requirements. Use specific, measurable metrics such as the number of concurrent users, data volume, transaction rates, or response times.

Set realistic goals. Base scalability objectives on realistic usage scenarios, considering expected growth patterns and peak demand.

Portability requirements

Portability determines if a system or its elements can work in different environments. It usually includes hardware, software, or other usage platform specifications. In other words, it establishes how well actions performed via one platform are run on another. Also, it prescribes how well system elements may be accessed and may interact from two different environments.

Examples of portability requirements

The app should be operable and maintain a consistent user experience across various mobile devices, including different screen sizes and resolutions.

The software must be capable of running on multiple operating systems, including Windows, macOS, and Linux, without any modifications.
A program running on Windows 10 must be able to run on Windows 11 without any change in its behavior and performance.

The web application should be fully functional on all major web browsers, including Chrome, Firefox, Safari, and Edge, with consistent performance and layout.

How to approach portability requirements

Research your target market. Portability requirements are usually based on preliminary market research, field research activities, or analytics reports on the types of software and devices the target audience has.

Deduce portability requirements from your analytics tools. You can take advantage of Google Analytics or other analytical platforms with access to visitor data to examine which types of devices and browsers, along with their versions, are most frequently used.

Consider the most complete list of portability requirements. Not only will this document provide guidance to engineers, but it will also outline the scope of testing scenarios. This includes

• the list of supported operating systems and their versions,
• network specifics,
• the list of supported browsers and their versions, and
• devices and other hardware requirements.

Compatibility requirements

Compatibility defines how a system can coexist and interact with another system in the same environment. In other words, these requirements specify how compatible the software product is with other programs. For instance, software installed on an operating system must be compatible with its firewall or antivirus protection. Obviously, a lack of compatibility can lead to poor performance, errors, or data loss.

Compatibility also defines how interoperable the system is, meaning how well it can exchange data with external systems. This type of requirements is crucial for smooth and efficient system integration.

Portability and compatibility requirements are quite similar as both relate to different operating systems, hardware devices, browsers, software systems, and their versions. For now, a cross-platform, cross-browser, mobile-responsive, and highly compatible solution is a common standard for web applications.

Examples of compatibility requirements

The iOS application must support iPhone devices running on OS versions 15, 16, and 17.

Healthcare data management software must be interoperable with various Electronic Health Records (EHR) systems to exchange patient data securely and efficiently.

A video conferencing tool must be compatible with a wide range of webcams, microphones, and speakers across different manufacturers.

The ERP system must be compatible with the company’s existing legacy software, ensuring smooth data exchange and operational continuity.

Banking software must be compatible with common financial data formats like CSV, XLSX, and QIF for importing and exporting financial data.

How to approach compatibility requirements

Identify target systems. Make a list of internal systems that your product must interact with.

Define compatibility with 3rd party applications. If the system must coexist with 3rd party software or other applications in the software ecosystem, include them. Also, define the expected performance levels.

Reliability requirements

Reliability specifies how likely the system or its element would run without a failure for a given period of time under predefined conditions. Traditionally, this probability is expressed in percentages. For instance, if the system has 85 percent reliability for a month, this means that during this month, under normal usage conditions, there’s an 85 percent chance that the system won’t experience critical failure.

Examples of reliability requirements

The system must perform without failure in 95 percent of use cases during a month.

All financial transactions should be processed with 100% accuracy, and the system must ensure data integrity at all times.

The system should be able to handle and recover from errors without data loss or incorrect data processing.

How to approach reliability requirements

Try different approaches. It can be tricky to define critical failure, time, and normal usage conditions. An alternative, somewhat simpler approach to that metric is to count the number of critical bugs found in production for some period of time. You can also track the time between critical failures or calculate a mean time to failure.

Estimate during testing and production. You can look for benchmarks of similar products and features, but if this information isn’t available at the product planning stages, it’s hard for you to specify the measurements. So it’s likely that you’ll be able to articulate these requirements during prelaunch testing and production. However, you can emphasize code quality during the development itself.

Maintainability requirements

Maintainability defines the time needed for a solution or its component to be fixed, changed to increase performance or other qualities, or adapted to a changing environment.

Like reliability, it can be expressed as a probability of repair during some time. For example, if you have 75 percent maintainability for 24 hours, this means that there’s a 75 percent chance the component can be fixed in 24 hours. Maintainability is often measured with a metric like MTTRS — the mean time to restore the system.

Examples of maintainability requirements

The mean time to restore the system (MTTRS) following a system failure must not be greater than 10 minutes. MTTRS includes all corrective maintenance time and delay time.

The video streaming service should automatically adjust the video quality based on the user's internet speed to avoid buffering.

How to approach maintainability requirements

Define modularity. Evaluate the system to define the degree to which it’s composed of separate elements. You have to make sure that the change to one component has minimal impact on others.

Consider lifespan. On establishing maintainability, consider a software product lifespan. The longer it is, the more sense it makes to develop a highly maintainable solution. In other words, if you’re building an MVP to test assumptions, there’s no need to invest in the quality of development this early.

Availability requirements

Availability describes how likely the system is accessible to a user at a given point in time. While it can be expressed as an expected percentage of successful requests, you may also define it as a percentage of time the system is accessible for operation during some time period. For instance, the system may be available 98 percent of the time during a month.

Availability is perhaps the most business-critical requirement, but to define it, you also must have estimations for reliability and maintainability.

Examples of availability requirements

The web dashboard must be available to US users 99.98 percent of the time every month during business hours EST.

The app must perform consistently across different devices and operating systems with a reliability rate of 99%.

The video streaming must be uninterrupted 99.8% of the time under normal network conditions.

How to approach availability requirements

Start with the financial or some other critical standpoint. Can you afford your application to be unavailable 5 percent of the time? Can you express the acceptable losses in financial figures or some other product-level KPI? Keeping in mind there are no completely failure-proof applications, define the threshold that you can’t cross.

Specify the component that you describe. You can approach the entire system, but if it has different environments (payment workflow, landing pages, dashboards), each of them may have its own reasonable failure limit and availability requirement.

Describe different load scenarios. The system may experience downtimes differently depending on different workloads. Similar to performance measurements, consider different situations to define normal and possible abnormal circumstances.

Security requirements

So the nonfunctional requirements part will set up specific types of threats that functional requirements will address in more detail. But this isn’t always the case. If your security relies on specific standards and encryption methods, these standards don’t directly describe the behavior of a system but rather help engineers with implementation guides.

Examples of security requirements

The payment processing gateway must be PCI DSS compliant.

The clinical software must comply with HIPAA (Health Insurance Portability and Accountability Act) and GDPR (General Data Protection Regulation).

Cloud data centers must comply with security certification ISO 27001.

How to approach security requirements

Define specific threats that you want your system to be protected from. For instance, such details should be considered: under what circumstances the unauthorized access takes place, what the precedents to the data breach are, and what kinds of malware attacks you want to fend off.

Expand nonfunctional requirements to functional ones. Include, say, a comprehensive authorization and authentication scheme for each system actor. Also, the system must introduce constraints on who can generate, view, duplicate, edit, or delete the data.

Consider standards that you rely on. If your system must be compliant with industry-specific security standards or regulations like HIPAA, the nonfunctional section is the best place for them.

Usability requirements

Usability is basically about user-friendliness. That means  the product interface must be intuitive and easy to navigate, its features must be understandable and easy to find, and, most importantly, it must meet the user’s needs.

There are many types of usability criteria. One of the most popular is by Nielsen Norman Group, which suggests evaluating usability with five dimensions:

Learnability. How fast can users complete the main actions once they see the interface?

Efficiency. How quickly can users reach their goals?

Memorability. Can users return to the interface after some time and start efficiently working with it right away?

Errors. How often do users make mistakes?

Satisfaction. Is the design pleasant to use?

Examples of usability requirements

The error rate of users submitting their payment details at the checkout page mustn’t exceed 10 percent.

Users should be able to find desired products within three clicks from the homepage.

Essential controls like mute, video toggle, and screen share should be readily accessible during calls.

The most frequently used features must be easily accessible and reached with minimal navigation.

How to approach usability requirements

Run usability testing. Usability testing is the main technique for assessing user experience that will allow you to quantify usability. Check our articles on the role of user testing and usability engineering to learn more.

Set the baseline. If you already have a product you want to improve, assess it to set up a baseline and define usability goals.

Test competitor products. If you don’t have an existing product or a prototype, run tests with that of competitors to set measurable usability objectives.

Establish thresholds based on your product KPIs. Can you afford to have only 50 percent of users find what they are looking for? What would be the number that satisfies your strategic plans?

Test usability on prototypes rather than on a finished product. This is a no-brainer since usability must be perfected before you launch the product.

Sometimes nonfuctional requirements are mentioned as synonymous with technical requirements. Learn more from our article about functional vs technical requirements.

How to document nonfunctional requirements: best practices

Before winding up, let’s discuss the key things to remember when defining and documenting the requirements for software quality.

Set requirements for system components rather than whole products. Consider which critical interfaces and systems need such requirements. If your users never interact with some part of your product (e.g., an admin panel), setting up performance limitations for these components may be useless or harmful since your team will expend much more effort with no evident gain.

Make NFRs measurable and testable. To understand whether your system meets quality constraints, be sure to quantify your requirements. You have to specify the units of measurement, the methods that you are going to use, as well as success and failure levels.

Be specific. Ensure each NFR is specific and unambiguous. For instance, instead of saying "the system should be fast," specify "the system should respond to user input within 2 seconds."

Collaborate. Engage different groups of stakeholders when writing NFRs. Conduct market research to understand user expectations, interview investors to align with their vision, and talk to team members to have a technical perspective.

Link NFRs with business objectives. The minute-long difference in system availability may not have a drastic impact on your sales numbers, but sometimes it can mean additional weeks of engineering. Try breaking down your business objectives into system requirements.

Consider 3rd party limitations. If a 3rd party API that you must use returns data slower than you want, there isn’t much you or your team can do about it.

Consider architectural limitations. Legacy systems can put constraints on quality. While refactoring legacy code is doable, sometimes the current architecture must be completely reworked to meet some of the requirements.

Look for existing standards and guides. It’s likely that many system quality recommendations have been made before. So check iOS or Android app guidelines to suggest some requirements for your app.

Review and adjust. Regularly review your list of requirements to ensure they still align with business goals and technological advancements. Adapt them if needed in response to new insights, market changes, or technological innovations.