What Are Non-Functional Requirements And Why You Need Them? With Examples

Cool cat wearing sunglasses with the "NFR" text on each eye

There’re essentials you have to think through before you’re to develop a product if you want it to work as you expect it to or even better. These are, as we explained in our previous article, 2 types of requirements: functional and non-functional. From this article, you will learn what non-functional requirements are, and why they are as important as technical ones.

What is a Non-Functional Requirement?

A non-functional requirement, or NFR, is a requirement for the  system as a whole. It doesn’t describe user actions, system behavior, or interface. Instead, it determines WHERE the product  should be used and HOW we better design it from a technical perspective. Often NFRs are referred to as technical user stories or software quality requirements.

This is what the NFR list for a product may look like:

A table with different non-functional requirements and their specifications
A table with different non-functional requirements and their specifications
A table with different non-functional requirements and their specifications
Example of a NFR-list for a video streaming platform or a video chat

Now let’s dive deeper into the types of non-functional requirements to better understand why you even need to describe them in the first place.

Requirements to for WHERE the system should work

There are systems we expect to work everywhere: on any device, any platform, from any place. This is their technical requirement. For example, Facebook or YouTube. But they weren’t like that in the beginning. Making the system work flawlessly around the world on any device is pretty difficult and expensive. An MVP doesn’t need this to test their hypothesis and get the first users. That’s why we always ask our clients how many active users they plan to have in a few months and where they are located. This brings a lot of benefits: 

  • fits the initial system scale to the expected load — avoiding unnecessary scaling saves money;
  • saves funds for not having to maintain the load that is not expected in the near future.

Basically, when you ask yourself “Where should my system work?” and then answer your own question — this is how you articulate the non-functional requirements for localization (early adopter countries) and scalability (concurrent users, storage capacity).

Example: A Texas factory owner wants to develop a video surveillance system that can meet specific needs of the factory. NFRs to it will be:

  • Localization: USA, language — American English
  • Scalability: 1 factory, 10 security officers, up to 100 simultaneous cameras.

Most likely, this system will never have to experience the Black Friday test in Europe. However, if this is suddenly required (for example, the business grows in an unforeseen way), the factory owner will have to scale it up. 

However, it’s a big game changer if we consider the potential of scaling from the very beginning, it saves a lot of money.

Some non-functional requirements don’t even require additional timespend. It takes the whole development some time to build a functional user story and features within. A technical user story, for instance, simply comments on the date and time formats for the specified use location.

Technical user stories also determine the browser and device support. You might’ve seen a note like “For the best experience, use the latest version of Chrome”? It indicates that the developers tested the platform, obviously, on the latest version of Chrome. It may work in other versions and browsers, but the software provider themselves don’t know how exactly — they haven’t tested it. Usually this is how companies save money on testing things and features not or least used by potential users. It’s a rather simple rule: you can grow a product and add new cool features to it only when the main functionality is working perfectly. 

Requirements for HOW the system should work

1. Effective performance

How to build it so that it works well? What does “well” even mean?

Example: Let’s take the same video surveillance system. If we want it to work well, then the video quality should be high (say, Full HD). But at the same time, we want to optimize server costs so that the client doesn’t overpay. Most likely, Full HD is useless at night or when nothing happens in the picture. Then we lower the quality and boost it automatically when cameras detect motion. Or maybe leave the decision up to the user? They could set, for example, the main camera to 720p and the others to 480p. 

Depending on the specifics of the business, non-functional requirements for video quality can vary and must necessarily be specified in writing.

2. Security

Another side of “how well” is “how safe”. The system may collect or transmit sensitive (in terms of security, safety, or privacy) data. Not meeting relevant requirements can cause its owner major legal problems. In 2022 covering damage from data leaking may cost a company up to $4,35 million, according to the IBM data breach report.

Examples of security requirements: 

  • The users of the platform should be over 18 y.o.
  • The payment processing gateway must be PCI DSS compliant.
  • 1-1 calls should be HIPPA compliant.
  • User profiles and data storage should be GDPR compliant.

3. Speed

Non-functional requirements also answer the “how fast” question, in case the speed is critical. 


  • The results must load within 3 seconds.

4. Integrations

Last but not least, technical user stories define the necessary integrations into functional user stories, in case we don’t develop custom solutions.


  • If the user needs to pay, the NFR specifies the payment method (e.g. Stripe, PayPal, in-app purchases, etc.).
  • If the user should receive a system email, the NFR says what system will perform it (e.g. MailChimp, Sendinblue, Mailgun).
  • If the user wants to watch a video, NFR determines the player.
  • If the user needs to call, NFT names the video conferencing system to integrate.
  • If the client needs to analyze performance, NFT specifies the requirement for Google Analytics integration.

And so on, so on, so on.

Let’s summarize

