ABSTRACT
All engineering design processes can be looked at as a series of decisions made by the stakeholders involved. For example, consider mechanical engineers looking to improve an existing automatic transmission. Mechanical engineers can decide to use a new material for gears, use a different manufacturing process, update control software, or even pursue a radically new design-in hopes of making it more reliable, cheaper, or both. They may also choose to do nothing to the existing design and move to another product altogether. These decisions need to be evaluated based on their impact on the attributes with which the DM is concerned. In a for-profit firm, the overarching attribute is usually profit, but surrogates of reliability are also sometimes used. It is clear that for sufficiently complicated products, the number of decisions that can be made are enormous, possibly infinite. Consequently, it is not always possible for designers to actively make each decision themselves. In helping the DM make decisions, we need a formal understanding of his or her preferences. The benefit of a formal understanding of a decision maker’s preferences is the implementation of these preferences to make decisions by the decision maker himself or herself or by a facilitator.* One can also embed his or her preferences in a mathematical function so that the process of decision making can even be automated on the computer. The decisions are still being made, but by a different, possibly virtual, entity that (hopefully) mimics the actions of the decision maker. Since an error in modeling the preferences of the decision maker can lead to a grossly incorrect decision, a lot of emphasis is placed in decision analysis on finding the functional forms that truly model decision maker preferences. In this chapter we will study in detail how all this can be accomplished and about what pitfalls we should be careful.
