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.


How We Optimized Analytics Process in Software Development Company

Wireframing is one of the key stages of the analytics process at Fora Soft. Interactive prototype being a rough image of the future product gives the team space to alter functionality at the earliest stage before the development. It also tributes to the client’s confidence that we’re on the same page regarding the product view.

axure wireframe
Axure prototype example

Developing the systems and platforms of various structures, for various audiences and user needs, you still have to design core functionality and basic scenarios all the time. 

Imagine how rich the difference is between the functionality of an e-learning platform, a booking app, and a streaming service. However, most likely all of them will feature a sign-up scenario, editing a user profile and sending messages to the chat.

Having analyzed the wide scope of company projects, Fora Soft analyst team has distinguished the most common user scenarios and created the completed wireframe templates for them, following the usability guidelines and the best practices in web and mobile UX design.

These ready-to-use wireframe templates contribute to the analytics process optimization in Fora Soft. They allow us to dedicate more time and effort to the product’s killer features rather than its basic functionality. The templates are concise and flexible enough to be applied to different kinds of systems.

Among them, you will find a video conference template. Our area of expertise is multimedia software such as systems for online education, sports, teamwork, telemedicine, and video surveillance. 
Check the Fora Soft wireframe library here and try its templates to design your amazing projects.

Download the kit right here: