We invite the engineering design research community to examine the current state of the engineering design lexicon. We expose the nature and the pervasiveness of practices that often hinder intelligible discourse within the engineering design literature.

We are investigating the language used by researchers, educators, and practitioners in the design discipline. Our activity is driven by the concern that many researchers use the same term with different intended meanings, creating what we call confounding situations which may lead to material misunderstandings in design research. Compounding the problem is the fact that some commonly used design terms are not truly supported by standard dictionary definitions.

We hereby invite the engineering design research community to examine the current state of the engineering design lexicon.. (We use the dictionary definition of the word lexicon: a special vocabulary of a science, discipline, etc.). Using a simple table-design example, we show confounding situations where such commonly used terms as criterion and metric are used sometimes as synonyms and sometimes not, potentially leading to material miscommunications. In addition to detailing the outlines of the design lexicon deficiency, we pose important rhetorical questions regarding the potential negative impact of this unclear lexicon. We also propose some avenues to a constructive and productive community-wide discussion on this subject. We pose the following general questions:

1. What do you think of the current state of the engineering design lexicon?
2. Does the alleged confounding state of the engineering design lexicon matter?
3. How should the design community address the general state of the engineering design lexicon?

We present our views regarding each of the above questions, and we look forward to receiving your input. We hope that this effort will be a catalyst for the development of an engineering design dictionary that will enjoy broad acceptance within the design community.

1. What do you think of the current state of the engineering design lexicon?

Our view:

It is our observation that, although the maturing field of engineering design is possibly as old as the field of engineering itself, the lexicon of engineering design is in a state of infancy. The unfortunate reality is that we employ implicit or explicit definitions that may vary from author to author, in a given context; from paper to paper, for a given author; or even from paragraph to paragraph, in a given paper. The engineering design lexicon can be characterized as generally being in a stagnant state. Our view is supported by the illustration of many confounding situations regarding the engineering design lexicon.

Other views

2. Does the alleged confounding state of the engineering design lexicon matter?

Our view:

We note that for almost every mature technological area, there exists in tandem an equally mature lexicon - one that allows for and promotes concise and intelligible discourse. The field of engineering design is unfortunately not so blessed, as yet. In our view, this less-than-mature discipline is experiencing a re-invigorated evolution that began in the recent past from both academic and industry perspectives. A more rigorous approach to the teaching and the practice of engineering design will play a constructive role. We note that the existence of a broadly accepted engineering design lexicon will not only benefit the engineering design discipline in general, but will also facilitate other specific activities, such as the development of engineering design taxonomies. We also note that the motivation for a mature design lexicon is rooted on practical considerations. Today's design activity takes place in a truly multidisciplinary environment, which often involves engineers of diverse backgrounds. Written and oral design discourse among design researchers does not rely on a generally accepted and documented lexicon. These situations are symptomatic of a communication infrastructure that is not effectively facilitating the vigorous evolution of the engineering design discipline of recent years.

We propose the notion that the confounding state of the engineering design lexicon does matter, and that it constitutes a material hindrance to the continued scholarly development of the engineering design discipline. We believe that a deliberate activity should be undertaken to explicitly address this situation. It is our view that the existence of a clear and concise lexicon - that is accepted by a broad spectrum of the engineering design community - will play a significantly constructive role in the development of the engineering design discipline.

Other views

3. How should the design community address the state of the engineering design lexicon (confounding situations)?

Our view:

We fully recognize that the eventual success of this lexicon examination and development effort singularly depends on the occurrence of two events (i) a good degree of community acceptance of the basic tenets of this discussion, and (ii) meaningful community participation. To proceed along the path of lexicon development discussed herein, several avenues can be conceived for broad community participation. The first and most obvious option is for design researchers to publish their own related views and findings in appropriate journals. Another approach is for interested parties to work with us to the common end, using any number of possible means. We hope that active design researchers will form related collaborations that may result in written works that would reflect the broad related thinking in the community.

While we fully expect various credible views to be expressed in different forums, we hope that this effort will progressively lead to a discernible delineation of some form of community standard or consensus. We now attempt to define the morphology of the segment of the community which should play an active part in this prospective activity. We shall refer to this segment as the lexicon community. We believe this lexicon community should be composed of a diverse, manageably small group of design researchers and practitioners, in consultation with a significantly broader group of individuals directly and indirectly connected to the activity of engineering design. The lexicon community should comprise researchers (1) from different schools of design thinking, (2) from a generationally mixed make-up, (3) from disparate levels of design research experience, and (4) from diverse disciplinary backgrounds (e.g., civil, mechanical, electrical, and environmental engineering). Most importantly, the members of this lexicon community should come to the table with an open mind, ready to advance the overriding objective of consensus. We believe that this last point in critical. In the case of dictionary development efforts in such fields as accounting and economics, the opportunity for controversial roadblocks can be readily managed because of these disciplines' relatively mature development stage. The field of engineering design in unfortunately not so blessed. The opportunities for credible disagreements abound, making it critical that participants understand the paramount necessity for building consensus.

