21
AC 2007-1102: ESTABLISHING FUNCTIONAL REQUIREMENTS AND TARGET SPECIFICATIONS: A KEY COMPONENT OF PRODUCT DEVELOPMENT PROJECTS Karim Muci-Küchler, South Dakota School of Mines and Technology Karim Muci-Küchler is an Associate Professor of Mechanical Engineering at South Dakota School of Mines and Technology. Before joining SDSM&T, he was an Associate Professor of Mechanical Engineering at the University of Detroit Mercy. He received his Ph.D. in Engineering Mechanics from Iowa State University in 1992. His main interest areas include Computational Mechanics, Solid Mechanics, and Product Design and Development. He has taught several different courses at the undergraduate and graduate level, has over 25 technical publications, is co-author of one book, and has done consulting for industry in Mexico and the US. He can be reached at [email protected]. Jonathan Weaver, University of Detroit Mercy Jonathan Weaver is an Associate professor of Mechanical Engineering at the University of Detroit Mercy (UDM). He received his BSME from Virginia Tech in 1986, his MSME and PhD in ME from RPI in 1990 and 1993, respectively. He has several years of industry experience and regularly consults with an automaker on projects related to CAD, DOE, and product development. He can be reached at [email protected]. Daniel Dolan, South Dakota School of Mines and Technology Dan Dolan joined the faculty of the SDSM&T in 1981 after completing a PhD in Mechanical Engineering from the University of Minnesota in 1977 and a Humboldt Fellowship in Germany in 1981. He has been involved in teaching for almost 25 years. He has taught courses in thermodynamics, dynamics, controls, manufacturing, IC engines and vehicle dynamics. He has worked in industry on engine development and manufacturing control system development. He has coauthored over 25 technical papers and is co-inventor on six patents. © American Society for Engineering Education, 2007 Page 12.689.1

Establishing Functional Requirements And Target

  • Upload
    others

  • View
    6

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Establishing Functional Requirements And Target

AC 2007-1102: ESTABLISHING FUNCTIONAL REQUIREMENTS AND TARGETSPECIFICATIONS: A KEY COMPONENT OF PRODUCT DEVELOPMENTPROJECTS

Karim Muci-Küchler, South Dakota School of Mines and TechnologyKarim Muci-Küchler is an Associate Professor of Mechanical Engineering at South DakotaSchool of Mines and Technology. Before joining SDSM&T, he was an Associate Professor ofMechanical Engineering at the University of Detroit Mercy. He received his Ph.D. in EngineeringMechanics from Iowa State University in 1992. His main interest areas include ComputationalMechanics, Solid Mechanics, and Product Design and Development. He has taught severaldifferent courses at the undergraduate and graduate level, has over 25 technical publications, isco-author of one book, and has done consulting for industry in Mexico and the US. He can bereached at [email protected].

Jonathan Weaver, University of Detroit MercyJonathan Weaver is an Associate professor of Mechanical Engineering at the University ofDetroit Mercy (UDM). He received his BSME from Virginia Tech in 1986, his MSME and PhDin ME from RPI in 1990 and 1993, respectively. He has several years of industry experience andregularly consults with an automaker on projects related to CAD, DOE, and productdevelopment. He can be reached at [email protected].

Daniel Dolan, South Dakota School of Mines and TechnologyDan Dolan joined the faculty of the SDSM&T in 1981 after completing a PhD in MechanicalEngineering from the University of Minnesota in 1977 and a Humboldt Fellowship in Germany in1981. He has been involved in teaching for almost 25 years. He has taught courses inthermodynamics, dynamics, controls, manufacturing, IC engines and vehicle dynamics. He hasworked in industry on engine development and manufacturing control system development. Hehas coauthored over 25 technical papers and is co-inventor on six patents.

© American Society for Engineering Education, 2007

Page 12.689.1

Page 2: Establishing Functional Requirements And Target

Establishing Functional Requirements and Target Specifications:

A Key Component of Product Development Projects Abstract Two very important steps in the product development process are identifying customer needs and establishing functional requirements and target specifications for the product. Unfortunately, it is quite common in academic design projects to begin a project by giving to the students most of the functional requirements and target specifications for the product that they have to develop. Under that framework, the students are not actively involved in two key aspects of “real world” product development, namely identifying the needs of the customers and translating those needs into functional requirements and target specifications. If the customer requirements are not fully understood and adequately translated into required functions and quantifiable metrics and their corresponding target values, it is very unlikely that a successful product design will result from the development effort. Setting target specifications is a challenging process and even experienced engineers sometimes have difficulties selecting metrics that adequately capture how well a particular customer need is met. Consequently, it is very important that students participating in design projects in product development courses learn structured methodologies to perform those tasks. To explore the benefits of such an approach, a formal process to establish functional requirements and target specifications for a product was introduced into a sophomore product development course, a senior capstone design course sequence, and a graduate level course in product development. In all cases, the students started the task of setting functional requirements and target specifications for the product after following a structured methodology to identify the customer needs. In this paper, the process followed, an assessment of the results obtained and suggestions for future improvement are discussed presenting examples taken from different projects carried out by students.

Introduction

