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.