Skip to main content

Don’t talk about non-functional requirements, talk about quality attributes

When discussing software development, terms shape our perception and priorities. One such discussion revolves around the terminology used for requirements that go beyond direct functionalities. Traditionally, when talking about architectural needs, I used to call them non-functional requirements (NFRs). However, I switched recently to a  more fitting term—quality attributes—as it may better emphasize their importance and value. 

 

Generated by AI

Let me explain why this more than just a semantic change but a strategic enhancement…

What are non-functional requirements?

Before I explain my reasoning, let me shortly define what non-functional requirements are:

Non-functional requirements (NFRs), also known as quality attributes, refer to criteria that judge the operation of a system rather than specific behaviors or functions. These requirements define the overall qualities and characteristics that the system must possess, ensuring it meets user needs and performs efficiently and effectively in its environment. Some key requirements include:

  1. Performance: How fast and efficiently the system responds under various conditions.
  2. Usability: The ease with which users can interact with the system.
  3. Reliability: The system’s ability to operate consistently over time.
  4. Security: The measures in place to protect the system from unauthorized access and vulnerabilities.
  5. Maintainability: How easily the system can be modified to correct faults, improve performance, or adapt to a changed environment.

The Problem with "Non-Functional Requirements"

I noticed that using the term "non-functional requirements" often leads to misunderstandings and undervaluation. Business stakeholders see only their requirements as important and the ‘real’ requirements whereas these NFR’s are something that cost a lot of money, don’t add any value and only IT cares about.

Here are a few reasons why:

  1. Negative Connotation: The prefix "non-" implies a lack or absence, which may subconsciously devalue these requirements compared to functional ones.
  2. Ambiguity: The term is broad and vague, encompassing a variety of aspects such as performance, usability, reliability, and security without specifying their critical roles.
  3. Perceived Secondary Importance: Developers and stakeholders might prioritize functional requirements over NFRs, believing that the latter are secondary concerns.

The Case for "Quality Attributes"

By reframing non-functional requirements as quality attributes I noticed that it significantly enhanced their perceived value and importance. Instead of perceiving them as a secondary(less important) list of requirements, they became a core element in all discussions we had with business stakeholders.

Here’s why:

  1. Positive Framing: The term "quality attributes" inherently emphasizes the positive impact these requirements have on the overall system.
  2. Clarity and Specificity: It directly ties these requirements to the quality of the product, making it clear that these attributes are essential for a high-quality system.
  3. Equal Importance: Referring to these requirements as quality attributes encourages stakeholders to consider them as integral and critical as functional requirements.

Take away

Domain Driven Design and the concept of the ubiquitous language already learned us the importance of using the right words to describe something.  I experienced this first hand.

Shifting from the term non-functional requirements to quality attributes turned out more than just a change in terminology. It’s a strategic move that highlights the essential role these attributes play in creating high-quality software. By emphasizing quality attributes, we not only enhance the perceived value of these requirements but also drive the development of more robust, efficient, and user-friendly systems. This shift can lead to better prioritization, improved software quality, and ultimately, greater satisfaction for all stakeholders involved.

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more