At the present time many undergraduate engineering programs in the US include one or more design courses aimed at better preparing students for the “real world” practice of the profession. In addition to the traditional Senior Design Project or Capstone-type courses that students must take during their last year, now freshman, sophomore and/or junior level design courses are also being incorporated into the curricula (see for example Starkey et al.1, Newman and Amir2, Wood et al.3, and Muci-Küchler et al.4). It has been recognized that, in general, engineering design involves more than applying sound technical knowledge to solve an “open-ended problem.” It typically encompasses all the tasks that must be performed to develop technical products and takes place in the framework of working in teams (most often multidisciplinary) following a structured approach. Although many faculty members teaching design courses have adopted a project-based learning strategy that fits this product development scenario (see for example Dutson et al.5, Catalano et al.6, and Muci-Küchler and Weaver7), in most cases not enough emphasis has been given to the activities of identifying the needs of the customers and other

Page 12.689.2

Page 3: Establishing Functional Requirements And Target

relevant stakeholders and of establishing the functional requirements and target specifications for the product. Most engineering students think that when they will be designing a product in industry they will be given as a starting point a detailed list of specifications that the product must meet. Although in some instances that could be the case, typically the design engineer has to be involved in the process of setting those specifications. Although marketing personnel from the company lead the effort of gathering information from customers and other stakeholders, they usually lack the technical expertise required to translate many of the needs identified into useful metrics and their corresponding target values. Since the need statements are commonly expressed in the “language of the customer,” it is not possible to translate them into technical specifications for the product without having a clear understanding of what those statements really mean. The latter can only be achieved through active participation in the process of identifying the needs and having a considerable amount of interaction with potential customers and other relevant stakeholders. Once the target specifications for the product have been set, they will drive the remaining of the product development effort. Consequently, if they don’t properly capture what the customers and other relevant stakeholders are expecting from the product, it is very unlikely that the final design obtained at the end of the development process will be a success. In a sense, it is like solving a problem using wrong input data: the final answer will be incorrect. In a very competitive marketplace and a global economy in which consumers have ever increasing expectations of the products that they buy, companies need engineers that can participate in all the activities required to design a successful product. That includes the tasks of identifying customer needs and setting target specifications for the product. Project-based design courses provide an ideal setting to teach students a formal and structured process to identify customer needs and to translate those needs into functional requirements and target specifications for the product. The authors have followed that approach in a sophomore product development course, a senior capstone design course sequence, and a graduate level course in product development. Muci-Küchler and Weaver8 already documented in detail the relevant aspects related to the task of identifying customer needs. This paper focuses on the task of setting functional requirements and target specifications. The process followed, an assessment of the results obtained, and suggestions for future improvement are discussed using examples taken from projects carried out by students. Approach Followed

The product development process (PDP) that the students are required to follow is very similar to the one proposed by Ulrich and Eppinger9 for “market-pull” products having a low to moderate level complexity. Figure 1 schematically shows the different phases of the process. The details of the activities involved and the deliverables corresponding to each phase can be found in the book “Product Design and Development.” 9 As can be expected, in product design projects conducted in an academic setting and lasting one year or less it is not possible to include the “production ramp-up” phase and actually launch a product into the market. Depending on the size of the team involved and the time available, students can be exposed up to the activities corresponding to the “testing and refinement” phase. However, the architecture of the product must be relatively

Page 12.689.3

Page 4: Establishing Functional Requirements And Target

simple in order to minimize the effort required to perform the “system-level design” and “detailed design” phases.

Figure 1. Phases of the generic PDP proposed by Ulrich and Eppinger9

The courses related to product design and development that the authors have taught for several years include a one-semester sophomore-level product development course and a two-semester senior design course sequence at one academic institution and a two-semester capstone senior design project and a one-semester graduate-level course in product planning and development at another university. The first three are mandatory courses for undergraduate students majoring in Mechanical Engineering. The fourth one is part of a Master in Product Development program and the students taking it typically come from different engineering disciplines. In these courses the authors use a project-based learning strategy to teach the process, methodologies and tools typically used to develop new products. The students work in teams on a design project that starts at the beginning of the course or course sequence and are required to apply the concepts/processes/tools that they learn in the course to their project. Typically each team works on a different project, but on two occasions all the teams in the class were asked to work on the same project as independent “companies” competing against each other. Keeping in mind that product design and development courses (both at the undergraduate and graduate level) are intended to be a learning experience for students, it is important to decide in advance the role that the instructor will have. Based on our experience, the students benefit the most when the instructor acts as an “external product development consultant” guiding students in the process and methodologies that must be followed without becoming a part of the product development team. In this capacity, the instructor explains each product development task that must be done and uses one or more examples taken from different projects to illustrate how they must be performed. He/she provides extensive feedback based on the work that the students do but avoids making design decisions for them. The instructor gives suggestions, questions the results of each task, encourages students to reflect on the process that they followed and ways to improve it, etc. Most undergraduate students typically feel uncomfortable with this approach, especially during the early stages of the project, because they would prefer to have the instructor as the team leader rather than as an external consultant. However, they appreciate the benefits of this approach once they start working in industry and realize how well the experience has prepared them. After they have completed their project, they can review their effort and learn from mistakes that they made.

Page 12.689.4

Page 5: Establishing Functional Requirements And Target