To write complete non-functional requirements that can ensure the quality of the system, the analyst better discuss with the client and list the following possible attributes:

  • Localization and Language / Multi-language support,
  • Date and Time formats, Timezone, Currency,
  • Current scale and potential Scalability,
  • Browser support,
  • Operating System / Device compatibility,
  • Quality / Size / Format constraints,
  • Security / Safety / Privacy concerns,
  • Speed (Performance), Responsiveness, Reliability,
  • Third-party integrations.


Functional and non-functional requirements go hand in hand when planning a system. While the first bring more value to the end user, the second explains where and how the product delivers that value. While describing non-functional requirements is crucial for building an MVP, it goes fil-rouge throughout the entire product life cycle.


What Should Come After The 1st MVP Release For It to Be a Success?

A funny cat picture with the article alternative title

In Fora Soft, when we release a product for the first time, it’s already an MLP (Minimum lovable product). But usually the first milestone in product development is MVP (Minimum viable product) launch. However, it’s not a point to stop. But what to do next? What comes after the MVP release and how do you know the product is ready? The answers are in this article. 

Gather feedback from your users

If you want your MVP to be a perfect product-market fit, it’s a good idea to make sure your clients understand what the product is about and how they should interact with it before promoting the platform. Otherwise there’s a chance you spend a pretty penny on marketing and get no result. 

Sign up for startup websites

Like these:

  1. Product Hunt 
  2. Indiehackers
  3. Betalist 

The scheme here is quite easy yet effective:

Your profit: 

  • feedback from real users = the “Do they need the product?” hypothesis testing 
  • badge on your website = trust level increase
Badge on a website

Test the platform on users

Determine your target audience 

TA is a group of people that are most likely interested in your product. They share some needs and wants or have similar ones. 

For instance, TA for an LMS-system is students and teachers that take and give lessons online. 

Test your product with focus groups

  1. Gather up a group of 10 people
    They shall be as close to how you describe your TA as possible. It’s better if they’re strangers to you — friends and family might not be objective.
  2. Decide what exactly you want to test
    For instance, your goal is to test how intuitively students interact with the platform.
    Describe the scheme: “Download the app, sign up, make basic actions (sign up for a class, attach a file with a completed assignment)”.
    Plan the result: “9 users will register, 5 will sign up for a class, 3 will attach their files”.
  3. Test the platform
    We recommend watching the users as they interact with the product: face-to-face or on a video call. You’ll notice some minor yet important details the user might’ve missed in a written report.
  4. Gather feedback
    Note what users could and couldn’t do or accomplish. What questions and issues have they faced? Were there lags or bugs they encountered? Did they like using the product, why? Would they recommend it to a friend? Would they use it themselves?

Carry out a customer development interview

Customer development interview (Custdev) — a means to get data while in-depth interviewing TA. While carrying out a custdev you discover current top-of-mind needs, preferred means of communication and content types. You’ll need these for the promoting campaign later. 

Tip: If you’re on a low budget and can’t afford a custdev, prepare the questions in advance and ask them while testing the product with the users. And if you’ve already made past-testing amendments, now it’s a good idea to see if the amendments are good and efficient.

Custdev aims at discovering how and where your TA gets information and what particular points for ads placement will be the most effective. 

There’re some Rules:

  1. Gather up a group of 10 people. They shall be as close to how you describe your TA as possible. Again, it’s better if they’re strangers to you — friends and family might be not objective. 
  2. Make a questionnaire. With the same questions for each of the respondents to prove the hypothesis.
  3. Ask open questions: how, what, why. Let the respondents share their experience in detail. Don’t ask them for a particular solution. Just find out what the problem is and why solving it is important for the respondent. 
  4. Ask follow up questions.
  5. Remain in the present. Ask them how they act right now (no woulda-shoulda-coulda and Past tenses). Focus on how they tend to act. And better not ask about the future or wishes. The respondent may subconsciously want to appear better than they are and respond accordingly, but it won’t correlate with how they act in a real setting. 
  6. Record the interview. You’ll get a bigger load of data and will be able to come back to it anytime you need, the data mining will be more effective.

Questions you might want to ask

Process the feedback

Effective feedback processing and eliminating product flaws are two Atlases of successful products. If a user can’t fulfill their needs and wants with a product, or the first-use experience is unpleasant, they won’t waste their time on it anymore. 

How to process feedback correctly:

  1. Discuss the feedback with the team
  2. Brainstorm on possible solutions and improvements together
  3. Make up a to-do list for the next release. Use MoSCoW prioritization method (Must have, Should have, Could Have, Won’t have (this time)) to prioritize: 

1st Priority: features that the product Must have. These are the essentials for the current development stage. If a product doesn’t have them, it won’t be successful. Basically, an MVP already has it. You can only improve them or add new ones if the custdev shows it’s necessary. 

