NFRs Modeling, NFRs Patterns

by Sam Supakkul

Introduction | NFRs patterns and anti-patterns | World Assumptions


Many failures associated with systems and software systems are attributed to the failure to properly deal with non-functional requirements (NFRs), some of which led to serious consequences. For example, insecure TJX's internal systems and networks were compromised in one of the largest credit card theft in history, or the infamous 1992 London ambulance dispatch system that arguably caused loss of life. It is therefore important to build quality into systems, but this task is not easy due to many difficulties that are associated with NFRs. For example, NFRs can be:

To deal with these difficulties, the following are some ideas that can be considered.


NFRs should be defined with a context. An NFR may be thought of as an adjective that needs to modify a noun to be meaningful. For example, safety NFR should be defined with a topic, such as "safety of the crew" or "crew safety" to refer to the need for the system to ensure the safety of the crew or "safety of the spacecraft" or "spacecraft safety" to refer to the need for the system to ensure the safety of the spacecraft, for instance by turning delicate instruments away from geomagnetic storms. However, it should be noted that the notion of "software safety" has not been used to refer to the safety of a software system, but rather the safety of users and environment that may be harmed by the system. For security NFR, it should be defined with a topic to define what precisely should be secure, e.g. "security of an e-commerce web site" or "security of credit card information".

However, NFRs that are defined without topic can be useful as a general piece of knowledge about particular NFRs. For example, security is generally defined in terms of confidentiality, integrity, and avilability NFRs; performance generally refers to either space or time performance. These topic-less NFR definitions may be catalogued and consulted when modeling NFRs in the context of specific topics.


Contradicting definition can be addressed by explicitly clarify an NFR with more specific NFR terms so that the stakeholders can agree upon or even disagree upon so that a more agreeable definition may be defined. For example, the US FISMA law defines information and system security NFR in terms of confidentiality, integrity, and availability NFRs (also known as the CIA Triad in the security community), where confidentiality may be further defined as privacy and proprietary, integrity as authenticity and non-repudiation, and availability as timeliness and reliability. For a different situation such as for systems involving with credit card related transactions, credit card information may be defined in terms of confidentiality of the information.

Contradicting importance can be addressed by explicitly indicating the relative importance or criticality of the NFRs in question for a particular situation. For instance, usability may be assigned to be very critical while security assigned to be critical for an e-commerce website. On the other hand, security may be assigned to be very critical while usability is assigned to be neaturally critical for a military application.


Some NFRs, such as performance, are easier to quantify, for example in terms of transactions per second or response time in seconds. However, such quantitative requirements cannot be guaranteed to be achieveable at all times, thus they still are softgoals in some aspects. On the other hand, some other NFRs, such as security or usability, are harder to quantify. Oftentimes, it may be desirable to rationalize how they are achieved "qualitatively" through reasoning and evidence to illustrate what mechanisms are chosen to achieve the NFRs and why they are more desirable than other alternative mechanisms. Through this kind of reasoning, the stakeholders can determine whether the project has chosen the most desirable course to achieve the NFRs that is based on an acceptable tradeoff among potentially conflicting NFRs.


The objective or goal aspect of the NFRs for the system should be posted and refined until they are agreeable by the stakeholders. The detailed objectives are then used to explore alternative mechnisms, where each may have positive or negative side-effects towards other NFRs.


When alternatives that have both positive and negative contributions towards different NFRs are considered, they should be selected with bias towards NFRs with higher criticality. For instance, for an e-commerce system where usability is more critical than security, ID/password-based authentication may be chosen for the sake of usability, over a more secure mechanism such as fingerprint or token-based authentication; otherwise, it is unlikely that the website would be able to attract on-line customers as it would be too time consuming and inconvenient to first collect biometric samples from the customers before they can make any purchase on-line.

NFRs Patterns and Anti-patterns

To properly deal with the difficulties associated with NFRs during software development, it requires a large amount of knowledge in many dimensions, including domain knowledge, goals-means knowledge, and development knowledge dimensions, as shown in Figure 1.

Figure 1. NFRs Knowledge Dimensions

For the domain knowledge dimension, software engineers need to what an NFR means in general and what it means for a particular domain, organization, or application, as well as what NFRs are relevant and important for a particular domain. For the goals-means knowledge dimension, the engineers need to know what are possible alternative means for achieving a particular NFR and what means are more suitable for a particular domain. Finally, for the development knowledge dimension, the engineers need to know how to represent and model NFRs during requirements engineering to facilitate the collaborations and obtain agreements among stakeholders, and how to map and trace them to other development artifacts such as architectural and detailed design, as well as code and deployment plans.

One way to help alleviate the time and effort needed to acquire such a large amount of knowledge is to capture the knowledge, best practices, and experiences as patterns that can be reused by software engineers as a starting point, as well as capture common mistakes or past failures as anti-patterns for the engineers to learn and avoid. This article attempts to collect some of the patterns so that they can be improved and used as general guidelines for dealing with NFRs.

The following are NFR patterns along the dimensions depicted in Fig. 1. Their content will be gradually added and refined as time permits. They are modeled using the notations from the NFR Framework [book (draft), paper (draft)] and the RE-Tools.


© 2009-2010 Sam Supakkul
Updated Nov. 23, 2009