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.

Popular posts from this blog

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t

DevToys–A swiss army knife for developers

As a developer there are a lot of small tasks you need to do as part of your coding, debugging and testing activities.  DevToys is an offline windows app that tries to help you with these tasks. Instead of using different websites you get a fully offline experience offering help for a large list of tasks. Many tools are available. Here is the current list: Converters JSON <> YAML Timestamp Number Base Cron Parser Encoders / Decoders HTML URL Base64 Text & Image GZip JWT Decoder Formatters JSON SQL XML Generators Hash (MD5, SHA1, SHA256, SHA512) UUID 1 and 4 Lorem Ipsum Checksum Text Escape / Unescape Inspector & Case Converter Regex Tester Text Comparer XML Validator Markdown Preview Graphic Color B