Friday, 29 June 2007

The importance of defining non-functional requirements

You wouldn't believe the amount of projects I've come across where nobody on the project team has established what the non-functional requirements (NFR's) are. If you're reading this and thinking "what the hell are non-functional requirements" then this very brief introduction to them is for you. If you're already familiar with NFR's then read on anyway as there may be a few nuggets in here for you that you don't already know.

So, non-functional requirements (sometimes referred to as Software Quality Attributes), in the simplest terms define performance, scalability, capacity, resilience, and many more attributes of the software being delivered. The best way for me to describe why NFR's are so important is to share with you a few experiences. Here's one experience to demonstrate the point:

A web application is designed, built, tested, passes UAT, and deployed. The customer is happy for the first 6 months as traffic levels have been low. Over time the traffic levels rise (from 30 user sessions a day, to over 2000 sessions a day). The web site starts to crash regularly, the customer is very unhappy with the "quality" of the delivered software and wants it fixing. Well, you can see where this is going already. The answer to this seems obvious, why didn't the supplier agree traffic levels with the customer up front and design the solution appropriately?

Well, this isn't always as easy as this. Did the customer even anticipate such high traffic levels? Is the customer techno savvy enough to care about such things as this is what they pay you for isn't it? Shouldn't you have made some assumptions in this case?

When I'm dealing with a customer who isn't techno savvy and doesn't know what their traffic levels are going to be, there's always the temptation to design for a large number of users, i.e. design BIG. Unfortunately, going large on these decisions costs more money to do and very quickly you become uncompetitive and could potentially end up with the customer walking away and cancelling the project before it's even started. The best thing to do in these circumstances is to agree with the customer an affordable level of scalability and then warrant the system to this level. Basically, agree that your design can handle say 100 concurrent sessions, and do your internal performance testing to this level. In this situation you're only warranting the system to 100 sessions and if the customer exceeds these limits then the solution may continue to operate comfortably but you won't fix any issues that occur without charging for it.

For further reading on the subject of NFR's here's a link to an extremely thorough list of NFR's that I use daily! Volere Requirements Specification Template

No comments: