Guide to non-functional requirements: types and examples

For your digital solutions to deliver against your goals, thinking about how they’ll work is as important as considering what they’ll do. However, as these qualities are typically more ambiguous and complex to define than traditional software features and functionality, effectively setting requirements and measuring success can be tricky.

In this post I’ll talk through some of the most common types of these kinds of ‘non-functional’ requirements for your website, web application or other software system, along with examples, giving you a language to express your software needs and showing you how to build them into your development plans.

What are non-functional requirements in software architecture?

Non-Functional Requirements (NFRs) are the properties of a software system that sit outside of specific features and functionality that typically dictate how the system should behave; in recent years the term Quality Attributes has become an increasingly popular alternative term to categorise these kinds of requirements (although technically NFRs are a wider term that also includes technical and business constraints). Here we tend to call them Quality Attribute Requirements, or QARs for short.

To understand the difference between functional and non-functional / quality attribute requirements, It can be useful to view functionality as what a system does (think ‘nouns’), and quality as how well it does it (think ‘adverbs’). They are also often known as ‘-ilities’, as you’ll see later on when we walk through some examples.

Why are NFRs / quality attributes important?

In Agile software development, functionality requirements are typically captured through user stories and Agile story mapping exercises, which detail the tasks and features users will interact with on their journey to achieve key goals.

In contrast to these functional requirements, non-functional requirements are easy to miss in upfront requirements gathering. For example, it may be assumed that the system will possess certain qualities without these needing to be specified, or the perceived complexity involved in defining them may lead to their being deprioritised.

It’s vital to address NFRs/QARs as early as possible in your specification however, as it’s the qualities of your software that are most likely to drive the shape of its architecture, rather than functionality requirements which (for the most part) can usually be achieved in a number of different ways.

Building a high-quality system that delivers against both your functional and non-functional requirements is much easier if you’ve thought about it earlier (also known as ‘shifting left’ in the process). It’s also been shown repeatedly in industry reports that higher software engineering performers get that way by having better practices in the first place, so (perhaps counter-intuitively) it may make your processes more efficient too.

What are some attributes of good software?

The non-functional requirements needed for your software, website or application will of course depend on your context and the outcomes you’re looking to achieve, particularly as there are so many that can be applied. This great list of quality attribute requirements from Wikipedia shows the scale of choice that’s out there:

accessibility, accountability, accuracy, adaptability, administrability, affordability, agility, auditability, autonomy, availability, compatibility, composability, configurability, correctness, credibility, customizability, debugability, degradability, determinability, demonstrability, dependability, deployability, discoverability, distributability, durability, effectiveness, efficiency, evolvability, extensibility, failure, transparency, fault-tolerance, fidelity, flexibility, inspectability, installability, integrity, interchangeability, interoperability, learnability, maintainability, manageability, mobility, modifiability, modularity, operability, orthogonality, portability, precision, predictability, process, capabilities, producibility, provability, recoverability, relevance, reliability, repeatability, reproducibility, resilience, responsiveness, reusability, robustness, safety, scalability, seamlessness, self-sustainability, serviceability, securability, simplicity, stability, standards, compliance, survivability, sustainability, tailorability, testability, timeliness, traceability, transparency, ubiquity, understandability, upgradability, vulnerability, usability…

That’s a long list! And way too long to use as-is. Many of these terms overlap, or are different ways of saying the same thing, or can be considered children of other attributes. There are several more-or-less standard ways of creating hierarchies for all these, and we at Box UK used them as the basis for our own set of categories. We use these as a starting point when discussing NFRs/QARs with our clients, helping guide conversations while still allowing the flexibility to add additional criteria as needed since clients always have their own attributes they need to include. Let’s look through some of these on a case-by-case basis…

Non-functional requirement examples

Availability

In our categories, Availability is a broad type of requirement that includes additional NFRs/QARs such as reliability and resilience.

What is availability / reliability / resilience in non-functional requirements?

