• Specifications are a brief list of functional objectives.
• These are often called Functional Requirements (FRs)
• We can look at the design process as mapping Functional Requirements (FRs) to Design Parameters (DPs). We can also look at mapping from the design parameters to the Process Parameters (PPs) as the task of process engineering.
• Examples of DPs could be # of engine cylinders, or a final dimension.
• Good rules of thumb for specifications are,
- try to talk in general terms that focus on the function instead of solution (e.g., “the automobile should be able to move on ground with a 12 inch variation in height” instead of “the axle clearance should be 12 inches”).
- break requirements into separate parts.
- keep the requirements as simple as possible.
- avoid vague language, use numbers and technical goals.
- don’t specify more FRs than needed.
• In design we should try to meet, not exceed specifications. The Kano model helps to illustrate this [Ullman],
• As an example consider the progress in the computer industry. Specifically Moore’s Law - about every 2 years the number of transistors on a chip will double (implies memory doubling, speed doubling, etc) this has proven to be remarkably accurate.
• If we construct a graph we can show how the consumer response shifts as a function of time
• We can combine a number of new and old features in products as FRs. These will affect both customer expectations and product cost. A graph shows what marketing departments research in terms of customer needs.
• For new products we can try to determine their value with market surveys and by examining competitors products.