Definition and Differences between functional requirements and non-functional requirements

Functional requirements

Functional requirements are presented as lists of features or services that the system must provide. They also describe the behavior of the system against particular inputs and how it should react in certain situations.
Whether it is a user or a system, a functional requirement can be formulated at different levels of detail, naturally having to preserve the accuracy of the specification.
Two important characteristics of the requirements specifications are completeness and consistency.
A requirement specification document is complete if all the requirements requested by the users are defined and is consistent when there are no conflicting requirements.
Although for small systems these results are easily reachable, a greater effort is required for systems characterized by a high number of requirements.
In fact, in this second case, the difficulty is due to the greater occurrence of errors and omissions, as well as to the presence of a large number of stakeholders with different, at times conflicting, needs that may not be evaluated in the first phase of specification writing.
Therefore, the presence of inconsistencies could be escorted even after having delivered the product to the customer, giving rise to exorbitant costs.

Non-functional requirements

Non-functional requirements represent the constraints and properties / characteristics relating to the system, such as time constraints, constraints on the development process and on the standards to be adopted. The non-functional requirements do not only concern the software system being developed, some may constrain the process used to develop the system. Examples of this type are: the specifications of the quality standards to be used, the specification of the use of a particular CASE instrument, a description of the process to be followed.
Typically, non-functional requirements do not apply to individual functions or services, but to the entire system. They do not directly concern the specific functions provided by the system, but can either refer to features that the system requires (such as reliability, response times, memory occupation), or define the constraints to which the system must underlying (such as the capacity of the I / O devices and the data representation used in the system interfaces).
The non-functional requirements are strictly bound to the needs of the users, to the organizational policies adopted, to the standards used, to the necessary method of interaction of the relative system with other components. Therefore, they can be classified into:

1. product requirements, which describe the characteristics of the product, in terms of usability, efficiency, reliability and portability;
2. organizational (or process) requirements, which derive from organizational policies and procedures relating to the client and the developer;
3. external requirements, which refer to factors unrelated to the system and the related development process, such as legislative requirements, interoperability requirements.

The proposed classification has a purely theoretical character, as it comes in handy proposing a schematic view of the wide range of non-functional requirements that can intervene in the context of a project.

In fact, in reality, and even more so in the document that will have to describe them, it is practically impossible to implement such a rigid distinction between expressed concepts, perhaps in the same requirement, above all if we consider the relationships that exist between the various types of requirements.
Therefore, the one provided is only one possibility to classify the non-functional requirements. For example, only the product requirements could be considered non-functional, referring to others as “constraints”.