Non-functional Requirements: Examples, Types, How to Approach

Reading time: 11 minutes

Imagine you’re buying a motorcycle. What features do you have in mind?  Do you expect it to travel at high speed of 170 miles per hour and not to fall apart? Can you attach a sidecar to it or expand luggage space by attaching 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 kind of machinery, software has its own non-functional requirements. Be it a website, a mobile or a desktop app, it should have a set of quality attributes to meet end-user needs.

What are non-functional requirements?

Simply said, a non-functional requirement is a specification that describes the system’s operation capabilities and constraints that enhance its functionality. These may be speed, security, reliability, etc. We’ve already covered different types of software requirements, but this time we’ll focus on non-functional ones, and how to approach and document them. If you need general recap on software documentation and planning, check our video.

Software documentation, explained

If you’ve ever dealt with non-functional requirements, you may know that different sources and guides use different terminology. For instance, the ISO/IEC 25000 standards framework defines non-functional requirements as system quality and software quality requirements. BABOK, one of the main knowledge sources for business analysts, suggests the term non-functional requirements (NFR), which is currently the most common definition. Nevertheless, these designations consider the same type of matter – the requirements that describe operational qualities rather than a behavior of the product.

The list of them also varies depending on the source. And, frankly, it may differ for different products. For instance, if you intend to collect any user data and your website operates in the EU, you must meet GDPR compliance rules. In some cases, this may not be relevant to you. Or you may have additional compliance requirements if you process payments.

In this article, we’ll cover only the most common types that should make it to your checklist. However, there may be hundreds of them. Usually, such sources as BABOK list non-functional requirements in an isolated manner. We grouped some of them since the approaches to documenting these requirements overlap and some can’t be estimated without the other ones:

Performance and scalability. How fast does the system return results? How much will this performance change with higher workloads?

Portability and compatibility. Which hardware, operating systems, browsers, and their versions does the software run on? Does it conflict with other applications and processes within these environments?

Reliability, availability, maintainability. How often does the system experience critical failures? and how much time is it available to users against downtimes?

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

Localization. Does the system match local specifics?

Usability. How easy is it for a customer to use the system?

Performance and scalability

Performance defines how fast a software system or its particular piece responds to certain users’ actions under certain workload. In most cases, this metric explains how much 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.

Scalability assesses the highest workloads under which the system will still meet the performance requirements.

How to approach

Start with Google recommendations for regular web pages. Google is very sensitive about desktop and mobile speed load times. So, if you look 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.

Google estimates performance based on multiple factors

Google estimates performance based on multiple factors

Check basic response time recommendations. Jakob Nielsen back in 1993 outlined 3 main metrics for response time. While this outline may seem ancient, the metrics 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 user will notice the delay, but without interrupted flow of thought;
  • 10 seconds – when user attention is completely lost.

Usually, you don’t want to reach this 10-second threshold, as about 40 percent of users will abandon a website after 3 seconds.

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 pace, you may have different time constraints for text, images, and videos.

Specify the current workload for a measurement. Since you may have, say, 5 thousand users on average during the day and 1 thousand at night, define which load scenarios you 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 third-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.

Consider scalability. We also included scalability in this section, since it considers the maximum load that the system doesn’t necessarily process now, but may process in the near future. For instance, you expect that the number of sessions in the application will double after a marketing campaign and you still want to preserve the existing performance.  Although it’s hard to make predictions in advance, it’s worth setting at least some load expectations.

Example of performance requirements:  

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

Portability and compatibility

Portability defines how a system or its element can be launched on one environment or another. It usually includes hardware, software, or other usage platform specification. Put simply, 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.

Portability also has an additional aspect called compatibility. Compatibility defines how a system can co-exist with another system in the same environment. For instance, software installed on an operating system must be compatible with its firewall or antivirus protection.

Portability and compatibility are established in terms of operating systems, hardware devices, browsers, software systems, and their versions. For now, a cross-platform, cross-browsing, and mobile-responsive solution is a common standard for web applications.

Portability non-functional 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. If you are working within a corporate environment and the software will be accessed through a documented list of devices and operating systems, it’s quite easy to define compatibility and portability.

How to approach

Infer portability requirements from your analytics tools if you can. If you have access to visitor data via Google Analytics or other analytical platforms, you can assess which types of devices, browsers, and their versions are most frequently used.