To start the product development effort, the teams need a document providing initial information and guidance regarding the product that they have to develop. That document, which we refer to as the “mission statement” for the project, contains a brief product description (preferably only one or two sentences long) that highlights a few key attributes expected in the product. Also, it states the main business goals for the development effort, the primary and secondary markets (if any) for the product, any assumptions and constraints that must be taken into consideration, and a list of the relevant internal and external stakeholders (from a company perspective) that will be considered as the customers. Regarding the assumptions and constraints, the first include aspects that the persons that prepared the mission statement feel can be achieved but that can be changed depending on what is found as the project progresses. The constraints correspond to aspects that must be met for the product to be considered a viable option. In a practical setting, these include information based on products currently available in the market, the company infrastructure, etc. The term customer is used here in a broad sense to refer to all the persons that will have an input regarding the product. Thus it encompasses more than the persons that will be buying and using the product. We have followed two different approaches regarding the mission statement. In some instances this document has been prepared in advance and used to “kick-off” the project at the beginning of the course. This has been our preferred option when there was a project sponsor from industry, a research center, or the community at large (like, for example, a local entrepreneur). We have also used this alternative when the instructor had in mind a specific product and direction. In the second approach, we have asked each team to propose possible product opportunities and helped the students to select one of them. Once a product was identified, we have requested the team to prepare a tentative mission statement for the project and provided feedback to improve it. Table 1 presents the mission statement for a project that a team of five students did as part of a one-semester graduate course in product planning and development. This project was selected to illustrate the topics considered in this paper since it deals with a relatively simple product that can be familiar to a wide audience and that also reveals some of the challenges faced by the students. However, it is important to point out that the ideas presented in this document draw from the experience and lessons learned by the authors while supervising a wide variety of projects over a period of many years. Before proceeding, we would like mention that when results or data from the “Weed Eradicator” (WE) project are presented, they correspond to information extracted from the final report prepared by the students10. While looking at the examples taken from this project, it is important to keep in mind that the team only had one semester to develop the product and that the students were simultaneously learning about the product development process. In the case of the “Weed Eradicator,” the team identified the type of product that it wanted to develop and prepared the mission statement. For items such as the key business goals and the internal stakeholders, the team was asked to adopt the framework of a company instead of a group of students doing a project for a course. Although improvements can be made to this mission statement, it gives the reader a good idea of the initial direction taken by the team. Once a mission statement is available, the product development process can start. In the courses related to product design and development that the authors teach, a strong emphasis is placed in

Page 12.689.5

Page 6: Establishing Functional Requirements And Target

the first phase which corresponds to the conceptual design of the product. The typical tasks that the students are required to perform are schematically shown in Fig. 2 and explained in the book by Ulrich and Eppinger9.

Table 1. Mission statement for the “Weed Eradicator” project10 Product

Description A hand-held device used to remove weeds from the lawn and/or garden by mechanical means that is easy to use, light-weight and ergonomically designed.

Key Business Goals

• Environmentally friendly.

• First prototype will be ready for test by “Date”.

• Prototype build investment will be less than or equal to “Amount”.

• First product introduction by “Quarter” of “Year.”

• Sale price between $20 and $25 per unit.

• Return on investment of at least 30%.

• Initially, product will be sold through eco-friendly catalogs, magazines and internet web sites.

Primary Market

• Environmentally friendly consumers who prefer a natural way of controlling weeds.

• Homeowners.

• Gardeners.

Secondary Markets

• Landscapers

Assumptions

• Easy to use.

• Hand-held operation.

• Made of a minimum number of pieces and moving parts.

• Easily remove the weed and prevent the weed from growing back.

Constraints

• Design that can be patented (original idea that avoids existing patents).

• Materials used should resist corrosion.

• Product weight should be less or equal than 7 lbs.

• Designed with safety as a priority.

Internal Stakeholders

• Production, Manufacturing and Service.

• Marketing and Sales.

• Shipping and Distribution.

• Investors.

External Stakeholders

• Purchasers and users.

