With fast-approaching deadlines, ever-expanding to-do lists and launch dates looming, engineers juggle a lot. It’s easy to let certain priorities and good habits slide when crunch time hits.
But according to Ryan Betts, vice president of engineering at InfluxData, it’s vital that non-functional requirements stay at the top of every engineer’s mind. While functional requirements stipulate what a system does, NFRs dictate how well the system does it — think response time, user experience and security.
“If a team ignores non-functional requirements, they will inevitably fall behind in their iteration velocity as code becomes brittle, entangled, poorly tested and otherwise encumbered,” Betts said. “As this happens, quality decreases, delivery dates slip and become less certain.”
Without NFRs, software can still work; it just might not work as well as anyone would like. And for Tony Dong, an engineering manager at Rippling, that’s an important distinction. To avoid spending time building software the user can’t easily use, his team sets concrete NFRs at every project’s kick-off meeting.
“Non-functional requirements help to focus us on the ‘what’ and ‘why’ of the product we’re building,” Dong said. “We really want to focus on building not just products that functionally work, but products that meet the user’s expectations.”
NFRs can delight customers and engineering teams alike, but defining and championing them takes work. Three tech leaders from around the Bay Area spoke to Built In San Francisco about why they think it’s worth it.
Why is it important to prioritize non-functional requirements throughout the development process?
Like many other software engineering professionals, I like to define the functional and non-functional requirements of the project when writing the project requirement document. Working in the tech industry for a few years now, I have learned that non-functional requirements, sometimes referred to as “quality requirements,” are equally as important as the functional requirements. Not prioritizing them may result in unusable software — even if your system delivers all the functional requirements right.
Even though most engineers know the importance of attributes like software quality, performance, reliability, security and scalability, sometimes ambitious timelines and the pressure to deliver the project can result in ignoring non-functional requirements. As an engineer, I always thought of NFRs as implicit requirements and kept them in mind when developing software, but until recently, I considered them secondary to functional requirements.
Ambitious timelines and the pressure to deliver the project can result in ignoring non-functional requirements.”
I worked on a project that involved developing an API that provided data to all the internal systems at Fivetran. When developing the requirement document for that project, as always, I listed all the functional requirements in detail with a limited section describing the non-functional requirements. After completing all the functional requirements, I felt the system was ready and started testing.
I quickly realized that sometimes the system takes more than 30 seconds to respond under heavy loads. Since the project catered data to all kinds of applications ranging from the user-facing websites, external APIs, long-running scheduled jobs to cron jobs that run every minute, a response time of 30 seconds was unacceptable to some of the applications. A cron job that runs every minute cannot use an API that takes 30 seconds to provide data. That was the moment I realized how important the performance was, because it made the system unusable for some of the applications.
Even though the system met all the functional requirements, it was not ready to be pushed to production. I took a step back, spent some time thinking about the architecture and spent two weeks optimizing the system for the desired performance. That experience showed that if I concentrated equally on NFRs from the start, I would have delivered the project earlier.
How do you prioritize each non-functional requirement? Who else is involved in this process?
Prioritizing all the NFRs are very important. Not prioritizing any one of them could result in an unusable system. I believe the entire engineering team working on the software should be involved in prioritizing the NFRs, along with the stakeholders from the client applications planning on using the software.
Before the team can prioritize the NFRs, defining them clearly is very important. Specifying that the system should be fast, scalable, accurate and secure is very different from defining exact numbers, like the system should respond in less than 3 seconds or be able to handle 100,000 requests per second. Having a clear metric of what you are trying to achieve speeds up the development process and helps make the right architectural decision.
When prioritizing NFRs, how do you balance the trade-offs that enhance or degrade certain attributes?
Prioritizing NFRs comes with certain trade-offs, so finding the right balance is very important. For example, setting the performance expectation of the software to 1 second is very different than setting it to 3 seconds. Agreeing to 99.99 percent availability is very different from agreeing to 99.95 percent. When defining all these requirements, you need to spend some time discussing the business requirements with the team and stakeholders to see if you need 99.99 percent availability or if your business use case can work well with 99.95 percent.
Keeping the requirement realistic is critical to finding a balance. For example, designing a system for 100 million users per day when you anticipate that your website will have 10,000 visitors per day for the next six months would not make sense. By the time you finish developing for this aggressive requirement, you might not even need this system, or the stakeholders might have figured out an alternative. The key to a successful project is finding a balance between the business requirements, quality attributes and time to market.
Why is it important to prioritize non-functional requirements throughout the development process?
Customers care about quality, timeliness and product evolution. Of these, quality is the only one typically captured as a functional requirement. If a team ignores non-functional requirements, they will inevitably fall behind in their iteration velocity as code becomes brittle, entangled, poorly tested, and otherwise encumbered. As this happens, quality decreases, delivery dates slip and become less certain, and iteration speed falls. Each of these will cause more harm to a customer relationship.
If a team ignores non-functional requirements, they will inevitably fall behind in their iteration velocity.”
As we built our Time Series cloud product, we ended up with an API gateway implementation that did not cleanly separate concerns. This part of the code base caused performance and reliability issues, almost all of which were directly attributable to code structure. The API itself met functional requirements, but creating new APIs, scaling API request capacity and managing deployment of new API code became fragile and frustrating. Taking the time to untangle this code, correct bad abstractions and improve observability and monitoring have all paid off in improved iteration speed and decreased defect rates.
Betts’ four steps to prioritizing non-functional requirements
- Observability is a feature and a core part of the product: Know how you are going to measure feature performance to understand the feature’s impact on users and adoption.
- Be a good consumer: Enable your peers to understand continuous integration dependencies and to trust that passing CI means your service will function. Provide a way for them to know their changes are safe.
- Be a good provider: When making changes that will affect callers of your service, be diligent in making those changes safe. Provide a clear API so that consumers understand your service's contracts.
- Use a definition of ‘done’ to control technical debt and quality: Use your team’s definition of done to enforce a standard of code review, unit testing, integration testing, observability, migration planning, feature-flagging/deployment planning, user documentation and operational runbooks.
When prioritizing NFRs, how do you balance the trade-offs that enhance or degrade certain attributes?
In my experience, complex trade-offs between NFRs often indicate a missing consensus around strategy. Deciding the shape of a product is an evolutionary and iterative process. As that vision evolves, NFRs also change. Often, conflict between NFRs happens in these gray areas where product strategy, positioning or pricing is being questioned and improved.
If you find your team can’t reach a consensus on NFRs, it can be useful to widen the aperture and understand if they have a shared understanding of the product strategy.
Why is it important to prioritize non-functional requirements throughout the development process?
Rippling focuses on building very user-facing products. Non-functional requirements help us to focus on the “what” and the “why” of the product we’re building. We really want to focus on building not just products that functionally work, but products that meet the user’s expectations. A lot of our NFRs focus on usability and user experience of the product and if it actually solves the user’s needs. This is something we continually prioritize in every project.
A lot of our NFRs focus on usability and user experience of the product and if it actually solves the user’s needs.”
An example of a project where we focused on NFRs is in our reports feature. This feature allows customers to slice and dice their data, performing complicated filtering and aggregations. A non-functional requirement was that we created a responsive interface for applying filters and aggregations. This requirement drove us to build drag-and-drop UI components and dynamic data previewing. These two features created a seamless experience for the user to preview the results of their selection in real time without operating over the entire dataset. It enabled users to gain a more in-depth understanding of the tool through continuous exploration and feedback.
How do you prioritize each non-functional requirement? Who else is involved in this process?
We start gathering NFRs as part of the project kick-off with engineering, product and design, as well as other stakeholders. We try to look holistically at what users are trying to accomplish and from there, determine both functional and non-functional requirements of the project. During the development of the project, we will have weekly syncs in place to help keep us aligned on our goals and make sure we’re building the product in a way that’s actually solving the user’s needs.
When prioritizing NFRs, how do you balance the trade-offs that enhance or degrade certain attributes?
We typically look at two different dimensions when it comes to NFRs: customer impact and building speed. We measure customer impact by looking at the frequency and intensity of the problem they have because we haven’t built the product yet. As with any startup, projects don’t happen in a vacuum. You're prioritizing against all of the other projects in your backlog, so we always try to maximize our output and impact.
When we’re looking at NFRs within a project, we first make sure that it’s the most important thing we should be working on as a team. After that, we look at all of the possible things we could be building within this project and figure out how to maximize our development efforts to have the most customer impact.
