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.
Posts
3 comments:
"non-functional" requirement as others know it, complete with the connotation that they are less important and less comprehensible, is something I find appalling
"Meta-requirements" is a good word. A functional requirement refers to a use-case or user story. A meta-requirement applies to all of them.
But 'meta-requirements' are typically less comprehensible. They are, for example, difficult to test and verify, or reason about. I grant, this seems to be a problem with our development tools, rather than intrinsic to the properties themselves.
A functional requirement refers to a use case or story. A meta-requirement refers to the interactions between the system, the engineers who program it & the tools they use to do so. Usability, performance, scalability and security are neither functional NOR meta. If they are to be considered meta then what I previously called meta must be meta^2.
But I don't see things that way since the requirements you call meta ARE just limitations of tools. Whereas the ones I call meta which would have to be meta^2 require an AI to evaluate. And that's making a lot of generous assumptions.
Engineers are obviously concerned with the boundary between which requirements specs tools support and which specs they do not support. I am concerned with the boundary between which requirements specs tools CAN support and which specs tools can NEVER support. In fact, it's more like, which requirements specs can be written down formally and which cannot ever be written formally. If you can't even specify a requirement then you can NEVER create a tool to support it.
Maintainability and testability cannot be formally defined even though they are real and meaningful specs. The reason why is because you can never prove your system passes those specs. You can only ever prove it fails them. And proving it passes them might be as impossible as proving your system never halts. Something you can do for specific systems but you can never do in general. So you can never create a tool to prove this property.
It's very reasonable to say "the UI is always available and always visibly begins to respond within half a second to any user initiated action".
It's entirely unreasonable to say "the system can be modified by a skilled and expert programmer to accommodate any new data format within three days".
What if the "data format" is C++?
And it's entirely meaningless to say "a skilled and expert programmer can BEGIN to modify the system to accommodate any new data format within 3 days".
Post a Comment