I don’t know about you, but every time I read the word “non-functional”, I feel a yawn coming on, and I start to look for something else to do. While non-functional requirements or quality attributes, as they are also called, may not be exciting, they are still important: They impact the user experience, and they influence architecture and design decisions.
Say you are looking for a new car, and you’ve found one that looks great. The car also has a powerful motor, lots of safety features, and a sat nav. But during a test drive, you discover that it’s noisy inside the cabin, the seats aren’t comfy, and its real-world consumption is surprisingly high. While the car has all the right features, the driving experience is not great–and that’s due to its poor nonfunctional properties.
Another example is the training part of my website. If the response time is sluggish, and it takes too long to receive a confirmation once a seat has been booked, then users are unlikely to have an enjoyable experience. Other common nonfunctional requirements include robustness, interoperability, usability, and compliance with a regulation or a standard.
As important as they are, non-functional properties are sometimes overlooked, particularly in an agile context where we spend less time with upfront research and analysis. This can be particularly painful for those attributes that apply to the entire product. If, for instance, you forget to capture that your mobile app should be available on iOS and on Android, then this may require correcting fundamental architecture and technology choices, which is likely to delay the project or make it more expensive.
If you are unsure which non-functional requirements are important for your product, then I suggest you engage with the users and the development team. Try observing users, conducting problem interviews, and carrying out user tests using early product increments / prototypes. The tests allow you to discover new attributes and to understand, for instance, if the current performance is acceptable.
The development team is a great partner for finding relevant non-functional requirements, particularly if the team members have worked on a similar product before or deal with support and production issues. If that’s not the case, then you should consider inviting members of the operations and customer services group to listen to their views on qualities such as robustness and availability.
I like to capture non-functional requirements as constraint stories. Here is an example:
I call the story above a constraint, as it constrains other user stories. Just like a regular story, the constraint has two parts: a narrative and a list of acceptance criteria. The narrative describes the non-functional requirement from the perspective of the persona, Mary. The criteria clarify the interaction and describe the environment. Both are required to validate the constraint. (Tom Gilb’s Planguage, which is an alternative approach to describing nonfunctional requirements, would call the first condition “scale” by the way. The narrative contains the “target” and the “gist”.)
Whatever format you choose to capture your non-functionals, ensure that the description is precise and testable. If I say, for instance, that booking a training course on our website should be quick, then that’s a first step towards describing the attribute. But it would be too vague to characterise the desired user experience, to help the development team make the right architecture choices, and to validate the constraint. I will hence have to iterate over it, which is best done together with the development team.
Explore non-functional requirements that apply to the entire product or to important features early on. This helps you create a great user experience and make the right architecture and technology decisions. To ensure that they are always applied, you may refer to them in the product’s Definition of Done. This definition states the criteria every product increment has to fulfil to be considered done in Scrum.
Product strategy, OKRs, and KPIs are popular product management frameworks. But how can they be…
How product leadership is practised has a big impact on the success of individual products…
The product strategy is a crucial product management artefact. But what exactly is it? Who…
The product vision can be a powerful vehicle to inspire and guide people. But how…
Product portfolios, like Microsoft 365 and Adobe Creative Cloud, play an increasingly important role in…
The product roadmap is an important product management tool. But is it still useful? What…
View Comments
As Gause and Weinberg wrote long ago, nonfunctional requirements are usually constraints on functional requirements. The context for a nonfunctional requirement is typically some set of system functions.
Accordingly, I think it makes sense to capture the nonfunctional requirements as acceptance criteria for epics or user stories, without separate stories for nonfunctional requirements.
Hi Roger, Thanks a lot for your comment. I share your view, as long as an NFR or constraint is limited to an epic or story. But when nonfunctional properties constrain the entire product or several epics, I find the introduction of a separate constraint story helpful. Examples are generic performance requirements, or a robustness requirement that applies to all payment stories. Do you agree?
It does seem like a judgment call. However, I find that nonfunctional requirements that apply to the entire system or more than one epic are a red flag. For example, it's unlikely that the same performance constraint truly is "required" for all functionality of the system.
I don't see it as a red flag. The example might be a bit too generic. But consider a story like "As Mary I want the homepage to be completely loaded within 500ms." A lot of stories in the development process will affect the homepage later - let's say of a web shop. Developing this NFR would mean 2 things in my point of view:
1. Make it load within 500ms now - this could be an epic in itself depending on the current state.
2. Create an automated test that will check with each new iteration that the constraint is still met.
What about a reliability requirement which expresses a scenario where after a system failure the system reboots and is operational in a certain amount of time? In this case, this is not associated to a particular functionality...
Given how you've suggested to describe NFRs, how do you propose the definition of 'done' should be for an NFR story? (since it's never actually 'done' due to NFRs being a constant constraint for every story pretty much)
I consider a constraint story as "done" when its narrative has been implemented successfully and the acceptance criteria are met. You may want to state in your Definition of Done that the generic NFRs in your Product Canvas or product backlog - those NFRs that apply to all stories - have to be fulfilled. Does this help?
But if restrictions must be met in all requirements, isn't this ultimately a good practice that should be incorporated as a standard and all requirements met?
Thanks for sharing your question, Rafael. It seems to me that we are essentially saying the same thing: If non-functional requirements are generally applicable, they must be met by all functional requirements/user stories. The question is how you implement this constraint. As I tried to explain in my previous reply, one way to do this is to refer to the global NFRs from the Definition of Done, assuming that you follow a Scrum-based process. Hope this helps!