Suppose you’re a dairy farmer. You keep cows for the milk they produce. One of the systems you use is a milking machine. The functionality of that system is getting the milk out of your cows. The farmer’s cows need to be milked twice a day, if not they can even die. Suppose milking your cows with this machine once takes a whole day. Question: can this machine fulfill the function that it is meant for?
The answer of course is no, but in IT, strangely enough, people argue that the answer is yes. They argue that the function is milking and how fast it is done is an NFR (non-functional requirement).
In the early days of IT, when users were confronted with — for instance — unacceptably slow behavior of IT systems, the software engineers called these requirements “non-functional.” After all, they had written perfect milking logic, hence “it is not the fault of the logic that we produced that the infrastructure is not fast enough.” Logic is logic; you can’t blame it for anything. For the software engineers this had the added benefit of shifting blame, of course. Ironically, the software engineers have always been the main originators of these kind of problems and throwing more hardware at badly written software is a major anti-pattern.
The kind of reasoning employed seems a spillover from the fact that (especially) software engineers tend to think in terms of the pure logic they create, and logic itself has no dimensions, no space, no time. There is no time (or space) in 2 + 2 = 4. There are more places where applying discrete logic in real world situations breaks down. Many such situations exist in philosophy, for instance. In IT, software engineers are particularly susceptible to this disease of splitting the world into clean logical constructs and the rest. With the rise of IT in our society, this view has spread, finding a fertile culture to grow in. As Hubert Dreyfus argued in What Computers (Still) Can’t Do, the belief of the supremacy and independent meaningfulness of logic is deeply ingrained in our (western) culture, from the ancient Greeks to today.
It is not only performance that is a NFR in the eyes of many. Everything having to do with operations is generally seen as non-functional too. Backups, operator work, security, logging, monitoring, you name it. A good example form the continuity requirements, such as RTO (Recovery Time Objective or Return To Operation: how much time does it take after a halting failure to be back up and running?), RPO (Recovery Point Objective: how much data may be lost as the result of a failure?). Translating this to the dairy farmer and his milking machine: if it crashes, how long will it take to restart and how much milk will be lost? If it takes half a day to restart, the farmer (and above all the cows) is in big trouble.
If you define function as the purely logical description of only a part of its behavior, instead of the real-world description, the real world doesn’t go away. It returns as non-functionals. Splitting behavior in functional and non-functional is — in low-level IT-engineering terms — a no-op.
Now, thirty years ago, when we had relatively little IT, mostly providing functions directly used by humans, it kind of worked. But our world is changing and a ‘business function’ these days may even be delivered fully by automated systems and sometimes even also fully consumed by automated systems. With all the digital logic we are adding, we are fundamentally changing the behavior of our species and the total landscape, that now more and more consists of machines executing unimaginably amounts of digital logic and interfacing with the rest of the world.
Aside: shortsightedness is something we humans do very well. If we call the mounds and roads that termites build nature, then an eight-lane motorway, a skyscraper, and a residential neighbourhood are nature too. Not thinking of our changes to the environment as nature is just another example of shortsightedness. Our buildings, roads, factories, ships, etc. comprise how we humans as a species are changing the world. To drive the point home: these human-created environments are indeed new ecological niches for other species, e.g. foxes now living in residential areas and living off our garbage (which for them is not garbage at all, it is all a matter of perspective).
So, are there absolutely no non-functional requirements at all? Well, yes, I can think of two at least of any system: cost and time. Any piece of functionality, from large systems down to user stories in modern methodologies as SAFe (Scaled Agile Framework), takes time and cost to acquire/create and maintain/operate. The behavior produced are all functionals, including performance, continuity and so forth. What it takes to create the functionality are the real non-functionals: time & money.
The real NFRs are time and cost of acquisition and operation/maintenance of function. I tried to think of more but I could not think of a single one. Can you?
And if you agree, can we turn it around? I think that would be a very good thing, because the false-NFRs are not taken as serious as the rest of functionality, for one because they are IT and the business often still doesn’t take IT as serious as it should. Not having the false-NFRs in focus is a major source of poor results. So let’s listen to Uncle Ludwig once more:
A man will be imprisoned in a room with a door that’s unlocked and opens inwards; as long as it does not occur to him to pull rather than push. — Ludwig Wittgenstein
This article is published as part of the IDG Contributor Network. Want to Join?
