NFRs and You
NFRs are non-functional requirements. I’ve talked about them before, but lately the name has been bothering me. It’s that non in the name. Unlike non-goals, which are the things you’re not going to do or worry about, Your NFRs are not things that your project won’t do, and they’re not requirements you can ignore. NFRs are things you do need to worry about.
I mean, look at the phrase non-functional requirement. You mean you don’t want it to work? Or are you saying it doesn’t do anything, but it’s required anyway? Why would you put any effort into something that has no function?
Requirements without function or benefit should be pushed back against, but what we typically call NFRs are neither. NFRs are usually drawn from the list of -ilities. Things like burstability, extendability, reliability, and durability. For any given project you will likely need one or more of them, so ignoring them is a bad idea.
That said, the -ilities aren’t your typical functional requirements either. “The method shall return a (nil, error code) tuple when receiving invalid input.” That’s a pretty straightforward requirement that defines how the code should function. It’s also pretty easy to unit test. Write up a set of test cases that provide whatever level of coverage of the combinatorial explosion of possible inputs and call the method. As long as you get the expected answer you’ve met the functional requirement.
No, I think what we call NFRs are really operational requirements. Requirements around the way things behave when they’re operational. Things that are hard (impossible?) to test with unit testing. Consider burstability. Sure, you could write a test that, in parallel, calls your method 100’s of times per second. But does that give you any confidence that the system overall can handle it? To really get some confidence on burstability you need to actually try it. Maybe not in production, but in a production like environment, with all of the vagaries that implies.
And like any other requirement, operational requirements need to be part of the plan. You can’t just bolt extensibility on at the end. Or at least you can’t do it in a sustainable way. Which means you need to think about operational requirements from the beginning. They’re requirements, just like any other requirement. They’re just usually a little harder to figure out. Especially if you’re just looking at the business logic, because they’re not in the business logic, they’re in the business case.
The business logic will tell you what to do when a customer places an order, and what should happen if they do something wrong. It won’t tell you what to do on the Friday after Thanksgiving. It’s the business case that will tell you that while your typical order rate is X, on that day it will be 10x, and for the subsequent 6 weeks it will average 5x. And you better be ready for it, or else.
So next time you hear someone asking you about your NFRs, think about what they’re really asking you. Think about the scope of the question, and plan for it.
