Why I Dislike “Non-functional” Requirements

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.


“Co-functional requirements.”

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.

Posted in Uncategorized | Leave a comment

Right brain, left brain

Summary: As my journey toward reconciling the two halves of my brain continues, I have realized that my left brain (the analytical half) is building scaffolding out toward my right brain (the feelings half).

The rest of the story:

I smoke pot.  There it is right here in print. Deal with that how you will.

Did pot smoking change my life? Absolutely. I’ll address those changes in later posts. In keeping with my goal of doing things in-the-small, today I want to focus on feelings

My parents were my role models. My home was Ozzy and Harriot supportive. But feelings were 

Posted in Uncategorized | Leave a comment

Better quality from less testing

Alternative titles:

  • Death of the Iron Triangle
  • Attributes Testing for Software
  • Quality Driven Development

Part 1: Using test matrices to prioritize your testing and risk taking

Part 2: Iron Triangle demise: Project constraints are product variables, too

Part 3: Flow stuff: Smaller increments are better


Posted in Uncategorized | Leave a comment

Quality management elevator speech

“So, what do you do?” asks the company president.

Influential people ask these things. It’s a valid question and deserves a solid answer AND it is a great opportunity gain a strong ally.  She truly wants to know my general approach to managing quality… software quality assurance is, after all, still a rapidly evolving field.

Here’s my short answer… my hierarchy of quality building blocks:

  • Build the powerhouse
  • Get the house in order
  • Stop the bleeding
  • Minimize the losses

What do we do first? Stop the bleeding.

If the bleeding stops, we find the cause and eradicate an entire family of errors. And that tends to get our house in order.  That’s a good day’s work.

If  the bleeding won’t stop, we minimize the losses.

And we build the powerhouse whenever we have earned the opportunity.


Posted in Uncategorized | Leave a comment

Tester location scenarios

Tester location scenarios

Image | Posted on by | Leave a comment

What Testers Do

A recent tweet claimed, rightly, that we testers lose effectiveness when we cannot describe what we do and what we are doing.  I agree.  And toward having a general response to that “What do you do?” question, I submit the following…

What testers do

What we testers do – given enough knowledge and wisdom – is create new paradigms that will help us better explain and manage quality.
5 – create paradigms
4 – extend state of the art of testing
3 – create and manage quality systems
2 – master best known practices
1 – test code and documentation 

We don’t manage bugs. We don’t test the things that don’t need testing.

Posted in Uncategorized | Leave a comment

Quality in-the-small

Summary: Quality driven dev, when dialed to 11, can quickly reduce error rates to near zero.  At least that’s the theory.


Big Bang fails too big. Frequent delivery fails more often and provides better learning opportunities. That’s a huge improvement. Quality-driven dev, which focuses agile dev on salient quality factors, can further improve dev results. 

Operational definition of “quality”

    Q(total) = f (q1, q2, … qn) 

That is… for any cycle, quality is some function of the salient quality factors in your context. 

Knowing your context, *you* are responsible for defining quality for your customers. If you want someone else to define and manage your quality, you are sinking not swimming.

If this sounds like a heavy responsibility, relax, here is a theoretical life preserver:

  • Atomize and timebox your cycles
  • Select ONE QF as the driver
  • Ignore other QFs (!)
  • Make your code change(s)
  • Run your acceptance tests for that QF

If you have concerns about potential side effects (e.g. a focus on security may have affected performance), then explore or rerun the tests for this other QF (in this example, performance).

The theory is that as cycle time approaches zero, the risk associated with ignoring secondary QFs also goes to zero.

My recommendation is to try this at home… or at least with an engaged customer.

I’d love to hear your results.

Posted in Uncategorized | Leave a comment