Home » Agile » Equal Rights for Non-Functional Requirement

About Gil Zilberfeld

Equal Rights for Non-Functional Requirement

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.
Reference: Equal Rights for Non-Functional Requirement from our NCG partner Gil Zilberfeld at the Geek Out of Water blog.

[ratings] Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a sysadmin Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. Introduction to NGINX
2. Apache HTTP Server Cookbook
3. VirtualBox Essentials
4. Nagios Monitoring Cookbook
5. Linux BASH Programming Cookbook
6. Postgresql Database Tutorial
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments