logotyp inwedo
Agile Project management Technology

Mastering non-functional requirements: 5 best practices for effective project management

Non-functional requirements in Agile are one of those aspects that are quite often neglected or left until the very end of the project. They seem hard to define, even harder to test, and, well, the work put in isn’t as visible as that to add new features.



Unfortunately, it often turns out that meeting security or scalability requirements after a product is almost built is far more time-consuming and costly than anticipated. In the worst-case scenario, several parts of the product might have to be rewritten – significantly delaying its launch and increasing expenses as well.

Our non-functional requirements (NFR) guide can help you avoid this scenario, though. In this article, we’ll cover what causes PM/PO and Agile teams to underestimate NFRs and show how you can add them to your project to guarantee that it will be fully functional.

What are non-functional requirements?

Non-functional requirements (often also called quality attributes) are those that describe a system’s performance, security, and overall operational capabilities. Their main purpose is to make a product (whether it be an application, software, or website) more efficient and convenient to use, thus improving the user experience.


Basically, functional requirements focus on what a product should do, whereas non-functional requirements are all about how the product will do that.

To put the differences between these two types into an example, imagine you are building a website for a service and want to include a “create an account” functionality for your users. To make it easier for them to sign up, you plan to add “Sign up with Gmail” and “Sign up with a Facebook account” features to the webpage. Those would be the functional requirements.

In order for the account creation process to be smooth for all of your users, however, there are a few non-functional requirements that you should add to the website requirements lists as well:

  • Page loading speed on different devices
  • Method and location of storing and securing customers’ data
  • Number of users the website can handle without slowing down or crashing
  • Action that user should perform when the sign-up method they pick doesn’t work as intended

Will the “Create an account” page work without those requirements? Technically, yes. However, if the page loads slowly or not properly on mobile devices, there’s a higher chance that the user will leave the page than finish creating an account.

Then, you might have to spend extra time and money fixing those issues – something you could have avoided if you added the NFR requirements to your task list from the beginning.

What makes non-functional requirements so challenging to add?

As you can see, NFRs can align your product with the features that future users might need for a given task and also contribute to providing an exceptional user experience.

But if those requirements can be so useful for the creation of an application that is fast, secure, and easy to use, why are they so often overlooked? There are a couple of reasons for that:

➡️ Teams find it hard to capture the right NFR for the project

To know what NFRs ought to be included, Agile teams must ask the stakeholders/clients about their expectations and then also research user expectations.

➡️ NFRs are subjective

It can be difficult to determine how exactly they should be added to the project, as the opinions of users and stakeholders are personal. Developers might also have different opinions on what security measures to include or what is an acceptable response time.

➡️ Tricky to measure and test

NFRs vary so much that each one has to be measured and tested differently. Development teams also often struggle to figure out how they can verify whether the requirements are met or not.

Sometimes it also happens that the development team only includes the most obvious NFRs in the requirements lists (performance, security features, or legal compliance) but skips, say, scalability. That can lead to a situation when their new website or application crashes due to a sudden increase in traffic or number of users, and forces the developers to work urgently on fixing the product.

Non-functional requirements – best practices for adding them to your project

Now that you understand why spending sufficient time researching both functional and non-functional requirements is key to the success of a project, your next question might be: “So what is the best way to include NFRs in my project?”

Below, we have noted four simple steps that will be of great assistance when it comes to adding an NFR criteria right at the start of a project that ought to be in mind its entire development.


Build a non-functional requirements list

NFRs are all about giving your target users a product that they will enjoy using. The first step here is therefore to think about how exactly the website or application should work in order to make using it a pleasure. For example, should the website load quickly on both laptops and mobile devices? Will it be possible to increase the font size? Perhaps security is of the utmost importance for users?

An excellent approach to determine what users will need most is to look at how your target audience uses similar products and what their main issues are when doing so. Based on this information, you can then figure out what features or qualities you should add to your new product.

Talking with the stakeholders or clients about which product qualities they would like to be included (and how they will be critical to the entire product) will also contribute to clarifying the requirement list.

Of course, like with everything in Agile development, an NFR list shouldn’t be set in stone. As priorities during project development change, the NFR list must be verified and modified accordingly.

Set clear expectations for each requirement

After finishing the research phase, you should have a list of quality requirements to focus on during the development stages. The list is probably quite vague for now though, so it’s time to make the requirements a bit more specific.

