Over the years, I have said bad things about the term “non-functional” when used in conjunction with “requirements.” Until today my best argument is that the term “non-functional” already has a meaning – in the vernacular it means “not working.”
Requirements that do not work? Eh?
Well as of today, I have a better argument… and it comes from my work limiting testing to high priority qualities. (Under development.)
Really, the only reason that we treat functionality as the most important quality, is that we have always done it that way. Suppose that something other than feature/functionality is the most important quality for a sprint. It happens.
Back in the ancient programming days – the 1950s and 1960s – the only quality of interest was functionality. But that was then. Now we have zillions of qualities. Well, they have always been there – but many have gained more importance over the last few decades. Portability was not a concern when there was only one computer. Security was not a concern before computers were linked together.
In like manner, many other qualities have gained importance for various reasons. David Bernstein makes a very persuasive case for maintainability being the primary quality these days. He reaffirms the 75 or 80% of the cost of a system is spent in the maintenance phase. The IEEE has a list of several qualities that apply to software.
And now along comes Agile development with its short cycles… and my hypothesis that shorter cycles allow us to focus on fewer qualities because as time goes to zero, the risk associated with unintentional/unexpected consequences also goes to zero. All right, that’s a bit geeky. The idea is that very short cycles allow us to focus upon only one quality and manage the risk associated with NOT testing all the other quality attributes.
Absurd you say? We must always retest all the previous bug fixes, say you. Bull. Those “regression tests” are the least productive. We should avoid them. We should delete them. But I digress.
The purpose of this posting is to find a better name than “non-functional requirements.”
Okay, let’s suppose that your whole team has selected security as the main quality for your next sprint. Would we categorize any other stories for that sprint as “non-secure”?
Suppose you decide the next sprint will focus on maintainability. Would you call any other requirements for that sprint “non-maintainable”? No.
Suppose the next sprint is about extensibility. Would the rest be “non-extensible requirements”? Requirements that could not be extended? Really?
So let us stop talking about “non-functional requirements”. Functionality is not the paramount, primal category of requirements that is was when Dykstra was young.
Let’s call security-related requirements “security requirements” and performance-related requirements “performance requirements,”, etc.
Dr. Sean Murthy took me to task, suggesting that “…we need a collective term to convey qualities that are not about ‘functionality’…”
And it hit me like a bolt… “non” is the problematic part. The other attributes *compliment* the functional requirements. They are “co-functional requirements.”
Take a bow, Dr. Murthy.