Despite their name, non-functional requirements are critical to the development process. Unfortunately, it’s a lesson most engineers learn themselves before they enforce it.
For Director of Engineering Daniel Howard, that experience happened when building the first version of the gaming platform Versus Systems. Too much focus on getting to a feature-complete state without performance testing led to a long period of inability. Before the team could add new features, they first needed to backtrack and focus on scalability. Today, performance is built into the development process.
Howard said it is important to prioritize non-functional requirements because they profoundly impact the user experience. Users won’t notice new features if they are distracted with long loading times or frequent crashes. Because of their impact, non-functional requirements receive the same consideration as functional requirements, Howard said. Before each sprint, the product manager and engineers collaborate to prioritize both feature requests and NFRs. A dedication to NFRs now will save time and money — and spark new ideas — on future deployments.
“NFRs tend to originate from the engineering team rather than the product team, so they provide excellent opportunities for developers to be proactive in identifying problems and forming solutions,” Howard said.
Why is it important to prioritize non-functional requirements throughout the development process?
It all comes down to the user experience. You can have a ton of great features but still provide a terrible experience if they take forever to load, crash all the time or get hacked easily. You always prioritize things that will have the most significant impact, which might mean adding a new killer feature and improving response time or security.
When we were building out the first version of the Versus platform, we focused heavily on getting to a feature-complete state and then shipped the app without ever really testing performance under load. It was a huge relief to get the platform out the door, but then there was a very long period where we added no new functionality because everyone’s primary focus was on scalability. Now, load testing is woven tightly into our process.
We prioritize non-functional requirements the same way we prioritize features.”
How do you prioritize each non-functional requirement? Who else is involved in this process?
We prioritize non-functional requirements the same way we prioritize features. Each team has a grooming session before every sprint, where a product manager meets with engineers to prioritize work for the next cycle. At that point, feature requests are ranked alongside any NFRs that have arisen, and we generally end up with a mix of both in a given sprint. Larger non-functional initiatives may be broken out into their own projects with dedicated engineers.
I’d say the main difference between functional requirements and NFRs is that NFRs tend to originate from the engineering team rather than the product team, so they provide excellent opportunities for developers to be proactive in identifying problems and forming solutions.
In prioritizing NFRs, there can sometimes be trade-offs in which certain attributes either enhance or degrade others. How do you identify and balance these types of trade-offs and how do they inform your decisions around what to prioritize and when?
Our software runs sweepstakes and free giveaways, which come with lots of legal restrictions. We need to know several things about the contestants to make sure they’re eligible to win, and when someone wins something big, there are special tax rules to follow. All of this can get in the way of us providing a streamlined UX design. In a certain sense, it’s easy to know where to strike the balance because we’re not going to do anything that breaks the law. It’s more about being creative within those guidelines and figuring out how to provide the best experience we can.
