Functional requirement

revision 0 — sometime — the contributor

Functional requirements specify the how product characteristics are manifested by a product; they describe what the product has to do. Verbs are commonly used to specify functional requirements.

Contents

What is a Functional Requirement?

Given a design problem, the second task is to identify the functional requirements (FRs) of the product, i.e. the requirements pertaining to what the product will have to do. (The first task is to get product characteristic definitions.) FRs are different from a product's behaviour. Behaviour is how a product responds to a stimulus, whereas a function is how that stimulated response serves some purpose in an environment.

Product behaviour answers the question: "How does the product fulfil its function?"

Product function answers the question: "Why is a particular product behaviour important?"

Behaviour depends on structure (e.g. an I-section beam behaves differently from an O-section beam in carrying a load), and since the product has not been designed yet, we have to start with function.

So a FR is a precise specification of the function of a product, phrased in terms of things it will do during operation.

Ideally, 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 physical product 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 it's intended operational functions, then what's the point of engineering the product at all?

The emphasis on product operation should run throughout the design endeavour – costing, testing, marketing, manufacturing, etc. Unfortunately, it rarely does. Cost specialists will consider cost the overriding factor that product design must address. This may be due to their short-sightedness, or to the designers' short-sightedness in accepting the importance of cost. Similar arguments may be made for all design factors.

Specifying Functional Requirements

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 planes. It is obvious that at a certain level, we will have some idea about the shape of the product. Planes don't look like cars; probably, they never will. There are of course exceptions⁽¹⁾

1.

A telephone

Nonetheless, any sense of a product's structure should always remain just that: a concept.

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 clause describing the action or reaction of the product within its operating environment.

In real life, design problems are rarely specified with just FRs. This is often because the individuals setting the problem do not know how to specify the problem correctly. A design problem could include FRs, specified in various bizarre ways, as well as characteristics and constraints. It is a very important upstream design task to study a design problem specification and extract the FRs, and to respecify them in a more structured way. Anything that isn't a FR, a characteristic, or a constraint doesn't belong in the problem specification.

Exercise for the reader:

What do you do if there are items in a design problem specification that are not FRs, characteristics, or constraints? Your client obviously intended something by including those other items. But what?

Understanding the problem is usually more than Half the battle toward finding a suitable solution.

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 environment, rather than part of the product. Since designers rarely have any substantive control over the operating environment of their products, it is considered acceptable (even desirable!) to mention the physical characteristics of the environment in the FR specifications. Resist bending. Note: 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. Note: 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).

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. 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. Indeed, this is more a specification of a product characteristic than an FR. 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?