Class2_1

1. Class2_1 • Introduction to a rational design process • Defining the problem • Specifying requirements

2. Reminder… I hope you have: Downloaded the design report template Read the syllabus carefully Read the design requirements carefully Read the requirements clarifications page Read the “lessons learned” list on our class website

3. Questions about DP? (Remember to check class web page for detailed information about DP requirements)

4. Design work this week Write your draft problem definition and specifications in your design report template. What data will you need for your specifications? Start gathering… Bring your design template file with you to class on Thursday. Thursday will be a working session to improve your draft.

5. Monitors off please

6. How is engineering design done? Is there a process?

7. Model of the Design Process Define the problem Specify product requirements Invent alternatives Evaluate the alternatives Engineer the details / analyze performance Test prototypes Report complete product description

8. Design process • This is only one of many models of the design process • Examples…

14. Design process • All of these model have two characteristics in common Design occurs in stages Design is iterative

15. Why do design in stages? • Organizes a complex process • Less likely to overlook something or make mistakes • Helps others collaborate on the design • Helps communicate the current status of the design

16. Why is design iterative?

17. Some effects of iteration in design • Makes engineering design messy • Bane of concurrent engineering • Source of expensive changes • Basis for claim that “all design is re-design” • Tempts management and engineering into being conservative in their design goals

18. Accommodating iteration • Good engineering design planning makes the best possible accommodation for the necessity of iteration in design. • What does this mean for you in your design project work? • Brainstorm with your row mates and make a list…

19. What did you come up with?

20. Our design process • We will follow the process shown on the next slide. • Give it a try. Avoid short-circuiting the process (i.e., deciding on a design and then going through the motions of the process)

21. Model of the Design Process Define the problem Specify product requirements Invent alternatives Evaluate the alternatives Engineer the details / analyze performance Test prototypes Report complete product description

22. Stage 1: Define the problem • Seems an obvious first step • But often not well done! • Elevator example • Moral of the story: before you start a design always think carefully about what is really the problem

23. Define the problem • Typically the problem statement is one to several paragraphs, giving an overall description of the goals and constraints.

24. Define the problem • What are some things you can do to help you define a design problem? • Example: talk to customers • Others?

25. Define the problem • I propose there are two basic questions the engineer must answer when trying to define the problem 1. Who is the constituency for my design? (who are the customers and what are their needs?) 2. What is the context of my design? (social, regulatory, technical feasibility, cost, time and expertise available, etc.)

26. Model of the Design Process Define the problem Specify product requirements Invent alternatives Evaluate the alternatives Engineer the details / analyze performance Test prototypes Report complete product description

27. Stage 2: Specify requirements • Product specifications describe what the design should accomplish (but not how it will accomplish it)  • These are a further refinement of the problem definition • Define the problem in “engineering terms”

28. Specifications At the beginning of the design process, good specifications strive to: 1. Describe what the design must accomplish, but not how. 2. Be as quantitative as possible; be as unambiguous as possible 

29. Example of a bad specification: The mouse trap spring will be easy to set. Bad because it is not quantitative and presumes how the design will be built rather that what it must do.

30.   Example of a good specification: The mouse trap will be settable by one inexperienced person in less than 30 seconds. Good because it says what the trap should be able to do, and is quantitative in its description.

31. Specification list example • Example of specification list from a previous ME 212 design project (see Word document “specifications_example_2010.docx”)

33. Purposes of specifications • Help define the problem. • Become a basis for evaluating design alternatives. • Provide a description of the design that can be used internally for manufacturing plans, quality control, cost estimating, etc. • Provide a description of the design that can be used externally, for communication to customers, meeting legal obligations, intellectual property definitions, etc.

34. Specifications • As the design evolves, the product specifications are also expected to evolve.  • Product specifications are typically organized under a variety of headings. • It is also quite common to assign priorities to the specifications.

35. Specification headings Functional requirements Physical requirements Marketing Cost/budget limitations Service environment Safety objectives Legal/regulatory/standards requirements Manufacturing

36. Specifications headings Maintainability Reliability Environmental impacts Ergonomics/aesthetics/human factors Schedule requirements Intellectual property protection Transportation/distribution limitations Compliance/interface with existing products Company resource issues/needed expertise/personnel

37. Spec. priority schemes • Typical prioritization schemes include:  • D (demand), W (wish) • R (required), G (goal), P (preferred) • 1, 2, 3 (high to low)

38. More tips and help… Can be found in the design report template

39. That’s all for today. • Remember, bring your draft problem statement and specifications on Thursday.