Functional / non-functional

This is the most commonly-encountered division.

Functional requirements (FRs) express services that a system is to deliver.
All other requirements are non-functional (NFRs). These include requirements related to the "-ilities" (suitability, reliability, usability, interoperability, verifiability, ...). Nonfunctional requirements are typically not either satisfied or not satisfied, unlike functional requirements; instead, they are satisfied to a higher or lower degree. Example: A system isn't typically either usable, or not usable, but may be more usable or less usable than some other system.

Nonfunctional requirements are often called goals.

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 classification is also made for them. behavioral requirements or developmental quality requirements (or requirements that are neither):

Behavioral requirements characterize what a system's behavior is to be. These requirements are satisfied (or not) by what the system does when it runs.
Developmental quality requirements characterize the process by which a system is produced and evolved. These requirements are satisfied (or not) by the actions of the people responsible for producing a system.

Examples	"Turn out the lights when the room is unoccupied"	(behavioral)
Examples	"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)

Operationalizable: can be refined into a functional requirement whose satisfaction implies the NFR's satisfaction.
Example: Security (an NFR), refined into Confidentiality (also NFR) and then into PIN-authenticated (functional).
Checkable: cannot be operationalized, but there can be a functional requirement for a system component that can check and verify whether the NFR is being satisfied.
Example: Performance (NFR), refined into "Check database workload", refined into "Monitor and report number of queries answered per second" (FR).

Thomas A. Alspaugh
Assistant Professor, Informatics Dept.
School of Information and Computer Sciences