To the extent that the experiences are transferable, the lexicon community should learn from other recent successful efforts (e.g., the economics dictionary development effort [Pearce, 1996]). Several specific activities could pave the way to a strong developmental activity. (1) The first involves active participation of the community in carefully designed and well publicized web sites that would solicit community thinking on specific questions. (2) The organization of a well conceived series of workshops where participation would be limited to those who are strongly inclined to maintain constructive subsequent participation. (3) Develop a program of internationalization of this lexicon development effort. In particular, US researchers could benefit from the areas where Europeans are at a more advanced stage. (4) The publication of articles that explicitly address this problem would serve to both advance our thinking in these regards, and further sharpen the interest of the community. (5) The lexicon community should make the case for support to appropriate government agencies (e.g., NIST, NSF), professional societies (e.g., ASME, ANSI, ISO), and University publishers (MIT Press) that are inclined to be part of the solution. These institutions may choose to get involved in various degrees, ranging from mere publication of results, to technical assistance, to financial sponsorship.

Reference

Pearce, D. W., (Editor), (1996), "The MIT Dictionary of Modern Economics", 4th Ed., The MIT Press, Cambridge MA, USA, ISBN 0-262-16132-X.

Other views

In this part, we present a table design example (Fig. 1) that we use to facilitate the discussion of some commonly used confounding terms. The table is composed of a flat top and of four nominally identical cylindrically shaped legs. Only those designs that conform to this geometrical configuration are considered. The following information (or, should we say data?) is provided, as a list of statements (issues of interest).

Statement-i: (i = 1, ..., 9)

1. The designer has direct control over the numerical values of the table width, a, the table length, b, the table height, h, the table top thickness, t, the table leg diameters, d, the table-top extrusion-depth, s, and the table color, c.
2. The leg position, r, is prescribed to be equal to 0.1 meter.
3. The mass, m, should be minimized.
4. The deflection, d, that would result from the application of a force, F, of 100 kg, should be minimized.
5. The material-used is prescribed.
6. The table color, c, should be dark.
7. The table length, b, must be no more than twice its width, a.
8. The table length, b, should be as close to 1 meter as possible.
9. Other issues of interest to the designer are:
   1. Esthetics (e.g., color, corner radius).
   2. Safety (e.g., stability, strength, corner radius, leg buckling load).
   3. Manufacturability (e.g., ease of machining).

In the remainder of the discussions, we will refer to each of these above items as "statement-i".

All other characteristics of the table are presumed given by the decision maker. In presenting the table characteristics, we have thus far avoided using such terms as design parameter or design variable. (Throughout the discussions, we use the word "term" in both a singular and a collective senses, as allowed by the English language. In other words, we say that "design parameter" is a "term".) As is observed, the design task above is not meant to be comprehensively stated. The table-design presentation only provides sufficient detail to allow for partial discussion of the design lexicon. Furthermore, some readers might credibly argue that the determination of the above issues of interest are themselves a part of the design process. However, this potentially interesting discussion is beyond the scope of this paper.

Figure 1. Table Example.

In this part, we attempt to describe the table design example through common terms used by the design community. In so doing, we expose some of the difficulties that we typically face in design-related discourse. We present the issues in no particular order of importance, nor do we provide solutions to these problems. However, in as much as possible, we generally discuss the design terms in a progressive level of complexity, with the following outlines:

Category I: "Design Parameter"

Confounding Situations
Rhetorical Questions

Category II: "Design Metric"

Confounding Situations
Rhetorical Questions

Category III: "Aggregate Objective Function"

Confounding Situations
Rhetorical Questions

Category IV: Other Interesting Terms

Confounding Situations
Rhetorical Questions

In the following discussions, the table design example is used to expose some of the difficulties that we typically face in design-related discourse.

Category I: "Design Variables"

(design parameter, design variable, parameter, variable, constant, constant Parameter, performance parameter, independent variable, decision parameter, input parameter, process parameter, tuning parameter, exogenous parameter, random parameter, tolerance parameter, noise parameter, fuzzy parameter, uncertainty parameter, state variable).

We start with the terms that are directly related to what we often call a design parameter. We begin by noting that most designers would use statement-1 to designate design parameters. The width, a, the length, b, the height, h, the top thickness, t, the leg diameters, d, the table-top extrusion-depth, s, and color might all be called design parameters, with generally clear implied meanings. Some might call these same quantities design variables, again with generally clear meanings. Others, on the other hand, might refer to these quantities simply as parameters, or variables (short for design parameters and design variables, respectively). At this point, we observe that the terms design parameter, design variable, parameter, and variable are used as synonyms in ways that generally raise no questions, but should.

In the above context, a candidate definition for design parameter is: a characteristic or property of an artifact or process, being designed, over which the designer has direct control; this characteristic or property is used by the designer with the expectation that the variation of its value might alter the value of one or more of its characteristics or properties that are used to evaluate this artifact or process; this quantity may be numerically or textually/linguistically valued. In stating that the constant or quantity may be textually valued, we note that certain quantities used as design parameters might take on values that cannot be placed on the real axis in a self-evident (unique) manner. Color, for example, might be given the value dark or light, or might be quantified in three dimensions (e.g., its red-blue-yellow components); and, in fuzzy terms, thickness might be given the value very thin, thin, average, thick, or very thick.