• Nursery shops (e.g. Frank's).

• Hardware stores (e.g. Ace, Aco).

• Retail Outlets (e.g. Meijer, K-mart, Target, Wal-Mart, Sears).

Understanding the design problem is accomplished by identifying the needs of all the relevant stakeholders, setting target specifications for the product, and decomposing the problem into critical sub-problems. Although the latter is not explicitly shown in Fig. 2, it corresponds to the first activity of the concept generation task. As an integral part of the process of setting target specifications, competitive benchmarking is performed. Muci-Küchler and Weaver8 provide a very detailed description of the approach that the authors follow regarding the task of identifying customer needs. Interested readers are encouraged to take a look at that reference. Here we will focus on the task of setting target specifications for the product and we will briefly touch upon the activity of problem decomposition. The mission statement and the list of customer needs are the inputs for the task of setting target specifications for the product. The customer needs identified by the team working on the “Weed Eradicator” project are presented in Table 2. The primary needs can be viewed as labels used to

Page 12.689.6

Page 7: Establishing Functional Requirements And Target

group the needs into categories. The secondary needs are the actual need statements obtained by the team after interacting with the different stakeholders. An importance rating is assigned to each need based on a 1 to 5 scale in which each level has the following meaning: 1. Feature is undesirable to most customers. 2. Feature is not important. 3. Feature would be nice to have, but is not necessary. 4. Feature is highly desirable. 5. Feature is critical. Finally, each need is classified according to the Kano Model of customer satisfaction as “Basic” (B), “Performance” (P), or “Exciting” (E). Although a total of forty eight needs were identified by the team, two aspects are evident from Table 2:

• It is very likely that some customer needs are missing.

• A few of the need statements are probably redundant. For example, Ullman11 points out that typically the “production customer” wants a product that is easy to manufacture and assemble, uses standard parts and methods, uses available resources and existing facilities, and produces a minimum of scrap and rejected parts. Also, he mentions that in general the “sales customer” wants a product that is attractive, is suitable for display, and is easy to package, store and transport. Although both customer groups were included as internal stakeholders in the mission statement for the product, all the typical needs mentioned above are basically absent from the list that the students prepared. The needs associated with the category “the WE is easy to store” refer only to requirement expressed by the consumer. Most teams fail to identify some of the customer needs or have a few need statements that are redundant. The latter does not constitute a major issue. However, if customer needs are missing, target specifications reflecting those customer requirements will be absent and that can have a negative impact in the rest of the product development effort.

Figure 2. Main tasks of the concept development phase9

Page 12.689.7

Page 8: Establishing Functional Requirements And Target

Table 2. List of customer needs for the “Weed Eradicator” project10 Primary Need # Secondary Need Imp. KM

1 The WE’s primary form of weed removal is mechanical 4 B

2 The WE does not harm vegetation near weeds to be removed (gardens) 4 B

3 The WE can be used with and without chemicals 4 P

The WE is environmentally

friendly 4 The WE does not damage electrical lines, underground sprinklers, etc. 5 B

5 The WE is light-weight 5 B

6 The WE is easy to carry 4 B

7 The WE is portable 4 B

8 The WE requires little effort to operate 5 B

9 The WE requires little to no training in order to operate 4 B

10 The WE operator is comfortable when operating the WE 4 B

11 The WE causes little body strain during operation 4 B

12 The WE is insensitive to weed position prior to operation 4 P

13 The WE can be operated while the user is standing or sitting 2 P

14 The WE can be operated at waist level 3 P

15 The WE can be operated at chest level 3 P

16 The WE is adjustable in height 5 P

17 The WE is fun to use 3 E

18 The WE requires little operator bending during operation 5 B

19 The extracted weed can be easily removed from the WE 5 B

The WE is easy to set-up and

use

20 The WE can be quickly cleaned 3 P

21 The WE can use chemicals to ensure weed doesn’t grow back 3 P

22 The WE removes or kills the root 5 P

23 The WE goes deep into the ground for long roots 4 B

The WE permanently removes the

weed 24 The WE can pull out or kill weeds with thin roots 4 P

25 The WE operation is fast 5 P

26 The WE works better than pulling by hand 5 B

27 The WE can be used quickly from a disassembled state 5 B

28 The WE removes or kills multiple weeds 2 P

29 The WE removes or kills the weed in the first attempt 5 B

30 The WE is easy to position around the weed 3 B

31 The WE pulls only the weed, not the surrounding vegetation 4 B

32 The WE prevents little or no dirt removal 3 B

The WE is efficient

33 The WE leaves as small of a hole as possible 4 B

34 The WE works in flower beds with or without mulch, grass, and gardens 5 B

35 The WE has good weed retention in dense soil 4 B

36 The WE works in clay, sand, and dirt 4 B

37 The WE can be used to trim the bushes as well as pull weeds 1 E

The WE works in a variety of environments

38 The WE works with a variety of different weeds 4 B

39 The WE provides value for the money 5 P The WE is inexpensive 40 The WE is competitively priced 4 P

41 The WE is made of strong materials 5 B

42 The WE is corrosion resistant 5 B The WE lasts a

long time 43 The WE requires little or no maintenance 3 P

44 The WE does not take up much space during storage 3 P The WE is easy to store 45 The WE can be hung on a hook 3 P

46 The WE is difficult or impossible to use in an unsafe manner 5 B

47 The WE has safety guards or blocks when not in use 5 B The WE is safe

48 The WE will not operate during maintenance or cleaning 5 B

Page 12.689.8

Page 9: Establishing Functional Requirements And Target

To set target specifications, students are asked to use the following approach proposed by Ulrich and Eppinger9: 1. Prepare a list of metrics. 2. Collect competitive benchmarking information. 3. Set ideal and marginally acceptable target values for each metric. 4. Reflect on the results and the process. Preparing the list of metrics is a very important activity. Students must consider each customer need in turn and, based on the interactions that they had with the different stakeholders, select one or more metrics that can be used to quantify how well a given product meets that need. To do this translation process, the team members need to have a very good understanding of what the customers meant when a given need statement was recorded. For example, if the production customer wants a product that is easy to assemble, one can think in different metrics that can be related to that need: time to assemble the product, number of steps to assemble the product, list of tools required to assemble the product, number of persons required to assemble the product, physical space required to assemble the product, etc. The objective is not to create a long list of metrics for each need but to include only those metrics that clearly capture what the customer tried to express. The ideal would be to have a single metric that clearly reflects each need. Sometimes, before students start to prepare the list of metrics, we ask them to read the paper “Metrics: You are what you measure!” by Hauser and Katz12. Although the paper talks about metrics in a general sense, it creates awareness on the impact that metrics have and provides useful suggestions for selecting good metrics. Also, we ask students to consider the following guidelines provided by Ulrich and Eppinger9:

• Metrics should be as complete as possible.

• Metrics should be dependent, not independent, variables.

• Metrics should be practical.

• Some needs cannot easily be translated into quantifiable metrics.

• Metrics should include the popular criteria for comparison in the marketplace. Examples related to each of the guidelines mentioned above are presented in class. Although one would like to have only objective metrics associated with each need, it is important to recognize that for some needs this is not convenient or possible. In those cases, the need statement is used as the metric and evaluated using a subjective scale with input from the customers. To give an idea of this situation, consider the case of teenage consumers requesting that a given product “looks cool.” Although one can try to use objective metrics such as list of colors schemes, list of shapes, etc., the attribute “looks cool” is very subjective and strongly depends on the perception of the customer. Students are told that using the need statement as the metric must be avoided except in special cases like the example presented above. Table 3 shows the list of metrics for the “Weed Eradicator” project. Each metric is assigned a unique number for easy reference. The needs associated with the metric are presented next, followed by the level of importance assigned to the metric and the units selected to measure it.

Page 12.689.9

Page 10: Establishing Functional Requirements And Target

Table 3. List of metrics for the “Weed Eradicator” project10 # Needs Metric Imp. Units

1 1 Primary form of weed removal is mechanical 4 Binary

2 2 Area of effect if chemicals are used 4 cm2

3 3,20 Can be used with and without chemicals 4 Binary

4 5,6 Product mass 5 kg

5 44 Disassembled length 3 cm

6 44 Disassembled width 3 cm

7 44 Disassembled height 3 cm

8 44 Disassembled volume 3 cm3

9 6 Product length 4 cm

10 6 Product width 4 cm

11 6 Product height 4 cm

12 6 Product volume 4 cm3

13 7 Is portable 4 Binary

14 8 Operating/actuation force 5 Subjective

15 9,25,26,27 Number of operating steps 4 #

16 10 User is comfortable when operating the WE 4 Binary

17 11,18 Degree of body bending at waist 5 Degrees

18 11 Upward force to remove the weed 4 Subjective

19 11 Downward force to insert puller 4 Subjective

20 12,28,31,33 Radius of effected area 4 cm

21 13 Can be used while standing 2 Binary

22 13 Can be used while sitting 2 Binary

23 14 Comparison of operating height to average height of waist 3 cm

24 15 Comparison of operating height to average height of chest 3 cm

25 16 Range of operational control height 5 cm

26 17 Is fun to use 3 Binary

27 22,24,26 Physical evidence of complete root removal 5 Binary

28 22,26 Weed does not return 5 Binary

29 4,23 Distance puller travels under ground surface 4 cm

30 25,26 Time to extract the weed 5 sec

31 28 Number of weeds removed per attempt 1 #

32 29,34,35,36 Product efficiency 5 %

33 30 Easy to position around the weed 3 Binary

34 32 Mass of removed dirt 4 kg

35 37 Able to cut through bush branches 1 Binary

36 38 Weed types that are efficiently removed 4 List

37 39 Provides value for the money 5 Binary

38 40 Product cost 4 $

39 41 Plastic deformation in the components during operation 5 Binary

40 42 Corrosion resistant materials are used 5 Binary

41 43 Number of uses before maintenance is required 3 #

42 43 Steps needed to perform general maintenance 3 #

43 45 Product can hang on a hook 3 Binary

44 19 Time to remove weed from the WE 3 sec

45 21 Time needed to clean the WE 1 sec

46 46 Safety features active during use 4 List

47 47 Safety features active during storage 5 List

48 48 Safety features active during maintenance and cleaning 4 List

Page 12.689.10

Page 11: Establishing Functional Requirements And Target

For the level of importance associated with each metric, the same 1 to 5 scale that was used for the need statements is employed. Students are advised to choose the level of importance for a metric considering two factors: i) the importance of the needs related to the metric, and ii) how well that metric reflects those needs. Depending on the metric, the units of measurement can be conventional engineering units, binary, list, or subjective. For the latter, a convenient scale must be defined to indicate the level of customer satisfaction. As part of the activity of preparing the list of metrics, students are asked to use a “needs-metrics matrix” like the one shown in Fig. 3 as a graphical tool to see the relationship between the needs and the metrics. Some teams generate the needs-metrics matrix as they are selecting the metrics for each need while others prepare this matrix once they have completed their list of metrics. In addition to being a useful tool to visualize how the needs and metrics are related, as can be seen in Fig. 4, the needs-metrics matrix is one of the key elements involved in the “House of Quality” that is used by many companies as part of their “Quality Function Deployment” (QFD) process. In Fig. 4 “what” refers to the customers needs, “how” refers to the metrics, and “what vs. how” corresponds to the needs-metrics matrix.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

