Two of my most recent engagements have been working with clients on defining the non-functional requirements (NFRs) for a new system. It is strange that even now NFRs, and everything about them, is seen as a bit of a black-art. Part of the problem of course is in the very name; who, after all, wants a system to do something that is “non-functional”? Surely we want a system that functions, not one that doesn’t. The problem is also exacerbated by the fact that no one seems quite sure whose job it is to find (gather, elicit or whatever) NFRs. In my next blog I give my five top-tips for dealing with NFRs on a project but first, what exactly are NFRs?Most people who are asked to state the requirements for a new system know how to state what they want it to do, for example:

• The [banking] system must be able open a new bank account.
• The [e-commerce] system must be able to send orders to the warehouse.
• The [social security] system must be able to send a payment to a claimants bank account every two weeks.

These are all examples of functional requirements, they are statements of the functionality we expect from the system. Whether these are expressed as free-text statements, as use cases or as more formal pseudocode type statements they all have the same goal, namely to be a complete and unambiguous statement of what the system is required to do. However there is something missing from these statements. It may be sufficient for the system to open a new account, given the right input data, but how long should it take, a second, a minute, a year? Similarly should the e-commerce system be able to place orders all day and every day or is it allowed to have a break during the evening? Should the social security system be able to send payments to a claimants bank account even if that person is not previously known to the social security department? The functional requirements only really become complete if these additional quality attributes are stated as well. Qualities are one of the things we usually define as being NFRs; in this case the performance, availability and security qualities we expect from our systems respectively.

The other types of thing we usually express as being an NFR are the constraints under which the system must operate. It is very unlikely you will be given complete free reign to develop your system without taking into account some rule, regulation or policy you need to comply with. Examples of these for our three systems above would be country specific banking regulations, XML formats that orders must use or disability regulations that allow all people to use the social security system. Constraints can also include existing systems that your brand-spanking new system must talk to during the course of its operation. The warehouse system in the above example may already exist and be a bit picky about how it receives its orders so unless new orders are provided in the correct format they will be ignored.

Okay, so in summary, NFRs are the quality attributes we expect our system to have and also state the constraints under which our system will be built. Next I’ll take a look at the best way of dealing with NFRs based on some recent (and sometimes painful) experiences.