Upon examination of statement-2, many designers might declare the quantity, r, to be a constant or a parameter, or possibly a constant parameter. We note that the terms parameter and design parameter are often treated as being equivalent. If we adopt the above definition for the term design parameter, then we might ask if the quantity, r, is a design parameter. If the designer does have direct control over the value of r, (in order to fix it to the prescribed value) then we may call it a design parameter. If, on the other hand, the quantity, r, is regarded as being out of the direct control of the designer and is thought of as being equal to the prescribed value that will not change during the design process, then we might say that it is not a design parameter. According to the candidate definition of design parameter stated above, a quantity is a design parameter if it is varied during the design process in an effort to satisfy designer preference. Similarly, from statement-5, "material-used" is not a design parameter, if it is not actively varied during the design process. Some might call it a parameter that is textually/linguistically valued (the name of the material); but few might call it a constant, which is typically numerically valued (should this always be assumed?). It might also be useful to establish a hierarchy of terms. For example, a set of definitions that the design community produces might state that (i) all design parameters can become constants, but not the reverse; and (ii) all constraints are requirements, but not the reverse (see Sec. 3.2). The message here is that, as a community, we currently do not have definitive answers to the above questions. Furthermore, the previous discussion strongly suggests that creating a coherent set of definitions for the numerous common and less-common terms used in engineering design will likely be an intensive undertaking that will require careful thinking.

We now address the term performance parameter, which is entirely distinct in meaning from the term design parameter. In some writings, the term parameter is used as a synonym of the term performance parameter. As a result, when we read that a quantity is a parameter, we might not be sure if the designer has direct control over its value in the design process (i.e., design parameter), or if the designer has indirect control over its value and it will be used to evaluate the design (i.e., performance parameter). In a different vein, the term constant can be a source of confusion. We often treat a constant as a quantity that does not normally change in the design process. At least, we do not expect a constant to be changed in the same fashion that we expect a design parameter to change. We then ask the question: What is the difference between a variable, a constant, a parameter, or a constant parameter? The words constant and variable are often used as antonyms, the words constant and parameter are sometimes used as synonyms, but the words variable and parameter are often used as synonyms, thereby resulting in arbitrariness and confusion. If these three words (variable, constant, and parameter) were defined in a consistent way, one would expect a large degree of transitivity in their collective meanings. In addition, we sometimes distinguish between the words variable and constant with regard to time-dependence and time-independence, respectively. However, when time is not involved in the process, this distinction offers no guidance.

In an effort to minimize confusion, we sometimes used the term dependent or independent to precede the words variable and parameter. In particular, we use the term independent parameter (or independent variable) to indicate that the designer has independent control over the value of this parameter or variable. When used in this way, it is still not clear whether an independent parameter is always used as a design parameter. Actually, we know that the converse is not true. Design parameters are not always independent; very often in optimization, design parameters are not independent from one another (i.e., the presence of constraints). In addition, we know that the mass, m, and the deflection, d, are dependent parameters (they depend on design parameters, see statements 3 and 4). Again, should we assume that dependent parameters are always used to evaluate designs, as are design metrics (discussed later), which might make dependent parameter and design metric synonyms.

The theme of this category revolved around the term design parameter, of which we have provided a candidate definition for the mere purpose of facilitating the current discussion. We have also discussed important issues concerning the terms parameter, variable, constant, constant parameter, design parameter, design variable, and independent parameter. We conclude this part of the discussion by bringing attention to other relevant terms, decision parameter, input parameter, process parameter, tuning parameter, exogenous parameter, random parameter, tolerance parameter, noise parameter, fuzzy parameter, uncertainty parameter, state variable - to name a few (and replace in each of the previous terms the word parameter by the word variable), and by asking the reader to think of what s/he believes the definition of these terms to be; and as importantly, if s/he feels the design community has adequately defined these terms.

Category II: "Design Metric"

(design metric attributes, behavior parameters, behavior variables, costs, criteria, exogenous parameters, figures-of-merit, goals, merit functions, objectives, objective functions, performance functions, performance metrics, performance parameters, performance variables, specifications, utility functions , preference functions, output parameters, output variables, target, expectation, characteristic, property, constraint, requirement, measure)

We now introduce the issues that pertain to the term design metric. From the defined table example, many designers might declare several characteristics of the table to be design metrics, such as the mass, m, and the deflection, d, (see statements 3, and 4). Let's now note three prominent characteristics of these two quantities: (i) they can be functionally expressed in terms of design parameters, (ii) they are used to evaluate the behavior or performance of the design, and (iii) they are measurable.

In light of the above discussion, a candidate definition for design metric is: a characteristic or property of an artifact or process, being designed, that is used to evaluate its performance; such characteristics are measurable, and are dependent on one or more design parameters. Note that we exclude the possibility that a design metric would not depend on a design parameter. In such a situation, the designer would have no way of controlling the value of the design metric, and the design process would be ill-defined. At a minimum, the design metric should itself be a design parameter to allow for the requisite control of the design metric by the designer.

According to the above definition, mass, m, deflection, d, and color, c, would be design metrics. Note however that color, c, could not be uniquely ordered because it is measured as a three-dimensional quantity (i.e., its Red-Blue-Green components), which needs human decision before it can be mapped to a one-dimensional space, which is needed for unique ordering. For all design metrics, we simply require that we be provided a measure of their values, while no human preference is yet expressed. According to statements 2 through 9, leg position, mass, deflection, material used, color, length, width, esthetics, safety, and manufacturability would all be design metrics. Accordingly, a means to measure color, esthetics, safety, and manufacturability would have to be provided in order for the designer to have the ability to evaluate their impact on the design.