1 X

2 X

3 X

4 X

5 X

6 X X X X X

7 X

8 X

9 X

10 X

11 X X X

12 X

13 X X

14 X

15 X

16 X

17 X

18 X

19 X

20 X

21 X

22 X X

23 X

24 X

25 X X

26 X X X X

27 X

28 X X

29 X

30 X

31 X

32 X

33 X

34 X

35 X

36 X

37 X

38 X

39 X

40 X

41 X

42 X

43 X X

44 X X X X

45 X

46 X

47 X

48 X

Metrics

Nee

ds

Figure 3. Needs-Metrics matrix for the “Weed Eradicator” project10

Besides serving the obvious function of making sure that there is at least one metric associated with each need and one need associated with each metric, the needs-metrics matrix is useful to help the team reflect about the results that it has obtained so far. If several needs are related to the same metric, it is possible that the some of those need statements are redundant. If they are not, the team needs to find additional metrics that reflect those customer requirements. Also, if one need is associated with several metrics, the team can revisit the metrics to see if all of them are really needed.

Page 12.689.11

Page 12: Establishing Functional Requirements And Target

Figure 4. House of quality used in QFD

From the list of metrics prepared by the team working on the “Weed Eradicator” project (see Table 3) the following observations can be made. Although the metrics highlighted in light blue correspond to forces, the students selected a subjective 1 to 5 scale (1 corresponding to less force and 5 corresponding to more force) to try to quantify the amount of force. Due to the constraints imposed by the limited amount of time (one semester) and the resources available, the team felt that it was not going to be able to conceive a convenient testing setup to measure those forces in engineering units. Since the metrics need to be practical, the students opted to use the subjective scale. It is obvious that other units would be used if the project was taking place in industry. In the case of the metrics highlighted in yellow, the team could have tried to find better measures than the ones selected or at least could have used a 1 to 5 scale to evaluate them instead of using binary “yes/no” units. The two metrics highlighted in light gray seem to be unnecessary since the dissembled and the assembled length, width and height of the product are already included as metrics. Finally, the three metrics highlighted in magenta could have been worded so that their meaning is more clear. In particular, the needs-metrics matrix presented in Fig. 3 shows that the metric labeled “product efficiency” is the only one associated with four different needs. Reading those need statements it is obvious that more metrics are needed to represent them. Feedback like that mentioned above needs to be provided to each team as soon as possible. Although students may not have time to do all the necessary corrections and adjustments, this is a very important part of the learning experience. If the instructor is supervising several different projects, he/she needs to try to keep fresh in his/her mind all the relevant details of each project to provide guidance to the teams. This becomes a challenge when an instructor has to work with more than two or three teams at the same time. Unfortunately, in general teaching assistants lack the experience and skills needed to help with this task.

