« Back to Planio Blog

Jory MacKay on August 16, 2022

Jory MacKay

Jory is a writer, content strategist and award-winning editor of the Unsplash Book. He contributes to Inc., Fast Company, Quartz, and more.

August 16, 2022 · 9 min read

Data shows that inaccurate requirement gathering is one of the key reasons up to 70% of projects fail. Yet, beneath that stat is the real problem: Teams focus too much on functional requirements (what the system does) and forget about the non-functional aspects (how the system does it).

Non-functional requirements ensure you provide a good user experience and that your product performs at a level that your customers, clients, and stakeholders expect.

Unfortunately, too many product teams ignore non-functional requirements (NFRs) until it’s too late. Even worse, updating NFRs after building your software is costly and can blow out your budget. By some reports, unnecessary rework of code and requirements costs companies anywhere from $400,000 to $94 million a year!

You don’t need to make those same mistakes.

This guide will cover what non-functional requirements are, why they’re important, and how to include them in your product roadmap and sprint planning.

Jump to a section:

What are Non-Functional Requirements (NFRs)?

Non-functional Requirements (NFRs) define ‘how’ systems do what they do. This includes characteristics such as their performance, security, maintainability, scalability, and ease of use. Essentially, they provide the proper checks and balances to the functional requirements.

But what does that really mean?

Functional requirements are what you’re going to build. This could mean a webpage, app, or onboarding flow. On the surface, the functionality of your product seems like the most important focus for your team. And it is! Without functional software, you have nothing for your users to use.

But functionality isn’t enough to create a compelling product.

Non-functional requirements ensure a system or product is actually usable, provides a great customer experience, is secure, and complies with legal regulations.

NFRs are essential. But they’re also a matter of balance and compromise. While you don’t want to forget about them until it’s too late, you also don’t want to focus too much on NFRs at the expense of your costs, schedule, and resources (i.e., the triple constraint of project management).

Imagine you’re buying a sports car. Among your functional requirements for the car would be that it has doors. The non-functional requirements would specify how those doors work. Are they regular old doors? Or those super cool gull-wing doors you see on fancy Teslas and Mercedes?

Any choice works. But you have to decide which option gives you the best driving experience.

The 10 Main Types of Non-Functional Requirements

Where most teams make mistakes with NFRs is that they focus on the one or two obvious ones and forget about the rest.

Your team won’t “forget” to think about performance issues or test reliability. But are you planning for localization, regulatory issues, or maintainability?

A good product manager needs to consider all ten non-functional requirements during the development phase. That includes:

In reality, non-functional requirements often overlay from type to type. So use these categories only as guidance when thinking about the NFRs for your project.

How NFRs help development teams

Let’s step back from project management and put ourselves in the development team’s shoes.

Dealing with non-functional requirements may seem like you’re adding to your project’s scope. However, ultimately, they make software systems far easier to develop, deploy, and maintain. In turn, this makes a developer’s life much easier.

Here are the main ways that NFRs make your development team’s life easier:

• They help shape the architecture. Non-functional requirements help teams plan ahead and future-proof their design. Without strategic NFRs, developers build features on top of other features with no high-level vision to work towards.
• They baseline performance. NFRs help developers understand what “good” looks like for the system. This gives software teams a performance target to baseline against, ensuring that the system always delivers what it’s meant to.
• They reduce time spent on bugs. Especially for the performance, reliability, and maintainability NFRs, they help teams build high-quality code that fails less often.
• They help teams avoid rework. The added depth and richness NFRs bring helps developers get things right the first time around. That saves time on rework, allowing developers to be more efficient and better manage their busy workload.
• They bring the developer and the end-user closer. Lastly, well-written non-functional requirements help developers understand the end user better. That insight into the ‘how’ really helps developers build features that truly meet the customer's expectations.

How NFRs help project managers

Back to project management and time to think about non-functional requirements more strategically. Or, to be more precise, what happens if you don’t think about non-functional requirements as a project manager?

It’s easy for something small to derail your project, leaving you under-delivering against your objectives. Here are just some of the reasons forgetting non-functional requirements may cause you and your project to come unstuck:

1. You could miss deadlines. Missing NFRs can lead to rework, bug fixes, or even complete systems failures. Those minutes and hours add up, leading to deadlines slipping because the system simply isn’t ready.
2. You’ll blow your budget. Similarly, development time costs money, so excess work leaves you footing the bill. Don’t blow your project budget by missing a simple NFR that leads to costly overtime.
3. Unhappy customers. Non-functional requirements ensure you deliver what the customer needs in exactly the right way. Fail to consider your NFRs, and you’ll ship a completely unusable product, upsetting your users in the process.
4. You’ll inadvertently create risk. Remember those security NFRs? Fail to consider the full picture, and you could open up your project team and your user, to risks they didn’t even know existed!
5. Your scope will creep. And to finish, if you fail to identify the right non-functional requirements properly, you’ll end up with scope creep. If your scope creeps, you’ll be doing extra work that pushes out your timelines and inflates your budget.

Updating non-functional requirements after building your software will be costly and can blow out your budget.

7 steps to including NFRs in your roadmap and planning

NFRs are clearly important. But how do you work them into your product strategy?

Here are seven simple steps to incorporate non-functional requirements into your project or product roadmap:

1. Build a quality attributes list

Start by understanding what “quality” means to you and your customer.

For any particular feature or functional requirement, try to understand what the customer would need by asking yourself:

• What is important to the customer?
• What qualities would make the feature/product great?

If you’re struggling, try and think of it in reverse by brainstorming what would make that feature really bad.

For example:

Functional requirement: As a user, I want to land on the homepage, so I can begin using the product.

