Why Classify Requirements

Most treatments of RequirementsManagement go to a lot of trouble to distinguish between different kinds of requirements. One can classify requirements by whether each statement is a requirement, a constraint, or a goal. Others distinguish between BusinessRequirements, UserRequirements, PerformanceRequirements?, FunctionalRequirements, NonFunctionalRequirements, SystemRequirements, OperationalRequirements?, SoftwareRequirements, HardwareRequirements?, InterfaceRequirements?, MaintenanceRequirements?, AttainableGoal?s, StretchGoal?s, ad infinitum.

Many of the distinctions seem vague or arbitrary. For example, let's say the customer wants a user to be able to complete a sales order in less than a minute. Is that a user requirement? A business requirement? A functional requirement?

What is the point of all these classifications? Are different types of requirements analyzed in differing ways? Is it ever useful to only look at one particular class of requirements in isolation? Do the classifications help in managing changes to requirements? Do the distinctions matter to anyone other than RequirementsSpecificationWonks?

The requirement/goal/constraint distinction, while apparently one of the easiest-to-understand classification systems, also seems to be the least useful. A statement is usually classified as a "goal" if it is vague and untestable, or if it is just a desire that does not have to be fulfilled--and most authorities recommend that such statements be removed from requirements documents. A "constraint" is usually just a requirement that is considered to be less negotiable than the others. (That last sentence is not true; see below.)

Goals are usually used as design guidelines, but aren't binding like requirements. Goals are ways for managers to "require" developers to overdevelop the system. Think of adding a margin of safety on the maximum load a bridge will support. A common goal in military/aerospace systems is using 50% of capacity or throughput. This allows for software growth without hardware growth, which has a funny way of happening as FeatureCreep while still in development. There is also historical evidence of fully-loaded (or nearly so) systems being overloaded when fielded, so the extra margin allows the system to survive.

Near the end of the project, anything not labeled a requirement gets dropped on the floor. And some of the requirements get dropped on the floor, too.

So it sounds like some types of requirements are the real requirements and others are not. Why not just drop the non-real requirements, rather than using these cryptic categories?

Because the true requirements of the system are usually best defined as non-measurable goals. Requirements, as defined in most software development literature, are limited to testable issues.

[If it can't be measured or tested, how do you know when you've done it? And how do you know when to stop?]

Don't forget about QFD, QualityFunctionDeployment. These guys have a method for putting a number on requirements to prioritize them on a project-wide scale. Everything you want to add as a requirement is assigned a weight towards the total project value. If you need to make one item more important than another one then you have to shift the weighting factors around. Pretty cool.

The usual classifications

The following are seldom explained clearly outside the Requirements Engineering world, but they have pretty standard meanings.

A functional requirement is something that the system must do: a function that it serves, like "transport people from one place to another", "store certain information to be retrieved later", "communicate flight booking information to travel agents", etc.

A non-functional requirement is an attribute of a functional requirement, like how fast the system does it, how easy it is for users to use it, how expensive it is to produce, etc.

A constraint is a limitation on the kinds of designs that may be considered for implementing the requirement, like "it must be built out of steel" or "it must be written in COBOL".

A constraint is different from a requirement in that a constraint describes design space while a requirement describes function space. Function space is the various ways that you measure the effects of a given design. You can control design space pretty directly, just by choosing it. Function space is not so easy to control. Engineering is the art of finding something in design space that achieves desired results in function space. That's what people go to school for.

Of course, sometimes the word "requirement" is used to refer to any criterion of success whatsoever. In this community, the word actually has two easily-confused senses: the broad one just indicated, and the narrower one of a specified property of the function space.

Why classify?

Here are the principal reasons for making these classifications.

First, separating function space from design space is intended to give the designers total freedom to explore any kind of design whatsoever. By limiting requirements to function space, we focus on what the customer really cares about while allowing the engineers to bring all their knowledge and creativity to bear on the means for achieving it. The separation of function space from design space is perhaps the key cognitive move in system engineering, making possible all sorts of intelligent heuristics for finding good designs.

Second, functional requirements are distinguished from non-functional requirements because there are usually much more difficult problems in designing and testing for non-functional requirements. Getting a design to meet the non-functional requirements often takes up large portions of the schedule and is filled with knotty problems. Functional requirements tend to be more straightforward. For example, getting a database to store and retrieve transactions is pretty straightforward. Getting high performance out of it on a distributed network with high load requires a lot more thought, design, and testing. ("Non-functional requirements" is a horrendous choice of words, but it's standard in the system engineering community.)

Finally, constraints are described separately because often there are reasons why the customer wants to assume that your design will be taken from a given space. For example, if the function is "provide lift for an airplane", the customer probably wants wings rather than some magnetic contraption that requires a huge network of nuclear-powered satellites. By having the separate word "constraints", we can explicitly limit the design space without confusing the distinction between design space and function space.

The HexGridSphere example classifies goals as AttainableGoal?s and StretchGoal?s.

See: PutaNumberOnIt, DontPutaNumberOnIt (both of these pages are still in process; we're hoping to achieve some sort of consensus here)

CategoryRequirements