This post discusses nonfunctional requirements such as performance, robustness, and interoperability, and the Ford Shelby Mustang GT500.
I don’t know about you, but every time I read the word “nonfunctional”, I feel a yawn coming on, and I start to look for something else to do. While nonfunctional requirements or quality attributes, as they are also called, may not be sexy, 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 engine, 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 the actual fuel 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.
Discovering Nonfunctionals
As important as they are, nonfunctional 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 nonfunctional 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 if, for instance, the performance is acceptable.
The development team is a great partner for finding relevant nonfunctional 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.
Describing Nonfunctionals
I like to capture nonfunctional requirements as constraint stories. Here is an example:
I call the story above a constraint, as it constraints 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 nonfunctional 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 nonfunctionals, ensure that the description 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 nonfunctional 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. Capture the requirements precisely to ensure testability. And don’t rush to test-drive a Ford Shelby Mustang GT500 depicted at the top of this post. It’s not the greatest sports car on the planet – at least according to Top Gear’s Jeremy Clarkson.
Learn More
You can find out more about working with nonfunctional requirements by attending my Certified Scrum Product Owner training course. Unfortunately, I won’t be able to tell you more about Mustang cars: I’ve only driven one many years ago and only for a few miles. All I remember is: It was fast.
Post a Comment or Ask a Question
7 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.
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…
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.
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?