Fil Salustri's Design Site

Site Tools


This is an old revision of the document!

Functional Requirement

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.

Function are different from behaviour. Behaviour is how a product responds to a stimulus, whereas a function is how that stimulated response serves some purpose in an situation.

What is a functional requirement?

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?

Specifying Functional Requirements

bakelitetelephone.jpgFig. 1: A telephone.

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.

iphone4.jpgFig. 2: Is this still a telephone?

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”.

Examples of Good and Bad Functional Requirements

Well-specified functional requirements

  • The product must display enlarged images.
  • The robot must orient parts on the ground at any angle. Note
    • We can mention the “ground” here as part of the situation, rather than part of the product. Since designers rarely have any substantive control over the operating environment (part of the situation) of their products, it is considered acceptable (even desirable!) to mention the physical characteristics of the environment in the FR specifications.
  • Resist bending.
    • There are various equivalent English forms for expressing FRs; here, there is an implication that we are talking about “the product” during its operation. One might ask: “To what degree should the product resist bending?” But the answer to this begs the introduction of a constraint.
  • Excess heat must be dissipated to the ambient air.
  • The container must hold hot liquids.
    • We might have said “cup” instead of “container,” but that may have carried unwanted connotations regarding capacity (e.g. a mug holds more than a cup). “Container”, on the other hand, is much more general and helps leave open the possibility of developing innovative designs.

Badly-specified functional requirements

  • Maintain toughness in bending.
    • Who is doing the maintaining here? This can be interpreted as a direction to the designer, not a function of the product; i.e. the designer must design a product such that he maintains the product's toughness. This is why it's important to specify the subject of every constraint.
  • Minimize the weight of the car.
    • Although this isn't a constraint (because an objective function like minimize doesn't set hard limits on the value of the weight of the car), it is an instruction to the designer and not a product function.
  • Minimize material costs.
    • Cost is not a product function. And it clearly is an instruction to the designers, not about the product.
  • It must be possible to pour hot liquids into the cup.
    • This is a passive statement, more descriptive of the cup's user (which is part of the environment) than of the cup itself.
  • Use 6061-T6 aluminum.
    • This includes a direct reference to the required value of a characteristic of the product.
  • The robot must have a rotating elbow joint.
    • Same as above.
  • Use a grade of steel that maintains toughness.
    • The reference to a material is not appropriate.
  • Manufacturing costs cannot exceed 10% of the unit cost.
    • There are all kinds of things wrong with this one. Can you identify all the problems with this statement?
Well, maybe not never….
design/functional_requirement.1584034210.txt.gz · Last modified: 2020.03.12 13:30 by