- Posted by dan on March 8, 2011
So firstly we should say what a Non-Functional Requirement (NFR) is.
"A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture". - Wikipedia paraphrase
What NFR's encompass
It seems that you can have NFR's for practically anything and I feel that there's a considerable gap in the way we capture the requirements of our system. I'm a firm believer in "If it's a required, then it should be tested". But somethings on the NFR list are quite difficult to write an automated test for. for example:
It's no-wonder that NFR's are often refered to as the "*ilities" .
Non-funtional requirements are also referred to as the quality attributes. Before you get upset, it doesn't mean to say all those unit tests having nothing to do with quality, they help ensure that the product indeed does what it's supposed to. But they probably don't measure the performance or the usability of the product.
Somehow after doing Scrum for years now, I'm brought right back to this picture from the Scrum Master training.
The picture, shows, that the customer wanted a tyre hanging from the tree. But even this doesn't specify how heavy the customer is. Can the tyre (or the tree for that matter) continue to function under high load.
Recently my team has been slaving away on an internal tool ready for release day. No we're not quite at the level of Continuous Delivery to release that often, we have a fixed date we work to.
The project had gone really well, we were pair programming using TDD and BDD for the higher level acceptance tests. Our product owners was closely involved, it was as close to the perfect project as I've had in recent time. But there was one thing I overlooked.
Don't Forget the Non-Functional Requirements (NFR's)
For all the good the above mentioned techniques have brought us, None of it could of been deployed at any time, which is a goal of Scrum and many of the Agile development methodologies. The reason why because we hadn't seperated out of Data Access Code into a seperate process. Now please don't confuse this with not seperating it out into a seperate layer. It was a seperate layer, but ultimately it would of run under the same IIS worker process as the rest of our application and we have an NFR that for security says that Data Access must be performed in a seperate process.
This is completely understandable for a public facing website, but our tool was for internal use only.
What's Your Definition of Done
Your definition of done, might say:
- All software must be maintainable
- All software must be highly performant
- Must function under high load
But are these points really that helpful. Does an internal tool that's destined to by used by a team of 10 people really need to be able to function under high load? Probably not in this case and thus we highlight the problem with generic NFR's, they just might not be applicable. But if we follow the definition of done we end delaying our delivery of value.
A Possible Answer
Well maybe with all things Agile or scrum is another type of card such as the NFR Card.
I can't claim it as my idea, only one I'll try now I've read, this great post on understanding non-functional requirements
. The key is as with the User Stories
or BDD Scenarios
is that the card should offer something concrete and measureable. Of course somethings are very difficult to quantify, like usability or supportability. Try and make them quantifiable, lifes much easier if they are.
Some NFR's it might be better to elect to have them as qualities or attributes that are monitored and measured over time. Usability could be measured by increase in conversion. Supportability could be measured by a qualitive survey on how supportable it is. Obviously quantitive measures are better. But if these NFR's are really that important then we should be able to monitor the quality it's there to ensure.
How do other's deal with NFR's? Should they be negotiable by the team with the architecture team. Or should the team decide on the NFR's.