NFRs Are For More Than Just IT
Typically when specifying and designing a product it is the functional requirements that get a lot of time in the spotlight. After all, it is what customers or users will be able to do with the product that is really important. It is, to some extent, the functionality that people actually “buy”—and it is the functionality that enables them to achieve some kind of goal, complete a task, or solve a problem. You might buy a washing machine because you want an easy way of doing the laundry. A washing machine that doesn’t provide that functionality is not going to sell well at all!
Yet often functionality becomes a commodity, and non-functional elements act as a differentiator. I’m no expert, but as a consumer, I’d say most washing machines fulfill pretty much the same functionality. Some have more programs than others, but I’ll be honest, in our house, we only use about two of them. And when I’m putting the washing on, I pretty much choose one at random anyway. So the decision of which washing machine might end up being bought is based on a combination of price but also looks and quality. If the functionality is broadly the same, then I might buy the one that looks best and fits with the other appliances in the house. Or, I might buy the one that has the longer warranty (which implies the manufacturer is more confident about the quality).
Advertisement
These aspects (reliability, look & feel) are examples of two non-functional aspects of the product and they are vitally important. It is sometimes thought that non-functional aspects (and therefore the Non-Functional Requirements) are relevant only for automated or technical solutions or products, but in reality, they are relevant for just about any type of solution—even if that solution is entirely manual. Let’s take one specific example: Security.
Security of Manual Processes
Another well-known category of NFR is security. If we were to expand this category out, we would likely conclude that in large part it is referring to information security. Amongst other things, it is important that the organization’s intellectual property doesn’t ‘leak’ and that the company doesn’t inadvertently disclose confidential information to an unauthorized source.
Quite rightly, there is a focus on hardening computer systems to make them as difficult to hack as possible. However, how often is the security of manual processes considered? How often are staff trained on ‘social engineering, where an imposter attempts to get sensitive information by deception? The answer might be “not nearly enough”.
This might sound somewhat abstract, so let’s examine a hypothetical example. Think back to the last time you rang a service provider to ask a question or make a change. You probably had to “clear security” by answering lots of different questions. If you wanted to see information about an account you hold online, you probably had a series of passwords to enter. But, what about if you put a letter in the mail. Would the same processes apply, or would the request just get ‘actioned’? In some organizations, requests that come via mail get routinely actioned without much scrutiny. Sometimes the rationale stated for this is that “a letter contains a signature, so it’s authenticated”. To which I would ask “do you compare it against a sample of the client’s signature? If not, how is it providing any type of authentication?”.
This could end up being the first chink in the armor. A clever social engineer might change the address associated with the customer’s record, perhaps to an anonymous rented mailbox. They can then collect statements, which they can use as proof of identity. They might even glean information about the other types of accounts that the person holds. Better yet, after a few weeks, they can change the address back so the target never knows they were ‘hacked’. Yet this ‘hacking’ happened without any IT intrusion whatsoever—the ‘hacker’ simply wrote in and asked!
Conclusion: NFRs aren’t just for IT!
So, hopefully, I’ve convinced you that security doesn’t just apply to IT. What about other categories of NFR? They are usually just as relevant, elements like performance, back-up, disaster recovery… it doesn’t matter if your solution is entirely manual you still need to work out what would happen if something unexpected happens. The IIBA Business Analysis Body of Knowledge Guide (BABOK®) suggests 15 common categories of NFR (see BABOK® section 10.30), and this is the tip of the iceberg, it’s usually sensible to expand upon these based on the individual circumstances. Typically, many of these are relevant irrespective of the type of solution. We ignore NFRs at our peril!