A non-functional requirement (NFR) describes a feature or trait that defines a system’s state of being.

NFRs are

• expressed in the form of “system shall be <requirement>”, an overall property of the system as a whole or of a particular aspect and not a specific function
• Called “quality attributes”, “qualities”, “quality goals”, “quality of service requirements”, “constraints”, “non-behavior requirements”, “technical requirements”
• Can be categorized as either
  • execution qualities (safety, security, usability) which are observable during operations (at run time)
  • evolution qualities (testability, maintainability, scalability) which are embodied in the static structure of the system

It is important to understand various types of NFRs, if they apply to your specific project and what questions can be used to help elicit and define non-functional requirements.

Different teams will group NFRs into different categories based on what they are producing, what they are familiar with, etc.  Some groupings today are:

• FURPS – Functionality, Usability, Reliability, Performance, Supportability
• RASUL – Reliability, Availability, Servicability, Usability, Installability
• IIBA Supports – Reliability, Performance, Efficiency, Operability, Security, Compatibility, Maintainability, Transferability

I will be covering a number of NFRs to help you understand each of them and provide questions you should be asking and example statements in future posts.