Non-Functional Requirements - The basis for a good system

Home News Non-Functional Requirements: The basis for a good system

In my earlier blog, I elaborated on an effective approach to conducting a GAP analysis. One outcome of this analysis may be the need for a new system. This new system must meet the needs and requirements of the stakeholders. In order to best identify this, requirements are collected from these stakeholders. In this blog, I want to talk about non-functional requirements: what they are and why they are valuable. Change management also plays an important role here, since implementing a new system often involves structural changes within an organization.

What are non-functional requirements?

Retrieving requirements is a task that falls to the Business and Information Analyst. Requirements tend to be thought of as functional requirements. Functional requirements describe what the system must do to meet user needs. They are the specifications of the functions and desired behaviors that a system must provide.

Requirements that are frequently forgotten, but just as important, are the non-functional requirements (NFRs). NFRs ensure that a system is reliable, efficient and user-friendly. They describe the quality requirements and design constraints that a new system must meet. In addition, they affect the user experience and overall acceptance of the system.

What non-functional requirements are there?

When you search online for an overview of non-functional requirements categories, you get several results. The most comprehensive is the NEN-ISO/IEC 25010. In practice, I always use a more limited set of these. This was always sufficient for my projects. In this blog I explain which non-functional requirements I describe in my projects.

Performance: Performance describes how well a system performs in terms of speed, efficiency, and resource utilization.
Reliability (Reliability): Reliability describes the ability of a system to function stably and consistently within expected operational conditions.
Usability: Usability describes how easily and efficiently users can work with the system to achieve their goals.
Scalability (Scalability): Scalability describes the ability of a system to grow with increasing load or complexity without sacrificing performance, stability or ease of use.
Security (Security): Security describes the measures and mechanisms in place to protect data, users, and systems from unauthorized access, misuse, manipulation, and attack.
Maintainability (Maintainability): Maintainability refers to the ease and effectiveness with which software can be modified, improved or corrected during the software life cycle.
Portability: Portability focuses on the ability to move the system to other environments, operating systems or platforms without the need for modification or restructuring.
Compliance: Compliance refers to meeting regulations, standards and guidelines relevant to the software.
Availability (Availability): Availability refers to how often and how long the system is operational for users.
Extensibility: extensibility refers to the ability to easily add new functionality, modules or components without having to significantly modify or rewrite existing code.

Concrete examples of non-functional requirements can be found here.

How do I capture non-functional requirements?

As indicated, retrieving the non-functional requirements is a task for the Business and Information Analyst. These requirements must be retrieved from the stakeholders. Examples of stakeholders are end users, customers, the client, the system developer, etc. Gathering this information can be done by conducting interviews or organizing one or more workshops.

The non-functional requirements must then be documented. There is no one way to capture non-functional requirements. I usually choose to record them in a table. This table can be a separate document, but it can also be part of, for example, a Business Analysis Document. I give each requirement a unique number and a title. I add a description using the SMART principle (Specific, Measurable, Acceptable, Realistic, Time-bound). In addition, I add acceptance criteria and indicate under which NFR category the requirement falls. By recording the non-functional requirements in this way, it is possible to test whether the system meets all the requirements. For this, there are different types of testing. For example, stress testing, failover testing, penetration testing, usibilty testing and regression testing.