Page 12.689.12

Page 13: Establishing Functional Requirements And Target

Once the list of metrics is ready, the next step is to perform a competitive benchmarking. The teams are asked to identify existing products that they would like to consider and to perform a competitive benchmarking based on needs and one based on metrics. Depending on the type of product and the resources available, sometimes the teams can purchase some of the products and actually use them to generate the benchmarking information. In other cases, students have to rely on information contained in product brochures or catalogs, data available in the literature (like the Consumer Reports magazine), and/or simple physical or computer models. Figure 5 shows some of the different products that the team working in the “Weed Eradicator” project used for the competitive benchmarking.

Figure 5. Some of the products considered during the competitive benchmarking10

In the competitive benchmarking based on needs, a subjective scale is used to assess how well each product under consideration satisfies each need. Ideally, the team will let a representative sample of customers use the products and rate them. If that is not possible, the team members have to use the products and assign the ratings themselves trying to think as the customers. For the competitive benchmarking based on metrics, students have to measure the performance of each product with respect to each metric. For subjective metrics, the approach described for the competitive benchmarking based on needs is followed. A very important part of this activity is trying to correlate the customer perception recorded in the benchmarking based on needs with the objective performance measures determined in the benchmarking based on metrics. This is critical since it reveals how the values corresponding to a given metric are related to customer satisfaction.

Killer Kane

Weed Hound

Weed Popper

Weed Puller

Page 12.689.13

Page 14: Establishing Functional Requirements And Target

Using the results of the benchmarking based on metrics, students are encouraged to prepare one or more competitive maps like the one shown in Fig. 6 considering the most important metrics. Competitive maps are very helpful to see how the different products considered are positioned with respect to each other. They also facilitate the next step of the process which corresponds to setting the target specifications for the product.

Product Price vs. Product Efficiency

$0.00

$2.00

$4.00

$6.00

$8.00

$10.00

$12.00

$14.00

$16.00

0 20 40 60 80 100 120

Efficiency (%)

Pri

ce

(U

S d

oll

ars

)

Weed Hound

Weed

Popper

Fork

Winged

Weeder

Chemical

Injector

Manual Pulling Hand Manual Pulling Knife

Avg. Excluding

by Hand

Ideal

Value

Marginal Values

Weed Eradicator

Figure 6. Competitive map for product price vs. % efficiency10

Now that the team has prepared the list of metrics and performed the competitive benchmarking, it needs to analyze all the results that it has obtained so far and decide the target values for each metric. Following Ulrich and Eppinger9, two values are assigned to each metric: a marginal one and an ideal one. The ideal value is the best result the team would hope for. The marginal value is the one that would just barely make the product commercially viable. Students often need to be reminded that the ideal values that they select must be realistic. For example, if the customers want a product that is light weight, the weight of the product is one of the metrics that the team needs to consider. Saying that the ideal value for this metric is zero makes no sense since this is not physically possible. Based on the competitive benchmarking, students can select a value that is the same or a little bit less than the lightest competing product. Meaningless values will be of little use during the following phases of the product development process. Regarding the values assigned to the metrics, depending on the case, they can be expressed as “at least X”, “at most X”, “between X and Y”, “exactly X” or a set of discrete values. Table 4 shows the target specifications selected by the team working on the “Weed Eradicator” project. All the values corresponding to lists were replaced by “List 1”, “List 2”, etc. in order to be able to fit the table in a single page. Obviously, any deficiencies in the list of metrics cascade down through the process and have an impact in the final results.

Page 12.689.14

Page 15: Establishing Functional Requirements And Target

Table 4. Target specifications for the “Weed Eradicator” project10

# Metric Imp. Units Marginal

Value

Ideal

Value

1 Primary form of weed removal is mechanical 4 Binary Y Y

2 Area of effect if chemicals are used 4 cm2 <49 <24

3 Can be used with and without chemicals 4 Binary N Y

4 Product mass 5 kg <1.4 <0.18

5 Disassembled length 3 cm <20 <3.5

6 Disassembled width 3 cm <20 <3.5

7 Disassembled height 3 cm <109 <34

8 Disassembled volume 3 cm3 <21000 <416

9 Product length 4 cm <20 <3.5

10 Product width 4 cm <20 <3.5

11 Product height 4 cm <138 <34

12 Product volume 4 cm3 <55200 <416

13 Is portable 4 Binary Y Y

14 Operating/Actuation Force 5 Subj. >1 <2

15 Number of operating steps 4 # <4 1

16 User is comfortable when operating the WE 4 Binary Y Y

