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

Reading time:

13

minutes

Imagine you’re buying a motorcycle. What features do you have in mind? Do you expect it to travel at 170 miles an 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 other kind of machinery, any software product 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?

Non-functional requirements or NFRs are a set of specifications that describe the system’s operation capabilities and constraints and attempt to improve its functionality. These are basically the requirements that outline how well it will operate including things like speed, security, reliability, data integrity, etc.

Functional and non-functional requirements

Both functional and non-functional requirements describe specific characteristics that a product must have to meet the needs of the 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 to correct errors.” (Well yeah, Meta, the system must provide this functionality. Just so you know 😉)
• Non-functional requirements specify the quality attributes of the system, hence their second name — quality attributes. Continuing our messaging platform example, a non-functional requirement can be the speed with which a system must perform editing to satisfy user expectations, “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.”

We’ve already covered different types of software requirements as well as written a detailed post on the differences between functional and non-functional requirements. This time we’ll focus on non-functional ones, provide examples, and explain how to approach and document them. If you need a general recap on software documentation and planning, check out our video.

 Non-functional requirements 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 the 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.

What are the key types of non-functional requirements?

The most common ones are performance, scalability, portability, compatibility, reliability, availability, maintainability, security, localization, and usability. But there are quite a few types of non-functional requirements that can make it to your checklist too.

Key types of non-functional requirements

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, and browsers, along with their versions does the software run on? Does it conflict with other applications and processes within these environments?

Reliability, maintainability, availability. How often does the system experience critical failures? How much time does it take to fix the issue when it arises? And how is user availability time compared to downtime?

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

Localization. Is the system compatible with local specifics?

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

Usually, such sources as the above-mentioned 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.

Let’s now take a closer look at each requirement along with examples so you have a better understanding of the topic.

Performance and scalability

Performance and scalability are the two core non-functional requirements no system can do without. Since they go hand in hand, we’ve put them in one section.

Performance and scalability non-functional requirements

Performance

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

Example of performance requirements:

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

Scalability

Scalability assesses the highest workloads under which the system will still meet the performance requirements. There are two ways to enable your system 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.

Example of scalability requirements:

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

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.

Google estimates performance based on multiple factors

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. 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 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 40 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 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.

Define your scalability expectations. 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.

Portability and compatibility

Two more key players in the world of non-functional requirements are such attributes as portability and compatibility.

Portability and compatibility non-functional requirements

Portability

Portability determines how a system or its element can be launched within one environment or another. It usually includes hardware, software, or other usage platform specifications. 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.

Example of portability requirements:

A program running on Windows 10 must be able to run on Windows 11 without any change in its behavior and performance.

Compatibility

Compatibility, as an additional aspect of portability, defines how 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.

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

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

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, 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.

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.

Reliability, Maintainability, Availability

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

Reliability, maintainability, and availability non-functional requirements

Reliability

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.

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.

Example of reliability requirements:

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

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. Maintainability is often measured with a metric like MTTRS — the mean time to restore the system.

Example 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.

Availability

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.

Example of availability requirements:

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

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 for your system.

How to approach

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.

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

Security

Security is a non-functional requirement assuring 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.

Security non-functional requirements

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.

Example of security requirement:

The payment processing gateway must be PCI DSS compliant.

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, and 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 you rely on. If your system must be compliant with some security standards or regulations, for example HIPAA, the non-functional section is the best place for them.

Localization

The localization 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.

Localization non-functional requirements

You can learn more in our article about website localization in the travel industry.

Example of a localization requirement:

The date format must be as follows: month.date.year.

How to approach

Rely on market research. To document this requirement, you have to rely on 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, things like language, currency, and address and payment formats are crucial requirements.

Usability

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.

Usability non-functional requirements

There are many types of usability criteria. One of the most popular is by Nielsen Norman Group that 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 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?

Example of usability requirements:

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

With that in mind, 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 and 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.

General recommendations for 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.

If you want to learn more about software documentation in general, check our video:

Software documentation in 11 minutes or less