According to CTO Chris VanAvermaete of consulting firm Inspirant Group, the term “non-functional requirement” is a bit of a misnomer for a system quality that is generally just as critical as a functional requirement.
“I’ve always prioritized NFRs like I prioritize regular functional requirements,” VanAvermaete said.
NFRs ensure the effectiveness and usability of an entire system, defining system attributes like performance, security, scalability, reliability and more. Despite their name, NFRs are necessary to deployments; failing to meet an NFR can lead to security issues and even non-compliance with regulatory or standards agencies.
To deal with competing priorities, VanAvermaete categorizes all NFRs within a range of low to critical requirements. Critical NFRs would damage the enterprise if not addressed, while low requirements are considered nice-to-haves that can act as building blocks for future tech releases.
But it’s not up to VanAvermaete alone to categorize NFRs.
Input from project stakeholders, product owners, managers and architects ensure that the functions deemed “critical” align with the business vision.
In your opinion, why is it important to prioritize non-functional requirements throughout the development process?
As an architect, I’ve always kept a placeholder for non-functional requirements to be completed before architecture or design tasks could be completed and encouraged continuous testing throughout the development process where possible. I have occasionally got bit by less-than-comprehensive NFRs that fail to take into account all use cases.
For example, we built a system that was a series of microservices for inserting, updating and searching for records. The idea was that services would be used by both a user-centric web app for searches and updates and other systems that would invoke them through batch and real-time interfaces for inserts. We built the services, tested them using load-testing agents and determined that our system performance was both fast and scalable over what was needed.
What we did not take into account is that while the system could handle a single transaction in less than 500 milliseconds as well as hundreds of transactions per second in parallel, most of the systems we integrated with would be sending hundreds of thousands of transactions per day into the system one at a time due to the nature of their mainframe batch technologies. While our load tests could push 100,000 transactions into the system in less than 10 minutes using multi-threading, it would take nearly 14 hours for the other systems to send in the transactions single-threaded. Fortunately, we discovered this during data load dress rehearsals and were able to build a process that would process the files on behalf of the other systems to meet timing needs.
I’ve always prioritized NFRs like I prioritize regular functional requirements.”
How do you prioritize each non-functional requirement? Who else is involved in this process?
I’ve always prioritized NFRs like I prioritize regular functional requirements. Critical requirements are things the system can’t go live without and would damage the enterprise as a whole if not addressed, such as regulatory compliance or security requirements for systems that are outward-facing.
High requirements are those that should not go live, but are more limited in scope to a certain user base and may have manual workarounds to address; this is normally about performance and scalability.
Medium requirements tend to fall into the category of things that don’t comply with enterprise architecture guidelines and may affect total cost of ownership, supportability and maintainability.
Low requirements are “nice-to-haves” that usually align with future technology directions or enterprise architecture next-gen initiatives that are not yet standards. All of these levels are important and implementation plans need to address each level, though not all may be implemented in a given release. Categorization of these levels is a joint effort by business stakeholders, product owners and managers and architects.
In prioritizing NFRs, there can sometimes be trade-offs in which certain attributes either enhance or degrade others. How do you inform your decisions around what to prioritize and when?
By prioritizing the NFRs as noted above, you have a rough order of which requirements need to take precedence in the case of competition or constraints. Ultimately, when two very high requirements are conflicting, it’s usually the development or testing teams that need to quantify the trade-off. Then, it’s up to the architects and stakeholders to negotiate a reasonable compromise.