2nd Priority: features that are important for the current stage but aren’t that critical. A product Should have them in the next development sprint. 

3rd Priority: features that could make a product better if there was additional development budget. It’s what the product Could have at its best. 

4th Priority: features that will definitely not be in the product, at least for the next 2 timeboxes. It’s what it Won’t have. 

We recommend focusing on the 1st and 2nd priorities as they suggest most needed improvements for the current period of time. The 3rd and 4th ones are just possible enhancements. When improving the product, you may see it change dramatically so there won’t be any need for the features of the 3rd and 4th priorities. So it’s better not to waste your funds and your analysts team’s time on that. 

Make changes to the product 

Adapt your MVP to be better product-market fit with your clients. Develop and test 1st and 2nd priorities improvements. Besides custom solutions, some common ones are have the same intentions: explain how to use the platform for newbies and keep them engaged. 


Automated platform introduction to a user. The goal is to demonstrate what it is for, how to use it properly, and what the benefit is. It makes the user experience much smoother and leaves a good first impression.

Minor interface adjustments 

Product adaptation is a nice product enhancement strategy. It’s a pretty common thing when a user can’t find the target action button or doesn’t get how to interact with certain functionalities. It’s crucial to keep abreast, keep track of the feedback. 

This is why sometimes it’s a good idea to test how comprehensible and intuitive the interface is to the user if there’s no additional navigation. It’s easy to assess. Let’s say the user scenario suggests that the “Sign up for a class” action takes 3 steps. When testing the product you see that the user takes some workarounds and accomplishes it in 10 steps. Meaning something in the interface wasn’t clear for them. This will help add new useful features and enhance existing UX and UI in the next product version. 

Referral system

It’s a way for the platform to “collaborate” with the user by rewarding the referrer for attracting new users. Nothing motivates better than personal gain. Think of what would be enough of a motivation for one to stick to their friend asking for a favor. 


One of the significant metrics of the app effectiveness is user engagement. How frequently they open the app, how much time they spend in it. Notifications will help with the first. Pique their interest with words and emojis only. 

Custom email newsletters will work for web apps.

Text update applying Tone of Voice

If you use texts at the MVP stage (in pop-ups, welcome-screens, etc.) make them consistent in Tone of Voice. These are the rules by which the brand communicates with the users. 

Does your product target teens? Use more slang to be on the same wavelength. Is your TA mostly businessmen and entrepreneurs? Address the users more respectfully and make the communication concise, maybe even formal. 

Relevant ToV guarantees that users will perceive the information better, since they better understand how the product works. 

Moreover, if your brand speaks the same language as its TA, some sort of emotional connection and bond establishes between them, as if they were friends. That’s a significant advantage over competition products. 

Promote the platform

Pick the promotion channels and plan the works

  1. Think of the concept
  • Pick the promotion channels 

Based on the custdev data make a list of the most potentially effective sites for placing advertising messages.
For example, your clients are movie geeks that want to save money on online cinema subscriptions. From the interview we learnt that they visit platforms with vouchers and promo codes often. This is where we will place our ads.

Set up the channels in the single brand identity. Use the same logo and an informative profile background. Let your designer make an entire design system, select color solutions for visual content. 

  • Make your advertisement hypotheses (objectives) to test. Make them SMART 

For example, Facebook users will download the app 100 times within 2 weeks. 

  • Calculate the overall costs

Use forecasting services for digital advertisements. When planning a campaign in Google ads, Facebook ads, Snapchat ads, TikTok ads, Twitter ads you’ll see how many impressions (how many unique users will see the ad) and clicks you’ll get for your budget.

Agree on promotional posts with authors/admins personally. Consider the fees and taxes. 

2. Plan content creation works: make briefs for copywriters, designers, photographers, etc. 

Create the content

Use the information you gained from custdev to determine the best content type for your TA. Write copies, record and edit the video, make pictures, and adjust them to your specific placement sites.

If the campaign includes any social media marketing activity, make up a content-plan, a list of posts topics.

Launch a test campaign

Commence promoting the product and testing hypotheses. We recommend launching a test campaign for 2 weeks — this must be enough. Keep track of the changes. If you see that one of the hypotheses doesn’t prove itself and you don’t get the anticipated result, amend the budget allocation, channels selection, etc. 

Launch the campaign in the most effective channels

Draw the conclusions to the test campaign. Select the most effective ads placement sites. Plan the budget and the results based on the test campaign data. “With the $ X budget I’ll get Y new users, N demo requests”. Use this to better plan and calculate ROI of the project in the long-term perspective. 

Final words

Answering the question from this article intro — you know better when your product is ready. What we can say for sure is that there’s always room for improvement in the post MVP phase. And once you have your MVP and have done all the necessary adjustments, you’ll know the direction. To give you an idea, check out what we do next with our clients in CommunityHill, Janson Media, and AppyBee cases.