Non-functional requirements are more functional than you think!
In my daily work, I regularly used the naming 'non-functional requirements'. I learned it some years ago and used it since as an expression for things like throughput, response time or reliability of an application or service. I never really questioned its meaning. Still, I often had the impression that the naming does not fit well. In conversations with clients, it was often necessary to explain in more detail what is meant with non-functional requirements. Fortunately, this is over now!
Quality Attributes – welcome to my vocabulary
Ionut Balosin describes in his article Does IT Industry Need Better Namings? that some of our namings in the IT industry are misleading. Non-functional requirements are one of the namings he criticizes in section ‘Non-functional requirements or quality attributes’. I really like how he uses two (simple) approaches to better understand the questionable naming:
Approach 1: What is the meaning according to the dictionary?
non means ‘not, absense of, unimportant, worthless‘. Ionut Balosin questions how we as an industry can name something non-functional that has an impact on the architecture and semantically is ‘worthless’. Why would we even care about such requirements?
Approach 2: How are non-functional requirements achieved?
Non-functional requirements are implemented through functions, e.g. security via encryption or usability via a wizard. So Ionut Balosin questions for good reason that we name something as being non-functional when it is implement through functions.
After reading Ionut Balosin thoughts I really wondered why I used such an obviously misleading naming for years. From now on I will use the general term quality attributes instead of … I dont remember.