Engineering Design I Chapter 2. Needs Assessment.

Engineering Design IChapter 2. Needs Assessment

R. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 6

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:usefulused to maintain items in high placesused outdoors on level groundused indoors on smooth surfacescould be a stepladdermight be foldingstiff and comfortable for users

must be safemust meet appropriate standardsmust not conduct electricityrelatively inexpensivelightweightdurable

R. HornseyNeeds 7

ObjectiveDesired attributes of the product.

The product should be … tall, fast, strong, yellow

GoalA goal is similar to an objective, but is typically more important. Several objectives might together constitute a goal.

ConstraintA limitation or restriction which must be obeyed.

Function What the product should do.

ImplementationThe method for actually achieving the operation of the product. Implementation is situation-specific.

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. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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

cost portability convenience durability score

cost - 0 0 1 1

portability 1 - 1 1 3

convenience 1 0 - 1 2

durability 0 0 0 - 0

R. HornseyNeeds 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: Characteristic Importance

Lightweight 23%

Easy to carry 17%

Reliable handle, hinges. clasp 11%

Durable 9%

Lots of compartments for screws etc 7%

Low cost 6%

Rust free 5%

Attractive appearance 4%

Stackable 4%

Other 14%

R. HornseyNeeds 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. HornseyNeeds 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

Constraint Measurement method Quantitative value

Size of grass, G survey 5 < G < 10 acres

Size of woods, W survey 20 < W < 50 acres

Cost verified estimate < $750,000

Stream flow rate > 5 cubic feet/s

R. HornseyNeeds 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. HornseyNeeds 15

Exercise List the constraints, along with methods for measuring them

and estimated values, governing the size of a laptop computer

R. HornseyNeeds 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. HornseyNeeds 17

Objective Weight Measurement or Estimation Target

Lightweight 23% estimate weight from the volume of each part of the toolbox

W < 5lbs

Easy to carry 17% comfortable to X% of users with 20lbs load X > 90%

Reliable handle, hinges. clasp

11% Estimated mean number of operation cycles, N, before failure for open, close, pick-up, put-down etc cycles (from prototype)

N > 100,000

Durable 9% Number of years, Y, before discolouration observed under exposure to UV light during accelerated aging

Y > 5

Lots of compartments for screws etc

7% At least S small compartments (2x3x1 inches) and L large compartments (4x8x1 inches)

S > 4, L > 1

Low cost 6% Estimated retail price P < $25

Rust free 5% Corrosion resistance of any metal patrs, R, as a percentage of corrosion resistance of surgical stainless steel

R > 95%

Attractive appearance 4% Rated attractive by A% of users A > 90%

Stackable 4% F% of footprint usable as stacking surface F > 90%

Other 14%

R. HornseyNeeds 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. HornseyNeeds 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

1. machine must be safe

2. low risk of injury to operator

3. low risk of operator mistakes

4. low risk of damage to work-piece or tool

5. 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. HornseyNeeds 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

Low risk of injury to operator

Low risk ofoperator mistakes

Automatic cut-out on overload

Low risk of damageto work-piece or tool

Machine must be safehow

why

R. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 25

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

R. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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. HornseyNeeds 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!