Functional vs Non-Functional Requirements – How to Write FRs & NFRs

User Stories are a popular way to define requirements for software projects. Compared to traditional requirements, they dramatically improve communication between people who need the software and those who can deliver it, leading to better digital solutions.

This post is about analyzing a User Story and turning it into something software developers can deliver. It assumes you are familiar with the User Story paradigm or have read my earlier post, The Everything User Story Guide: Tips and Tricks for Writing Better Requirements.

Functional vs Non-Functional Requirements: What is the Difference?

Most developers will tell you that User Stories are fantastic. However, the User Story alone is not enough for them to start coding. The User Story expresses WHO needs WHAT and WHY they need it. For developers, that is just the start of a discussion. To deliver working software, they need a lot more detail about your request.

Specifically, they need to understand:

• what the software should DO (Functional Requirements) and
• how well it should DO it (Non-Functional Requirements)

That is the main reason that the development team and business representatives must collaborate to write User Acceptance Criteria for the User Story.

This post will show you a method for effectively breaking down a User Story into its functional and non-functional items. This technique is called Functional Decomposition (aka Functional Breakdown), and it is used to reach the level of requirements that the International Institute of Business Analysis™ (IIBA®) calls Solution Requirements.

These two dimensions are really the crux of software development. But before we get into the how-to define FRs and NFRs, let me set the stage by defining them.

What Are Functional Requirements?

Functional Requirements (FRs) are the backbone of most software development projects. They are what your product will do for users, and what makes people want to use it.

FRs are the “detailed what” of a solution. They include the functions and associated data that a solution, feature, or product will provide. The terms “Functional Requirements” and “Functional Specifications” are often used interchangeably to mean the same thing.

Think of them like blueprints; they give you all the details you need to build your new house—they tell you how many rooms there will be, how big they will be, how many windows there will be per room, etc.—so you do not have to worry about those things while you are building.

FRs ensure that all decisions made during software development revolve around solving the problem at hand in a way that meets the needs of your business stakeholders and users.

In a Lean/Agile environment, Functional Requirements are captured in the Acceptance Criteria of a User Story. When the team fleshes out a User Story during elaboration, they define the functional details in an FR/NFR Acceptance Criteria checklist.

In a Waterfall software development environment, Functional Requirements are typically grouped in a document called Software Requirement Specifications (SRS document) or Functional Requirements Document. I have also come across the term Functional Specification Document on various projects.

What are Non-Functional Requirements (NFR)?

NFRs describe the aspects of a product that go beyond the core functionality. They are ultimately what will make your product unique and make all stakeholders (especially users) love it. The most common types are Quality Requirements (characteristics) and Constraints (limitations).

• A Quality Requirement is something that would increase customer satisfaction: “Prescriptions must be filled within 30 minutes.” 
• A Constraint is more like a legal requirements or a physical law of nature: “Prescriptions for controlled substances must be reported to the National Institute for Health daily”.

The difference between a Quality Requirement and a Constraint is the stakeholder’s response to their violation.

• If a Quality Requirement is not met, the stakeholder is likely dissatisfied with the solution.
• If a Constraint is violated (i.e., rules, laws, regulations, environmental factors, etc.), the solution cannot be implemented.

Because of this distinction, you should focus on discovering as many Constraints as possible as early as possible to avoid costly corrections or failures.

What Is Functional Decomposition or Feature Decomposition?

Functional Decomposition is a useful technique for breaking down User Stories into Functional and Non-Functional Requirements (NFR). The development team uses it to split Epics and large User Stories into smaller ones that will fit inside one iteration, but they also use it to flesh out details in preparation for coding.

In the Agile method, this process is more important than ever because it allows you to build working software in increments or Sprints. As each Sprint comes to an end, new software is available.

This allows you to test your product in a way you could never have done before: with real people using it and providing feedback.

The process works by adding detail to a User Story until it is clear how all the pieces will work together. Simply put, Functional Decomposition breaks down a complex task into a series of simpler tasks.

How To Write Functional Requirements?

Functions are the heart of any digital solution. Functionality is what makes an application valuable. Every software program has at least one function, which is why it exists.

For example,

