What are examples of business requirements

Many requirement specifications and functional specifications differentiate between what are known as Functional requirements and Nonfunctional requirements. Functional requirements are requirements related to the intended use of the product. The non-functional requirements include requirements such as reliability and time behavior.

Differentiation between functional and non-functional requirements

This distinction between functional and non-functional requirements dates back to the times of ISO 9126 (which has since been replaced by ISO 25010):

Fig. 1: ISO 9126 distinguishes between functional and non-functional requirements

The separation between the two types of requirements can be found primarily in stand-alone software.

a) Functional requirements

Functional requirements are the requirements, the implementation of which directly serves the purpose of the product. They are specific to this product. Examples of this type of requirement are:

  • The software has to calculate the body mass index based on a formula.
  • The software must warn of drugs for which there is a contraindication or interaction.

b) Non-functional requirements

Nonfunctional requirements however, are mostly unspecific for a product. Examples of non-functional requirements are:

  • Time behavior: The system must have calculated the result within 10ms.
  • Resource consumption: The system can process 15,000 transactions per second without the CPU being used more than 50%.
  • Robustness: The system can be operated continuously for 4 weeks without restarting.
  • IT security: the software blocks the login for 30 seconds after three unsuccessful attempts.

Problems with functional and non-functional requirements

a) Difficult distinction

The distinction is often not trivial: Where would you subsume the ability of a system to recognize incorrect entries?

  • Under usability? One of the principles of usability according to ISO 9241 is fault tolerance.
  • Under reliability? ISO 9126 explicitly includes fault tolerance.
  • Under functionality? After all, it is a function of the system to recognize incorrect entries and to react accordingly.

It can also be argued about whether interoperability is really not a functional requirement. How else should the functionality of a system be found out via the UI?

Conclusion: A distinction between functional and non-functional requirements is usually superfluous. However, the software requirements specification must ensure that both types of requirements are specified.

The successor standard ISO 25010 no longer regards two aspects as functional requirements:

  1. (IT) security
  2. Interoperability

Fig. 2: ISO 25010 also recognizes functional requirements

b) Distribution of the documentation

Some manufacturers divide the functional and non-functional requirements into different documents: The product managers specify the functional requirements, the developers the non-functional ones.

The Johner Institute advises against this division. This means that manufacturers run the risk of separating related aspects and describing aspects that do not belong together in one document. This leads to regulatory problems with approval and traceability, among other things.

Note that maintainability is an aspect of the architecture, not the system requirements!

A requirement specification should describe stakeholder requirements, a functional specification the system requirements. You can check the latter very well with ISO 9126 or ISO 25010 for completeness.

c) Structure of the documents

Structuring documents according to the taxonomy of ISO 9126 or ISO 25010 does not make sense. The Johner Institute recommends dividing the software requirements according to the type of interface. In the audit guarantee, it provides complete templates in order to document the requirements systematically and in compliance with the standards.

Additional information

Find out more here how the audit guarantee can help you to document requirements quickly, precisely and in accordance with the law and thus to minimize delays in development and problems in audits.