Engineering Design I Chapter 2. Needs Assessment.
-
Upload
ralph-arnold -
Category
Documents
-
view
217 -
download
0
Transcript of Engineering Design I Chapter 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 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