Consider the fullest list of portability requirements. Not only will this document provide guidance to engineers, it will also outline the scope of testing scenarios:

  • Operating systems and their versions,
  • Network specifics,
  • Browsers and their versions, and
  • Devices and other hardware requirements.

Example of portability and compatibility requirements of Visual Studio IDE

Example of portability and compatibility requirements of Visual Studio IDE

Define compatibility with other applications, including 3rd parties. If the system must coexist with third-party software or other applications in the software ecosystem, include them.

Example of compatibility requirements: 

The iOS application must support iPhone devices running on OS versions:

  • 3.6
  • 3.3
  • 3.4
  • 4.3
  • 2.3

Reliability, Availability, Maintainability

While these three types of requirements are usually documented separately, we aggregate them in one section, since they approach the same sort of a problem from different angles. Another thing to keep in mind with these requirements is that they are extremely hard to express in calculative terms. And, frankly, many system providers don’t document them at all. Let’s see.

Reliability. This quality attribute specifies how likely the system or its element would run without a failure for a given period of time under predefined conditions. Traditionally, it’s expressed as a probability percentage. 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.

As you may have guessed, it’s fairly tricky to define critical failure, time, and normal usage conditions. Another, somewhat simpler approach to that metric is to count the number of critical bugs found in production for some period of time or calculate a mean time to failure. Three ways to measure it are:

  • Probability percentage, time;
  • The number of critical failures, time; and
  • Mean time between failures.

Maintainability. Maintainability defines 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. 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.

Availability. And finally, availability describes how likely the system is accessible for a user at a given point in time. While it can be expressed as a probability percentage, 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.

As you can see, these three metrics are closely connected. And more importantly, you should approach them together if you decide to document them as non-functional requirements to your system.

How to approach

Start with the financial or 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.

Consider product lifespan. On establishing maintainability/reliability/availability, 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.

Approach estimations during testing and production. You can look for benchmarks of similar products and features, but if this information isn’t available at 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.

Example of availability requirements:

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


This non-functional requirement assures that all data inside the system or its part will be protected against malware attacks or unauthorized access. But there’s a catch. The lion’s share of security non-functional requirements can be translated into concrete functional counterparts. If you want to protect the admin panel from unauthorized access, you would define the login flow and different user roles as system behavior or user actions.

So, the non-functional 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.

How to approach

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, what kinds of malware attacks you want to fend off.

Expand non-functional requirements to functional ones. They can include, say, a comprehensive authorization and authentication scheme for each system actor. Also, the system is supposed to introduce constraints on who can generate, view, duplicate, edit, or delete the data.

Consider standards that your rely on. If your system must be compliant with some security standards or regulations, the non-functional section is the best place for them.

Example of security requirement:

The payment processing gateway must be PCI DSS compliant.


This attribute defines how well a system or its element falls in line with the context of the local market-to-be. The context includes local languages, laws, currencies, cultures, spellings, and other aspects. The more a product sticks with it, the more success it should have with a particular target audience.

Things to consider

Rely on market research. To document this requirement, you have to rely on the preliminary market research from a product manager or a comprehensive field study by a UX researcher.

Be specific in terms of localization aspects. If there are several options for each component within a single market, all of them should be addressed. For instance, language, currency, and address and payment formats are crucial to have.

Example of localization requirement:

The date format must be as follows:


Usability is yet another classical nonfunctional requirement that addresses a simple question: How hard is it to use the product? Defining these requirements isn’t as easy as it seems. There are many types of usability criteria. One of the most popular one ones by Nielsen Norman Group suggests evaluating usability with five dimensions:

Learnability. How fast is it for users to complete the main actions once they see the interface?

Efficiency. How quickly users can 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?

Keeping that in mind, you must consider how to make these requirements measurable.

How to approach

Start with the old design. If you already have a product, consider measuring the number of errors, the time it takes to learn the interface and complete tasks to set up a baseline and define usability goals.

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

Run usability testing on competitor products. If you don’t have an existing product, run tests with competitors to reveal areas of improvement. You may also check our article on usability engineering to learn more.

Test usability on prototypes rather than on a finished product. This is a no-brainer, since usability must be established before your engineering even begins.

Example of usability requirements:

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

General recommendations to documenting non-functional requirements

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

Make them measurable and testable. To understand whether your system meets quality constraints, make 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.

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.

Link NFR 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 third-party limitations. If a third-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.

Add a comment