Nonfunctional requirements describe qualities of a system (what it is) rather than its behaviors (what it does). Scott Ambler inspired much discussion when he recently asserted "Scrum's product backlog concept works well for simple functional requirements, but... it comes up short for nonfunctional requirements and architectural constraints." in an article on Dr. Dobb's Portal.
The article sparked discussion on the Scrum Development Yahoo Group, as people shared their views on how Scrum might deal with nonfunctional requirements. Ron Jeffries helped to focus things by providing an example requirement: that the system maintain an uptime percentage of 99.9%.
One proposed way of dealing with this requirement was to make it functional, and thus testable, by putting a time-box around it. The requirement would then become: The system will maintain 99.9% uptime for [insert time period here]. Additional functional requirements were suggested such as creating a monitoring and notification mechanism.
Several people suggested another approach in which requirements of this type be addressed in the team's 'definition of done'. That is, each story is not considered done until it has been determined that the implementation of the story is not likely to cause downtime. This might be achieved through a review process and/or load testing, for example.
Leave a comment and share how your Scrum team deals with nonfunctional requirements.