Thomas A. Alspaugh
Kinds of Software Requirements

Partitioning requirements by their subject matter

Functional / non-functional

This is the most commonly-encountered partition.

Examples Provide safe, reliable, and quick transportation around campus  (functional)
Print a receipt for every transaction  (functional)
Be self-explanatory and easy to use. (non‑functional)

Behavioral / developmental-quality

A slightly different partition [Faulk1995-srt] divides requirements into behavioral requirements or developmental quality requirements (or requirements that are neither):

Examples Turn out the lights when the room is unoccupied  (behavioral)
Be thoroughly testable so that customers will have a high level of confidence. (developmental quality)

Functional/non-functional and behavioral/developmental-quality don't quite divide requirements the same way. Most notably, there are nonfunctional requirements (such as, perhaps, Cost less than $500 per copy) that are arguably neither behavioral requirements (because they don't address the system's behavior) nor developmental quality requirements (because they don't characterize the development process). There are arguably behavioral requirements (such as, perhaps, Secretly provide access to internal program state needed to make testing more effective) that are more closely related to a nonfunctional requirements such as testability than to any ordinary functional requirements. It seems that every developmental-quality requirement would also be a non-functional requirement, and any functional requirement would also be a behavioral requirement (I have not come up with counterexamples, in any case).

Subdividing non-functional requirements

Nonfunctional requirements can be divided into operationalizable and checkable NFRs (and perhaps a third category of neither operationalizable nor testable — this has not been established yet) (Xu+Ziv+2006-apnf).

Partitioning requirements by their form


A goal is something that is desired but that might or might not be achieved, depending on circumstances. Goals are advantageous in several ways:

  1. They express things that often cannot be complete achieved (such as high quality or user friendliness), or definitely established (for example by testing), but that are nevertheless things the stakeholders care about.
  2. They are useful for thinking about tradeoffs of one thing for another.
  3. They are at a higher level than other requirements.
  4. They often refer to the system's stakeholders and the context in which the system will operate, rather than to the system itself.
  5. They are usually more stable than the system's proposed properties, models over time, and narratives; they tend not to change.


A requirement is often assumed to be a property that is expected to be true of the system: The system shall ….  The traditional requirements document is a thick book of such properties; such requirements documents rarely have coffee stains.

Such requirements are explicit properties that are expressed in isolation, which means that their intended context is implicit. The property is specifically stated, but the situation in which it applies and its significance in that situation are not stated.

It is traditional to use the verb shall for property requirements.

An example set of property requirements: the EMS requirements, for a phone message system used in industry to prototype and explore potential new features.

Models over time

In this form, the requirements (as a group) are the properties possessed by a model. The system is supposed to behave like the model.

Example: a Statechart or other finite state machine.

The desired system properties are left implicit in this form of requirements. It is not possible to distinguish which properties of the model are essential properties of the system, and which are accidental properties of the particular model that was chosen.

Models are most frequently used to express behaviors that unfold over time. If a model is formal, its behaviors can be explored or verified using software tools.


A narrative about the system can express what is expected from it in a particular situation. Narratives have the advantage of providing context and motivation, and showing how different expectations are related to each other. People are very good at expressing and understanding narratives, and can pick up on a wide variety of implicit or hinted information in a narrative.

Some kinds of narrative requirements are:

  1. Unstructured text telling a story.
  2. A use case, in its original meaning as a statement of a case (situation) in which a system will be used.
  3. A UML use case, or a narrative divided into steps with a variety of possible relationships among the steps. These relationships are often not understood except by a use case's authors.
  4. A timeline model (which is also of course a model), in which the relationships among events are graphically expressed by laying them out along timelines.

Regardless of the form in which requirements are expressed, people seem to end up telling, writing, and asking for narratives that motivate, explain, and illustrate what the requirements say.


Tabular forms organize requirements (often property requirements) into tables that show how the individual requirements are related, make it easier to find the requirement you are looking for, and simplify checking the requirements for completeness. The classic example of tabular requirements is the SCR (Software Cost Reduction) form.


Different people want different things from requirements.


Requirements come from many sources.



Stuart R. Faulk. Software requirements: A tutorial. NRL Memorandum Report 5546-95-7775. Naval Research Laboratory, Washington, DC. Nov. 1995.


Lihua Xu, Hadar Ziv, Thomas A. Alspaugh, and Debra J. Richardson. An architectural pattern for non-functional dependability requirements. Journal of Systems and Software, 79(10):1370–1378, Oct. 2006.

flip bgunflip