Think about it – if you want your website to load smoothly, which of the following two requirements would make it easier to test that?


Obviously, the second one. So, together with a list of NFRs that you will follow during the project, you also need to specify how exactly each one should perform and how you will test it later. In one of our previous articles, “NFR in software engineering“, we mentioned a few questions that can make clarifying the objectives for an NFR and later testing them a bit easier for your team.

Another nice approach to specify your goals for non-functional requirements is through using the SMART method to write more specific, measurable, attainable, relevant, and time-bound goals.

Consider how adding NFRs might impact product functionality

The main reason why adding an NFR at the end of the project or after completion is so expensive? Since it often involves rewriting parts of the project just so the main features and, e.g., security functionalities work together without conflicts. In the worst case scenario, you may even need to rewrite most of the website or application code because the ready version doesn’t meet the requirements.

The earlier you prepare the functional and non-functional requirements, the better you’ll be able to gauge how well they will work together and if any trade-offs need to be made. That way, you’ll be able to save your developers’ time (and nerves) and also avoid going massively over budget just because several features need to be adjusted.

Decide how and where you will store the NFR requirements

When it comes to NFRs, many teams also struggle with a method for keeping the requirements documented and visible. One of the most often popular methods to do so is through User stories, for instance:

As someone who keeps worrying about the security of my data, I want it to be password/fingerprint scan protected and encrypted so that I can be sure no one has access to my account.

Two more examples follow from the BrainsLink and Mastering Business Analysis blogs, respectively:

As an impatient and overworked data analyst, I want to process 10,000 records in under 60 seconds so I can get more done in less time.

As an online banking customer, I want my checking account balance to display within five seconds of my request so that I don’t get frustrated and can see if I have the funds to pay my bills.

In case the NFR you picked doesn’t fit nicely into the story metaphors, there are a couple of different methods for noting requirements – include them as “acceptance criteria”, create technical stories, or just add them to your “Definition of Done” checklist. There isn’t one right method of documenting NFRs, so you can pick whichever will be most convenient for your team.

Create a non-functional requirement testing plan

Not enough testing is often one of the main reasons why a website or application needs to be reworked later. But while functional testing is often pretty straightforward, NFRs can be a bit more tricky to verify since each one needs to be tested differently.

Discussing with the developers and testers which methods to adopt for each requirement and planning the testing stage right from the start will make a lot of aspects easier later on, though.

For example, testing the application under heavy load early will give you plenty of data on what you can expect to happen when there are, say, far more users logging into the application than usual. Then, you’ll be able to prepare plans for what to do if such a situation occurs after the application has been released and how to restart it in case of a crash.

As we mentioned in the previous point, however, it’s essential that testing objectives and pass/fail criteria are as specific as possible. For instance, the pass criteria should be “The application must be able to support 10,000 concurrent users” rather than “The application must keep working under heavy load”, since the former will be much easier for you to verify.


Giving non-functional requirements the attention they require can be extremely useful when it comes to completing development projects on time and within budget. Not to mention that this way you can guarantee the ready product will have everything your future users need to keep using the product for longer.

Although researching, specifying, and testing those requirements might take some effort and can be confusing, this will be time well spent. You’ll save time and money on code rewrites and urgent patches down the line, while your users will see that how your product works is just as crucial as what your product does.

Maybe these pieces of content will also be worth reading?

Agile Project management Technology

January 26 2023

What are non-functional requirements? List of 9 types + examples

You already have a good idea of what your application should do and look like and the value it will create. You also know that your application has to be reliable – that is, work on the most popular browsers without causing people problems or inconvenience. These are all critical aspects of a system, but how do you translate them into code? This is where non-functional requirements come in handy.

Read more
Agile Product Development Project management

September 9 2022

All you need to know about user stories in agile development

Agile is our methodology of choice, and we see how positive its impact is on our productivity and relationships in the team. User stories are its essential element that proves its human focus. This complete guide will prepare you for working with an agile software team that works with user stories!

Read more
Agile Business Process Optimization Project management

October 5 2022

Agile software development and IT process optimization: a comprehensive guide

Many agile software development project managers face a similar dilemma: Out of fast, cheap, and high-quality, you need to pick two. Whichever way you go, you’re sure to face challenges on the way and get stuck in project bottlenecks. But what if you managed to get closer to the ideal of having it all? You can do so by optimizing software and IT processes. Curious? Read on!

Read more
arrow-up icon