Non-Functional Requirement (NFR)

During the development process, most people tend to focus on analyzing and documenting the system's functional requirements—that is, the requirements concerning specific functions and features that the software must have. However, there is another crucial factor that, while not directly related to functionality, significantly impacts the product's success: Non-functional Requirements (NFRs).

In this article, we will clarify what NFRs are and what a Business Analyst (BA) needs to do with these requirements.

1. What are Non-functional Requirements?

To make it simple, Non-functional Requirements are requirements that are not related to the specific functions of the system but focus on aspects such as:

• Performance: The processing speed and responsiveness of the system.

  • Example: The system must be able to handle 1000 concurrent requests.

• Security: The ability to protect data and the system from unauthorized access.

  • Example: User data must be encrypted to protect personal information.

• Reliability: The ability of the system to operate stably and continuously.

  • Example: The system must operate 24/7 with downtime not exceeding 10%.

• Usability: The ease of use and user-friendliness of the user interface.

  • Example: The interface must be intuitive, easy to understand, and easy to navigate.

• Maintainability: The ease with which the system can be repaired, upgraded, and maintained.

  • Example: The code must be written clearly, be easy to understand, and have a good structure.

• Scalability: The ability to expand the system to meet growing demands.

  • Example: The system must be capable of handling an increasing volume of data and users.

And other types of requirements such as screen size compatibility, etc.

2. Why are Non-functional Requirements Important?

Although Non-functional Requirements do not directly create new features for the product, they play a key role in ensuring its quality and success.

For instance:

• An online banking application with slow, sluggish transaction processing speeds will easily frustrate users and cause them to switch to another bank's app.

• An insecure e-commerce website can be attacked by hackers, leading to data loss for both the business and its users, damaging the business's reputation.

• An application with a confusing and difficult-to-use interface may lead users to uninstall it after just a few interactions.

Therefore, ignoring Non-functional Requirements is like "building a house without a foundation"—the product can "collapse" at any moment.

3. What Should a BA Do with Non-functional Requirements?

There are many different types of NFRs; you can refer to my sample file https://www.tankbaclass.com/file-share/54122932-852f-4ad2-a5f1-161dbd80fd5a. For a BA, not all types of NFRs need to be handled by you. Below, I will list common types of NFRs and classify which ones a BA needs to handle and follow, and which ones they do not.

3.1 NFRs that BAs Need to Handle:

• NFRs directly related to business operations: For example, performance requirements for a payment system, security requirements for customer information, or usability requirements for the user interface.

• NFRs affecting the user experience: For example, page load speed requirements, user interface aesthetics, or accessibility on different devices.

• NFRs related to standards and regulations: For example, data security requirements according to GDPR, or accessibility requirements for people with disabilities according to WCAG.

In these cases, a BA needs to:

• Proactively elicit and analyze NFRs: Find NFRs in documents, meetings, or through discussions with clients and senior BAs.

• Describe NFRs clearly and specifically: Use measurable criteria to quantify NFRs. For example, "The system must have an average response time of less than 3 seconds."

• Discuss and align with stakeholders: Ensure everyone has a shared understanding of the NFRs and how to implement them.

• Track and verify: Ensure NFRs are met throughout the development process and after the product is deployed.

3.2 NFRs that BAs Do Not Need to Handle:

• Highly technical NFRs: For example, requirements regarding database architecture, programming languages, or server performance. These are typically handled by the development team or a Software Architect (SA).

• NFRs related to the testing process: For example, requirements for test case coverage or testing tools. These are usually handled by testers.

• NFRs related to project management: For example, requirements concerning schedule, budget, and risk management. These are typically handled by the project manager.

In these cases, a BA needs to:

• Clearly understand the content of the NFRs: Ensure you understand their meaning and importance, even if you are not the one implementing them directly.

• Communicate the NFRs to the relevant parties: Ensure the dev team, testers, and project manager understand the NFRs and their responsibilities in implementing them.

• Track and monitor: Follow the implementation of the NFRs and report any issues to the relevant stakeholders.

Non-functional requirements are an indispensable part of developing a software product. A product, no matter how good its features are, will easily disappoint users and cause them to abandon it if its non-functional requirements are not met or are inadequately addressed. Understanding, thoroughly analyzing, and effectively managing NFRs helps a BA create higher-quality products, contributing to the project's success. We hope this article helps you gain a clearer understanding of NFRs and the importance of this type of requirement.