Incorrect structures in requirements specifications and functional specifications often lead to misunderstandings among the customer, product management and development. This article explains the differences between functional requirements and non-functional requirements and what needs to be considered.

The cause can often be found in the insufficient separation between functional requirements and non-functional requirements. In the worst case, a single requirement contains both types of requirements. Therefore, it is worth taking a closer look at this distinction, especially in the case of non-functional requirements.

A basic distinction is made between functional requirements and non-functional requirements.

The term functional requirement is easily understood: It is a functional requirement if it contains a technical function. If a functional requirement is formulated precisely, it is often easy to specify a unique test case.

A non-functional requirement is one where there is no function behind the requirement. In this case, it is more complex. In the case of non-functional requirements, a distinction must be made between two categories: qualitative requirements and boundary conditions. With the qualitative requirements, the topics are treated, such as performance, security, reliability, changeability/maintainability and portability. It is to be mentioned that the qualitative requirements are often not measurably formulated and consequently not testable. Nevertheless, in order to realize a test, non-measurable requirements must be transformed into functional requirements. In practice, linking (tracing) the qualitative requirement to the newly created functional requirements has proven to be effective for traceability and transparency. The boundary conditions define the conscious restrictions on the system. Laws, standards, technologies and processes have a limiting effect. The test cases of the boundary conditions are mostly analytically specified (such as: “is standard xy fulfilled?”).

The following is an example of a possible structure of a requirements specification.

• List of involved stakeholders
• Glossary
• Introduction
• List with changes of the document
• Context
• Use-case specification
• Functional requirements
• Non-functional requirements
• Business rules

In summary, a uniform basic understanding between the different types of requirements and their appropriate treatment is a fundamental prerequisite for increasing the quality of specifications.