Skip to content
Share this post

Non-Functional Requirements - The Hidden Iceberg

written by:

Become a Business Analyst

Speak to a Learning Advisor to learn more about how our bootcamps and courses can help you become a Business Analyst.

The discussion on non-functional requirements, popularly abbreviated as NFR, is a pretty controversial topic.

Sometimes, we hear that the technical team provides the non-functional requirements. It's a bit strange as a system is built for stakeholders and stakeholders should be the providers of the same.

Why do stakeholders find it difficult to provide NFRs?

What makes a requirement non-functional?

Why do we need them?

Is there any easy way to identify them?

Are they too technical for our stakeholders? 

NFRs mean those requirements that are not related to the functionality of the system as the name says it.

Then what exactly are these and why do we need them?

Let's imagine a system where it publishes results for 10 graders school certification examination in a country, say USA. What kind of load it will have when the results are declared? Hundred thousand students and parents will log into the system within 30 minutes of the results being declared. The system must be able to handle such a large spike in load.

This is the kind of requirements which is generally referred to as Non-functional requirements, the requirements which are important for the user community or for the smooth functioning of the system like usability, reliability etc.

It is actually interesting to know that the non-functional requirements have a significantly higher impact on the system architecture than functional requirements.

Failure to capture non-functional requirements can lead to complete re-designing of a solution.


Non-functional requirements should always be described in clear terms, such as

  1. The system should be able to handle 0.1 million users simultaneously.
  2. The response time has to be less than 2 seconds for each user.

Here is a good list of common non-functional requirements:


NFR Category Non-functional Requirements Short explanation Applicable to situation Can be tested by
Constraint Price The target price for the solution Most Checklist
Constraint Resource constraints Constraints imposed on development such as constraints imposed due to the small screen size of mobile devices. Most Checklist
Compliance Compliance Regulatory compliance. Healthcare (HIPAA, FDA) Integration testing across systems
Compliance Documentation Documentation requirements. Healthcare, Aviation, Automotive Test cases for color blindness
Compliance Legal and licensing issues or patent-infringement-avoidability Adhering to compliance requirements. Most Test cases verification of record data update
Maintainability Analyzability Ability to investigate a failure Most Backup recovery test
Maintainability Changeability Ability to change one component without affecting others, and without causing unexpected failures Most Review the application code
Maintainability Deployment The ease with which an application can be deployed and upgraded. Most Review the application code
Maintainability Escrow The source code of an application is kept securely and available to the buyer under certain conditions Purchased an out-sourced product Checklist
Maintainability Extensibility / Modifiability Ability to extend the product easily Most Consumer feedback
Maintainability Supportability Ability to support applications for a specific period, locations etc. Most Checklist
Maintainability Testability Ease of test automation Most Checklist


NFR Category Non-functional Requirements Short explanation Applicable to situation Can be tested by
Performance Performance/response time (performance engineering) Time taken to respond to a user request. Most Checklist
Performance Resource utilization % of available capacity used Most Checklist
Performance Scalability Ability to support a specified number of users/transactions Systems supporting a large number of users Review the application code
Portability Interoperability Ability to work with existing systems. Most Review the application code
Portability Platform compatibility Ability to work with stated platforms. Most Review the application code
Portability Replaceability   Most Review the application code
Reliability Availability % of the time the system is available. Critical systems Latency testing
Reliability Backup The frequency at which data must be backed-up. Universal Test on desired platforms
Reliability Disaster recovery Time taken to restore the application after a disaster. Most Multiple browser tests
Reliability Failure management (Fault tolerance) Ability to manage failures. Most Checklist
Reliability Quality (e.g. faults discovered, faults delivered, fault removal efficacy) Target defect density Mission-critical applications Code and Design Review
Reliability Recovery / recoverability (e.g. mean time to recovery - MTTR) Ability to recover quickly Mission-critical applications Review the application code
Reliability Reliability (e.g. mean time between failures - MTBF) Ability to provide service when needed Mission-critical applications Review the application code
Reliability Replaceability Ability to replace a faulty part on the fly Mission-critical applications Review the application code
Reliability Resilience Ability to withstand attacks Mission-critical applications Checklist
Reliability Robustness Ability to operate continuously even under adverse conditions. Most Simulation of internet attack
If the hardware is present, heat cycle testing
Reliability Stability   Most Checklist
Security Audit and control aka Accountability To track changes made to data. Finance, Healthcare Review the application code
Security Authenticity   Most Review the application code
Security Confidentiality Protect data from being exposed to unauthorized users Most Review the application code
Security Integrity Maintaining correctness of data Most Penetration test
Security Privacy Ability to keep personal data secure. Health care Penetration test
Usability Accessibility The application being usable by persons with special needs such as color blindness. Government Review the application code
Usability Ease of use Limit the number of clicks to maximum 3 clicks to complete any transaction Most Review the application code
Usability Emotional factors (like fun or absorbing) Making application likable by a certain audience. Education Checklist
Usability Internationalization Ability to operate the application in different countries such as handling multiple time zone, currency, languages etc. Most Review the application code
Usability Learnability Different user groups should be able to use the product with or without training Most Review the application code
Usability Safety Ensure safe usage of the product and prevent damages caused by the application. For example, safety features for a navigation system. Where there are dangers to human life. Aviation, Automotive, Health care etc.. Keyboard control test
  Certification Certification on a particular technology such as certified on Azure. Most Untrained user test
  Localization Ability to satisfy the needs of a particular country or domain (say petroleum industry) Most Review the application code
  Re-usability Ability to re-use existing components and create new reusable components Most Review the application code
Portability Installability Ability to install or uninstall easily Most Review the application code


  • Makes the system user-friendly/easy to use and acceptable
  • Absence of them makes it lot more difficult to use for users
  • The system may get abandoned due to the absence of these features


  • Gets missed out often in requirements gathering exercise
  • Difficult to articulate or define quantitatively

We will be happy to receive comments on other types of non-functional requirements that you may have come across in your projects.


 Spot the similarities - NFRs and building foundation

 Enterprise Analysis vs Strategy Analysis – Why the Shift?

  Previous Next  

Related Posts

Write Comment

Write Comment