1 / 56

Need Analysis / Problem Statement

Need Analysis / Problem Statement . By: Prof: Wilmer Arellano Fall 2008. Overview. Prescribing the Design Process Problem Definition Need Analysis The Designer-Client-User Triangle The Client’s Need The Client Interview The User Needs The Survey Need Analysis Example

Télécharger la présentation

Need Analysis / Problem Statement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  1. Need Analysis / Problem Statement By: Prof: Wilmer Arellano Fall 2008

  2. Overview • Prescribing the Design Process • Problem Definition • Need Analysis • The Designer-Client-User Triangle • The Client’s Need • The Client Interview • The User Needs • The Survey • Need Analysis Example • Problem Statement • Assumptions and limitations. • Operating environment. • Intended user(s • Intended use(s).

  3. References • Excerpts from the book “Engineering Design, a Project Based Introduction”, second edition by Clive I. Dym and Patrick Little. John Wiley and Sons, Inc. ISBN 0-471-25687-0 • Karl T. Ulrich and Steven D.Eppinger. (2000). Product Design and Development. Second Edition. McGraw-Hill: New York

  4. Prescribing the Design Process

  5. Problem Definition • Input: • client’s Need Statement • Tasks: • Talk with the Client, (interview) • Some Potential Users (Survey), • Conduct your own Brainstorming Sessions, (Fishbone) • Review Similar Products, Industry Reports, Literature, Patents • Talk to Marketing People, and Experts. • Research, Market data publications, Market Trends. • Output: • Revised Problem Statement • Refined Objectives • User Requirements • Constraints • Assumptions and Limitations

  6. Need Analysis(The Client’s Need) • Client Statements usually have limitations because they often: • Contain errors, • Show biases, or • Imply solutions. • “FIU College of Engineering needs to reconfigure the intersection (Bias, the problem could be timing of the signals instead of reconfiguration) of Flagler Boulevard (Error) and 107th Avenue so students can cross the road.”

  7. Need Analysis(The Client’s Need) • Customer: “We want a rear door installed on the aircraft we are ordering” (Implied Solution) • Design, test, and get FHA (Functional Hazard Assessment) approval for a new tail section with a door in order to make sale.

  8. Need Analysis (The Designer-Client-User Triangle) • There are three parties involved in a design effort and we will use three different tools for each party to gather the information: • The Client, who has objectives that the designer must clarify • We get information from the client by means of interviews • The User, device, who has his own requirements • We get information from the users by means of Surveys or Focus Groups • The Designer, who must develop specifications such that something can be built to satisfy everybody. • The designers contribution comes from brainstorming.

  9. Obtaining the Object Attributes and Lists of Objectives • We will use a method based on attributes to clarify the needs and obtain the problem statement and Project Objectives. • Attribute: A quality or characteristic of the object to be designed

  10. Object Attributes • Objectives or goals are ends that the design strives to achieve. (We generally view design objectives • They are normally expressed as “being” statements that say what the design will be, as opposed to what the design must do. • Objectives are abstract • Constraints are statements that expresses measurable bounds for an element or function of the system. • Constraints are typically stated as clearly defined limits whose satisfaction can be framed into a binary choice, for example, the ladder material is a conductor or it is not. • The cost cannot exceed $95. • Constraints values could be change to a different value

  11. Object Attributes • Functions are the things a design is supposed to do, the actions that it must perform • Functions are usually expressed as “doing”. • Lastly, implementations or means are ways of executing those functions that the design must perform . • Need analysis deals first with objectives and later with constraints

  12. Object Attributes Examples • Objectives • The Car should be lightweight • The Car should be fast • Constraints are restrictions on a behavior or a value or some other aspect of a designed object’s performance • The Car must not weight more than 1,000 pounds • The Car must run at least 80 mph • Functions are the things a design is supposed to do, the actions that it must perform • The Car will automatically control speed • The Car will turn right and left • Lastly, implementations or means are ways of executing those functions that the design must perform . • The power of the car is to be generated by a 4 cylinder gas engine

  13. The Client’s Need • The Product needs to be based on the customer needs, make sure that you: • Identify hidden needs as well as explicit needs. • Keep record of the needs activity of the development process. • Ensure that no critical customer need is forgotten. • All the team members understand the customer needs.

  14. The Client Interview • Prepare a Structured interview wit questions like: • When and why do you use this type of product? • Walk us through a typical session using the product. • What do you like about the existing products? • What do you dislike about the existing products? • What issues do you consider when purchasing the product? • What improvements would you make to the product? • Are there already products on the market that have similar features? • And you can always ask a second question: • What does that mean? • Why do you want that? • Every Project is different please customize

  15. Client Interview(Discovering the Roots) • 5 Whys is a problem solving technique that allows you to get at the root cause of a problem fairly quickly. It was made popular as part of the Toyota Production System (1970’s.) • By repeatedly asking the question "Why" (five is a good rule), you can peel away the layers of symptoms that can lead to the root cause of a problem.

  16. The User Needs(The Survey)

  17. One team’s example Not much technical information gathered in this Survey. Price Question should be more accurate

  18. One team’s example continued

  19. The Survey • Survey results could depend on the facilitator and how good that person explains the project and the intention of the survey. • To mitigate this problem write an introduction explaining the project and the purpose of the survey.

  20. The Survey • Group questions by categories • All uses related questions together • All Price related questions together, etc. • Make all the questions multiple choice except for some ( 2 or 3) where you let the user give new ideas like: • Please indicate any uses not listed here that you would be interested in. • Do not use Technical Terms or Trade Marks with no meaning to the user: • What would you use an ACME3 with DSP for? • Marketing • Include some customer loyalty question inquiring about the customer purchase repetition if satisfied • Do you have any favorite brand? • What makes a brand one of yours favorites? • Also break the price questions like: • Would you pay $200 for a product like this? (Close to your estimate) • Would you pay additional $150 if we offer additional bla, bla, bla?

  21. Brainstorming(Discovering the Roots) • Finally your team will contribute to the project introducing new needs not presented neither by the client nor by the user. One way to help to unfold the roots of a problem is the Fishbone diagrams. You could use then during your brainstorming in this section of the proposal. • Fishbone Diagrams. • Cause-effect diagrams are also called Ishikawa diagrams after their creator, Dr. Kaoru Ishikawa. These diagrams are used in identifying and organizing the possible causes of a problem. They are sometimes referred to as fishbone diagrams because they resemble the skeleton of a fish, with a head, spine, and bones.

  22. Brainstorming

  23. Customer Needs Example:Cordless Screwdrivers

  24. The Client’s Need Statement • “I need a drill with protective shields around the battery contacts that can withstand me and allows me to work no matter what with no surprises” • The questions in the client interview will clarify this statement. See results in the next slide.

  25. Client’s Need Interpretation(Client Interview) • The Client needs wireless screwdriver with the following characteristics: • The battery is protected from accidental shorting. • The screwdriver operates normally after repeated dropping. • The screwdriver operates normally in the rain. • The screwdriver provides an indication of the energy level of the battery. • In your proposal, use the main ideas in your need analysis but list the questions and answers in one appendix

  26. From the Survey • The SD drives screws faster than by hand • The SD can drive screws into hardwood • SD makes it easy to start a screw • The SD can be used on electrical devices • The SD fits in a toolbox easily • The SD is easy to set-up and use • The SD is not Heavy • The SD costs Less than $95 • The SD has Tungsten Carbide bits • The SD has Plastic Body • The SD can be used outdoors • The SD can be used indoors

  27. Your Brainstorming • This information is generated by your team

  28. Object Attributes • We need to combine the attributes indicated by the client with those coming from the survey and from your brainstorming into a table.

  29. Conduct Interview • Conduct Survey • Conduct Brainstorming • Put all results in a table • Remove repeated entries • Eliminate: • Functions • Constraints • Implementations

  30. List all The attributes from: • Client Interview • Survey • Brainstorming

  31. Remove repeated entries

  32. Object Attributes • We need to eliminate from the table all those attributes which are not objectives. • From the eliminated attributes, only the constraints will be incorporated back latter. • The remaining table will be the list of Objectives

  33. Project AttributesEliminate Constraints, Functions and Implementations

  34. Pruned List of Objectives

  35. Project Objectives • Next we have to order the objectives by similar categories. • One way to start grouping entries on the list is to ask ourselves why we want them. • For example, why do we want battery to be protected from accidental shorting. • The answer is probably because that’s part of what makes a screwdriver “safe”, which is another entry on our list. • Now we test “safe” against all the objectives and group together all of them related to “safe”.

  36. Project Objectives

  37. Project Objectives • Similarly, we could ask why we care whether the screwdriver can be used indoors. • In this case, the answer is not on the list we want it to be used indoors because otherwise it would not be useful. • So we add Useful to the list of objectives and group together all the related objectives.

  38. Project Objectives • Repeating the last Step we would find that “Easy to Use” and “Durable” must be included as objectives

  39. Project Objectives

  40. The Result Is the Grouped Objectives List

  41. Project Objectives • If we repeat the process once more we would find that “Marketable” should be included as an objective that encompass “Useful” and “Durable” • The next step would be to establish a hierarchy within each objective and do some style corrections. The final result is shown in the next page.

  42. The Result Is the Indented Objectives List

  43. Three Steps • Ask why you care for an objective. • If there is a Parent objective use it to group all related objectives • If there is no Parent objective create it and group all related objectives • If there are related parent objectives then create a Grandparent objective

  44. PrioritizingPairwise Comparison Charts • We show in the table above a pairwise comparison chart (PCC) for our four-objective screwdriver design. The entries in each box of the chart are determined as binary choices, that is, every entry is either a 1 or a 0. Along the row of any given goal, say Prevents Fatigue, we enter a zero in those columns for the goals Marketable and Safe that are preferred over Prevents Fatigue, and we enter 1 in the Easy to Use column because Prevents Fatigue is preferred over Easy to Use . We also enter zeroes in the diagonal boxes corresponding to weighting any goal against itself, and we enter ratings of 1/2 for goals that are equally valued. • Sometimes we get really lucky and our client expresses strong and clear preferences, or perhaps the potential users do, so that the designer doesn’t have to do an explicit ranking. More often, however, we do have to do some ranking or we have to place some values ourselves.

  45. The Result Is the Ordered Indented Objectives List

  46. Problem Statement • The Problem Statement is a paragraph summarizing the objectives and constraints that is later followed by the list of objectives and constraints.

  47. Constraints • Following the proposal outline, after the objectives you have to continue with the constraints. Make sure that you follow the correct numbering indicated in the posted proposal outline.

  48. Assumptions and Limitations • Assumption – The result of any project decision, which is required to complete the project definition, but is not a physical limit (minimum or maximum) that was imposed by the client, the technology used, or a physical law. Assumptions are the result of decisions that can be made by the team and affect the end-product design and implementation. Examples would include: • The maximum number of simultaneous users of a computer program, or • The maximum number of books to be stored on the shelves of a bookcase. • Limitation – The result of any project decision, which is required to complete the project definition, but is a physical limit (minimum or maximum) that was imposed by the technology used, or a physical law. Limitations are the result of things over which the team has no control, but must consider in its end-product design and implementation. Examples would include: • The maximum weight or size of user that would fit in the product without damaging it. • The maximum power consumption, or (Limited by size of PS or Breakers) • The maximum speed of the end product (limited by the type of gates or microcontroller)

More Related