Non-functional requirements

There is some dispute regarding the use of the term non functional requirements and whether it is the correct term. However, it is in common use and serves a recognised purpose. In this article it is used to describe general characteristics and properties that are required. They are non-functional in the sense that they don’t describe any sort of behaviour.

The business have a tendency to miss them altogether which means the business analyst needs to help the business in identifying these. There are some obvious ones that are identified quickly and easily such as system availability, acceptable response times and there may be cost and time constraints.

The remainder are often overlooked. It is very important to devote the effort extracting these as they can be critical to the project success and a significant contributor to cost which will increase if they are identified later in the project (for more information on costs attributed to late identification of requirements, see Requirements Engineering – an Introduction)

The only way to really identify these requirements is with a deep understanding of the business, it’s processes and strategy and the specific objectives of the project. The business analyst ofetn doesn’t have this knowledge, in which case, there are many ways to identify non-functional requirements which include:

  • examining functional requirements to deternmine possible non-functional requirements
  • walking through the business process or a prototype of the system
  • observing a user a work
  • interviewing a user 


Armed with this knowledge, it is more likely that the business analyst will be able to direct the stakeholders towards the requirements they never thought they had. 😉


The following is taken from Wikipedia from the acronymn FURPS and provides some triggers for the categories of non-functional requirements that may have been overlooked:

  • Functionality – Feature set, Capabilities, Generality, Security
  • Usability – Human factors, Aesthetics, Consistency, Documentation
  • Reliability – Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure
  • Performance – Speed, Efficiency, Resource consumption, Throughput, Response time
  • Supportability – Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability

Other Links

Non-functional requirements from Wikipedia – a huge variety of categories for non-functional requirements are suggested and described here

Volere requirements template and non-functional requirements – another view provided by Suzanne and James Robertson which is very useful


Related books

Mastering the Requirements Process contains a helpful chapter on non-functional requirements

Thank you for reading this article, please make comments if you have questions, disagree or wsh to discuss further

About Alex Papworth

5 Responses to “Non-functional requirements”

Read below or add a comment...


  1. […] Non-functional requirements (for more detail, see Non-functional requirements article) […]

  2. […] Non-functional requirements (for more detail, see Non-functional requirements article) […]

  3. […] It will also be necessary to detail non-functional requirements which describe the characteristics or qualities of the resulting system (see Non-functional requirements). […]

  4. […] Object Technology regarding quality of quality requirements – useful, academic article. Also see Nonfunctional requirements for more on quality […]

Leave A Comment...