The devil is in the details.

—Common proverb

Nonfunctional Requirements

Nonfunctional Requirements (NFRs) are system qualities that guide the design of the solution and often serve as constraints across the relevant backlogs.

As opposed to functional requirements, which specify how a system responds to specific inputs, nonfunctional requirements are used to specify various system qualities and attributes, such as:

  • Performance: How fast a system should respond to requests
  • 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

NFRs are persistent qualities and constraints typically revisited as part of the definition of done (DoD) for each Iteration, PI, or release. NFRs influence Teams, ART, Solution Train, and Portfolio backlogs.


Nonfunctional Requirements (NFRs) are intended to specify ‘system qualities,’ various systems attributes that are not directly related to their functionality. These attributes do not tell what the system does but how well it does it. In contrast, functional requirements are expressed as Capabilities, Features, and Stories, which define what the system does in response to various inputs. Although they may seem subtle, NFRs are just as vital to system success. Failing to meet NFRs can result in systems that do not meet the needs of the business, Customers, market, or applicable regulations or standards. In some cases, non-compliance can cause significant issues, such as cost, recalls, privacy, security, safety risk, legal exposure, and more.

Proper identification and implementation of NFRs are critical. The solution may be too costly or unviable if they are over-specified. If underspecified, the system may be inadequate for its intended use. No matter the scope of the system, an adaptive and incremental approach to exploring, defining, and implementing NFRs is a vital skill for Agile teams.

NFRs Constrain Backlogs

NFRs are associated with backlogs throughout SAFe, as Figure 1 illustrates. However, they are not backlog items. Backlog items come and go as they are implemented. NFRs are persistent constraints on the design and development of the system. For example, consider a requirement such as ‘all products in the suite require SAML-based single sign-on.’ While single sign-on is a functional requirement, the selection of SAML (Security Assertion Markup Language) is a constraint. Any new backlog item requiring sign-on functionality must include SAML in its acceptance criteria.

Figure 1. NFRs occur with all backlogs in SAFe
Figure 1. NFRs occur with all backlogs in SAFe

Because NFRs are significant attributes of the solution that the Agile Release Train (ART) and Value Streams create, they influence the backlogs of Teams, ARTs, and Solution Trains. The portfolio backlog may also require NFRs, typically for cross-solution qualities (like regulatory standards). Agile Teams use Built-In Quality practices to accelerate NFR testing and make it continuous. Teams include the relevant NFRs in their DoD, use them as constraints on local design and implementation decisions, and take responsibility for NFR testing.

As illustrated in Figure 2, NFRs are modeled as backlog constraints.

Figure 2. NFRs are associated with backlogs and constrain the design of the system
Figure 2. NFRs are associated with backlogs and constrain the design of the system

NFRs may constrain any backlog items as described in the SAFe Requirements Model. Most NFRs require one or more system quality tests (ideally automated) to know that the system complies with the constraint.

Types of NFRs

Generally speaking, there are two types of NFRs: Systems Qualities and Design Constraints. Each is described in the following sections.

System Qualities

NFRs are often architecturally significant requirements that describe the system’s various quality attributes (‘ilities’). They are as critical or even more critical than functional requirements that pass through the backlog. Working with Product and Solution Management and the teams, System and Solution Architects are often responsible for identifying and establishing NFRs. Figure 3 shows a relatively comprehensive list of NFR sources to consider during development.

Figure 3. Examples of system attributes that may be subject to NFRs
Figure 3. Examples of system attributes that may be subject to NFRs [1]

Design Constraints

In addition to these systems’ ilities,’ another type of NFR can substantially impact system design. There are ‘design constraints,’ which limit freedom of choice for some design options. Examples of design constraints include:

  • The system design shall use hardware components only from approved vendors (cyber physical system)
  • Single sign-on shall use the SAML protocol
  • Open-source components must be approved in advance by legal
  • All user data shall be encrypted and stored in the corporate database
  • Java, Python, and Javascript programming languages are approved for general use. Any other development languages must be approved in advance.

Of course, in support of innovation, these should be as few as possible and reflect centralized decisions that provide economies of scale, security, or other critical aspects of the solutions set.

The functional requirements, NFRs, and design constraints define the system’s scope and quality. By understanding both NFRs and design constraints, teams can make more informed decisions about the system’s design, ensuring that it meets the needs of the stakeholders while adhering to any limitations.

Specifying NFRs

Solution Intent includes NFRs and functional requirements and plays a crucial role in understanding the economics of fixed versus variable solution intent.

Solution intent can also provide traceability links between NFRs, other work items they impact, and tests to verify them. NFRs play a crucial role in understanding the economics of fixed versus variable solution intent (Figure 4).

Figure 4. NFRs are captured in solution intent
Figure 4. NFRs are captured in solution intent

Similar to other requirements, some NFRs are fixed and well-known in advance (ex: the adventure ride holds twelve people); others are variable (acceleration at maximum vehicle load shall be no less than x Gs) and will be refined over time.

