In our recent meet-up at the Agile Practitioner group, there was good talk about non-functional requirement testing. One of the first questions we discussed was how come non-functional requirements are second-class citizens. Usually they are patched on the app as an afterthought, and like any last effort, we botch it up.

One of the answers was that it’s a product management issue.

It is a simple prioritization issue. Requirements drop down the priority ladder, because someone, usually the product owner, has decided that they are not important enough as other requirements. For example, a security requirement – log-in reports in a financial application. True, we need security, but it’s not going to be the first thing we do, since we need to actually put the financial logic there too. And the latter takes precedence.

Simple prioritization, right?

Unfortunately, there’s a cost to that prioritization. Until something really bad happens, say, we need to provide these logs to the government tomorrow, all functional requirement will take precedence. So we either don’t get to that non-functional requirement, or we’ll get squeezed to do it in a third of the time it really takes to do it, and welcome to botch-city.

That’s one way requirements don’t get done. Here’s another. Let’s talk about availability. We need to be up 99.999999% of the time. All the time.

Our product owner would like this kind of availability, and the dev team says: good, prepare your wallet. The check contains a lot of zeros. After the product manages lifted his jaw off the floor, he says: “Well, let’s work on something cheaper, shall we?”. He just learned that non-functional requirements usually cost a lot more than regular requirements.

We assume that the product owner knows what’s best for the product. We’re expecting him to make the right decision, and therefore, we believe that he’s taking everything into consideration, and comes up with the perfect backlog.

Get ready for a surprise

Our product owner is not superman (or in our case, Lex Luthor). He cannot know everything about business, development, security, architecture, IT serviceability, database maintainability, and a whole lot more. It’s hard enough to keep in one’s head what the app is supposed to be doing…

If the product owner doesn’t understand security, he won’t know how to prioritize security features vs. the rest. And as humans go, will give attention to the familiar stuff over the unknown.

So how can we make sure that non-functional requirements get met?

Remember “whole team”?

In extreme programming, the “whole team” makes the decision, not just the product owner. As team members we should ask more questions: “Do we need authentication logging?”. If our poor product owner doesn’t know even what authentication logging means, he now has a mission  – learn and come back with an answer. And he would love it if that question also came with an estimate.

Ideally, the product owner should learn about everything required. Ideally he should have all the answers. But this is real life. We don’t know everything. Good decisions come from a team effort.

And by asking questions, seeking information, and bringing solutions together table we’ll have our democracy where all requirements are equal.