We now proceed to pose some important questions related to the term design metric. Is it appropriate to use an array of other terms to describe the quantities that we have declared to be design metric in the previous paragraph? In particular, may we also call these quantities attributes, behavior parameters, behavior variables, costs, criteria, exogenous parameters, figures-of-merit, goals, merit functions, objectives, objective functions, performance functions, performance metrics, performance parameters, performance variables, specifications, utility functions (von Neumann, 1953), preference functions, output parameters, output variables, target, expectation, etc.? It is our view that the answer is no. To facilitate intelligible discourse, for example, we propose the notion that it is indeed important for the engineering design community to know (or decide what is) the difference between criterion, goal, target and objective; between requirement, specification, and constraint; between preference function and utility function; and between design metric and performance parameter. In some cases, the difference might be negligible or immaterial, while in others the difference will lead to miscommunications. The important point here is that, as a community, we have no widely accepted and reliable point of reference.

The lexicon we use should make it possible to clearly differentiate between (i) the mass, m, and (ii) statement-3 [The mass, m, should be minimized]. The former is void of all human preference, and is simply used to evaluate performance (without yet saying how). The latter is not only saying that mass will be used to evaluate performance, but is also saying how (namely that a lower value of mass will be preferred over a higher value thereof.) The lexicon should make an entirely clear distinction between the former and the latter. Our common use of the many terms above (previous paragraph) fails us in that regard. As a possibility, we might call the former a design metric, and the latter an objective; but not the converse. As the state of the design lexicon stands today, when we read the word objective, we cannot be quite sure whether the writer is referring to the former (mass, itself) or to the latter (minimize mass, as a subjective statement of preference).

Let's now examine the differences between such terms as constraint, specification, requirement, criterion, goal, and objective by considering the table example statements. To begin with, these authors express the view that the above five terms should refer to statements of preference regarding characteristics or properties of the design or process, and not to these characteristics or properties themselves (e.g., to statement-3, and rather than to mass, m). Many might refer to statements-2, 5, and 7 as a constraints or specifications. The typical understanding is that, if constraints or specifications are not met, then the design is not acceptable/feasible. On the other hand, statements-3, 4, and 6 might be declared to be objectives, or goals. These statements merely define events that should happen as much as possible, with the understanding that these events will in general not be fully satisfied. Partial satisfaction of these events still results in an acceptable/feasible design.

In the literature, the words objective, criteria, and goal are typically used as synonyms. English dictionary definitions, however, would suggest that these words are not always synonymous. The words constraint and criterion are also sometimes used as synonyms. (In the hierarchy of these words, we might say that a constraint is always a criterion, but that the converse is not necessarily true (?) [Please note the question mark!]) The important point here is that there is no referential authoritative source on which we can rely, noting that the English dictionary is glaringly inadequate with regard to the design lexicon, and that general design dictionaries have yet to be developed by the community. In the same vein, regarding the word criterion, the plural form, criteria, is often used when the singular form, criterion, should be used. The American Heritage Dictionary [8] tells us under the definition of criterion - usage - "Criteria is a plural form only. It should not be substituted for the singular criterion."

In a similar vein, the word attribute has not quite found its appropriate place in the engineering design lexicon. From its English dictionary meaning, it seems that every characteristic or property of an artifact or process is one of its attributes. As such, we could call every design parameter and every design metric an attribute of the artifact or process. Furthermore, it seems self-evident that every design must be multi-attribute. Often, the term multi-attribute is used where other designers use the terms multi-objective and multi-criteria. While every design parameter and design metric is an attribute of the design, not every attribute must be a design parameter or a design metric. For example, the smoothness of the table surface (Fig. 1) is an attribute of the design, but is not a design parameter (by choice), nor is it a design metric (again by choice).

