The devil is in the details.
—Common proverb
Nonfunctional Requirements (NFRs) define system qualities 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.
In contrast, functional requirements are largely expressed in user stories, features, and capabilities. This is where most of the work occurs. Teams build systems that deliver value to the user, and most of the time and effort in solution development are devoted to that goal.
NFRs, however, ensure the usability and effectiveness 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.
One way to think about all the types of requirements that affect a solution’s overall fitness is the ‘FURPS’ categorization described in Managing Software Requirements [5]: Functionality, Usability, Reliability, Performance, and Supportability.
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 (PI), or release. NFRs exist in all backlogs: Team, Program, Solution, and Portfolio.
Proper definition and implementation of NFRs is critical. Over-specify them, and the solution may be too costly to be viable; under-specify or underachieve them, and the system will be inadequate for its intended use. Applying an adaptive and incremental approach to exploring, defining, and implementing NFRs is a vital skill for Agile teams.
NFRs are just as important as functional requirements to system success. NFRs can be considered constraints on new development, in that each eliminates some degree of design freedom for the people who are building the system. For example, SAML-based Single Sign-on (SSO) may be a requirement for all products in a particular suite. In this case, SSO is a functional requirement, while SAML is a constraint.
NFRs can cover a wide range of business-critical issues that are often poorly addressed by functional requirements. As a reminder to system designers, a comprehensive list of such potential NFRs is provided in [1].
NFRs are associated with backlogs at all levels of SAFe, as Figure 1 illustrates.
Because NFRs are significant attributes of the solution that the Agile Release Train (ART) and Value Streams create, their most obvious representation is at the program and large solution levels. System and Solution Architect and Engineering specialists are often responsible for defining and refining these NFRs.
All teams must be aware of the special attributes they’re creating for the system. Accelerating NFR testing, rather than postponing it, helps foster Built-In Quality practices. Teams include the relevant NFRs into their DoD, 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 costs of corrections that occur late in the process can be very high.
Team backlog NFRs can also be important, as they create constraints and performance requirements on the features and the subsystems that emerge. The portfolio backlog may require NFRs as well. This is often the case for cross-system qualities, as in the single sign-on case. Other examples include restrictions on open source usage, security requirements, and regulatory standards. If a specific portfolio-level NFR hasn’t been achieved, it may require Enablers to implement it. NFRs are defined in the ‘epic hypothesis statement’ that is used to describe business and enabler Epics.
NFRs are modeled as backlog constraints in the framework, as illustrated in Figure 2.
Moreover, the SAFe Requirements Model specifies that NFRs may constrain zero, some, or many backlog items. Further, to verify that the system is compliant with the constraint, most NFRs require one or more system qualities tests, as shown in Figure 3.
Many NFRs begin as enablers that need to be addressed. After that, they constrain the system and all new backlog items going forward.
Nonfunctional requirements can have a substantial impact on solution development and testing. NFRs are tricky to specify; it’s easy to go overboard. For example, a statement such as ‘99.999 percent availability’ may increase development effort exponentially more than a statement such as ‘99.98 percent availability.’ Sometimes that exacting level of detail is necessary, but at other times it’s not. Nevertheless, the impact of the NFR must be well understood by those persons who are defining the solution requirements. Similarly, if not given enough thought, physical constraints such as weight, volume, or voltage may cause the solution to be overly complicated and costly.
The Economic Framework of the solution should contain criteria to evaluate NFRs. NFRs should be viewed in the context of trade-offs with costs and other considerations. NFRs also affect Suppliers, as declaring them incorrectly, or without the full trade-off ramifications of the economic framework, could lead to unnecessarily complex and costly systems and components.
It’s also important to reevaluate NFRs regularly. Unlike other requirements, NFRs are persistent constraints on the backlog, rather than backlog items themselves. As a result, they may not always be addressed during PI Planning. NFRs do change during development, however, and it’s important to ensure they are addressed.
Solution Intent is the single source of truth about the solution, as shown in Figure 4. As such, it includes NFRs as well as functional requirements. It also includes links between NFRs, requirements that 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 likely to be unclear and will need to be tested and negotiated with Customers during development. The same goes for NFRs. Some are fixed and well known in advance; others will evolve with the solution.
By imposing constraints, NFRs may affect a wide range of system functionality. Therefore, they’re an important factor to consider in the following circumstances:
Analyzing business epics, capabilities, and features
Planning and building the Architectural Runway
Refactoring to better reflect increasing solution domain knowledge
Imposing DevOps constraints on manufacturing, deployment, support, installation, maintainability, and so on
The tools used to help develop the solution intent provide some mechanisms to establish an economic approach to define and implement NFRs:
Compliance – This is the proof that the system or solution meets regulatory, industry, and other relevant standards and guidelines.
Model-Based Systems Engineering (MBSE) – MBSE can be used to simulate the effect of NFRs and can link to the tests that validate them.
Set-based Design (SBD) – SBD provides different options for achieving NFRs and can guide a range of edge-case testing to support design decisions.
Considering the following criteria helps define NFRs:
Bounded – When they lack bounded context, some NFRs are irrelevant (or even harmful). For example, performance considerations can be critical for the main application but may be unnecessary 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 NFR business drivers and bounded context requires that NFRs have some degree of 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 mandate 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 influence the implementation approach. Implementation should occur in a way that will allow several learning cycles to ascertain the right level of NFR.
All at once – Some NFRs appear as new concerns and will require immediate implementation. For example, a new regulatory rule for derivative trading, if not immediately incorporated into the solution, could take the company completely out of the market or cause a regulatory violation.
Incremental story-by-story path – Teams sometimes have options for addressing NFRs. For example, the need for substantially improved performance can be dealt with over time, one story at a time (as shown in Figure 5).
NFR implementation is also impacted by the way ARTs have been organized. ARTs built around architectural layers will find it challenging to implement and test an NFR in its entirety. By comparison, trains organized around capabilities will find it easier to implement, test, and maintain systemic NFRs.
Using Agile Architecture supports the development of NFRs and helps maintain flexibility as the requirements evolve.
Of course, to verify that a system complies with NFRs, it must be tested. Testing NFRs is most easily viewed from the perspective of the four Agile testing quadrants, as shown in Figure 6 [2, 3].
Quadrant 4, ‘system qualities tests,’ is the home of most NFR tests. Due to their scope and importance, NFR tests often require collaboration between the System Team and the Agile Teams. To prevent technical debt, teams should automate testing wherever possible so that these tests can be run continuously, or at least on demand.
Over time, however, the increasing number of regression tests, even when automated, may consume too much processing time and too many resources. Even worse, it can mean that NFR testing may be practical only on occasion or only with the use of specialty resources or personnel. To ensure practicality and continuous use, teams often need to create reduced test suites and test data, as illustrated in Figure 7.
Figure 7. Collaboration with the system team and Agile teams to create a more practical NFR testing strategy
Although partial testing sounds less than ideal, it can be beneficial in increasing system quality:
When teams can apply reduced test suites locally, they may spot inconsistencies in the test data or the 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 improve continuously.
Teams gain a practical understanding of the impact of NFRs, which helps improve estimating of business and enabler features.
Even so, in some cases, the environment where the NFRs can be tested may not be available on a daily basis (e.g., field testing of vehicle guidance software). In these instances, the following approaches can be used [4]:
Using virtualized hardware
Creating simulators
Creating similar environments
In all cases, efficiently testing NFRs requires some thought and creativity. A lack of NFR testing, in contrast, may increase the risk of substantial technical debt or, worse, system failure.
LEARN MORE
[1] https://en.wikipedia.org/wiki/Non-functional_requirement.
[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[3] Crispin, Lisa, and Janet Gregory. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009.
[4] Larman, Craig, and Bas Vodde. Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.
[5] Leffingwell, Dean, and Don Widrig. Managing Software Requirements: A Use Case Approach (2nd ed.). Addison-Wesley, 2003.
