Skip to content
mainlogo google-rating trustpilot-rating mail call call-button cart
    Share this post

    Non-Functional Requirements - The Hidden Iceberg

    Written by:             Published on: Oct 3, 2018 12:00:00 AM

    Become an in-demand BA in 6 months or less!

    Talk to our Learning Advisor Today


    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

    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
    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
    Most Checklist
    Reliability Quality (e.g. faults discovered, faults delivered, fault removal efficacy) Target defect density Mission-critical applications Code and Design Review

    Recovery / recoverability
    (e.g. mean time

    recovery - MTTR)

    Ability to recover
    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
    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
    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
    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