We also point to the fact that the term multi-attribute refers to the attributes of the design (e.g., mass, color), while the terms multi-objective points to the objectives that are associated with these attributes. While (as stated above) every practical design is multi-attribute, not every design need be multi-objective. One could design a product that would have the sole objective of making money for the designer legally. The same product design might also become multi-objective by proposing that as many employees be hired as possible (possibly for altruistic reasons). In light of the above discussion, it does not seem appropriate to use the terms multi-attribute, multi-objective, and multi-criteria interchangeably. Use of the term multi-attribute utility function, on the other hand, seems to entail no ambiguity (Thurston et. al., 1991). This term refers to the fact that several attributes (not objectives) of the design are used to create a utility function (which expresses the designer's objectives).

Category III: "Aggregate Objective Function"

(aggregate objective function, costs, cost functions, value, value functions , utilities, aggregate preference function , multi-attribute utility function, multi-attribute, multi-objective, multi-criteria, multi-design-metric, multi-metric, subject to.)

This part presents a discussion that leads to some questions regarding the use of the term aggregate objective function. Let's begin by considering the meaning of certain common terms in the context of optimization and utility function development (von Neumann, 1953; Hazelrigg, 1996). (The application of utility to engineering design is presented in (Hazelrigg, 1996), where the role of decision-making in engineering design is addressed.) If we form functions that will be minimized using an optimization model to account for statements 3, 4, and 8, such functions might take the form:

	(1)
	(2)
	(3)

where a_m, a_d, and a_b are weighting factors.
The actual function to be minimized might take the form

(4)

We now pose related questions. Should the functions f_m, f_d, and f_b be called objectives, objective functions, costs, goals, cost functions, criteria, design metrics, behavior parameters, performance parameters, performance functions, performance metrics, figures-of-merit, merit functions, preference functions, value, value functions, goals, utilities, or utility functions? One could say that some of these terms are more appropriate than some others in the subject context. However, if one accepts the definition of the term design metric, previously provided, then using the term design metric to describe the subject functions would be inappropriate. Furthermore, the unfortunate reality is that most of the above terms are often used interchangeably, in ways that are not particularly clear to most (including these authors). The rationale for differentiating between these terms is generally unclear, if at all existent. And as the state of the engineering design lexicon stands today, no definitive clarifying reference exists.

Similarly, regarding the function J above, the following question can be posed. Should we refer to J as an objective, an objective function, an aggregate objective function, a preference function, an aggregate preference function, a utility function, a multi-attribute utility function, a design metric (!), a merit function, a cost, a cost function, a value, a value function, a measure, or a metric? We feel that it should be possible to succinctly distinguish between the function that pertains to one attribute (e.g., f_m, for mass, m) and the function that expresses the multi-objective (aggregate) preference, J. Unfortunately, interchangeable use of the above terms does not allow for this desirable distinction. For example, when we simply say objective function, it is not clear which applies (does it apply to a single objective, or to several?) Similarly, when we read the word objective, it might refer to mass, m, to f_m, or to J. In many cases this lack of linguistic clarity might be immaterial, but in other important cases it might.

We conclude the discussion of this part with some comments regarding the terms multi-objective, multi-criteria, and multi-attribute. It seems that, since we say multi-objective (singular form of objective), we should also say multi-criterion (singular form of criterion). Multi, when used as a prefix, does not render the original word plural. This is why we say multi-objective, and not multi-objectives. Should these words even be spelled with or without a hyphen? (Both forms are used). Furthermore, if the words multi-objective, multi-criteria, and multi-attribute are declared synonyms, then by implication, the words objective, criterion, and attribute would also be synonyms. However, as discussed above, the implied equivalence of these terms should be regarded with dubiosity.

Along the same line of thought, several researchers have decided to use exclusively the term multi-attribute. We note, however, that it is the number of design metrics (more than one) that one generally wishes to bring attention to, since every design is multi-attribute. This observation would lead to the term multi-design-metric, or multi-metric. However, since most practical designs are performed using more than one design metric, in general there seems to be little reason to be reminded of it. Also, the term multi-objective implies that the word objective (when invoked alone) is used in the context of one design metric, creating the need of say multi (in the case of more than one objective). Yet, we routinely use the term objective function to mean multi-metric (aggregate) preference function. This is an inconsistent use of the term objective. This is one of many reasons why it would promote good communication to use the term aggregate as a prefix to objective function or preference function (Messac, 1996a, b) when we invoke the multi-metric sense.

Category IV: Other Interesting Terms

(features, wish, hard goal , soft goal, data, information, knowledge, design, uncertainty, risk, imprecision, fuzzy, stochastic uncertainty, possibilistic uncertainty.)

This part of the discussion is intended to show that the deficiency of the current design lexicon is significantly broader in scope than the limited class of terms of the previous categories would suggest. At a different level of discourse that does not involve the table example, this part of the discussion goes somewhat beyond the most commonly used terms, as were those discussed earlier. We discuss the use of several terms that are often employed with dubious implications. As is often the case in engineering design discourse, use of the English dictionary again offers little assistance in uncovering appropriate definitions for this broader class of terms. In particular, we discuss such terms as data, information, knowledge, risk, uncertainty, probability, imprecision, fuzzy, and robustness. Importantly, we also note that a comprehensive analysis of the state of the design lexicon would devote significantly more attention to non-mechanical design than does this publication. The focus, herein, on mechanical design is not intended to suggest that the lexicon problem is more significant in the mechanical design arena. We made this choice merely for the sake of practical (scope) considerations.

We begin by considering the terms data, information, knowledge, and design. In the development of taxonomies for design, or in the activity of general research in engineering design, it might become necessary to clarify what the above terms really mean. Faced with this need, the researcher would, currently, have to either define his/her own definitions, or possibly adopt one of several existing definitions. Again, we note that no authoritative clarifying source exists. Adopting definitions from such fields as artificial intelligence, mathematics, operations research, computer science, or economics may not always be wise. We also note that, again in this instance, the English dictionary is unfortunately not helpful, as it defines information in terms of knowledge, and knowledge in terms of information (Mifflin, 1985).

It is interesting to note that the definitions of the words data, information, and knowledge, that exist in the literature do not clearly (mutually consistently) establish their hierarchy. Which of these three words is at a higher level? We present in the sequel a sample of definitions used in the literature, which suggests material difference of views among design researchers. Knowledge: An agreed upon set of facts. Knowledge can be defined as an understanding of the laws of nature and the ability to apply those laws to predict the behavior of physical systems (Hazelrigg, 1996). Knowledge: The sum and range of what has been perceived, discovered and learned about a product. (Mistree et al., 1991). Information: The degree of freedom that exists in a given situation to choose among signal symbols, messages, or patterns to be transmitted" (Miller, 1987). (This definition is a formalism of the notion that more information leads to a reduction in uncertainty). Information: Information relates to a specific decision. Quantitatively, it can be measured as the probability that the preferred choice in a decision will lead to the most desired outcome. (Hazelrigg, 1996). Information: Information is the measure of knowledge required to satisfy a given FR (Functional Requirement) at a given level of the FR hierarchy. The notion of information is very closely related to the probability of achieving the FR (Suh, 1991). Data, Information, and Knowledge: Based on dictionary definitions, the perception of knowledge and information can be stated as follows. Knowledge is the most complex form (among data, information, and knowledge). Knowledge is derived by human beings from information. Information is required before we obtain knowledge. Data is the simplest form and is characterized by a sense of hardness. Data and facts are often considered to be equal. Data is information, but not all information is data. Based on the above perception, designing is stated as "a process of converting information that characterizes the need and requirements for a project into knowledge about a product." (Mistree et al., 1991) The important message from the above quotations is that the above definitions are not in mutual agreement.

In terms of the relationships between knowledge, information, and design, Hazelrigg's (1996) definitions indicate that knowledge is associated with the inputs of a design process, while information is related to the design outcome (design decision). On the other hand, Mistree et. al (1991) define a design equation that takes the information (that characterizes the need) as inputs and generate the knowledge (about a product) as outputs. Suh (1991) simply considers information as the measure of knowledge, while his design equation is associated with FR's and Design parameters. Suh defines design as: The creation of synthesized solutions in the form of products, processes or systems that satisfy perceived needs through the mapping between the FRs (Functional Requirements) and the DPs (Design Parameters) of the physical domain. Further, in terms of the human involvement in the design activity, we may also ask: since designers make decisions, is the designer always (or, sometimes) understood to be the decision maker. Additional work by the community (not by individual researchers in isolation) in the definitions of these words is needed.

Robust Design is another term that is used with diverse interpretations. The English dictionary defines robust as strongly formed or constructed. Design for Robustness in engineering practice often refers to the adoption of Taguchi's (Taguchi, 1993) philosophy of quality, which involves minimizing variability in performance due to environmental and manufacturing conditions. In light of the previous comments, how do we differentiate between the terms robust design, quality-based design, design for tolerance, and design for variation, etc.? In a similar vein, in control design, high robustness and high performance are typically understood as opposite objectives. That is, a high performing design is not robust, and a very robust design is not high performing. This is because control engineers do not generally accept the notion that a robust design may be of high performance, since this design might be performing according to our wishes. This difference in meaning across disciplines can become a serious source of miscommunication. Again, the existence of a design dictionary would, in this case, assist the control engineer who intends to interact with design engineers or researchers.

We now turn our attention to such terms as uncertainty, risk, imprecision, and fuzzy. For the defined table example, a precise (crisp) number (0.1 meter) is used to describe the leg position, r, in statement-2. If we change the statement to "the leg position, r, is about 0.1 meter", we now introduce some vagueness into our problem description. Another example of vague description is associated with statement-6. When we say the table color, c, should be dark, one may inquire about the meaning and implication of the word dark. No one would argue that black is a dark color; however, would we consider green or blue as dark? In terms of the lexicon used for these vague quantities, some might call both parameters (r and c) uncertainty parameters, while others might refer to the leg position r as imprecise parameter and name the desired color of the table, c, a fuzzy numbers. It has been recognized that there are different classes of uncertainties in a design process, delineated along the amount of available information and along some special characteristics of the uncertainties. However, a universally accepted terminology does not exists. We hereby examine the terms uncertainty, risk, imprecision and fuzzy , which are often used for uncertainty analysis in engineering design, and we expose pertaining confounding situations regarding of the usage of these terms in the current design literature.

We begin with the dictionary definitions of these terms (Mifflin, 1985):

Uncertainty - the quality or state of being uncertain.

Risk - possibility of loss or injury.

Imprecision - state of being vague, inexact, not precise.

Fuzzy - of the nature of or resembling fuzz; indistinct; blurred.

Risk: A context in which an event occurs with some PROBABILITY or where the size of the event has a PROBABILITY DISTRIBUTION. Thus, the return on an investment may be risky in that it has a 1 in 10 (0.1 probability) chance of being a loss , a 5 in 10 chance of being a particular size, and a 4 in 10 chance of being larger still.

Uncertainty: A situation in which the likelihood of an event occurring is not known at all. That is, no PROBABILITY DISTRIBUTION can be attached to the outcomes. If the event in question is an investment in a project, uncertain returns would mean that the conceivable returns will be known but their probability of occurrence will not be known.

We note similar definitions provided by Siddall (1972), who defines risk as "each action has several possible outcomes for which the probabilities are known", and uncertainty as "each action has several possible outcomes for which the probabilities are unknown". While the above two quotes relate uncertainty to the situation in which the probabilities are unknown, we also find other definitions that instead relate uncertainty to probability analysis. For example in Hazelrigg (1996), uncertainty is defined as

Uncertainty. Any time that we conduct an experiment for which we cannot predict the outcome, that is, when the sample space contains more than one element with nonzero probability, we say that there is uncertainty.

We note that the above definition is consistent with that used in conventional decision analysis (Tribus, 1969). An important question at this point is: Which is associated with probability? Is it risk, or is it uncertainty?

While uncertainty or risk is generally associated with probability in the classical normative decision theory, recent years have seen the applications of descriptive decision theory (Zimmermann, 1989) that introduces the concept of imprecision and fuzzy number (Antonsson and Otto, 1995; Thurston and Carnahan, 1992; Wood and Antonsson, 1989) into uncertainty analysis. As pointed out by Zimmermann, in descriptive decision theory, the precision of problem description is no longer assumed; but ambiguity and vagueness is very often modeled only verbally (linguistically). The early publications in fuzzy set theory by Zadeh generalize the classical notion of a set, and propose to accommodate this type of uncertainty to the non-stochastic regime. Under Zadeh's theory, imprecision is used in the sense of vagueness rather than lack of knowledge about the value of a parameter, as is done in tolerance analysis. We find a review of the literature of imprecision in engineering design (Antonsson and Otto, 1995) where several definitions are provided, including:

Uncertainty, which usually represents uncontrolled stochastic variations with the mathematics of probability, is distinct from imprecision.

Imprecision. In the context of engineering design, the term imprecision is used to mean uncertainty in choosing among alternatives. An imprecise variable in preliminary design is a variable that may potentially assume any value within a possible range (a concept related to interval analysis) because the designer does not know, a priori, the final value that will emerge from the design process.

Wood and Antonsson, 1989 relate imprecision to fuzzy numbers by defining imprecision as: the range (support) or spread of values about the peak [preference of one (1)] of a parameter's fuzzy set. A comparison between fuzzy sets and probability methods is made by Wood et al. 1992. They discuss different types of uncertainties and suggest the terms stochastic uncertainty and possibilistic uncertainty to differentiate those uncertainties that could be modeled using stochastic representations from those that could be modeled by imprecision. Though the use of these terms is still worthy of debate, the important point here is that these authors recognized the need to clarify their specific use of terms. While we may keep the word uncertainty as a general term for any vague or unclear representation, it is necessary to reach an agreement on the terms we use for uncertainties with different characteristics, including those that could be modeled neither stochastically nor using fuzzy numbers.

References

Antonsson, E. K. and Otto, K. N., (1995), "Imprecision in Engineering Design," ASME Journal of Mechanical Engineering, Vol. 117, pp.25-32.

CIRP (International Institution for Production Engineering Research [English translation]), CIRP Dictionary, 9 volumes in 3 languages (English, French, and German), in press by Girardet, Essen, Germany.

Hazelrigg, G. A., (96), "System Engineering: An Approach to Information-Based Design", Prentice Hall.

Houghton Mifflin (1985), "The American Heritage Dictionary", Second College Edition, ISBN 0-395-32943-2, One Beacon Street, Boston, MA 02108. Messac, A., (1996a), "Physical Programming: Effective Optimization for Computational Design," AIAA Journal, Vol. 34, No. 1, Jan. 1996, pp. 149-158.

Messac, A., (1996b) "From the Dubious Art of Constructing Objective Functions to the Application of Physical Programming", 6th AIAA/NASA/ISSMO Symposium on Multidisciplinary Analysis and Optimization, Paper No. AIAA-96-4123, April 7-9, 1996.

Miller, J. G., "The Living Systems", McGraw-Hill Book Company, NY, 1987.

Mistree, F., Smith, W. F., Kamal, S. Z. and Bras, B. A., "Designing Decisions: Axioms, Models and Marine Applications," Fourth International Marine Systems Designing Conference, Kobe, Japan, pp. 1-24, 1991.

Pearce, D. W., (Editor), (1996), "The MIT Dictionary of Modern Economics", 4th Ed., The MIT Press, Cambridge MA, USA, ISBN 0-262-16132-X.

Siddall, J., (1972), "Analytical Decision-Making in Engineering Design", Englewood Cliffs, N. J., Prentice Hall. Suh, N. P., (1990), "Principles of Design", Oxford University Press, Oxford, U. K.

Taguchi, G. "Taguchi on Robust Technology Development: Bringing Quality Engineering Upstream, " ASME Press, New York, NY, 1993. Thurston, DL., (1991) "A Formal Method for Subjective Design Evaluation with Multiple Attributes", Research in Engineering Design, 3:105-122.

Thurston, DL., and Carnahan, J.V., (1992), "Fuzzy Ratings and Utility Analysis in Preliminary Design Evaluation of Multiple Attributes", Transactions of the ASME Journal of Mechanical Design, Vol. 114, No. December, pp. 648-658.

Tribus, M., (1969), "Rational Descriptions, Decisions and Designs", Pergamon Press, Elmsford, N. Y.

von Neumann, J. and O. Morgenstern, (1953), "The Theory of Games and Economic Behavior, Princeton University Press, Princeton, NJ, Third Edition. Wood, K.L. and Antonsson, E.K., 1989, "Computations with Imprecise Parameters in Engineering Design: Background and Theory", Transactions of the ASME, Vol. 111, pp.616-624.

Wood, L. K., Otto, N. K., Antonsson, E. K., (1992), "Engineering Design Calculations with Fuzzy Parameters", MIT, Mechanical Engineering Department.

Zadeh, L. A., "Fuzzy Sets as a Basis for the Theory of Possibility." Fuzzy Sets and Systems, 1:3-28.

Zimmermann, H. J, 1989, "Fuzzy Sets, Decision Making, and Expert Systems", Kluwer Academic Publishers, Boston.Dorderchet/Lancaster.

Under "Design Parameter":

1. What is the difference between design variable, design parameter, parameter, or variable?
2. What is the difference between a variable, a constant, a parameter, or a constant parameter?
3. Could the term parameter be used as a synonym of performance parameter?
4. Is an independent parameter always a design parameter?
5. Should we assume that dependent parameters are always used to evaluate designs, as are design metrics, which might make dependent parameter and design metric synonyms?

Under "Design Metric":

1. Is it appropriate to use an array of other terms to describe the quantities that we have declared to be design metric ? In particular, may we also call these quantities attributes, behavior parameters, behavior variables, costs, criteria, exogenous parameters, figures-of-merit, goals, merit functions, objectives, objective functions, performance functions, performance metrics, performance parameters, performance variables, specifications, utility functions , preference functions, output parameters, output variables, target, expectation, etc.?
2. What is the difference between criterion, goal, target and objective; between requirement, specification, and constraint; between preference function and utility function; and between design metric and performance parameter?
3. What is the difference between the terms multi-attribute, multi-objective, and multi-criteria? Are they synonyms? Should these words even be spelled with or without a hyphen?
4. What is the appropriate place of the word attribute in the engineering design lexicon?

Under Aggregate Objective Function:

1. (In Equation 4) Should the functions fm, fd, and fb be called objectives, objective functions, costs, goals, cost functions, criteria, design metrics, behavior parameters, performance parameters, performance functions, performance metrics, figures-of-merit, merit functions, preference functions, value, value functions, goals, utilities, or utility functions? Should we use these terms interchangeably?
2. (In Equation 4) Should we refer to J as an objective, an objective function, an aggregate objective function, a preference function, an aggregate preference function, a utility function, a multi-attribute utility function, a design metric (!), a merit function, a cost, a cost function, a value, a value function, a measure, or a metric? How should we distinguish between the function that pertains to one attribute and the function that expresses the multi-objective (aggregate) preference?
3. To be consistent with the term multi-objective, should we use the word multi-criterion (singular form of criterion) instead of multi-criteria?

Under Other Interesting Terms:

1. What should be the definition for requirement? Can a requirement be a constraint? Can a requirement be a goal? Is a requirement a preference? Or, is a preference a requirement? What is the difference between a specification and a requirement, if any?
2. Would it be helpful to classify some design terms with regards to the objective state of the design and the related subjective preference of the designer?
3. Would it be helpful to classify some design terms with respect to the hardness and softness of their implications?
4. What is the difference between the terms data, information, knowledge, and design.?
5. What is the difference between the terms risk and uncertainty? Which is associated with probability? Is it risk, or is it uncertainty?
6. What is the difference between the terms uncertainty , imprecision, and fuzzy? What terms should we use for uncertainties with different characteristics, including those that could be modeled neither stochastically nor using fuzzy numbers?
7. Since designers make decisions, is the designer always (sometimes) understood to be the decision maker.

Our views

Other views

Subjective vs. Objective Terms:

In an attempt to define more clearly the many terms that describe the objective state of the design and the related subjective preference of the designer (Thurston, 1991), we might find it helpful to classify some design terms with regards to this objectivism and subjectivism. In particular, we all agree that the mass, m, of the table is an objective measure of the amount of mass comprising the table, and that the length, b, of the table - too - is an objective measure of one of the table's characteristics. The numerical values associated with the table's mass and length do not reflect the designer's subjective preference. These quantities might be referred to as features, characteristics, or attributes of the table. And if we accept previously provided definitions, the mass could also be referred to as a design metric (since it is used to evaluate the table's performance), and the length could be referred to as a design parameter (since the designer has direct control of its value). Since these quantities provide no information regarding the designer's preference, we could regard these as objective terms. However, examining statements 3 and 8, in conjunction with Eq. (1) and (3), respectively, we might find it appropriate to refer to the statements as objectives or goals, and to Eqs. (1) and (3) as the associated objective functions. These terms (objectives and goals) could be referred to as subjective terms, as they do make a statement regarding the designer's (subjective) preference. The quantities functions fm, and fb could be called the objective functions (and not simply the objectives), as they are the mathematical representations of the objectives.