This set of NFRs state that the system must be available for use as much as possible, and that downtime must be minimised.

Availability, reliability and resilience can be built into a system in a number of ways, for example by avoiding single points of failure, implementing timeouts and circuit breakers, and carrying out zero-downtime deployments.

Compliance

What is compliance in non-functional requirements?

Non-functional requirements in the compliance category state that software systems must comply with legal and regulatory requirements; auditability is typically included in this category too.

Techniques to build compliance into your development project include avoiding production data in non-production environments (and tracking any instances to aid with debugging, etc.), keeping personal information out of any logs, and addressing regulations such as the “right to be forgotten”, GDPR and any international trade regulations.

Deployability

What is deployability in non-functional requirements?

Encompassing operability and transition attributes, the deployability requirement type is focused on making deployment a straightforward, low-risk, push-button event.

This can be achieved by separating releasing from deploying; releasing should be as simple as enabling a previously-deployed and tested feature. Deployability can be strengthened with a number of supporting approaches including trunk-based development, feature flags, comprehensive test automation, backwards-compatible changes, and automated configuration changes.

Feasibility

What is feasibility in non-functional requirements?

For your software project to be feasible, you must be confident that it’s possible to complete the work in the time and/or budget dictated. For this reason feasibility touches on a number of other QARs, including time-to-market, total cost of ownership, technical knowledge, and migration requirements.

There are a number of ways to assess and safeguard the feasibility of your software engineering project, for example using pre-built plugins, off-the-shelf solutions, managed services and cloud-native functions where appropriate. Ultimately though, meeting this non-functional requirement depends on close collaboration with your development partner, who can advise you of a suitable architecture to meet your various needs.

Maintainability

What is maintainability in non-functional requirements?

A maintainable system must be capable of being maintained cost-effectively over its expected lifetime, and can incorporate additional requirements such as modifiability, configurability, extensibility and interoperability.

In addition to a variety of technical approaches to ensuring maintainability, such as high cohesion / loose coupling, SOLID principles, using standard API formats and clear document interfaces, it’s important to track code and architecture metrics so that you can see where issues may be occurring and improvements needed (I’ll look at metrics further a little later in this post).

Observability

In addition to observability, this type of NFR / QAR includes requirements related to keeping track of your software system, including monitorability, traceability and recoverability.

What is observability / monitorability / traceability / recoverability in non-functional requirements?

All systems with these QARs must be capable of being monitored, even if that option is not currently used; teams must always be able to establish the health of a production system.

Tactics to ensure observability include:

• Correlation IDs generated at receipt of request, passed on to all subsystems and API calls, and included in all logs
• Reporting response status and timing for all API calls
• Centralising logs, with all services and instances logging to a single central location
• Only logging useful information and fixing errors as they are identified
• Implementing third-party monitoring services for crucial areas of the application

Performance

What is performance in non-functional requirements?

Perhaps one of the most common NFRs / QARs, this requirement states that all systems should be designed and built with an acceptable standard of performance as a minimum.

Taking into account areas such as latency, load and resource utilisation, performance can be negatively affected by high numbers of API calls, poor caching procedures, and high-load third-party services. It’s important therefore to focus on these areas when seeking to secure consistently high levels of performance, including using separate work queues to ensure the end-user experience is not affected by any latency issues.

Scalability

What is scalability in non-functional requirements?

Scalability means that the system must be able to accommodate larger volumes (whether of users, throughput, data) over time, and also includes NFRs such as elasticity, which is the ability to scale up and down quickly, as needed.

Today, scalability can be achieved more easily than in the past thanks to modern cloud-based solutions, which have the infrastructure needed to auto-scale according to requirements.

Security

What is security in non-functional requirements?

Particularly important where sensitive information such as personal details or financial data is being handled, security includes other NFRs such as confidentiality and authentication to ensure this information is protected by default.

There are many software engineering tactics that can be employed to safeguard your data such as encrypted integration points, encryption at rest and sanitised input, and it can be built into key processes through the addition of security risk registers and regular reviews/learning opportunities.