17 Degree of Body Bending at Waist 5 Degrees <30 <15

18 Upward Force to remove the weed 4 Subj. <3 1

19 Downward force to insert puller 4 Subj. <5 <3

20 Radius of effected area 4 cm <4 <3

21 Can be used while standing 2 Binary Y Y

22 Can be used while sitting 2 Binary N Y

23 Comparison of operating height to average height of waist 3 cm 85-115 95-105

24 Comparison of operating height to average height of chest 3 cm 85-115 95-105

25 Range of operational control height 5 cm 0 96-139

26 Is fun to use 3 Binary N Y

27 Physical evidence of complete root removal 5 Binary Y Y

28 Weed does not return 5 Binary Y Y

29 Distance puller travels under ground surface 4 cm 5-8 8-10

30 Time to extract the weed 5 sec <3.5 <2

31 Number of weeds removed per attempt 1 # 1 >1

32 Product efficiency 5 % >80 100

33 Easy to position around the weed 3 Binary Y Y

34 Mass of removed dirt 4 kg <.27 0

35 Able to cut through bush branches 1 Binary N Y

36 Weed types that are efficiently removed 4 List “List 1” “List 2”

37 Provides value for the money 5 Binary Y Y

38 Product cost 4 $ <13.5 <3.75

39 Plastic deformation in the components during operation 5 Binary Y Y

40 Corrosion resistant materials are used 5 Binary Y Y

41 Number of uses before maintenance is required 3 # >5 >10

42 Steps needed to perform general maintenance 3 # <3 0

43 Product can hang on a hook 3 Binary Y Y

44 Time to remove weed from the WE 3 sec <1 0

45 Time needed to clean the WE 1 sec 20 0

46 Safety features active during use 4 List None “List 3”

47 Safety features active during storage 5 List None “List 4”

48 Safety features active during maintenance and cleaning 4 List None “List 4”

Page 12.689.15

Page 16: Establishing Functional Requirements And Target

Students are made aware that once a product concept is selected later in the PDP, the team will have to define the final specifications for that product concept. The latter will show the value for each metric that the selected concept can actually attain. In general, difficult trade-offs will have to be made and the ideal values will only be met for some of metrics. In addition, the concept selected may drive a whole new set of concept-specific metrics and targets. For example, it may be battery powered, suggesting a number of new metrics (battery life for example). Before proceeding with the next task of the development effort, namely concept generation, the team is encouraged to carefully review the process that it followed to set the target specifications and to reflect on the results that were obtained. The mission statement, the list of customer needs, and the target specifications constitute the “upstream influences” that will control the rest of the PDP. It is not a good idea to proceed if the team does not have a clear understanding of what the customers want as well as a good set of metrics to quantify how well a product meets those needs. The last activity associated with understanding the design problem is to decompose it into sub-problems. There are different approaches that can be followed for that purpose such as functional decomposition, decomposition in terms of sequence of user actions, or decomposition in terms of key customer needs9. Depending on the type of product, one alternative may be more suitable than the others. In most cases, for technical products that are engineered, discrete, and physical, a functional decomposition is a good option. The key element of that approach is to identify the functions that the product has to perform in order to transform inputs of material, energy and signals into the desired outcomes. It is very important for the team to connect each function with target specifications that define the performance expected of a solution concept for that function. During the remaining activities of the PDP, specifications are useful to judge the performance of different product concepts as well as the final concept selected by the team. If virtual prototypes like the ones shown in Figs. 7 to 9 are available, they can be conveniently used to determine the value of some of the metrics. Also, physical prototypes such as the one shown in Fig. 10 can be tested (see Fig. 11) to determine the values of the metrics corresponding to a particular design. Assessment of the Proposed Approach The effectiveness of the proposed approach is tied to the level of commitment that the students have to perform each one of the activities in a conscientious fashion. We have found that some students look at projects as “things that they need to complete” to get a grade in a course or, in the case of senior design projects, to graduate. The performance of teams with that mindset is typically poor, particularly in the activities of identifying customer needs and setting target specifications. On the other extreme, some students are highly motivated and show a strong interest to learn about product development. Although those students are not exempt from making mistakes along the process, their overall performance is excellent. A few students show the true signs of being an entrepreneur (optimism, passion, willingness to take risks and learn from mistakes, etc.); the authors feel that a design process conducted in this fashion, which may be the only true taste of end-to-end product development such students receive in academia,

Page 12.689.16

Page 17: Establishing Functional Requirements And Target

begins to develop critical skills for any engineer – but will be particularly valuable for those with entrepreneurial visions (or who later develop those sorts of visions).

Figure 7. CAD prototype of the concept selected by the team10

Figure 8. Preliminary FEM simulation of the stresses in the fork in the closed position10

Page 12.689.17

Page 18: Establishing Functional Requirements And Target

Figure 9. Assembly drawing of the product concept selected by the team10

Figure 12 shows a chart comparing the number of needs and the number of metrics identified by eight different teams working independently in the development of the same product during the same semester. All the students were enrolled in the same section of a sophomore-level product development course and received feedback from the same instructor. Thus, all the teams were exposed to the same learning environment: lectures, case studies, etc. Based on the progress reports that the students turned in, two of the eight teams did an excellent job at identifying customer needs and setting target specifications. For comparison purposes, the instructor went over all the progress reports and compiled a list of the different needs reported by the teams, obtaining a total of 74. From Fig. 12, one can see that three teams only identified less than 30 needs, which is less than half of the number corresponding to the two top teams. At this point it is important to mention that before starting the process to set target specifications, all the teams received feedback about the process and the results corresponding to task of identifying customer needs. However, the three teams mentioned above did not try to improve their results. These findings are consistent with our experience over a period of several years. When a formal process is not followed to identify customer needs and set target specifications, the teams usually come up with a table that has a mixture of needs and specifications. In general, the number of items in the table is approximately twenty at most. As can be expected, it is very likely that the information presented by those teams fails to capture the requirements of all the relevant stakeholders. Typically these teams select a product concept without having a good understanding about the customer expectations and then spend many hours trying to make changes to their design every time a new flaw is identified.

