RE07 - Yet Another NFR Classification System

Martin Glinz, from the University of Zurich, presented a paper titled On Non Functional Requirements. I will first summarize Martin’s points, before sharing my thought on it all.


First he stated something we all agree - there is no consensus on how to classify non-functional requirements (NFR). Sometimes we hear that what a system does is functional and how it behaves is non-functional. But this does not always hold, and he gave an example of how two different actors would each view the same requirement as a “what” and “how”.



He talked about the Volere model which separates functional requirements (FR) and NFRs from one another. But this does not work if the NFRs are not global. Then he mentioned the RUP approach where we attach them all to use cases, and that also has a flaw in that it won’t allow us to find all of them.


He proposes another classification system, with 4 facets:

• Kind (function, data, performance, constraint – the IEEE standards)


• Representation (operational, quantitative, qualitative, declarative)


• Satisfaction (is it a must have all or nothing, or part is ok)


• Role (prescriptive, normative, assumptive)

He suggested definitions, which are based on the concepts of concerns. For example, a functional requirement pertains to functional concerns. Per this classification then, system requirements as a category is broken into functional requirements, attributes and constraints. Attributes are broken down into performance, quality, etc. And together the requirements under attributes and constraints form the typical NFR set.

And then came the Q&A session which was full of heated debate. Someone proposed the now famous argument that we need to lose the term “non-functional requirement” – it implies something is broken or that it is “less-than” in value as relative to FRs. What bothered me was Martin’s response, though I didn’t have an opportunity to debate this with him yet. He said that academically he agrees he would love to stop using the term, but from a practitioner perspective, that is impossible because they are attached to it. I about laughed, most practitioners I know shy away from NFRs, I’m pretty sure they have no emotional attachments to the term. Maybe if we stopped using the term, used the actual descriptive terms (performance, quality, etc.), then they’d actually start to write them more consistently.

While I very much respect Martin’s opinions, I don’t entirely agree with where he took this topic. The question I really want to ask, but was afraid to ask for fear of flying tomatoes (it was a heated debate I assure you) is: what is the reason for the classification system? We keep seeing people who try to re-classify these, but not one of them talks about how the classification will be used. And for a bunch of requirements experts, I think that is pretty short-sighted to not consider our use cases. I am not inherently opposed to a new classification; I think we need a good one. But I mean we really need to think about how we will use the classification system before trying to create a new one that may work in terms of classifying, but not be used by anyone!