What is a Non Functional Requirement

Non Functional Requirements or NFRs describe characteristics of software that are not defined in terms of functionality. Generally these are attributes or constraints on the system that end with ‘-ility’ or ‘-ilities’.  For example:

  • maintainability
  • scalability
  • usability

Non Functional Requirement Types

There are potentially dozens of NFR type.  The importance of each NFR type will depend on the type of software, the context and the use case.  Some of the most commonly considered NFR types are:

  • Security
  • Performance
  • Scalability
  • Reliability
  • Usability
  • Legal
  • Maintainability
  • Portability

A comprehensive list of NFRs is available on Wikipedia.

Security – a special case

It is worth taking a closer look at Security as an NFR.  Although security is commonly considered to be non functional, in reality most security requirements are in fact functional.    For example permission checks before running a process, is likely to be a functional requirement.  In our studies over 90% of all security requirements are functional.

The Benefits of Auto Detection of NFRs

Non functional requirements are an important dimension of software.   Often they are overlooked, or of poor quality (unspecific, incomplete or inconsistent).   NFRs can have a significant impact on the work to deliver a piece of software.  Neglecting them can lead to increased risk for a project.

When you use ScopeMaster to analyse your requirements for potential NFRs, you can build up a checklist to ensure NFRs are correctly and adequately covered.  This will reduce risk to your project.  Also you want to avoid mixing functional with Non-functional requirements unless it is necessary so to do.

NFR Detection, Automated

ScopeMaster scans your requirements (or user stories) looking for clues to important non-functional requirements.

CRUD Analysis with ScopeMaster - screenshot

ScopeMaster analyses the text of your software requirements.  It detects the most likely non functional requirements from within each requirement.

It determines a probability as to whether each requirement is or contains a non-functional requirement.

Example Use Cases

Most NFRs are “buried” within other requirements and are difficult to spot.  Architects often have to sift through hundreds of requirements to try and filter out NFRs that might impact the architecture of a system.  If these are not identified early enough, inappropriate design decisions might be made.  These design decisions can lead to costly rework or technical debt.  ScopeMaster’s ability to spot these NFRs from the outset helps to expose NFRs before the design work has taken place.  Typical use cases:

  • You have many requirements and are trying to detect all the NFRs of a particular category.
  • You have many requirements and are not sure whether you have included any NFRs within them.
  • You need to check for potentially conflicting NFRs
  • Your requirements have been gathered by multiple people and you need to harmonise the NFRs.

ScopeMaster detects the the probable phraseology from the requirements that may be or infer a non-functional requirement.

Quality Non Functional Requirements

What makes for high quality NFRs?  You should always try to quantify non functional requirements in quantifiable terms which makes sense to the team and to which the customer can relate.  These should give you the “acceptability level” of any given NFR.  For example, all web pages should load within 1.5 seconds, ready for the user to interact.  

Examples of Non Functional Requirements

Here are some NFR examples, note the specificity in each one.  Unambiguous pass/fail criteria are included with each:

Performance – All web pages will load to interaction within 2 seconds on a 5Mbs connection from anywhere in the world.

Capacity – With negligible changes, the software should be able to cope with 3m transaction records.

Legal – The system shall be compliant with GDPR legislation including the ability to report on and/or delete personal records subject to specific request.

Usability – The website shall be compliant with WCAG 2.2 level A