Do Software Architectures Meet Extra-Functional or Non-Functional Requirements?

Should our favorite “-ilities” and miscellaneous design/decision drivers be filed under “Non-Functional Requirements” or “Extra-Functional Requirements”? The two editors of IEEE Software Insights do not agree. Read their arguments and decide yourself.

Context

This post has its roots in a somewhat heated, half-serious terminology debate between us¹ when we reviewed a submission to Insights recently, our practitioner and experience report column in IEEE Software.

In requirements land, features aka functional requirements specify “what” a system is supposed to do (on various levels of refinement and elaboration, for instance identified with user stories and/or elaborated with use cases). And then there is all the rest:

1. The payment requests made during checkout in the (fictitious!) online shop “StayHomeStaySafe.com” should complete in less than three seconds in 80% of the cases.
2. Our software should be highly maintainable and evolvable.
3. Due to an Enterprise License Agreement, the relational database management system shall be “TRM Server Version 42.1” from “Delphi Systems”.
4. Apache 2 and Eclipse are our white-listed open source licenses; the usage of software licensed differently required explicit written approvals by project-external parties including the company-wide architecture board and the legal department.
5. The application has to run on existing hardware natively; the operating system must be Ubuntu 16.04.1 LTS. Level 1 and 2 support and systems management will be provided by an already existing (fictitious!) service center “CantReproduceNeedMoreInfo Ltd.”.

What is the most adequate generic term for such “how” requirements and decision drivers?

Olaf: The term Non-Functional Requirement (NFR) has been used for a long time.

Cesare: Extra-Functional Requirements (EFR) is the better term.

Let’s see whether one of us can convince the other to swap one character in his TLA portfolio, or whether there is a place for both terms. We will exchange arguments in a point-counterpoint style.

Qualities and Constraints: Not Much in Common

Olaf: Many existing methods and speakers use the term NFR, including Peter Eeles from IBM, Ruth Malan and Dana Bredemeyer and SAFe. In my blog post introducing the Design Practice Repository (DPR), I introduce NFRs as this: “quality attributes certainly are included, but NFRs can also be constraints not related to quality at all”.

The five examples above show how diverse the NFR space is; in another post on this blog, I define 5+2 criteria for the architectural significance of such requirements. In the absence of any strong defining semantics, I do not have a problem with defining by exclusion and using the prefix “non” (which I usually avoid, due to its lack of precision).

Qualities and Constraints: Beyond but Not Functional

Cesare: Wait! A requirement for something to be non-functional is a requirement for it not to work, which may be exactly what should happen under some circumstances. So the extra-functional formulation is the more appropriate one.

Olaf: Extra-functional sounds like an amplification to me, like “super-functional” or “über-functional”, which clearly is counter-intuitive (where are the qualities?). “This is an extra-hard problem” does not come across as “easy to solve” to me. Even worse, “extra” leaves me with a “free skating” impression, but meeting software quality requirements certainly is a duty/liability, not an option.

And I’d use “dys-functional” if I ever had to refer to a requirement for something not to work.

Cesare: Dys-functional implies that it doesn’t work properly, while if something is non-functional it simply doesn’t work at all.

Let me give an example. During the ongoing pandemic, online supermarkets are usually overloaded due to their limited capacity. To deal with this, they open up delivery slots gradually and do not accept orders unless customers can reserve slots in advance. Once it happened to my surprise: I found lots of available slots and I could get my order submitted, only to discover a few days later that the order had been cancelled and refunded. I received an apology letter stating: “due to the peak in demand, our order submission system should have been non-functional”.

So here we can see that the online supermarket only scales up to its capacity (two extra-functional requirements) and that when full, it should stop accepting orders (a non-functional requirement).

Olaf: Now I am confused, are you saying that both EFRs and NFRs should be specified? I’d say that “stop accepting orders when condition … holds” is just yet another functional requirement (one about a “rainy day” scenario). When working with Quality Attribute Scenarios to elicit NFRs, for instance, you can specify operating conditions under “environment” and the behavior under “response”. No need for an extra term!

Cesare: I never said that you should not use the term NFR. The example is meant to illustrate that requirements can exist for a system to be non-functional – like you say, under certain conditions. Would you rather classify the scenario “when it rains, stop working” as a functional requirement or as a requirement for the system to be non functional under a certain condition?

Olaf: It depends what you mean by “working” here; rejecting requests during a certain period is a behavior of the system that can be observed at its boundary and answers a “what” question rather than “how” questions; a contract for this behavior can be specified and tested against. So it is a functional requirement. We might need another post to clarify what we mean by “functional” before we can discuss “extra” vs. “non” 😉.

