Non-Functional Requirements: The Backbone of Great Software - Part 2

Non-functional requirements (NFRs) are as critical as functional requirements because they define a system's qualities and operational parameters.

Functional requirements specify what a software product should do (for example, “users must be able to log in”). However, non-functional requirements define how well it must accomplish these tasks under real-world conditions (for example, “the login process should respond within two seconds under peak load” or “all user credentials must be encrypted and stored securely”).

Together, functional and non-functional requirements create a foundation for building great software systems. 

In Part 1 of this topic, we also looked at trade-offs in non-functional requirements and the architectural impact of these requirements. Some key learning points from Part 1 were as follows:

• Non-functional requirements determine a system's performance in areas such as scalability, response time, performance, security, etc., ensuring it meets quality standards and user expectations beyond mere functionality.

• Functional requirements focus on what the system should do, while non-functional requirements define how well it operates under real-world conditions.

• Optimizing one NFR (for example, performance) can negatively impact others (for example, maintainability), requiring a balanced approach based on project goals and constraints.

• Non-functional needs (like scalability and availability) heavily influence architecture choice. For example, choosing microservices for high availability or plugin-based designs for modifiability.

In this article (Part 2), we’ll go further and look at some of the most important NFRs that should be considered while building systems.

Key NFRs to Consider

Some key non-functional requirements that should be considered while designing an application are as follows:

Response Time/Latency