DevOps
SRE

What Are Software Quality Attributes (NFRs): Defining and Managing Excellence

Software Quality Attributes

You see, building software is a lot like cooking your favorite dish. Just as you add ingredients to make your meal perfect, software developers consider various elements to craft software that’s top-notch. These elements, known as “software quality attributes” or “non-functional requirements (NFRs),” are like the secret spices that elevate your dish from good to gourmet. 

Questions that Arise During Requirement Gathering

When embarking on a software development journey, one of the crucial initial steps is requirement gathering. This phase sets the stage for the entire project and helps in shaping the ultimate success of the software. However, as you delve into this process, a multitude of questions arises

1. Is this a need or a requirement?

Before diving into the technical aspects of a project, it’s essential to distinguish between needs and requirements. A “need” represents a desire or a goal, while a “requirement” is a specific, documented statement that must be satisfied. This differentiation helps in setting priorities and understanding the core objectives of the project.

2. Is this a nice-to-have vs. must-have?

In the world of software development, not all requirements are equal. Some are critical, often referred to as “must-have” requirements, while others are desirable but not essential, known as “nice-to-have” requirements. Understanding this distinction aids in resource allocation and project planning.

3. Is this the goal of the system or a contractual requirement?

Requirements can stem from various sources, including the overarching goal of the system or contractual obligations. Distinguishing between these origins is vital to ensure that both the project’s vision and contractual commitments are met.

4. Do we have to program in Java? Why?

The choice of programming language is a fundamental decision in software development. Understanding why a specific language is chosen, such as Java, is essential for aligning the technology stack with the project’s needs and constraints.

Types of Requirements

Now that we’ve addressed some common questions during requirement gathering, let’s explore the different types of requirements that guide the development process:

Functional Requirements

Functional requirements specify how the system should function. They define the system’s behavior in response to specific inputs, which lead to changes in its state and result in particular outputs. In essence, they answer the question: “What should the system do?”

Non-Functional Requirements (Constraints)

Non-functional requirements (NFRs) focus on the quality aspects of the system. They don’t describe what the system does but rather how well it performs its intended functions. 

The product quality model defined in ISO/IEC 25010 comprises the eight quality characteristics shown in the following figure

Source: https://iso25000.com/index.php/en/iso-25000-standards/iso-25010

Functional requirements are like verbs 

– The system should have a secure login

NFRs are like attributes for these verbs 

– The system should provide a highly secure login 

Two products could have exactly the same functions, but their attributes can make them entirely different products.

AspectNon-functional RequirementsFunctional Requirements
DefinitionDescribes the qualities, characteristics, and constraints of the system.Specifies the specific actions and tasks the system must perform.
FocusConcerned with how well the system performs and behaves.Concentrated on the system’s behavior and functionalities.
ExamplesPerformance, reliability, security, usability, scalability, maintainability, etc.Input validation, data processing, user authentication, report generation, etc.
ImportanceEnsures the system meets user expectations and provides a satisfactory experience.Ensures the system performs the required tasks accurately and efficiently.
Evaluation CriteriaUsually measured through metrics and benchmarks.Assessed based on whether the system meets specific criteria and use cases.
Dependency on FunctionalityIndependent of the system’s core functionalities.Dependent on the system’s functional behavior to achieve its intended purpose.
Trade-offsBalancing different attributes to achieve optimal system performance.Balancing different functionalities to meet user and business requirements.
CommunicationOften involves quantitative parameters and technical specifications.Often described using user stories, use cases, and functional descriptions.

Understanding NFRs: Mandatory vs. Not Mandatory

First, let’s clarify that Functional Requirements are the mandatory aspects of a system. They’re the must-haves, defining the core functionality. On the other hand, Non-Functional Requirements (NFRs) introduce nuances. They can be divided into two categories:

Mandatory NFRs: These are non-negotiable requirements, such as response time for critical system operations. Failing to meet them renders the system unusable.

Not Mandatory NFRs: These requirements, like response time for user interface interactions, are important but not showstoppers. Failing to meet them might mean the system is still usable, albeit with a suboptimal user experience.

Interestingly, the importance of meeting NFRs often becomes more pronounced as a market matures. Once all products in a domain meet the functional requirements, users begin to scrutinize the non-functional aspects, making NFRs critical for a competitive edge.

non-functional requirements

Expressing NFRs: a Unique Challenge

While functional requirements are often expressed in use-case form, NFRs present a unique challenge. They typically don’t exhibit externally visible functional behavior, making them difficult to express in the same manner.

This is where the Quality Attribute Workshop (QAW) comes into play. The QAW is a structured approach used by development teams to elicit, refine, and prioritize NFRs. It involves collaborative sessions with stakeholders, architects, and developers to identify and define these crucial non-functional aspects. By using techniques such as scenarios, trade-off analysis, and quality attribute scenarios, the QAW helps in crafting clear and measurable NFRs.

