Everyone working in Software industry knows what Non-Functional Requirements (NFRs) are, but even after that, I have seen so many cases where solution is designed, developed and delivered without considering key aspects of NFRs or very poorly defined NFRs or team defined NFRs very late in the development cycle. Ultimately either solution fails, or business spend extra time and budget to get the solution fixed to meet these missing non-functional requirements.

In this article, we are going to discuss 3 important things about NFRs,

• Why and When to capture NFRs
• How to define measurable and testable NFRs
• NFR trade-off matrix and its importance

Why NFRs and When to capture NFRs?

Non-Functional Requirement will not describe what the system will do, but how the system will do it, such as performance requirements, design constraints, scalability requirements, etc.

Missing out of NFRs will have direct impact on adoption of the system, such as,

• System not scaling up to customer’s needs, system slows down and become unresponsive
• Security breach of confidential data
• System not available during the time when its required most, resulting in direct impact to business
• Disaster Recovery and backup not configured, resulting in data loss
• And many more..

Non-functional requirements (NFRs) should be gathered as early as possible in the development cycle, preferably along with functional requirements.

One more question which was very frequently asked – whom should I contact to define NFR, customer’s IT team or customer business folks? Answer is – BOTH.

• IT team will provide you details like limitation of current IT infrastructure, portability requirements such as portability across different cloud platforms like AWS, Azure, etc.
• Business will provide you details related to performance and scalability, such as how may user/market growth they are expecting in future, how this application can change this business and user interaction, etc.

So, contacting both business and IT is utmost important to capture NFRs.

Approach to define NFRs

Converting vague ideas about quality and making them measurable is both an art and science. Start with identifying which quality attribute you want to elaborate. Next, identify metrics that will be used to measure that quality attribute. Once you have identified measurable metric, use that metrics to define requirement that is both measurable and fulfill customer’s requirement too.

Following are couple of examples elaborating this process,

Trade-Off among NFRs

Assume you are developing an application for an enterprise, which can be accessed only by its employees. You want these employees to be productive and should be able to access this application from anywhere. But security is also important, as only company employees should be able to access this application and data. So, Security and usability are both important but there is potentially a trade-off to be made here. It would be convenient to be able to just pick up any device and access application without password, or application could be secured by requiring two factor authentication on every time application is accessed. So, these requirements contradict with each other.

In this scenario, a trade-off matrix helps us identify and communicate these trade-offs so that you can deal with them intelligently. Following is an example of trade-off matrix among 5 NFRs,

Read this table from left to right, you can see there is a negative relationship between security and usability. That means when there is conflict between Security and Usability, preference is given to Security. That doesn’t mean, you don’t give any preference to Usability. Ask a question to your self – how can you maximize Usability without compromising Security? For above example of multi-factor authentication, there could be solutions like supporting fingerprint ID or face recognition as second factor authentication, that can improve usability too, without compromising security.

I will highly recommend you to prepare this trade-off matrix during the requirement phase itself, and have a discussion with your stakeholders to review it, so that everyone understand these trade-offs, and no surprises during or end of the engagement. I am sure, you will be required to refer this trade-off matrix multiple times during your development phases.

 

In short, defining measurable and effective NFRs requires some thought and creativity. Highly recommend, plan for defining NFRs early in the development cycle and include NFRs as part of all phases of your software development, from requirement gathering to design to development and finally all the way up to testing.