Following on from my previous blog on the challenge of capturing non-functional requirements here are five tips for smoothing that process. These have been worked out through some often painful project experiences and, I hope, will avoid you making some of the mistakes I have seen made in the past if these are not considered.

1. Really, really think about who your stakeholders are. The process of gathering non-functional requirements should begin with creating a list of the different stakeholders (that is, the people who have an interest or concern in the system under development). These are not just the people who will actually be using the system but also the ones who will be operating it, maintaining it, ensuring it is secure and so on). One of the commonest mistakes I observe is that a key stakeholder is forgotten about until the very end of the project (sometimes just before the system is about to go live ) and a critical NFR is not accounted for.
2. Consider non-functional and functional requirements together. Some NFRs should be associated directly with functional requirements so need to be considered at the same time. For example discussions about response times (the system must provide a new account number in less than two seconds) are clearly related to the (functional) requirement for opening a new account. It is useful therefore to make sure NFRs are considered at the same time as functional requirements are gathered (otherwise you’re just going to go back and ask questions of the same stakeholders again).
3. Be an “NFR evangelist”. NFRs seem to be one of those project artefacts which no one wants to own. If this is the case on your project then be that person. Read up and understand the importance of NFRs. Create checklists of the kind of NFRs that need to be gathered. Be ready and prepared to present to users and management alike the importance of NFRs. Have a list of anecdotes at the ready that illustrate the importance of NFRs.
4. Realise once round the block won’t be enough. Despite your best efforts at understanding stakeholders and looking for NFRs at the time you gather functional requirements there will always be some things that are simply not known early on in the project. It’s not always known what external regulations need to be conformed to early on for example or even what detailed availability or performance requirements are needed. I favour a breadth-first approach here. Make sure that early on you at least capture the categories of NFR (performance, security, regulatory etc) together with the key requirements in each category. Later you can capture missing detail.
5. Be prepared to challenge peoples prejudices and unreasonableness. Believe it or not some people ask for things which aren’t as reasonable as they might be? 24X7 availability, sub-second response times are typical. Whilst it may be possible to build systems that support such NFRs the cost will probably be prohibitive. Be prepared therefore to challenge such requests and offer alternatives, or at least spell out what the costs will be.

Clearly there is more to gathering and analysing NFRs than is stated here however these are some of the considerations you might want to think about and use to start the process if you find yourself on a project where you are the one who is responsible for this.

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.