Good NFRs should be clear, concise, and measurable. It’s not enough to list that a system should satisfy a set of NFRs; they must be quantifiable. Achieving this requires the involvement of both customers and developers. Balancing factors like ease of maintenance versus adaptability is crucial in crafting realistic performance requirements.

There are a variety of techniques that can be used to ensure that QAs and NFRs are met. These include:

  • Unit testing: Unit testing is a type of testing that tests individual units of code.
  • Integration testing: Integration testing is a type of testing that tests how different units of code interact with each other.
  • System testing: System testing is a type of testing that tests the entire system.
  • User acceptance testing: User acceptance testing is a type of testing that is performed by users to ensure that the system meets their needs.

The Impact of NFRs on Design and Code

NFRs have a significant impact on high-level design and code development. Here’s how:

  • Special Consideration: NFRs demand special consideration during the software architecture and high-level design phase. They affect various high-level subsystems and might not map neatly to a specific subsystem.
  • Inflexibility Post-Architecture: Once you move past the architecture phase, modifying NFRs becomes challenging. Making a system more secure or reliable after this point can be complex and costly.

Real-World Examples of NFRs

To put NFRs into perspective, let’s look at some real-world examples:

  • Performance: “80% of searches must return results in less than 2 seconds.”
  • Accuracy: “The system should predict costs within 90% of the actual cost.”
  • Portability: “No technology should hinder the system’s transition to Linux.”
  • Reusability: “Database code should be reusable and exportable into a library.”
  • Maintainability: “Automated tests must exist for all components, with overnight tests completing in under 24 hours.”
  • Interoperability: “All configuration data should be stored in XML, with data stored in a SQL database. No database triggers. Programming in Java.”
  • Capacity: “The system must handle 20 million users while maintaining performance objectives.”
  • Manageability: “The system should support system administrators in troubleshooting problems.”

The relationship between Software Quality Attributes and NFRs

As and NFRs are both important aspects of software development, and they are closely related.

  •  Software Quality Attributes are characteristics of a software product that determine its quality. They are typically described in terms of how the product performs, such as its speed, reliability, and usability.
  • NFRs are requirements that describe how the software should behave, but do not specify the specific features or functions of the software. They are typically described in terms of non-functional aspects of the software, such as its security, performance, and scalability.

In other words, QAs are about the quality of the software, while NFRs are about the behavior of the software.

The relationship between QAs and NFRs can be summarized as follows:

  • QAs are often used to measure the fulfillment of NFRs. For example, a QA that measures the speed of the software can be used to measure the fulfillment of the NFR of performance.
  • NFRs can sometimes be used to define QAs. For example, the NFR of security can be used to define a QA that tests the software for security vulnerabilities.
  • QAs and NFRs can sometimes conflict with each other. For example, a software product that is highly secure might not be as user-friendly.

It is important to strike a balance between  Software Quality Attributes and NFRs. The software should be of high quality, but it should also meet the needs of the stakeholders.

Here are some examples of the relationship between QAs and NFRs:

  • QA: The software must be able to handle 1000 concurrent users.
  • NFR: The software must be scalable.
  • QA: The software must be able to recover from a system failure within 5 minutes.
  • NFR: The software must be reliable.
  • QA: The software must be easy to use.
  • NFR: The software must be usable.
Let’s work together!

See how we can help to overcome your challenges

FAQ

What are Non-Functional Requirements (NFRs)?

Non-Functional Requirements (NFRs) are criteria that define how well a software system performs its intended functions. Unlike Functional Requirements, which specify what the system should do, NFRs focus on how well it does it. They cover aspects like performance, usability, security, and more.

Why are NFRs important in software development?

NFRs are crucial because they ensure that a software system not only works but also meets user expectations for quality. Neglecting NFRs can lead to issues like poor performance, security vulnerabilities, or an unsatisfactory user experience.

How do I distinguish between Functional and Non-Functional Requirements?

Functional Requirements describe what the system should do, typically in the form of use cases or specific functions. Non-Functional Requirements describe how well it should do it, focusing on qualities like speed, reliability, and usability.

What are some common types of NFRs?

Common types of NFRs include performance (response times, throughput), usability (user interface design, user-friendliness), security (data protection, access control), maintainability (ease of updates and enhancements), and reliability (system uptime and error handling).

Are NFRs more critical in mature markets?

Yes, as markets mature and users expect basic functionality to be met, NFRs become more critical. Users start evaluating software based on quality attributes like performance and usability.
arrow arrow

Thank you
for contacting us!

Please, check your email

arrow arrow

Thank you

You've been subscribed

We use cookies to enhance your browsing experience. By clicking "Accept," you consent to the use of cookies. To learn more, read our Privacy Policy