When we talk about non-functional requirements, we're not talking about features in the menu or user-facing functionality.
We're talking attributes and characteristics, how the system exists in-the-world.
Things like it runs on Android and iOS.
It loads within half a second.
Works in Chrome, Edge, Safari, and maybe Firefox.
It handles 100,000 concurrent users.
And it follows brand standards.
These aren't functionality.
They're constraints.
There are qualities.
The often make or break a user's experience, but they're not always obvious.
Here's the problem.
Non-functional requirements apply across multiple stories or even an entire system.
That makes them harder to define, harder prioritize, and harder test, especially if they are vague.
Be fast means nothing.
Respond within half a second with 100,000 concurrent users, that's actionable.
And because NFRs are not attached to any one story, they often get ignored until they blow up, slow performance, cause security issues,
fail to support a browser, you name it.
Here's a better way to handle them.
Start by creating a user story to come into compliance.
then once you've got it working, add that requirement to your definition of done so you stay in compliance.
Let's say you support Chrome Edge and Safari.
Eventually, you want to add Firefox.
To ensure you don't forget to do that, write a story.
When I visit the site in Firefox, it works.
when that story bubbles up in priority, do the work to implement it.
Then update your Definition of Done.
Supports Chrome, Edge, Safari, and Firefox Another example, maybe you support English, German, and Spanish.
You want to add French.
you begin with a story, as a French speaking user, I want it to interact with the site in my preferred language.
Again, As it becomes a priority, it's worked on and finished.
Then you update your definition of done again, supports English German Spanish and French This approach works because it enables adding support for new
non-functional requirements to a product, but also helps a team remember ones they need to continue supporting.
So remember, nonfunction requirements are about how your system exists in the world.
Start by writing them as user stories.
Then as each becomes a priority, do the work to come into compliance with that story.
Finally, add each to your definition of done.
If this was helpful, hit like, subscribe, or drop a comment with how your team handles non-functional requirements.
See you next time.
So remember, nonfunction requirements are about how you system exists in the world.
Start by writing them as user stories.
Then as each becomes a priority, do the work to come into compliance with that story.
Finally, add each to your definition of done.
If you'd like more help working with user stories, download my 200 User Story Examples PDF.
It showcases the good, bad, and ugly user story from one of my early Agile projects with comments from me now on how I'd improve some of those user's stories
if I were writing them today.
You'll find the link in the description.
See you next time.