1 / 31

Engineering Design I Chapter 2. Needs Assessment

Engineering Design I Chapter 2. Needs Assessment. Needs Assessment Outline. In the first stage of the design cycle, we need to: understand the driving forces behind the design identify the constraints perform a competitive analysis determine the detailed objectives of the design project

atreece
Download Presentation

Engineering Design I Chapter 2. Needs Assessment

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.

E N D

Presentation Transcript


  1. Engineering Design IChapter 2. Needs Assessment

  2. Needs Assessment Outline • In the first stage of the design cycle, we need to: • understand the driving forces behind the design • identify the constraints • perform a competitive analysis • determine the detailed objectives of the design project • state the specifications to be met by the design R. Hornsey

  3. Establishing Need – Driving Forces • A design project does not take place in isolation, but will have a number of driving forces • these will influence both the definition of the problem and the most appropriate solution • hence an understanding of the driving forces is important for the engineer • A number of forces driving a project can be identified • Impetus from design sponsor • design sponsor can be a customer or another department in the company (e.g. sales department identifies a market opportunity) • sponsor has a greater or lesser responsibility for drafting the problem analysis statement (see later) • Safety and quality of life • Commercial incentives • Improving an existing product • personal experience R. Hornsey

  4. Changing Market • appearance of new competition • exchange rates, raw material costs • fashion • Changing customer needs • rising costs for repair or spare parts • impact of internet on telephone companies • Emerging technologies offer new opportunities • PC and MS-DOS • liquid crystal displays • the internet • fibre optics, semiconductor lasers, dvd • cell phones • What products might be influenced by the following technological advances, and how? • a miniature rechargeable battery with 10 times the energy storage density of current batteries • a 1-teraHertz computer (1 THz = 1000GHz) R. Hornsey

  5. Competition or Present Methods • Knowing how similar problems are already solved helps in a number of ways • saves time, offers ideas, raises questions • identify opportunities • Valuable questions are: • how do the products currently available to potential users solve the same problem now • if there is no existing product, how/is the problem solved? • if there are competitive products, which is more popular, what are their strengths and weaknesses? • what trade-offs led to these designs? • Taking apart a competitor’s product is known as reverse engineering • obtaining information on a product • checking if a competitor is infringing patents • see for example Semiconductor Insights at http://www.semiconductor.com R. Hornsey

  6. useful • used to maintain items in high places • used outdoors on level ground • used indoors on smooth surfaces • could be a stepladder • might be folding • stiff and comfortable for users • must be safe • must meet appropriate standards • must not conduct electricity • relatively inexpensive • lightweight • durable Brainstorming and Attributes • At the initial stage we might want to generate a list of attributes we would ideally like our product to have • what features should it have? • what should it do (functionality)? • do other products already have these attributes? • Associated questions that will appear are • what does that mean? • how are we going to do that? • why do you want that? • For example, a ladder might have the following attributes: R. Hornsey

  7. Goals, Objectives, Constraints, Functions, Implementations • Not all the items on the list are of the same type • ‘must not conduct’ is clearly a different condition from ‘inexpensive’ • Statements can be categorized: R. Hornsey

  8. Focus on the Needs of the User • A key attribute for an engineer is imagination • especially to imagine the effect of the new design, how it will be used, how it might fail, etc • and to put themselves in the place of the user • Failure of a design may occur at a number of levels • and knowledge of what these may be will assist our imagination • Concrete level • the actual physical reason for failure; e.g. seal failure in the Challenger • Process level • faulty assumptions, poor reasoning, and/or incorrect implementation that ked to the failure • e.g. incorrect choice of materials for low temperature launching of Shuttle • Values/attitudes/perspective level • the “corporate culture” that created the environment in which mistakes were not caught • e.g. management ignoring engineers’ warnings regarding the seals R. Hornsey

  9. Subjective Values • So far, we have assumed that all objectives are equally important • which will rarely be the case • But how do we rank degrees of relative importance? • For example, for a laptop computer we have objectives of • cost, portability, convenience, durability • While ranking all four criteria at once is tricky, we can usually decide between pairs of objectives • So we construct a matrix: • or pairwise comparison chart • in each row, we put a 0 for columns for which that criterion is more important than that in the row • and a 1 when the column is less important than the row • if the pair are equally weighted, we use 1/2 each • we then add up scores ... R. Hornsey

  10. e.g. portability and convenience both more important than cost • but cost more important than durability • so we see that nothing is more important than portability • hence, higher score indicates most importance • It is important to perform the pairwise comparisons on objectives of approximately equal value • e.g. among only secondary objectives R. Hornsey

  11. User Needs • Either the sponsor or the designers must ensure that the needs of the intended users of the product are met • it is risky to assume that your personal opinion is typical of all users • e.g. what do you look for in a car? • often questionnaires or focus groups are used to help determine the user needs • For example, the user-defined requirements for a toolbox can be summarised in a table: R. Hornsey

  12. Constraints • All design projects will have constraints • The difference between an objective and a constraint is that • an objective is aimed towards, whereas the design must meet the constraint(s) • For the project, we need to define a minimum set of real constraints • minimum: only essential constraints included • real: if product could be viable without constraint, then it isn’t a real constraint • In addition to explicitly stated constraints, non-explicit constraints may exist • what might be some common examples? • e.g. constraint table for a municipal park: R. Hornsey

  13. The same condition can be both an objective and a constraint • For example, cost can be a constraint • i.e. the product cannot cost more than $X • And an objective • i.e. we want the product to be as cheap as possible R. Hornsey

  14. Satisficing • Constraints make some designs unacceptable • Objectives allow us to select from a range of options at least one that is acceptable • together, constraints and objectives enable some designs to be sacrificed in order to find a design that satisfies all constraints • i.e. a design that satisfices • Satisfice: • verb: to obtain an outcome that is good enough. Satisficing action can be contrasted with maximising action, which seeks the biggest, or with optimising action, which seeks the best. • in recent decades doubts have arise about the view that in all rational decision-making the agent seeks the best result. Instead, it is argued, it is often rational to seek to satisfice i.e. to get a good result that is good enough although not necessarily the best. • the term was introduced by Herbert A. Simon in his Models of Man 1957 • The Penguin Dictionary of Philosophy, ed. Thomas Mautner, ISBN 0-14-051250-0 R. Hornsey

  15. Exercise • List the constraints, along with methods for measuring them and estimated values, governing the size of a laptop computer R. Hornsey

  16. Specifications • So far, we have translated the project sponsor definition into a set of quantitative objectives • this result is sometimes called the substitute quality characteristic • The next stage is the formal definition of specifications • at this descriptive stage of the project, specifications are almost the same as the quantitative objectives • but later, engineering specifications will contain all the technical data needed to define the product • Returning to our toolbox example … R. Hornsey

  17. R. Hornsey

  18. Clarifying Objectives • The next step of the design cycle – problem formulation – requires a clear set of objectives • Often, the project sponsor definition will be vague • “we want a widget” • So at an early stage the objectives should be clarified • part of the reason for this is to ensure that everyone has the same objectives • objectives may change over the course of the project • One technique for clarifying and communicating objectives is the objectives tree • Suppose we want to ensure that: • “the machine tool is safe” R. Hornsey

  19. Objective Tree Diagram • Expand the list of objectives • low risk of injury to operator • low risk of operator mistakes • low risk of damage to work-piece or tool • automatic cut-out when overload • Why? How? What? • Arrange the list into higher and lower priority objectives • machine must be safe • low risk of injury to operator • low risk of operator mistakes • low risk of damage to work-piece or tool • automatic cut-out when overload • Here ‘machine safety’ is the umbrella statement • low risk of injury is a means by which to achieve safety, etc. • We could make a similar list for ‘machine reliability’ or other desired characteristics R. Hornsey

  20. In practice, levels in the hierarchy should not be too numerous • because it is often tough to decide relative priorities • The last stage is to express this hierarchical list in diagrammatic form • There is no unique objective tree for a particular problem • it is just an aid to working out the problem either individually or for a team • it also highlights questions that need to be asked • and starts the team thinking about the problem how why R. Hornsey

  21. When to Stop Subdividing • We can keep dividing each branch of the tree into further sub-objectives • eventually, we find that each branch terminates in a function when there are no more sub-objectives • this leads to a solution-independent statement of the design • Alternatively, we know we have gone too far when specific implementations start to appear on the tree • the tree is a breakdown of the objectives, not a set of proposed solutions • the appropriate place to stop is the level before specific implementations are required R. Hornsey

  22. When to do the Objectives Tree? • The objectives tree is an ongoing process • It cannot start until at least some basic information is available • but it can help formulate questions, so it shouldn’t be constructed too late either • It is important to distinguish brainstorming from construction of the tree • brainstorming is a free “no bad ideas” forum • no criticism is allowed during brainstorming • everything written down • When the objectives tree is constructed, it can draw from and filter the brainstormed concepts R. Hornsey

  23. Example 1 – Ladder • We can return to the example of the ladder: • in this case, the tree grows sideways! C.L. Dym & P. Little, "Engineering Design: A Project-Based Approach", Wiley, 2000 R. Hornsey

  24. Example 2 – Transportation System • We need “a convenient, safe, attractive” regional transport system • How do we define the terms? • convenience: low journey time, low fare • attractiveness: user (comfort, noise), or non-user (visual appearance, noise) • safety: deaths, injuries, and property damage R. Hornsey

  25. From “Engineering Design Methods”, N. Cross, Wiley 2000 R. Hornsey

  26. Example 3 – Automatic Tea-maker • A variation on the objectives tree is the functions tree • where functions and means of achieving the functions are distinguished From “Engineering Design Methods”, N. Cross, Wiley 2000 R. Hornsey

  27. Example 4 – Beverage Container • Other categories, such as constraints can also be included on the objectives tree • e.g. a beverage container C.L. Dym & P. Little, "Engineering Design: A Project-Based Approach", Wiley, 2000 R. Hornsey

  28. Types of Problem • It can be useful to have an understanding of the types of problem that are encountered during the design process • The textbook outlines three problem categories • Problems of prediction • where the application of theory, physical laws, calculations etc are used to predict the behaviour of a system • Problems of explanation • in which we try to find out why something happened in practice or in experiments • Problems of invention • which are those which develop innovative solutions to a problem • We will meet all three types in the next chapter, Problem Formulation R. Hornsey

  29. Design Proposals • Section 2.5 of the textbook discusses the appropriate sections for a design proposal • read it! • Often the proposal is submitted to a potential customer as part of a competition against other companies for the project • so it must be good! • it should be technically sound, with a realistic timescale and a feasible budget • it might be tempting to underestimate costs, but this is a bad idea in the long run • for some instances, especially government agencies, there might be very well defined and precise formats for proposals, which must be followed R. Hornsey

  30. Summary • Driving forces for user needs • Brainstorming and attributes • Goals, objectives, constraints, functions, implementations • subjective values • constraints • satisficing • Specifications • Clarification of objectives • the objectives tree and how to construct • examples R. Hornsey

  31. Homework • Read and understand Chapter 2 of the textbook • especially proposal section (§2.5) • Do problems in Chapter 2 • especially 2.2, 2.4, 2.5 • Read the case histories • they are interesting as well as educational! R. Hornsey

More Related