Ultimately, what’s most important is that you understand your legal and compliance requirements at the outset (working with an external specialist if necessary), and communicate these clearly to your development team, so that you can work together to put in place any necessary actions to maintain the necessary levels of security.

Testability

What is testability in non-functional requirements?

Covering the levels of test coverage in place, the effectiveness and efficiency of tests, and the quality of testing reporting, the testability quality attribute requirement relates to how confident teams can be that the system will function as intended.

In these cases it’s important that the software testing/Quality Assurance (QA) team are closely involved with the project from an early stage, so that they can advise on the most suitable testing approaches for each feature, as well as for other QARs you may have in place. These approaches can include automated functional tests, integration and contract tests, manual tests, and third-party or bespoke testing tools.

Usability

What is usability in non-functional requirements?

Usable systems are straightforward to use by as many people as possible, whether this is end-users of a website, or administrators and content editors working with a back-end system. Accessibility is another crucial element when considering the usability of the system, particularly if your target audience has specific needs or a low level of digital literacy.

Investing in User Experience (UX) activities is vital to deliver a usable and accessible system, and setting minimum levels of accessibility, for example following the Web Content Accessibility (WCAG) guidelines. Tactics such as creating an interactive style guide, prototyping solutions and conducting usability testing can further support these requirements.

How to build a quality attributes list for your software project

Like your features and functionality specification, the quality attributes / non functional requirements your software needs should be tailored to your own context and goals. They need to be defined and prioritised in the same way functional requirements are, and like functional requirements it’s better if they’re broken down into smaller chunks first.

This is achieved by working through scenarios, and is probably best explained by example. When considering performance for instance, instead of saying “the site must be fast”, break it down into measurable scenarios. For example:

• Under normal circumstances, the home page must be fully rendered within 3 seconds, for 90% of users
• Under heavy load, the home page must be fully rendered within 5 seconds

(Note that you’ll also need to define the terms ‘normal circumstances’ and ‘heavy load’, to support with planning your solution, testing against your NFRs / quality attributes, and validating that they have been met.)

It’s a good idea to facilitate a collaborative discovery workshop to help you establish your specific QARs / NFRs, expand them into scenarios, and prioritise them for development. These workshops should involve all relevant stakeholders from your internal and development teams, so that everyone can understand the business drivers, technical constraints and architecturally significant requirements from the outset. When prioritising your requirements, a 3×3 matrix based on priority against risk can prove useful, to ensure you are targeting your efforts where they’re most needed.

Example priority / risk matrix

It’s also important to put metrics in place so that you can validate how your solution performs against your set QARs, as well as make ongoing improvements as needed. This is easier for some requirements than others, such as the performance example mentioned above, as well as qualities like availability and even usability (for example, “it must be possible for a new user to enter a complete project within 30 minutes without training”).

At the far end, you’ve got attributes such as flexibility, where it can be tough to assign clear metrics. It’s worth spending some time to qualify your requirements however, for example:

• Must be possible for an end user to <make the change> without needing special administration rights, with a clean, usable, drag-and-drop interface
• Must be possible for an admin user to <make the change>, but they need additional training
• Must be possible for a sysadmin to <make the change> by editing a config file
• Must be possible for a developer to <make the change>, but it should be a more-or-less copy-and-paste affair, with no complexity
• Must be possible for a developer to <make the change> but this might involve unconstrained development activity

With this information in place it’s then possible to say where a system sits along that metric, and make informed decisions about the effort involved in getting it to a higher level.

In summary

Whether you think of them as Non-Functional Requirements (NFRs) or Quality Attribute Requirements (QARs), addressing how your software will behave and the demands it will need to deliver against is a vital part of the project planning process. It’s important to make sure you have these discussions with your development team as early as possible so that high-priority requirements can be built into your solution from the outset – a much more cost-effective approach than retrospectively addressing these considerations when the majority of your features, functionality and integrations are already in place.