What are Nonfunctional Requirements?
Nonfunctional requirements or in short abreviation - NFRs, describe system attributes such as security, reliability, maintainability, scalability, and usability. These requirements cannot be counted as functional as they are around the product in a more higher level.
There can also be constraints or restrictions on the design of the system (in which they may be referred to as design constraints). These requirements are just as critical as the functional features and user stories, as they assure the usability and efficiency of the entire system. Some calls the NFRs as - usability reliability interoperability scalability...
Failing to meet any one of the NFRs can result in systems that do not meet internal business, user or market needs, or mandatory requirements that are imposed by regulatory or standards agencies.
NFRs and Agile Analysis
By imposing such constraints, NFRs may impact a wide scope of system functionality and therefore, they are an important factor in Agile analysis.
Specifically, the following activities must explicitly take NFRs into consideration:
- Business Epic and Business Feature analysis
- Planning and building Architectural Runway; analyzing prospective Architectural Features and Architectural Epics
- Refactoring models to better reflect increasing solution domain knowledge
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 one or two orders of magnitude more than "99.999% availability" requires. Is the extra effort worth an additional eight hours of uptime per year?
- Testable - NFRs must be stated with objective, measurable and testable criteria, because, if you can't test it, you can't ship it.
Testing NFRs
Testing NFRs is most easily viewed from the perspective of the four agile testing quadrants as reflected in the bellow image - 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. For automatic REST API's testing you can use RestCase, the tests will be available to run continuously or on demand depends on your testing needs.
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:
- 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.
The most important thing so understand is that testing non functional requirements is crucial!!!
NFRs must be stated with objective, measurable and testable criteria, because, if you can't test it, you can't ship it.