In case you’re unfamiliar with Non-Functional Requirements, let me provide you with the definition from the BABOK®:
“A type of requirement that describes the performance or quality attributes a solution must meet. Non-functional requirements are usually measurable and act as constraints on the design of a solution as a whole.”
Whew. That’s a mouthful. My rule of thumb is that if I hear any words that end with “ility”, it’s probably a non-functional requirement (although there are some that don’t end this way). Here are some examples:
- Availability
- Usability
- Reliability
- Scalability
- Compatibility
- Security
- Performance efficiency
I think you get the point. The list of possible non-functional requirements to consider on any project could be endless. But, as I have learned from personal experience (ouch!), these are things you don’t want to ignore or leave until the end of a project; they will come back to haunt you.
So, how can we use these to split User Stories?
There are a few ways to consider including non-functional qualities in your solution. This is one area where I think agile has made it more difficult – but if you are aware of these considerations, hopefully you’ll find a way to include them. Here are a few ways I have seen it done:
- Include them as a part of a definition of done that applies broadly across the whole effort
- Include them as acceptance criteria on individual stories
- Include them as a separate bucket of requirements
- Include as “Spikes” that are handled separately to prove out architectural strategies
Let’s take performance efficiency as an example. Maybe at the beginning stages of a project, you don’t care that much about performance. You’re probably working in a dev environment, might not have the fastest servers, and it doesn’t matter until you get to production, anyway.
The big story would be:
We are going with the option of including non-functional requirements as separate user stories:
Given that performance concerns are generally not of great concern early on in projects, I would include these in my product backlog to make sure they are not forgotten or ignored (and possibly educate the Product Owner about their importance).
I would also tack on some usability stories related to performance efficiency (also non-functional):
One other key thing I should point out about non-functional requirements is that they are the hardest ones to elicit and to define. That’s because they largely need to be measurable and testable. If you can’t nail down the numbers for non-functional requirements, then you won’t be able to test them.
Questions to ask:
- Can the quality attribute wait until later?
- Is it something that must eventually done to have a quality product?
- How can you make it measurable so it can be tested?
- Are there some areas where you could reduce the quality, because it’s not as important?
- Non-functional requirements can dramatically increase the cost of a project – are you focusing on only the most important ones for your project?
As you can see, these are probably some of the trickiest types of requirements to deal with – in any type of project, but especially in agile. Just make sure you don’t ignore or forget them!
Resources:
https://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories
