Engineering Design I Chapter 2. Needs Assessment

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