Page 12.689.18

Page 19: Establishing Functional Requirements And Target

Figure 10. Physical prototype of the concept selected by the team10

Figure 11. Testing of the physical prototype10

Page 12.689.19

Page 20: Establishing Functional Requirements And Target

On the contrary, when a serious team follows a structured approach the results are very positive. In one instance, a local entrepreneur approached the faculty to request the help of a senior design team to develop a device to train football players. He had a vision about the type of product that the students had to design. After the team completed the process of identifying customer needs, he realized that the initial direction that he proposed was not the most convenient one.

Number of Needs and Metrics

0

10

20

30

40

50

60

70

80

1 2 3 4 5 6 7 8

Team

Nu

mb

er

Number of Needs

Number of Metrics

Figure 12. Comparison of the number of needs and metrics identified by eight teams

Conclusions To develop a successful product it is imperative to follow a structured approach to identify the needs of the different stakeholders and to translate those needs into an appropriate set of target specifications for the product. Translating customer needs into target specifications is a challenging task and students need instructional support to learn how to perform this process. Projects performed as part of a course in product development and capstone senior design projects provide an excellent opportunity for faculty to teach students the activities that must be performed to establish the set of target specifications once the customer needs have been identified. Although some students learn the hard way the importance of these steps in the product development process, we feel that it is better that the students learn those lessons in academia rather than in industry after graduation. Upon completion of such a project, the students gain new appreciation for the statements we make in class along the lines that “customer needs should be the principle input to the concept generation phase” and “no amount of detailed design can overcome a conceptually weak design.” The approach used by the authors in the product development related courses that they teach was presented using a project done by students to illustrate most of the activities involved in the task of establishing target specifications. The results obtained have been very positive when the teams had a true interest to learn about product development and wanted to design a good product. The

Page 12.689.20

Page 21: Establishing Functional Requirements And Target

constraints in time and resources imposed by an academic setting typically resulted in a lot of stress for both faculty and students to follow a structured approach and complete the design project on time. Acknowledgments The authors would like to acknowledge the student teams that carried out the projects featured in the examples presented in the paper. In particular, the first author wants to acknowledge the five students that worked in the “Weed Eradicator” product development project: Wuinnie Jimenez, Tom Jones, Sergio Munoz, Doug Schrandt and James Watson. References 1. Starkey, J.M., Ramadhyani, S. and Bernhard, R.J. An Introduction to Mechanical Engineering Design for

Sophomores at Purdue University. Journal of Engineering Education, 83(4), 317-324, 1994. 2. Newman, D.J. and Amir, A.R. Innovative First Year Aerospace Design Course at MIT. Journal of Engineering

Education, 90(3), 375-381, 2001. 3. Wood, K.L., Jensen, D., Bezdek, J. and Otto, K.N. Reverse Engineering and Redesign: Courses to

Incrementally and Systematically Teach Design. Journal of Engineering Education, 90(3), 363-374, 2001. 4. Muci-Küchler, K.H., Dolan, D.F. and Jenkins, C.H.M. A Comprehensive Education in Product Development:

The Key to Introduce Practice into the Engineering Curriculum. Integrating Practice into Engineering Education Conference, Center for Engineering Education and Practice (CEEP), University of Michigan – Dearborn, Dearborn, Michigan, October 3 to 5, 2004.

5. Dutson, A.J., Todd, R.H., Magleby, S.P. and Sorensen, C.D. A Review of Literature on Teaching Engineering Design Through Project-Oriented Capstone Courses. Journal of Engineering Education, 86(1), 17-28, 1997.

6. Catalano, G.D., Wray, P. and Cornelio, S. Compassion Practicum: A Capstone Design Experience at the United States Military Academy. Journal of Engineering Education, 89(4), 471-474, October 2000.

7. Muci-Küchler, K.H. and Weaver, J.M. Using Industry-Like Product Development Projects in Mechanical Engineering Capstone Design Courses. 2005 ASEE Annual Conference and Exposition, Portland, Oregon, June 12 to 15, 2005. Session 1125.

8. Muci-Küchler, K.H. and Weaver, J.M. Learning How to Identify Customer Requirements: A Key Component of Product Development Courses. 2004 ASEE Annual Conference and Exposition, Salt Lake City, Utah, June 20 to 23, 2004. Session 2125.

9. Ulrich, K.T. and Eppinger, S.D. Product Design and Development. Third Edition. Irwin McGraw-Hill, 2004. 10. Jimenez, W., Jones, T., Munoz, S., Schrandt, D. and Watson, J. The Weed Eradicator Product Development

Project: Final Report. Product Planning and Development Course, Master in Product Development Program, University of Detroit Mercy, August 2001.

11. Ullman, D.G. The Mechanical Design Process. Third Edition. McGraw-Hill, 2003. 12. Hauser, J.R. and Katz, G.M. Metrics: You are What You Measure! European Management Journal, October

1998.

Page 12.689.21