I was a functional addict.

— James Taylor

 

 

 

Nonfunctional Requirements Abstract

Nonfunctional requirements (NFRs, or system qualities) describe system attributes such as security, reliability, maintainability, scalability, and usability (often referred to as the “ilities”). They can also be constraints or restrictions on the design of the system (in which they may be called design constraints). These requirements are just as critical as the functional features and user stories, as they assure the usability and efficacy of the entire system; failing to meet any one can result in systems that do not meet internal business, user or market needs or requirements that are imposed by regulatory or standards agencies.

Nonfunctional Requirements are persistent qualities and constraints, and, unlike functional requirements, are typically revisited as part of the “Definition of Done” for each iteration or Release (PSI). However, in the event that the system does not meet an NFR, that requirement may spawn new backlog items, such as refactors and performance enhancements. From a testing perspective, NFRs are only testable at the system level through system quality tests. Many NFRs require specialty tools (example: “handle 1,000 concurrent users without performance degradation”).

In the SAFe Framework, NFRs exist at both the Team and the Program Level. A Program Level NFR may be broken down into more granular Team Level NFRs, or a Team Level NFR may only apply to a team or a subset of teams.

Details

Types of Nonfunctional Requirements

Traditionally, one way to think about all the types of requirements that affect overall fitness for use has been the acronym FURPS, which is a requirements categorization for Functionality, Usability, Reliability, Performance, and Supportability (see Ref [1]). Functional Requirements are largely expressed in our user Stories and Features. “URPS” is the placeholder for NFRs. Though they may be a bit more subtle, NFRs are as just as important to system success as are functional requirements.

In one perspective, these items can be considered to be 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 it on SAML is a constraint).

Figure 1. Examples of Nonfunctional Requirements (see Ref 1)

 

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 Figure 1 below:
NFRs as Backlog Constraints

Figure 2. A backlog with backlog constraints in the Big Picture

In SAFe, we consider NFRs to be backlog constraints that may be applicable to Team and Program Backlogs as is illustrated in Figure 2.
As we have modeled it in the SAFe Requirements Meta Model, specific NRS may constraint zero, some or many backlog items. 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.

Figure 3. Association between backlog items, nonfunctional requirements and system qualities tests

NFRs and Agile Analysis

By imposing such constraints, NFRs may impact a wide scope of system functionality and therefore, they are in important factor in Agile Analysis. Specifically, the following activities must explicitly take NFRs into consideration:

Specifying NFRs

Properly defining NFRs requires 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 be 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 or impact of other system qualities.
  • Negotiable. Understanding the NFRS business drivers and bounded context mandates negotiability. Simple statements like “99.9999% availability” may increase effort by an order of magnitude more than “99.999% availability”. Is the extra 10x effort worth an additional eight hours of uptime per year? If so, so be it, otherwise……
  • Testable. If you can’t test it, you can’t ship it, so NFRS must be stated with objective, measurable and testable criteria.

Implementation Approaches

NFRs prescribe that some work be done (either right now, or in the future) to satisfy them. Sometimes the NFR must be implemented all at once; other times the teams can take a more incremental approach:

  1. All-at-once. Some NFRs appear as new, immediate, architectural features, and theoretically negotiable or not, you just have to do them 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.
  2. Incremental story-by-story path. Other times the teams have options. For example the need for “substantially improved performance” can be dealt with overt time, one story at a time, as Figure 4 illustrates.

Figure 4. Incremental scenario of introducing an NFR to the system.

Testing Nonfunctional Requirements

Figure 5. Agile Testing Quadrants. (Adapted from Ref 1 & 2)

Testing NFRs is most easily viewed from the perspective of the four agile testing quadrants as reflected in Figure 5 (see Ref [1 & 2]).
Quadrant 4, Systems Qualities Tests, is the home of most NFR tests. Due to their scope and criticality, testing NFRs often requires collaboration between the System Team and the agile teams, as fast and reliable testing speeds development. Wherever possible, teams should automate so that these tests can be run continuously, or at least on demand, so as to help prevent the growth of unexpected technical debt.

Figure 6. Collaboration of the System Team and Agile Teams to create a more practical NFR testing strategy

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 assure practicality and continuous use, teams may often need to create reduced test suites and test data, as is illustrated in Figure 6.
Though the above may appear to be less than idea, 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 adopted by the system team and 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 business and architectural features estimating

Even then however, in some cases the environment where the NFRs can be tested may not be available for the teams on daily basis (example: field testing of vehicle guidance software). In these cases, the following approaches can be used (Ref [3)]:

  • Using virtualized hardware
  • Creating simulators
  • Creating similar environments

In all cases, efficiently testing nonfunctional requirements requires some thought and creativity, as otherwise high-cost heavyweight tests may increase the risk of substantive technical debt, or worse, system failure.

Learn More

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

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

[3] Larman, Craig & Vodde, Bas. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010.

 

Last update 15 January, 2013

© 2010-2013 Leffingwell, LLC. All rights reserved.