Quality Attribute and Requirement Taxonomies

Olaf: I like the taxonomy by Martin Glinz who specialized on requirements engineering:

“A non-functional requirement is an attribute of or a constraint on a system. An attribute is a performance requirement or a specific quality requirement” (categories: reliability, usability, security, availability, portability, maintainability).²

Cesare: Indeed, the software requirements literature is full of examples of Non-Functional Requirements, but I am not arguing against the past. Those taxonomies of quality attributes are good; I also dedicate one lecture to them in my Software Architecture class, whose script is available on LeanPub. They have just been filed under an inappropriate label.

Olaf: The article specifically distinguishes constraints from qualities, which goes beyond labelling! See the examples above, requirements 3 to 5 in particular.

Cesare: Would you agree that such platform constraints can be also seen as “Compatibility” or “Portability” requirements (see the “-ilities” figure at the top of this post)?

Olaf: Some of them can, but not all. Constraints reduce the options in design. Many of them are caused by architectural decisions made previously (that I sometimes refer to as “legacy decisions”); they do cover (rather hard) technology choices such as platform selections — but (often softer) organizational aspects as well. So I have a hard time putting all of them in a single quality category. Anyway, which reference supports your position?

Cesare: I let George Fairbanks speak, p. 246-247 in “Just Enough Software Architecture”:³

“A quality attribute is a kind of extra-functional requirement, which are also called non-functional requirements and non-functional properties. The term extra-functional is preferred over non-functional because “extra” is more etymologically accurate than “non” in this context — these requirements go beyond functional requirements, not negate them. Most people would interpret a sign saying “non-functional” hanging on a water fountain to mean that it is broken, not that it is high throughput.”

Olaf: It is worth noting that George writes “accurate” and not “correct”. But this is just a single author voice, really. One that has weight, I admit that 😉. Martin’s paper, on the other hand, is published in academic conference proceedings.²

Cesare: Ok, here’s a peer-reviewed quote:

“The term nonfunctional requirement has been used broadly in academic literature and some parts of industry, but it suffers from an unfortunate ambiguity: “nonfunctional” is an actual word that, according to Merriam- Webster’s Collegiate Dictionary (11th edition), means something doesn’t work.”⁴

Olaf: That’s a good point.⁵ Authors do not agree… here are two more examples: “The Process of Architecting” (Peter Eeles/Peter Cripps), for instance, uses NFR: “requirements that include constraints and qualities”; this book generalizes from several industrial methods. We find the term in the Functionality, Usability, Reliability, Performance, Supportability (FURPS) taxonomy, but not in the ISO/IEC 25010 quality model. “Software Systems Architecture” (Nick Rozanski/Eoin Woods) also does not recommend the term NFR but uses “perspectives” instead.

Cesare: There is also the International Workshop on Testing Extra-Functional Properties and Quality Characteristics of Software Systems (ITEQS), now in its 5th edition.

Olaf: Yes, but in 2018 they gave the best paper award to a paper titled: “A Testability Analysis Framework for Non-Functional Properties”!

Looks like some more etymology work is in order now.

The Terminology Battle Continues…

Cesare: About extra, in addition to amplification (extra-hard but also extra-easy) there are many meanings. See for instance here: https://www.dictionary.com/browse/extra.

So extra in this case would mean “beyond”, “additional”. Performance is an additional requirement going beyond functional correctness. Your software should compute the correct result but also deliver it on time.

Olaf: Correctness (or accuracy?) actually is a quality. When I talk about functional requirements, I have user stories or use cases in mind that the system under construction supports its end users with. “Extra-functional” may make sense for the performance of a feature or availability of a component, but I am struggling to group all system-, team-, product- or organization-wide constraints under that label (see examples 3, 4 and 5 above).

“Non” has two meanings indeed, negation ¬ and “not a member of” ∉. But this does not invalidate the term NFR imho; “extra” has several meanings too, as you pointed out already. The “beyond” in “beyond or more than what is usual, expected, or necessary; additional” seems to indicate going stronger in the same direction/dimension. But going from accuracy to performance is a change of direction/dimension in terms of qualities — certainly related still; that’s why I advice people to specify NFRs in a specific and measurable way. Anyway, “extra” still sounds misleading to me.

Cesare: So would you say that extraordinary means more ordinary than usual? Or extraterrestrial, even more strongly rooted down into earth? What about extracurricular, would that be a student activity even more strongly related to the program of studies?