• The “Verify Order” function lets you see if the data entered into your order-taking system is correct.
• The “Calculate Sales Tax” function adds the sales tax to orders placed in your store.
• . . . and so on.

For each function in your software, name it using an active verb (one that states the action) and direct objects (the things the action creates or affects).

By naming functions this way, the name expresses exactly what the function does. “Enter Email Address”, “Update Customer” and “Print Invoice” are all examples of functions with clear names.

Functional Decomposition Gives You User Story Acceptance Criteria or a Sub-Story

Functional Decomposition is a two-for-one deal:

1. it helps you slice User Stories into manageable chunks, and
2. it helps define Acceptance Criteria in a way that makes sense to both business stakeholders and technical teams.

Functions are like the proverbial Russian doll – but with a twist.

• If you look inside a Russian doll, you find another, smaller doll. Inside that is another, and another, etc.
• If you look inside a function, you might find multiple functions or even User Stories!

If a function is too complex, or it is too large, to be completed in one iteration, it becomes a separate User Story. I call these functions “Mini Stories” or “Sub Stories”. They can be decomposed into additional Sub Stories if they are still too large.

If all the discovered functions can be done in one iteration, I turn them into Acceptance Criteria for the Story.

The process of Functional Decomposition reveals what developers must deliver to implement the User Story functionality. Each of the pieces inside your original set of functions might need further decomposition to ultimately expose everything needed for the function to work correctly.

Decomposing User Stories: Functional Requirements Examples

When decomposing a User Story, the functions the Story contains can be inferred or explicitly stated.

For example:

As a customer, I can select only items that are in stock to reduce order entry errors.

In this Story, I found the following inferred and explicitly stated functions:

• Select item (explicitly stated)
• Check item inventory (inferred)
• Reserve ordered item (inferred)
• Track order entry errors (inferred)
• . . .

It is up to the team to evaluate the size of each function. If it cannot be coded within one cycle, that function gets split into a Sub Story that answers the WHO, WHAT, and WHY questions that every User Story answers. Otherwise, I have just defined some high-level Acceptance Criteria for this User Story.

A Functional Decomposition Example that leads to split Stories instead of Acceptance Criteria would be:

As a car owner, I can apply online for automobile insurance to comply with state laws.

If you are selling car insurance online, you could use the following functions:

• Select the coverage type (User Story)
• Enter personal and vehicle data (User Story)
• Submit application online (User Story)
• . . .

In this case, all functions are too complex to make good Acceptance Criteria. Write these as User Stories and put them through the same process again. Remember that Acceptance Criteria are testable, so they must be simple enough to be tested.

Effective use cases start with the people who will be using the system and their goals. Learn how to effectively communicate complex Functional Requirements with Use Cases.

Complete Functional Requirements Through User Views & Data Elements

There is another dimension to Functional Requirements and that is the data component. All functions use, create, modify, delete, or present data.

Actually, the term “data” can be misleading. You need to concern yourself with all “Informational Components” to develop a complete set of Functional Requirements for a User Story.

Informational Components can be either “User Views” (e.g., reports, screens, windows, web pages, audio files, video files, text files, databases) or individual “Data Elements” (e.g., street name, house number, city, state, zip code, etc.).

What is the difference between a User View and a Data Element?

A User View is simply a collection of Data Elements.
A Data Element is “atomic data”, meaning data in its simplest form.

For example, a User View of “Customer Address” in the United States typically consists of a Customer Name, Street Address, City, State, and Zip Code. The latter are Data Elements whereas the “Customer Address” is a User View that allows anyone to locate the customer geographically. The Customer Address provides the value that the user needs.

Someone on the team must identify and define Informational Components of a function. This is usually accomplished in a User Story conversation in which members of the business and technical teams participate.

Once you know the functions and associated data of a User Story, you can easily create Test Cases or Scenarios that prove the Story works correctly.

Why Do Developers Need Nonfunctional Requirements (NFRs)?

Missing and misunderstood Non-Functional Requirements are often the cause of product and project failure. The annals of IT projects are full of examples where applications implemented every single functional requirement—but they did not fulfill the non-functional business needs even close to well enough to meet the customer’s desires.

Anyone who witnessed the Obamacare website implementation can identify with this reality. The website crashed constantly, and when it was available, wait times were often measured in hours.

