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

Posted by Analytics T.

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:

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.

Example:

• 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.

Examples:

• 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.

Conclusion

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.