Like all other requirements, NFRs must be quantified for clarity to ensure everyone clearly understands the goal. Figure 5 provides an example of defining an NFR using some of the properties discussed in Figure 3.

  • Step 1 defines the NFR’s quality, including its name, scale, and method of measure.
  • Step 2 quantifies the NFR’s measurable values, including the current measured value (baseline), the value to achieve (target), and the value that becomes unacceptable (constraint)

Figure 5 includes an example of specifying an NFR for an autonomous vehicle’s speed limit detection efficiency. On average, users currently set the speed manually at .1 times per mile, overriding the automated solution. New system functionality should improve that to .01 times per mile, but during implementation should never fall below .15 times per mile.

Figure 5. Steps and an example for specifying NFRs
Figure 5. Steps and an example for specifying NFRs

The following criteria help define NFRs:

  • Bounded – NFRs must have a specific bounded context. For example, an airplane’s flight control reliability should be much higher than the infotainment system.
  • Independent – NFRs should be independent of each other so that they can be evaluated and tested without consideration of other system qualities.
  • Negotiable – Negotiability of NFRs is a crucial aspect of economic performance.
  • Testable – NFRs must be testable with objective measures.

NFRs Impact Solution Development

Nonfunctional requirements can have a substantial impact on solution development and testing. As such, Architects and developers should use caution when specifying them. For example, a statement like “99.999 percent availability” may sound great but increases development effort by 10X more than “99.98 percent availability.” The impact of the NFR must be well understood by those defining requirements.

In many cases, applying a Set-Based Design can keep options open by specifying NFRs as a range (for example, 99.98 .. 99.999). Teams explore the solution space and gain additional knowledge that leads to better economic decisions. There may indeed be value in 99.999 reliability. Or lower reliability may be more cost-effective with adjustments made elsewhere in the system’s operational environment. Physical constraints, such as weight, volume, or voltage, impact solution development similarly. Deferring decisions to understand costs and value better often leads to improved economics.

The solution’s Economic Framework  (Figure 6) helps provide criteria to evaluate NFRs. NFRs should consider trade-offs with costs and other considerations. NFRs also affect Suppliers, and their knowledge and concerns should inform NFR specifications and the economic framework.

Figure 6. Five variables guide economic trade-off decisions for NFRs
Figure 6. Five variables guide economic trade-off decisions for NFRs

NFRs may require additional work, either now or in the future. Sometimes they must be implemented all at once. In other cases, teams can take an incremental approach.

  • All at once – Some NFRs appear as new concerns and will require immediate implementation. For example, regulatory changes may require the organization to respond within the specified time constraints or risk being in violation.
  • Incremental story-by-story path – At other times, the teams have options. For example, Agile Teams can improve performance incrementally, one story at a time.

Implementation should occur in a way that will allow several learning cycles to determine the right level of NFRs. The structure of an ART can also impact the implementation of NFRs. For example, ARTs organized around architectural layers will find it challenging to implement and test NFRs. Trains with mostly stream-aligned teams designed will find it easier to implement, test, and maintain NFRs. Applying Agile Architecture practices supports the development of NFRs and helps maintain flexibility as the requirements evolve.

Testing Nonfunctional Requirements

XP advocate and Agile Manifesto [3] co-author Brian Marick helped pioneer Agile Testing and a testing matrix, which provides a taxonomy for organizing tests. This approach was further developed in Agile Testing [4] and extended to scaling in Agile Software Requirements [4, 5]. Figure 7 describes the latest matrix [6] with guidance on what to test and when.

Quadrant 4 of the Agile Testing Matrix in Figure 7 outlines system quality tests to verify the system meets its NFRs. NFRs often require a suite of specialized automated testing tools (for example, load and performance testing tools) or internal solution telemetry to validate compliance.

Figure 7. NFRs are in quadrant 4 of the Agile testing matrix
Figure 7. NFRs are in quadrant 4 of the Agile testing matrix

Due to their considerable scope and tooling requirements, testing NFRs may require the help of the System Team. Since any system changes can violate conformance with NFRs, these tests must be run continuously, or at least whenever it’s practical. To support this built-in quality, teams should automate testing NFRs to run continuously with other tests or on demand when needed.

Learn More

[1] Non-functional requirement. Wikipedia. Retrieved October 13, 2023, from

[2] Gilb, Tom. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Butterworth-Heinemann, 2005.

[3] Manifesto for Agile Software Development.

[4] Crispin, Lisa, and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley Professional, 2009.

[5] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.

[6] Gregory, Janet, and Lisa Crispin. More Agile Testing: Learning Journeys for the Whole Team. Addison-Wesley Professional, 2014.

Leffingwell, Dean, and Ryan Shriver. Nonfunctional Requirements (System Qualities) Agile Style. Agile 2010.

Last update: 13 October 2023