According to the above classification, under the objective terms category we would find such terms as design metric, design parameter, and attribute (if we exclude preference information from their definitions), and under the subjective terms category, we would find such terms as preference function, utility function, goal, specification, constraint, cost function, criterion, figure-of-merit, merit function, objective function, performance function, and requirement. We note that the morphology of the latter class of terms incorporates at least some degree of the designer's preference. In addition, if clear definitions exist for a sufficient number of terms in each category, these authors find no need for such a long list of terms, whose mutual differences in meanings would become dubious at best.

Soft vs. Hard Statements

Another means to categorize these many terms is with respect to the hardness and softness of their implications. In particular, such terms as constraint, and subject to are entirely clear/sharp in their implications. That is, unless the statement of the constraint, or the statement following subject to is fully met, then the design is not acceptable/feasible. At the other end of the spectrum, such terms as wish, preference and goal are less categorical (soft) in their implications. These terms merely express statements that the designer would like to see satisfied to the maximum extent possible, while no extent of satisfaction of these statements is a prerequisite to the acceptability of the design. However, when we employ such terms as hard goal, we essentially destroy the meaning of the word goal. It seems to these authors that a hard goal is nothing but a constraint, but one that is dubiously stated. The users of the term hard goal then find the need to inject another term, soft goal, when simply goal might have sufficed.

Many terms, however, do not naturally lend themselves to this classification. For example, a succinct definition for the term requirement in the context of engineering design is not provided by the English dictionary. Can a requirement be a constraint? We might say yes. Can a requirement be a goal? We might again say yes. That is, we might require that mass be minimized (a soft term). The same line of questioning might apply to the term specification. It seems to these authors that this abundance of terms, that promotes the likelihood of diverging interpretation, significantly contributes to muddying the waters. We might ask: Is a requirement a preference? Or, is a preference a requirement? What is the difference between a specification and a requirement, if any? The questions are plentiful, while authoritative clarifying sources are glaringly lacking.

The support of this work by NSF DMII, through Grant number 9622652 (for Messac) and 9703613 (for Chen) is gratefully acknowledged. We also hereby express our thanks to Drs. Janet Allen, George Fadel, Sundar Krishnamurty, Kemper Lewis, David Rosen, and Deborah Thurston for their respective contributions to this work, which ranged from substantive and engaging discussions to written contributions.

References

Thurston, DL., (1991) "A Formal Method for Subjective Design Evaluation with Multiple Attributes", Research in Engineering Design, 3:105-122.