Table of content
Imagine you are buying a house. Supposedly, the next things you ask yourself are "what the neighborhood should look like, what should be the distance from the office, or will this house fit all my family members on Thanksgiving dinner?".
And you buy the house. Friendly neighborhood with good infrastructure. Fresh air. Nice view. Finally! The home of your dreams. And then you realize you now live near the flowers you have a severe allergy to. So the experience is somewhat spoiled because that allergy thing has been overlooked.
That’s how non-functional requirements work in product development. Not too much attention to those, and you can end up either slightly disappointed or even with a product from minor to no use.
This article will share some insights on how non-functional requirements can help build a better product and make the business thrive.
What are Non-Functional Requirements?
Simply put, non-functional requirements are specifications of the system's functionality and constraints that define its operation.
Non-functional requirements along with functional ones form the system's documentation – the collection of requirements and specifications that programmers use in software development. While functional requirements determine the system's functionality (features, main functionality, software structure and elements within it), non-functional requirements relate to how these features should work in certain conditions (in terms of performance, localization, scalability, etc.). Putting it utmost simple, non-functional requirements are more descriptive specifications of functional requirements.
For example, the feature of automatic email notifications is a functional requirement for the system. But if we specify that this notification should come to the user's email box in 3-5 seconds after registration, that means we put a non-functional requirement to this feature.
It is worth mentioning that non-functional requirements do not always relate to the system as such. They can also be of a business or compliance nature. For instance, if a system is expected to collect user data within the EU domain, it is bound to meet the GDPR compliance rules.
Why Non-Functional Requirements Matter?
This is often the case when non-functional requirements are given less importance while functional ones are prioritized. And you cannot build a properly functioning system without distinct non-functional specifications of how it should work. That’s that. So if we had defined non-functional requirements earlier, we would have saved a lot more time.
6 Main Types of Non-Functional Requirements
There are a myriad of non-functional requirements examples. With each new project, I get to know more and more. In these sections, I have figured out some of the most widely used types of non-functional requirements that you might most often meet at your projects.
Scalability and Performance
These two standards usually go hand in hand, as they stand for the system’s capability to handle specific workloads.
Performance defines the amount of user requests that the system can handle per second.
For example, the website’s infrastructure should handle 100k requests per second.
Scalability defines the highest workloads under which the system will still complete the performance standards. For example, 1000 - 1K users.
Compatibility and portability
One measures the system’s portability through its readiness to operate in different environments. Simply put, the less engineering effort is needed to make the system function in an OS it was designed for, the higher its portability is.
Once I was engaged in a macOS app project. The app used so many native controls, that in many instances it was relatively easy to port the app to Windows.
Portability goes along with another component – compatibility. This is the system’s ability to run on different hardware, operating systems, applications (and their versions), network environments or certain devices. The most common examples are the mobile apps' compatibility with older OS versions and cross-browser compatibility.
The security non-functional requirement covers the system’s ability to deal with malware and authorized access. In this, the system’s security requirement defines which attacks it should handle and how it should confront such malware.
For example, you can set up the password expiration frequency or define the login flow and user roles as user actions and user behavior.
Availability (along with reliability and maintainability)
The system’s availability stands for how accessible the system is for a user at a given point in time.
For example, the system can be available to a user 100% of the time. In this case, the availability requirement will also include a plan for the system’s drop and what amount of time it can be unavailable.
The availability requirement always goes on par with reliability and maintainability. Usually, reliability means how long the system can operate without a failure for a given period. It is usually reflected in a percentage measure.
For example, 92% of reliability means a 92% confidence that the system will not experience any critical failures during a specified amount of time.
The non-functional requirement of localization describes how adapted the system is to the local user requirements.
For instance, users of the mobile app released exclusively for Saudi Arabia market mostly read from right to left. It means not only the app’s text that must be presented differently, the entire user interface is mirrored. Change your device language to Arabic to see for yourself.
Another example is how Uber adapts its service while expanding to new markets. For one, entering the African market, the ride-hailing service who stresses its focus on online payments made an allowance to the market and provided for hard cash transactions. As Uber General Manager for Sub-Saharan Africa commented: “We can’t enter new markets with a one size fits all mentality.”
Thus, localization is as much a quality requirement as a business necessity. If you do not consider the user needs in a new market, your product will miss the spot there.
Business Non-Functional Requirements
Besides non-functional requirements that outline the technical standards and constraints for the product, there are also business requirements. Unlike the earlier ones, business requirements are usually defined by offline conditions that should be considered in the digital realm. However, they may cross over with other non-functional requirements as they are the business rules that govern how the data is handled.
Example. Imagine you need an emailer for massive email campaigns. You know that most users are still utilizing an outdated version of Outlook. Thus, emails can end up in the spam folder in no time. It means that one will have to simplify email templates and seek a niche emailer solution to cover outdated Outlook versions. This business constraint will drive the entire development!
Business requirements also reassure particular constraints to cement the logic within certain functionality. For instance, a private railway company had been transforming its offline process of railroad switch inspection. As a part of the transformation, the switches in the database were to be assigned their geo-coordinates via a mobile app. Its user would arrive at a railroad switch and assign their geo-position to the switch they arrived at. The switches with coordinates would not appear in the app’s user interface. This way business assured there is only one traceable source for assigning geographic coordinates to an object of a railroad switch in the database.
3 Tips on Formatting Non-Functional Requirements
Besides figuring out the non-functional requirements for your product, it also matters to document them well. Here are some insights from me on this score:
Make Them Measurable
As a matter of fact, saying that your software should be just “user-friendly” or “convenient” is not enough for the development team to implement the requirement. Instead, you should indicate distinct measures or numbers that would define the effectiveness of your product. For instance:
By giving your requirements definite standards, you have more chances to face unexpected complications during the development and have tangible standards for the end result.
Set Standards for Components, Not the System
There is a mistake almost all of us make, especially project managers. We often define requirements for the system rather than determine definite components. As a consequence, the requirements look vague and generic.
It will help much if you figure out the features in your interface with which the users interact the most often and set up performance requirements. This way, the standards will be more district and effective.
Never Ignore to Clarify
The clarification of the non-functional requirements is a mutual process of discussion between the stakeholders and the project architect. So if you are working with a product development team, it will help a lot if you voice your expectations from the software and clarify the requirements.
Let’s draw up a little. Non-functional requirements are an essential part of the software documentation that does not yield to the functional standards in terms of importance. In fact, non-functional requirements are the instrument, allowing you to make sure that your system will function the way you imagine.
If you want to discuss how non-functional requirements could look at your project, please contact me.
What are the examples of non-functional requirements?
There are different types of non-functional requirements, that are determined for every project individually. Here are some examples of non-functional requirements that you might most certainly encounter:
- Scalability and Performance;
- Compatibility and Portability;
What are non-functional requirements?
Non-functional requirements are the software specifications that align with functional specifications, specifying them and expanding them. Non-functional requirements are important to clearly define the system’s characteristics and features.
What are non-functional requirements in Agile?
Agile methodology usually implies such non-functional requirements as Scalability and performance; Compatibility and Portability; Security; Availability; Localization.