This is an old revision of the document!
A functional requirement (FR) specifies how product characteristics are manifested by a product; they describe what a product has to do. Verbs are commonly used to specify functional requirements.
Product behaviour answers the question: “How does the product fulfil its function?”
Product function answers the question: “Why is a particular product behaviour important?”
Example: The behaviour of a spring is to deform elastically. That is, when the spring is given an input of a certain physical load, the spring responds by changing shape until it's reaction force equals the applied input force.
The function that this behaviour serves depends on how the spring is used. It may be used as a vibration damper, or to increase control of a machine (such as a car), or to prevent damage to some delicate items by distributing applied forces over longer periods of time.
Behaviour depends on structure (e.g. an I-section beam behaves differently from an O-section beam carrying the same load), and since the product's structure has not been designed yet, we have to start by defining function.
So a FR is a specification of the function of a product, phrased in terms of things it will do during operation.
FRs should never describe the form, shape, material, or any other physical characteristic of a product. Though this can be hard to do, it is very important to remain uncommitted to structural features at the beginning of a design project. By focusing on function rather than structure, the designer assumes a state of mind that is more open to new, innovative, and creative ideas, and less likely to commit design errors of the past. The designer is also more likely to understand ideas expressed by other design team members and is less likely to assume everyone else's ideas are inferior. The result, on the whole, is a better design process, which means a better final product.
FRs focus on the operational features of products. This is an important philosophical point: the key to a product is how it functions in operation, not during manufacture, or transport, or maintenance, or during any other life-cycle phase. Of course, requirements from all life-cycle phases are important, but if the product cannot perform its intended operational functions, then what's the point of engineering it at all?
Notwithstanding the foregoing discussion, it is generally rather silly to specify FRs with no mention at all of the physical nature of the product. This is because we generally already have some idea of what the product will be and do. Boeing doesn't design cars, and Ford doesn't design airplanes. It is obvious that at a certain level, we will have some idea about the physical nature of the product. Planes don't look like cars; probably, they never will1). There are of course exceptions: consider the two telephones shown to the right. Nonetheless, no FR should explicitly refer to a design intervention's physical characteristics.
Furthermore, FRs describe what a product does, but not what is done to the product. Designers should think of their products as (re)active entities rather than passive ones; that is, a product responds to stimuli by exhibiting a behaviour, which is how the product achieves its function.
So we can describe a FR as a sentence that takes the following form: “The product does something,” where the does something part is a verb or verb clause describing an action or reaction of the product within its operating environment.
All FRs must use active verbs - verbs that describe some kind of dynamic. In particular, the following verbs must never be used in FRs: to have, to be, and to be able to.
Also, FR verbs must never be negatives. For instance, “The product cannot break in bending” is a negative verb. In this case, the FR should be phrased as “The product must resist bending”.