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 achieve non-functional requirements (NFRs), many of such failures have led to sometimes real-life tragic consequences. For example, insecure TJX's internal systems and networks have led to the largest credit card theft incident in history, or the infamous 1992 London ambulance dispatch system has arguably led to loss of life. It is important to build quality into systems, but this task is not easy due to many difficulties in dealing with NFRs because NFRs can be:
Some ideas might be helpful in dealing with these difficulties.
When modeling NFRs for a system, they should be defined with a context. Think of NFRs as adjectives that need to modify nouns to be meaningful. For example, for safety NFR, it should be defined with a topic, such as "safe users" or "safe system". For security NFR, it should be defined with a topic indicating what should be secure, e.g. "secure e-commerce web site" or "secure credit card information".
However, NFRs modeled without topic are also useful, for example, to capture general knowledge about particular NFRs. For example, performance generally refers to either space or time aspects without having to mention a topic. This general knowledge provides a general framework for what we should be concerned with when dealing with performance for a specific system. For example, when supplying a topic into a discussion about the performance of an ambulance dispatch system, the general knowledge provides us with alternatives to decide whether we should be concerned with space or time aspects, which is most likely to be the time aspect in this case.
Contradicting definition can be addressed by explicitly clarify an NFR with more specific NFRs for the stakeholders or organizations in question. For example, explicitly define that security of a particular system refers to confidentiality, integrity, and availability of the system (also known as CIA 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, explicitly define security of credit card information as 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. Some have used ranking order, for example, "1. availability, 2. confidentiality, 3. integrity, 4. usability" or "1. confidentiality, 2. integrity, 3. availability, 4. usability". Some others have used categories, for example, "very critical: availability, critical: important, integrity, neutral: usability".
Some NFRs, such as performance, are easier to quantify, for example 100 transactions/second or 8 seconds response time (although such quantitative requirements cannot be achieved 100% of the time). For some other NFRs, such as security or user friendliness, are harder to quantifier. For those NFRs whose achievement is subjective need to be achieved "qualitatively", which means its achievement is determined by ways of reasoning and evidence that are acceptable to the stakeholders. For example a system is considered sufficiently secure if the stakeholders agree that using ID/password is sufficient for authenticating customers making purchases on an e-commerce web site, or a system is considered sufficiently user friendly if context sensitive online help with live chat are provided. If the means are not acceptable to the stakeholders, alternative or additional means should be explored and selected until they are acceptable. In summary, many NFRs are achieved by how they achieved and whether the means to achieve them are proven and acceptable to the stakeholders.
NFRs are not achieved by accident. They need to be explicitly identified as goals that are traceable to explicitly defined means for achieving them, with rationale supporting those decisions as to why they are considered sufficient. Those chosen means should then be traceable to functional requirements, and subsequently to architecture and design.
Means for achieving some NFRs could provide synergetic results, for example, using load balanced computers clustering not only helps with performance, but also with availability as the system is still available when a computer in the cluster goes down. On the other hand, achievement means for some other NFRs provide conflicting undesirable results, for example, face or retina recognition would make the system more secure, but would also be more costly to implement and operate, or could drive away potential customers who are concerned with the privacy of their biometric information. The conflicting NFRs and their relative criticality or importance should be used as selection criteria for selecting means favoring more critical NFRs with acceptable negative consequences toward less critical NFRs.
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.
When evaluating whether some means sufficiently achieve the NFRs, we could use a qualitative reasoning such as a goal-oriented reasoning provided by the NFR Framework. For example, if security is defined as confidentiality, integrity, "and" availability (i.e. CIA), security is considered achieved if "all" of the CIA are achieved. On the other hand, if performance is defined as time-performance "or" space-performance, performance is considered achieved if "either" time or space performance is achieved. There are other guidelines for other concepts in NFRs modeling. However, each guideline may be treated differently based on the world assumption (closed world assumption or open world assumption) used for the evaluation. More detailed discussion on this topic is available here.
© 2009 Sam Supakkul
Updated June 6, 2009