___

Introducing the new SAFe Big Picture and enhanced framework articles LEARN MORE

Framework About Blog Read More SAFe Training

ENGLISH (US)

“ The devil is in the details.

—Common proverb

Nonfunctional Requirements
Definition: 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.
Details
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

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.

Nonfunctional Requirements

Single sign-on shall use Security Assertion

Markup Language (SAML)

The response time for book search shall be

Flexible Search under 200 milliseconds

The sales portal shall be available to users

Ajax Spike 99.98% of the time every month during
NFRs constrain eastern time business hours (09:00 to 18:00).
Shopping Cart backlog items
The payment gateway shall use Bill.com to
process transactions.
Purchase by
Credit Card The profile shall use 128-bit AES encryption.
The password shall use 256-bit AES
encryption.
NFRs
Book detail shall be compatible with the
JAWS screen reader.
© Scaled Agile, Inc.

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

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

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

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 So tware 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

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 https://en.wikipedia.org/wiki/Non-functional_requirement
[2] Gilb, Tom. Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and So tware Engineering Using Planguage.
Butterworth-Heinemann, 2005.
[3] Manifesto for Agile So tware Development. http://AgileManifesto.org/
[4] Crispin, Lisa, and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley Professional, 2009.
[5] Leffingwell, Dean. Agile So tware 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

The information on this page is © 2010-2024 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written
permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.

Framework Training Content & Trademarks Scaled Agile, Inc

Download SAFe Posters & Graphics Course Calendar FAQs on how to use SAFe content and Contact Us
trademarks
Blog About Certification 5400 Airport Blvd., Suite 300
Permissions Form Boulder, CO 80301 USA
Become a Trainer
Usage and Permissions
Business Hours
Weekdays: 9am to 5pm
Weekends: CLOSED

© 2024 Scaled Agile, Inc. Get News Terms of Use Privacy Policy Code of Conduct Remote Training Policy