Non Functional Requirements

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.

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.