Addressing Nonfunctional Requirements in Scrum

Posted by Chris Sims on Nov 10, 2008

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Customers & Requirements ,

Specifications ,

Agile

Tags

Scrum

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.

 

1. Back to top

   What is this non-functional requirement thing anyway?

   by Robert Lauer

   Is performance a nonfunc requirement?
   -> The actual requirement behind performance is time consumption in a specific functional context. Wait a minute! So performance is a function of of time consumption per service method. So it is a functional requirement after all, right?
   
   What about security? Is security a nonfunctional requirement?
   -> Security is about restricting access depending on the user (or certain properties of the user) and the function to be used. So it is a function of (user, function) mapped to a boolean result. Hey, another hidden functional requirement!
   
   So what is the nonfunctional requirements fuss all about?
   
   1. Laziness - Some folks don't want to spell out what they want exactly.
   2. Pragmatism - Some cross-cutting functional concerns like security may be hard to specify. Then again they may be complicated because we don't understand the problem after all.
   
   Any thoughts on that, anyone?

   Reply

2. Back to top

   No "non-functional" requirements in the world, it's "common" use case

   by Woo Daniel

   In case you have a user story to deposit cash, it would contain some authentication requirement, eg, type in username/password and check it with backend LDAP. All right, you have another user story to withdraw cash, it also has the same requirement for authentication. So, authentication will be across many user stories, that means it is reasonable to pull the common part of authentication into a standalone user story, yes, we sometimes call it "non-functional" requirement but I think it's a bad term, actually it's "functional" requirement, or just a "common" requirement, can be "extended" or "included" from other requirements just like use-case relationships in UML.
   So, what's "non-functional" requirements? There is no "non-functional" requirement, a requirement must be functional. In most cases, we are referring "common" requirements.
   I think "common" use cases are well used in UML, it's not Agile way to organize requirements that way but in practice it best fits my development.

   Reply

3. Back to top

   Thinking it from the tasks

   by Inanc Gumus

   I have opened that discussion in the scrum yahoo group of this thread's author talks about. Because, I am still not too-confident about the ideas.
   
   I rethought and came to a conclusion ( just for now ! ) which is: If the so called non-functional requirements cross-cutting some part of the system's user stories / scenarios then I think we might calculate all the story points associated with that stories by adding non-functional 'goals' to the estimation.
   
   And this brings us another conclusion which is that if the non-functional requirements are so big so that splitting up the stories won't bring so much benefit. This is my dilemma.
   
   But, I intuitively sense that many of the non-functional requirements can be build up and take a slice from each of the stories that need that nfrs.

   Reply

4. Back to top

   Re: What is this non-functional requirement thing anyway?

   by Stefan Tilkov

   There are some non-functional requirements such as accessibility, stability, reliability, extensibility, maintainability, loose coupling, simplicity etc. that require a good architecture. These are orthogonal to the functional requirements. They will not magically be fulfilled unless someone takes care of these aspects.
   
   Very often, attending to these requirements means that there's a conflict of interest with what's the fastest and easiest path to implement a functional requirement.
   
   I've seen a major project, using Scrum - in fact, at one of the best-known companies using this - that failed because somehow people no longer took care of these aspects.

   Reply

5. Back to top

   There is an agile way to capture non-functional qualities

   by Ryan Shriver

   The secret is to define the following attributes for each "quality", such as response time, availability, etc:
   
   Scale: <What to measure, the units>
   Meter: <How to measure, the method>
   Target: <The level above which you declare success>
   Constraint: <The level below which you declare failure>
   Benchmark: <The level where you are today>
   
   For example, from my recent talk "Agile Engineering for Architects" which I gave at Agile Dev 2008 (and will be uploaded to my website in the next few days):
   
   Name: Availability
   Scale: Percentage of time system is available for accepting transactions excluding 1 hour weekly maintenance window
   Meter: Weekly Monitoring Report from independent data center polling application every 5 minutes
   Target: >= 99.9% (10 mins down)
   Constraint: < 99.4% (60 mins down)
   Benchmark [Release 1.0]: 99.5% <- 2008 Q3 weekly average
   
   Here's a post on how I introduced this concept to a Scrum team I was coaching:
   
   theagileengineer.com/public/Home/Entries/2008/1...
   
   User stories are wholly inappropriate for handling non-functional requirements for the following reasons:
   
   1. They lack Sponsor & Architecture stakeholder visibility
   2. Separation of concerns (what vs. how well - each are independent)
   3. Binary nature of acceptance criteria. Qualities should be viewed as scalar, not binary.
   4. Stories should small enough to be completed in a Sprint, qualities must be monitored over time.
   
   -ryan (theagileengineer.com)
   
   </the></the></the></how></what>

   Reply

• Older >