Olaf: ROFL! The definition says “beyond or more”, so your extra examples provide anecdotal evidence but do not break my argument. Our discussion may qualify as “beyond the ordinary” by now… but extraterrestrial is still about astronomy; and why not call extracurricular non-curricular, as it does not mean that any students (or teachers) have failed?

Here is a counter example: if something is a non-goal of a project or other work, this does not mean that I actively try to make sure not to achieve it, it simply is out of scope.

Cesare: You mean if you achieve the non-goal by chance, you can be satisfied about the project non-success?

Olaf: I’d need a mathematician to help answer that question 😉.

We seem to get carried away here, let’s try to reconcile. I agree that “non” is not a great choice either, but it is used a lot in practice. So while I do not have a very strong opinion here, I still prefer NFR.

Cesare: I am glad I could plant the seed of the doubt.

Olaf: It is good to revisit this discussion… I’d say EFR and NFR are more or less equally wrong and possibly misleading. I am reluctant to switch to gain a minimal improvement (if any), but risk that people in industry will no longer understand me 😉.

Cesare: I prefer quality attribute, and I think non-functional is much more misleading than extra-functional. If there is a more accurate way to classify requirements, given we are in an industry which loves new technical terms and comes up with a continuous stream of buzzwords all the time, I would not be afraid to try to improve the state of the practice with better terminology.

Olaf: The “mislead” score of the two terms is highly subjective, as this post shows. Actually, the placement of the pause seems to influence the perception quite a bit: N FR (me) vs. NF R (you). But your remark on buzzwords is very valid… Zeljko Obrenovic wrote about this in “Insights from the Past: The IEEE Software History Experiment”, his contribution to our Insights column back in 2017.

How about a compromise: EFR are those NFRs that are closely related so FRs (see all your examples above), and the rest of the NFRs, the constraints in particular (my examples 3 to 5 above), are just that, NFRs. Can we agree on that?

Cesare: I propose a different synthesis. EFR may include both FR and NFR.

Consider security: only authorized clients should be able to invoke the API. This means that the API should be non-functional unless clients have the right API Key.

Or about the constraints you mentioned. Compatibility is an extra-functional requirement. If you install the application within the right Linux version it will be functional. If a dependency is missing, it will be non-functional.

Olaf: We’re back to the start… let me try to summarize. NFR has two different meanings, depending on where you pause: a) not about functionality and b) not working. Same for EFR: a) amplification and b) additional, beyond. I am in the a) camp for good reasons (e.g., this is the common vocabulary of most fellow architects) and you provided some evidence for b).

So let’s sign a peace treaty. We both have our points, none of us could win the other over.

Cesare: Ok!

Concluding Thoughts

One should be aware of the 2x2 meanings and pick one consistent set of terminology and a single taxonomy for a project or program (expressed as a Bounded Context in DDD terms).

Note that at best “extra-functional” can be more “accurate”, or “adequate” but not “correct” or “right”: while waiting for a formal model for hard- and software and software engineering (axioms, proofs etc.), we should be reluctant to call either NFR or EFR “correct” (there is no “optimal” domain or database model either).

Also note that you sometimes hear that certain qualities have a functional element in them, and that NFR is not a good choice of name for that reason (and “quality” should be used). For instance, security requirements often have functional and non-functional elements: you want the system to block unauthorized requests (which requires a function or feature). This point might be valid, but does not go away by switching to a new general term. And it seems to exclude those constraints that are not related to quality.

The take-away messages from this post are:

• Both desired software qualities (that describe how a system is supposed to behave while delivering its features) and constraints (that often do not have a strong connection to any particular functional requirement) fall under (E|N)FR. Many taxonomies for such requirements exist. At a minimum, you may want to distinguish operational and developmental requirements; our figure above at the top of this post goes a little further and is organized by life cycle phase and stakeholder group.
• Both terms are overloaded and may cause undesired associations: EFR might be a bit more accurate if we take the origin of the words (or prefixes) “extra” and “non” into account; NFR is much more commonly used in practice.
• It does not matter much whether you call quality attributes and constraints NFRs or EFRs, as long as you do so consistently and elicit them in a SMART way.⁶
• Finding out what the desired qualities are is equally important as addressing and satisfying them in the architecture of the system under construction (and its implementation). You also may want to evaluate continuously whether you succeeded (or at least have a chance to do so eventually). Two topics for future posts!
• Academics and method engineers like to argue and define. Sometimes just because.⁷

– Cesare and Olaf, co-editors of IEEE Software Insights (and also two of five authors of the Microservice API Patterns language)