That is an example of what happens when insufficient attention is paid to the quality dimension. The Obamacare website was able to process applications as soon as they were entered; it just took far too long to get there.

Basically, an NFR defines criteria, characteristics, or conditions that a single function or the entire application must meet before it is acceptable to the business community and the end-user community.

Non-Functional Requirements Examples:

To give you an idea of how to write NFRs, here are a few examples.

The nuclear power plant’s radioactivity monitor must be available 24 hours a day.

This implies that the function must never fail. Given the severe consequences of failure, this is probably a pretty reasonable requirement on the part of the business community.

The next Non-Functional Requirements example is technical in nature as it lists what specific technologies will be used to enforce access control.

Access will be controlled with retina scanning, fingerprint, and voice recognition controls.

However, NFRs don’t just affect functions. They can also affect data, as you can see in this NFR example:

A customer ID must have a unique (i.e., non-repeating), 15-digit (the specific length), positive (must not be less than 0), real number (must not be an irrational or imaginary number), that identifies a single customer.

NFRs that are relevant to the entire product should be defined at the beginning of an initiative. NFRs that are unique to a User Story or feature should be defined as the iteration progresses.

Before I show you how to dig deeper into how to identify NFRs, I will give you a brief classification.

Non-Functional Requirements can be broadly categorized into four types:

1. External Constraints
2. Performance Requirements
3. User Experience Requirements
4. Architectural Capabilities

Let’s take a closer look at each of them.

Types of Non-Functional Requirements

External Constraints
Digital solutions do not exist in a vacuum. There are many external factors that can influence or constrain your product. I call these external constraints. Here are some general groupings to think about.

• Boundaries Enforced by Nature
• Laws and Regulatory Requirements
• Organizational Policies and Rules
• IT Security: Access and Data Security
• Geographic location of Functions and Data

Performance Requirements
In the Performance category, there are limits to the speed and efficiency of the application and the overall business solution. The main issue with performance is not the difficulty of achieving it, but the cost. Modern applications can achieve amazing levels of performance if they are necessary –  and the business is willing to pay for it.

• Frequency: how often is a feature used?
• Urgency: response time vs. update time.
• Data volume of information
• Precision and timeliness of information

User Experience Requirements
User experience is a non-functional dimension that has become increasingly critical with the advent of the Internet. This is where technology meets real people and, like any touchpoint between opposites, can be tricky.

Many of your non-functional requirements will come from this category. You might discover user experience requirements related to your users’ skills, their environment (where will they use the application), their training needs, or perhaps their cultural needs and desires.

• Level of interaction
• Corporate and personal cultures

Architectural Capabilities
If the application is web-based, is it necessary for it to work on any device a user might use, such as a smartphone, tablet, PC, laptop, etc.? Again, the answer is simply a matter of money because the more devices your application needs to support, the more it will cost.

Non-functional requirements, which define required architectural capacities, deal with the responsiveness of the application to changes in its business and technological environment. These include changes in hardware capabilities, software, the competitive environment, or a combination of these factors.

• Maintainability defines how quickly your function or application should respond when the business environment changes.
• Portability is about how quickly you can migrate the application from one hardware platform or software framework to another.
• Scalability defines how easy it must be for the application to deal with growth over time.
• Availability is about when the application is accessible to its users.
• Reliability specifies how reliable the application must be compared to the potential cost of failure.

Properly defining and implementing Non-Functional Requirements can be a pain in the neck. If you specify them too narrowly, the solution might be too costly to be viable; if you don not specify them well enough, the system may will fall short of its intended purpose.

Last Thoughts

User Stories are a tool used to help focus and direct conversations between domain experts and developers as well as within software development teams. However, User Stories by themselves do not always provide enough information for developers to work with.

This is especially true since there are many different types of software, and the technical responsibilities required can vary greatly from one to another. For that reason, it is important to add Functional and Non-Functional Requirements as well.

The functional decomposition method that I use allows non-technical stakeholders to break down a larger system into smaller, independent elements which are easier to understand and therefore provide higher quality in the delivered product.

The Internet is a sharing environment, so please leave me a comment to share your thoughts, ideas, or other techniques. Together, we live to learn, or we live for nothing.