Nonfunctional Requirements and Level of Requirements Specification

Type: Principles and Rules
Sources: My friend Sven, a very insightful discussion with Tom Gilb.


There seem to be a constant quarrel about so called 'nonfunctional requirements': what are they, what are they for, why are they so sparse in the common requirement specification documents, etc. This article sheds light on the discussion. It is a how-to for a good requirements specification hierarchy. A good requirements hierarchy is an important prerequisite to a more-conscious and logical design or architecture process — because real requirements drive design, not designs in requirements clothes.

The Problem

Most requirement specifications document I see these days have lots of required functions, and few (if any) requirements for other attributes of the system, like all the -illities. Function requirements most often take a binary form, while a scalar form should be used for many of the other types of requirements, including performance and resource requirements.
Note: Many analysts confuse scalar with non-functional. See definitions below.

It's not a good idea to have mainly binary requirements at the topmost levels of a system's requirements specification hierarchy. Why? They tend to be unjustified design hypotheses to some scalar requirements not well known (yet), turned into requirements (design constraints) by classification as requirements, not by consciously selecting and evaluating them as a design to satisfy a set of real requirements.
Note: Oops, stakeholders and analysts do design while describing requirements? Yes, they do, but many are not aware of the fact.


Note: These are abridged versions of definitions taken from Tom Gilb's highly useful Planguage Glossary of Systems Engineering Terms, for the purpose of this page only.

  • requirement LOCALLY DEFINED AS stakeholder-valued future state.
  • binary requirement LOCALLY DEFINED AS a requirement for a system's attribute that is observable in two states.
  • scalar requirement LOCALLY DEFINED AS a requirement that possesses or is measured using at least one scale of measure.
  • design (noun) LOCALLY DEFINED AS a suggestion as to how to fulfill one or a set of requirements.
  • design process LOCALLY DEFINED AS consciously selecting and evaluating design hypotheses as a design to fulfill a set of given requirements
  • requirements decomposition LOCALLY DEFINED AS the process of breaking down a set of requirements into a different set of requirements in preparing a requirement specification document for a subsequent level or phase of the project. Note: In decomposing requirements, you are building (or altering) a (hierachical) structure of requirements on different levels.

Principle, Rule, and Notes

An expert analyst said the following the other day (with altered wording to be consistent with the above definitions):

"The higher the level of a system's requirements specification, the greater the portion of scalar requirements." — Sven Biedermann

I'd restate Sven's Principle into a rule:

"The higher the level of a system's requirements specification, the greater the portion of scalar requirements should be." — Rolf's interpretation of Sven's Principle

The reason for this is two-fold:

  1. Defined scales of measure demand comparative (i.e. non-binary, non-black-and-white) thinking, lead to requirements that are unambiguously clear, and help teams be aligned with the business.
  2. No computer system can directly fulfill a scalar requirement; it has to be decomposed into a set of function requirements finally (which are design hypotheses for a set of scalar requirements, really), or (and ultimately) a design has to be found to fulfill it. In either case, a set of functions interacts and thereby attains (or does not attain) certain scalar characteristics of the system.

Sven's principle thereby describes a necessary characteristic of good requirement specification hierarchies. In other words if you find a high-level requirements specification document with few or no scalar requirements, it does not mean it is not high-level. It probably means that the author forgot to include requirements other than function requirements. There are many more very useful categories of requirements, like:

  • performance requirements
  • resource requirements
  • constraints

Grammar representation of complete requirements hierarchy

Note RG 2009-10-03: I deleted this part because the ideas presented here were not clear enough to convince Tom Gilb, my friend and critic. If you want to see them, you can always trace back to a previous version of this page, using the history button bottom right.

Related Pages

rating: +1+x

If you want to know more about a topic, simply tag the article with a 'morePlease' or 'examplesPlease' tag!


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License