Non-Functional Requirements Explained in Practice
Probably you’ve heard about non-functional requirements (aka NFRs) before. I have also encountered this concept several times at the beginning of my path. However, when someone explained to me what the non-functional requirements are — it seemed understandable, but still unclear:
OK, so what? Should I use them in my daily work somehow or is it just a theoretical thing to know? 🤔
And it took several years of experience for me to come up with the answer. 💡
What Are Non-Functional Requirements?
Here’s the definition:
If you think of functional requirements as those that define what a system is supposed to do, non-functional requirements (NFRs) define constraints which affect how the system should do it.
It is much easier to understand the non-functional requirements (NFRs) through comparison with functional requirements. Let’s compare.
Functional Requirements Examples:
- When the user logs in — he/she is redirected to the “Home” screen.
- When the user clicks “Submit” the form data is saved.
- When the page is refreshed — the banner should not be shown.
- When the link is clicked — the page is opened in the new tab.
Non-Functional Requirements Examples:
- All the traffic should be encrypted and sent through the secured protocol so that any third-party entity can access it (Security).
- The page should work properly in the last 2 major versions of the following browsers Chrome, Safari, Chrome mobile, and Safari mobile (Interoperability).
- The system should work properly and should not fail under the load of 10'000 concurrent users using it (Performance).
- All the logs should be divided into 4 categories (debug, info, warn, error) so that they can be easily searchable (Maintainability).
- All the features should be accessed by the authenticated user with not more than 5 mouse clicks (Usability).
So, what we see here is that NFRs are the requirements that cover the Quality Attributes (-ities).
Quality Attributes
Here’s the list of the most popular quality attributes for the software systems:
- 📈 Performance and scalability. How fast does the system return results? How much will this performance change with higher workloads?
- 👜 Portability and compatibility. Which hardware, operating systems, and browsers, along with their versions does the software run on? Does it conflict with other applications and processes within these environments?
- ✅ Reliability, availability. How often does the system experience critical failures? How much time does it take to fix the issue when it arises? And how is user availability time compared to downtime?
- 🔒 Security. How well are the system and its data protected against attacks?
- 😀 Usability. How easy is it for a customer to use the system?
- 🛠 Maintainability: How easy it is to maintain the ongoing system? How quickly are the critical errors identified? How easy it is to add new features?
- 🏹 Deployability: How easily and quickly can the system or its parts be deployed without interruption?
You can find the full list of quality attributes here.
How to Write the Non-Functional Requirements
- 📄 Collect all the NFRs in a single document. Make it easy to find all the requirements in a single place.
- ✊ All the NFRs should follow the same structure and use the same definitions. In other words, they should be consistent.
- 📐 NFRs should always be measurable. Make sure to describe how to measure if the NFR is fulfilled.
- 🧪 NFRs should be testable. It makes no sense to describe something that cannot be checked. After NFR is written — check whether it is possible to test it.
- 🔴 Prioritize the NFRs list. Let your developers and QAs know what is critical and what is less important to be implemented and checked.
How to Use NFRs in Practice
Who is responsible for writing the NFRs?
Usually, the Software Architect is responsible for defining the NFRs. Together with the customer, business analyst, UX designer, and technical lead they should come up with a reasonable list of the NFRs.
Should the functional requirements depend on the NFRs?
Definitely. You can think of NFRs as a Constitution and the FRs as laws. Each functional requirement should be written in a way to not contradict any of the NFRs.
Should the NFRs be tested?
Yes, NFRs definitely should be tested. Despite testing all the NFRs together with the functional features testing is ideal — it is always too much time-consuming in practice. So the best choice here could be to create a regular process of non-functional testing. For example, right after the regression testing or once in a period (month, quarter, year).
How to accelerate Non-functional testing?
Of course, non-functional testing is much easier when most of its part is automated. Think creatively and write automated tests to check whether NFRs are fulfilled. It saves a huge amount of time providing the guarantee that in the end, you receive a high-quality product.
👋🏻 Thank you for your reading.
💡 I hope this article inspired you to improve the non-functional requirements in your project.
📣 Please share this story if you think it is useful and follow me to be the first to receive the next stories.
Further Reading:
