I was doing some idle reading when I came across this sentence which startled me:
A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security.
Since when did any of these things become non-functional requirements? Up to now I'd always understood non-functional requirements as arbitrary choices of aesthetics and judgement calls. The fuzzier and least trackable aspects of a software designer's job.
Which made me realize that the whole concept of a "non-functional" requirement as others know it, complete with the connotation that they are less important and less comprehensible, is something I find appalling and incomprehensibly alien.
I understand a meta-requirement well. Testability and Maintainability are meta-requirements. And yes I invented that on the spot in 5 seconds. But "non-functional" puzzled me.
So I had to look up the concept of "non-functional requirements" because I couldn't wrap my brain around it or guess the kind of brain damage of anyone who originated it.
In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.
Ah of course ... engineers. The people who obsess about behaviour rather than understanding. I understand the brain damage involved in the concept now.
Engineering is the mental disorder where a total lack of synthesis leads the sufferer to be incapable of intuiting internals and so 1) they delude themselves that internals can't matter, then 2) raise their crippling disability to the status of a virtue by claiming that fuzzy qualitative behaviours are much less important than quantitative ones.
In short, the narcissistic delusion that what you can't do, wasn't important in the first place. No matter how often empirical reality says the exact opposite.