A non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors.
tow a caravan
Non-functional requirements are often referred to as quality attributes and typically show up in the system architecture of your product.
Easy to overlook
Usually, not part of your customer conversations (until it's too late).
Easy to over-engineer
Premature investment in NFR can distract you from creating value for your customers
Out of sight
Most of the NFR are hardly observable during the product development process.
It is the probability that the system will perform successfully at a given time when used and under given conditions and in an ideal support environment.
A = uptime / (uptime + downtime)
In most cases, this is a number fairly close to one and presented as a percentage.
99.95% is usually a good threshold
Reliability is closely related to availability.
This is the probability that the system will work for a certain time, a given time interval.
R = total time in service / # of failures
Availability tells you the total amount of downtime you have in a year, for example.
Reliability talks about how that downtime is distributed over that year.
This can be one large downtime period or several smaller, scattered downtime periods. Depending on what kind of product it is, one of them may be more beneficial than others. Users have to do long synchronous work with your product and even the slightest amount of downtime will cause crashes to reset. This will practically make it impossible to complete it at all. In this case, one big downtime followed by a large safe period of time can be beneficial.
This is the time it takes to complete a particular operation.
We usually measure whether a certain percentage of your users falls below or above a given threshold.
It is usually difficult and impractical to try to achieve a performance goal for 100% of your users. Some of them have old hardware, weak internet connection or other software with high computational load.
Performance is one of the most subjective non-functional requirements because it is based on user perceptions and expectations.
There are well-known experiments showing that you can effectively improve the perceived performance of a slow operation by distracting the user in some way and achieving an improvement in perceived performance without improving the operation itself, which can be costly or even impossible. Specific performance and execution times for some operations that were normal 10 years ago would now be considered completely inappropriate or unacceptable.
It measures how quickly a system can adapt to a significant change in processing requirements at both the top and bottom scales.
The time it would take for a system to adapt to an increased/decreased load.
It may even be an automated process based on some triggers in your environment. Your system must be designed in a scalable way. Early design decisions can be the difference between an easily scalable product and an almost impossible to scale product. Scalability also matters. Different values will lead to the solution of a number of new problems. Therefore, you need to think carefully about the realistic amount of workload, both now and possibly in the future.
How the specific non-functional requirement is defined in the context of the product?
How do we measure and gather data points for this requirement?
Set a Target
What are the right goals for users and business we are addressing with our product.
Identify gaps and put in place action plan that addresses those gaps.
By following this outline, you will be able to solve most of the non-functional requirements that you need to solve. Taking action to achieve your goals is always the most obvious thing to do.
Cutting corners and deprioritizing non-functional requirements is often refer to as Technical Debt.
Technical Debt can jeopardize your product success by incurring high costs on new features development, limiting product operations, and prevent your from meeting non-functional requirements.
Product teams need a deliberate strategy for addressing technical debt on time.
Where functional requirements meet user expectations, this is the starting point, the point of the product market. If non-functional requirements are not a key value proposition for your product, it probably doesn't make sense for you to invest in non-functional requirements before the product hits the market. We will put our efforts into making our product do the right thing. And when you know you have the right product, you can start investing in solving non-functional requirements. Products should be completely rewritten at a later stage. We always start with the end goal, set aside our future non-functional requirements, and make sure that even if we're not investing in them right now, we're laying the foundation for a scalable, performant, and highly available product.
If we don't launch our product with these goals in mind, it will be difficult for us to address them at a later stage.
There are exceptions:
If NFR become part of your main value proposition, you need to be sure that they will be considered. Performance should be your main focus.
If you are legally bound to follow the rules. You can't afford not to do this from day zero. If possible, outsource these features or defer them as late as possible to allow you to focus on your main value proposition.
No “one size fits all”
The right targets and goal should be derived by how non-functional requirements are delivering value to your users and what is the minimum bar that will meet their expectations.
No “free lunch”
Higher goals come at higher cost, so we always need to be mindful about over or under investing engineering time and cost.
Under-investing can also be dangerous and long-term fatal for your business.
You are not alone in this.
The key is to partner with your engineering team. They shouldn't be left without context. A product being performant, secure, and reliable isn't a product of the engineering doing their job the right way. It needs nurturing, time, and focus at the right doses.
Emil Tabakov, Coursera Sr PM