This post discusses why non-functional requirements like performance, robustness, and interoperability matter, and how you can discover and describe them.
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 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 non-functional 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 non-functional 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 or 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.
I like to capture non-functional requirements as constraint stories. Here is an example:
I call the story above a constraint story, 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 non-functionals, 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 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. Capture the requirements precisely to ensure testability.