The devil is in the details
Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs.
Nonfunctional Requirements (NFRs, or system qualities) are just as critical as functional Epics, Capabilities, Features, and User Stories. They ensure the usability and efficacy of the entire system. Failing to meet any one of them can result in systems that fail to satisfy internal business, user, or market needs, or that do not fulfill mandatory requirements imposed by regulatory or standards agencies.
NFRs are persistent qualities and constraints that, unlike functional requirements, are typically revisited as part of the Definition of Done (DoD) for each Iteration, Program Increment, or Release. NFRs exist at all SAFe backlog levels: Team, Program, Large Solution, and Portfolio.
Definition and implementation of NFRs is critical or the system builder. Over-specify them and the Solution may be too costly to be viable; under-specify or under-achieve them and the solution will be inadequate for its intended use. An adaptive and incremental approach to exploring, defining, and implementing NFRs is a key skill of the successful Lean-Agile system builder.
Traditionally, one way to think about all the types of requirements that affect a Solution’s overall fitness for use has been the acronym “FURPS,” which is a traditional requirements categorization for Functionality, Usability, Reliability, Performance, and Supportability . Functional requirements are largely expressed in User Stories and in Features and Capabilities. This is where most of the work occurs: Teams build systems that deliver functional value to the user, and a majority of the time and effort in solution development is devoted to that functionality.
“FURPS” is the placeholder for Nonfunctional Requirements. Though they may be a bit more subtle, NFRs are as just as important to system success as are functional requirements. NFRs can be considered constraints on new development, in that each eliminates some degree of design freedom on the part of those building the system. For example: “We need to implement SAML-based single sign-on for all products in the suite” (SSO is a functional requirement; basing the technology on SAML is a constraint). NFRs can cover a wide range of business-critical issues that are not well addressed by functional requirements. As a reminder to system designers, a fairly comprehensive list of such potential requirements is described in .
NFRs Occur at All Levels
Nonfunctional requirements are associated with backlogs at all four configurations of SAFe, as Figure 1 illustrates.
Because NFRs are significant attributes of the solution that the Agile Release Train and Value Streams create, the most obvious representation of NFRs are at the Program and Large Solution Levels. System and Solution Architect and Engineering are often responsible for defining and refining these NFRs.
All teams must be aware of these special attributes of the system they are creating. This helps foster Built-in Quality practices by accelerating NFR testing, rather than postponing it. Teams include the relevant NFRs into their Definition of Done, use them as constraints on local design and implementation decisions, and take responsibility for some level of NFR testing on their own. Otherwise, the solution may not satisfy key NFRs, and the cost of correction can be very high when it occurs late in the process.
In addition, Team Level NFRs can also be important, as they create constraints and performance requirements on the features and subsystems they create.
The Portfolio Level may require certain NFRs as well. This is often the case for inherently cross-system qualities, like the single sign-on example. Other examples include restrictions on open source usage, common security requirements, regulatory standards, and more. If a specific portfolio level NFR is not yet achieved, it may require architectural Enablers to implement it. In other cases, portfolio level NFRs may naturally appear on business and enabler Epic success criteria.
NFRs as Backlog Constraints
In SAFe, NFRs are modeled as “backlog constraints,” as is illustrated in Figure 2.
More technically, the SAFe Requirements Model specifies that NFRs may constrain zero, some, or many backlog items. Further, in order to know that the system is compliant with the constraint, most NFRs require one or more system qualities tests, as is illustrated in Figure 3.
Many NFRs begin their lives as enablers that need to be addressed. Thereafter, they constrain the system and all new backlog items going forward.
The Systemic and Economic Impact of NFRs on Solution Development
Nonfunctional requirements can have major impact on solution development and testing. NFRs are tricky to specify, and it’s easy to go overboard. For example, a statement like “99.9999% availability” may increase development effort by one or two orders of magnitude more than “99.999% availability.” Sometimes that’s necessary and other times it’s not, but the impact of the NFR must be well understood by those writing the specifications. Similarly, physical constraints such as weight, volume, or voltage, if not given enough thought, may cause the solution to be overly complicated and too costly.
The Economic Framework of the solution should hold criteria to evaluate the extent to which NFRs should be taken as a trade-off with costs and other considerations. Suppliers are likewise impacted by NFRs, and declaring them incorrectly or without the full trade-off ramifications of the economic framework might lead to unnecessarily complex and costly systems and components.
It is also important to reevaluate NFRs regularly. Unlike other requirements, NFRs are persistent constraints on the backlog, rather than backlog items themselves, and so they may not always come up during PI Planning. But nonfunctional requirements do change during development, and system builders must be well aware.
NFRs and Solution Intent
Solution Intent is the single source of truth about the solution, and as such it includes NFRs as well as functional requirements. It also includes links between NFRs, requirements they impact, and tests used to verify them. NFRs play a key role in understanding the economics of fixed versus variable solution intent.
Early on, some of the functionality is not clear and will need to be tested and negotiated with Customers during development. The same goes for NFRs—some are fixed and well known up front, while others will evolve with the solution.
By imposing constraints, NFRs may impact a wide scope of system functionality. Therefore they are an important factor in Agile analysis:
- Analyzing business epics, capabilities, and features
- Planning and building the Architectural Runway
- Refactoring to better reflect increasing solution domain knowledge
- Imposing DevOps constraints by manufacturing, deployment, support, installation, maintainability, etc.
The tools used to help develop solution intent provide some mechanisms to help establish an economic approach to defining and implementing NFRs.
- Agile Architecture – A solid intentional architecture supports development of NFRs and helps maintain flexibility as they change
- Model-Based Systems Engineering – Models can be used to simulate the effect of NFRs and can link to the tests that validate them
- Set-based Design – SBD provides different frames for achieving NFRs and can guide a range of edge-case testing in support of design decisions
Defining NFRs is assisted by consideration of the following criteria:
- Bounded. Some NFRs are irrelevant (or even impairing) when they lack bounded context. For example, performance considerations can be extremely important for the main application but irrelevant (or too expensive) for administration and support applications.
- Independent. NFRs should be independent of each other so that they can be evaluated and tested without consideration of or impact from other system qualities.
- Negotiable. Understanding the NFR business drivers and bounded context mandates negotiability.
- Testable. NFRs must be stated with objective, measurable, and testable criteria, because if you can’t test it, you can’t ship it.
Many NFRs prescribe that some additional work be done—either now or in the future—to satisfy them. Sometimes the NFR must be implemented all at once; at other times the teams can take a more incremental approach. The trade-offs described in the economic framework should impact the implementation approach. Implementation should be built in a way that will allow several learning cycles to ascertain the right level of NFR.
- All at once. Some NFRs appear as new, immediate concerns and just have to be done now. For example, a new regulatory rule for derivative trading, if not immediately accommodated, could take the company completely out of the market or cause a regulatory violation.
- Incremental story-by-story path. At other times the teams have options. For example, the need for “substantially improved performance” can be dealt with over time, one story at a time, as Figure 5 illustrates.
NFR implementation is also impacted by the way ARTs have been organized. ARTs built around architectural layers will find it very hard to implement and test an NFR in its entirety. ARTs organized around capabilities will find it easier to implement, test, and maintain systemic NFRs.
Testing Nonfunctional Requirements
Of course, in order to know that a system meets NFRs, it must be tested against them. Testing NFRs is most easily viewed from the perspective of the four Agile testing quadrants, as reflected in Figure 6 [2, 3].Quadrant 4, System Qualities Tests, is the home of most NFR tests. Due to their scope and criticality, NFR testing often requires collaboration between the System Team and the Agile Teams. Wherever possible, teams should automate so that these tests can be run continuously, or at least on demand, to help prevent the growth of unexpected technical debt.
Over time, however, the accumulated growth of regression tests, even when automated, may consume too much resource and processing time. Worse, it can mean that NFR testing may be practical only on occasion, or only with specialty resources or personnel. In order to ensure practicality and continuous use, teams often need to create reduced test suites and test data, as is illustrated in Figure 7.
Though “partial testing” sounds less than ideal, it can actually be beneficial in increasing system quality:
- When teams are able to apply reduced test suites locally, they may spot inconsistencies in the test data or testing approach
- Teams may create new and unique tests, some of which may be adopted by the System Team to help build the larger set
- Testing infrastructure and configurations will likely be continuously improved
- Teams gain a practical understanding of the impact of NFRs, which helps improve estimating of business and architectural features
Even so, in some cases the environment where the NFRs can be tested may not be available on a daily basis (example: field testing of vehicle guidance software). In these cases, the following approaches  can be used:
- Using virtualized hardware
- Creating simulators
- Creating similar environments
In all cases, efficiently testing nonfunctional requirements requires some thought and creativity. A lack of NFR testing, on the other hand, may increase the risk of substantive technical debt or, worse, system failure.
Learn More https://en.wikipedia.org/wiki/Non-functional_requirement  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Crispin, Lisa and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009.  Larman, Craig and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.  Leffingwell, Dean and Don Widrig. Managing Software Requirements: A Use Case Approach (second edition). Addison-Wesley, 2003.
Last update: 20 April 2016