Functional and Non-Functional Requirements – When Do I Need Them?

When you build a product or solution using Agile approach, you will likely need to deal with a variety of requirements from different sources. The two most common types of requirements that you will likely encounter are Functional Requirements (FRs) and Non-Functional Requirements (NFRs). Many teams struggle to gain a clear understanding of these two types of requirements, which can often lead to less-than-desirable performance and output.

Let’s take a look at both of these types of requirements so we can gain a solid understanding.

Functional RequirementIn its simplest form, a functional requirement describes the user’s desired experience with the system. For example, able to conduct some type of business process and/or transaction. On the other hand, Non-Functional Requirements are much more subtle; they usually describe system-level behavior and/or performance (such as system availability, scalability, performance, etc.), which is usually assumed or not explicitly stated. For example, Consumers often assume a cloud-based web application would be secure and responds within a few seconds.

This table below describes a few of the common characteristics for both FRs and NFRs. Let’s take a closer look and see what similarities and differences there are.





Contract, scope document, customers, stakeholders, users, etc.

Architects, engineering teams, support teams, etc.


User stories, Epics, Features

User stories, technical specifications


Product Manager, Product Owner, Business Analyst

Architect, Project Lead

Typical Level of Detail

Low to medium

Low to high


The originating point for functional requirements is usually the end consumer or paying customer. The people who have a need for a product or service usually has a problem that needs to be solved, and these are usually expressed in the form of functional requirements. This information is commonly recorded and tracked in different forms of documentation.

As for Non-Functional Requirements, the source is not quite as predictable. Many times, these requirements are generated by internal technical staff, possibly a System Administrator, Architect, or Systems Engineer who has a broader view of the overall system. These experts can often drive Non-Functional Requirements to ensure the product meets security and/or performance needs of the customers.


The format used to capture FRs and NFRs are generally very similar. System behavior is usually easier to describe and articulate in the form of technical specifications, but they may be written as User Stories as well.


Ownership and management of requirements can vary significantly depending on the organization, but the most common practice for Functional Requirements is through Product Management or Business Analysis specialists. Non-Functional Requirements can also be managed by the same staff but are often handled by the product development team.

Level of Detail

The level of detail for FRs and NFRs can also vary drastically depending on what type of product/system is being built, but in most cases, Non-Functional Requirements tend to have more specificity due to the need to quantify system behavior. For example, if a system is required to have an uptime of 99.99% instead of 99.9%, the seemingly small different can represent significant amount of effort and cost. Hence, the level of detail for Non-Functional Requirements is generally more critical than Functional Requirements which can be broader in scope.

In closing, both Functional and Non-Functional Requirements are important pieces of data to develop and maintain effectively because they are central to the value that your team needs to deliver and realize for the customers.

Requirements Management

View Course
Eugene Lai
Eugene Lai