What would make it great? If it would load really fast.

What would make it bad? If the text size was so small, you couldn’t read it.

Congratulations, you’ve just discovered two Quality Attribute Requirements (QARs)!

If you need further information, don’t be afraid to do some research and look into the market to understand the good and bad qualities of similar products.

2. Set clear expectations for each requirement

Now that you have a better idea of the quality attributes you want to deliver, it’s time to put some meat on the bones of your NFRs.

This is all about quantifying your user’s expectations and turning vague words into solid, actionable statements from which to build your product.

Let’s use the examples from earlier on:

Before → ‘If it would load really fast.’
After → ‘The page will load in under 1 second’

Before → ‘If the text size was so small you couldn’t read it.’
After → ‘Text size will be 16px’

Remember to continually reference back to your functional requirements to understand the context and what the customer needs to achieve.

Pro tip: Keep your NFRs in your product backlog alongside all your other tasks. A project management tool like Planio can help you stay organized, so none of your important requirements (functional or non) get missed.

3. Analyze the wider impact of your NFRs

No project happens in isolation. There will be many other projects, changes, and roadmaps around the business.

Before you start developing, take a step back and ensure that your non-functional requirements won’t inadvertently cause issues for another part of your product or wider IT infrastructure.

Here are some examples:

• Performance: Are your performance requirements going to drain other resources?
• Security: Are you working to the same standards as other applications?
• Usability: Is your customer already familiar with workflows from other products?
• Maintainability: Are there central processes for product updates?
• Resilience: Are there standards for continuity already in place across the business?

If nothing else, cross-checking your NFRs with other project teams may help identify new requirements you hadn’t even thought of!

Ultimately, non-functional requirements make software systems easier to develop, deploy, and maintain.

4. Decide on your NFR implementation approach

This one is a project manager’s bread and butter: Delivery.

Are you going to deliver all of your NFRs in one big bang, or will you build them up incrementally? The answer is likely to be a bit of both, depending on the type of non-functional requirement. For example:

• You won’t want to take a risk on a security or regulatory NFR, so we’d recommend delivering it all at once.
• On the other hand, you could tackle performance NFRs one user story at a time until you reach the desired level of quality.

It’s all about balance here. An all-at-once approach takes longer and leaves your users waiting longer for new features. But, you don’t want to under-deliver and risk making your customers unhappy by taking an incremental approach.

5. Include NFRs in your next sprint cycle

Great! Now your NFRs are ready to hit the developer's desk and come to life.

As you would with any user story, take your time with your sprint planning and fully estimate the size of each requirement. This is to ensure your development team can absorb each requirement into the workload.

There are many different estimating methods, including planning poker, t-shirt sizing, and 3-point analysis, so pick the one that works best for you and your team.

Once you’re happy, get them into your agile project management tool, ready for the developers to start working on.

6. Create an NFR testing plan

No new feature can truly come to life without some testing. Data backs this up, too. A lack of testing is one of the main contributors to development rework!

Your test plan is designed to help you discover defects, errors, and gaps that might cause the NFR to deliver a bad experience.

Here are five easy steps to build a test plan:

1. Start by analyzing the requirement you’re testing. You’ll already know all about the requirement, so discuss them with the developers and testers so that you’re all up to speed.
2. Design your testing strategy. Consider which areas of the NFR are most important, the time/resource you have available, and the type of testing you want to do, such as unit testing or stress testing.
3. Define your objectives and pass/fail criteria. This will depend on the requirement itself and any tolerance you’re comfortable with.
4. Plan the test environment. It’s always good to be prepared, so line up the right test environment to give you the best chance of success.
5. Execute, monitor, and deploy. Now it’s all about putting the plan into action before making a go/no-go decision for deployment.

If you want some additional help, check out our Ultimate Guide to Creating a Test Plan.

7. Assess the impact of NFRs through user research

It’s not all over once the NFR is deployed. You need to monitor its effectiveness once it’s in the hands of the customer.

There are so many ways to get rich UX feedback from your users, whether it’s through surveys, interviews, A/B tests, or usability assessments.

From your user research, you’ll understand if the NFR has landed correctly or whether there’s some further rework you and the project team need to do.

What are the potential risks of non-functional requirements?

Before you run off and start adding hundreds of NFRs to your product backlog, remember that they’re part of a delicate balance. Too little emphasis on NFRs and you open yourself up to the risk of rework or not meeting users’ expectations. But too much emphasis and you’ll blow your project budget, scope, and schedule out of the water.

As you start to include more NFRs into your product roadmap, beware of these common risks:

• Negative performance and usability. Remember to step back and consider your wider environment, as NFRs can negatively impact other product features. It’s all about testing and learning to avoid creating any problems in your wider environment.
• An ever-growing scope. Once you start looking into NFRs, it’s easy to come up with hundreds of great ideas for your product. Remember to take a pragmatic approach. Otherwise, you’ll end up with a project scope that continues to grow.
• Deprioritization. Because NFRs aren’t as exciting as functional requirements, business stakeholders often want to deprioritize them. Occasional deprioritization is fine. But do it too often, and you’ll be left with a product that simply doesn’t work. Again, it’s all about balance.

It’s time to get on board with NFRs

So many projects fail because they forget to consider non-functional requirements. Don’t make the same mistakes and get on board with NFRs, as they’ll make the difference between happy and unhappy users.

Our guide to including NFRs in your product roadmap will lead you through the process from start to finish. Once you’ve got a clear view of what matters to users, it’s all about structuring your NFR delivery through discovery, planning, testing, and deployment. In the end, you’ll ensure that how your product works is as important as what your product does.