>>Speaker: Hello.

Today we're going to talk about

the engineering design process.

All engineers design things at some point in their career.

They could be designing a physical object;

they could be designing a piece of software or a process.

But engineers design things;

it's one of the ways that they solve problems.

And as an engineer, it can be a little overwhelming

when you first encounter a major design project.

So what we want to show you

today is a process that you can use to

help break that design project down into

little bits, and be more successful than

you would be if you just sat down and

started designing just offhand.

So you've seen this slide before; this is the

problem categorization slide,

and it shows the various types of problems that

you can encounter.

And you can have anywhere

from not enough information,

to just enough information to access information,

and your problems may have no answer,

one answer or more than one answer.

When you're in the classroom,

typically you encounter classroom

problems that have one answer,

and you're given just enough information.

And we talked about on the problem-solving

methodology day, how the problems you

encounter can fit into any of these categories.

Well, typically with engineering design,

you are encountering problems

that have more than one answer.

You may be given not enough information,

you may be given just enough information,

or you may be given way too much information.

But typically the problems that you encounter have

more than one answer,

and so part of the engineering

design process is determining which of these answers

is best for your product

and for your application.

So here we have a slide that shows you

the combination of problem-solving and design.

And so you can compare the two of them.

so you can see the DRPIE, the define, represent,

plan, implement and evaluate cycle on the

left hand side in the gray.

You can also see the engineering design process

over here on the right,

and you'll see that there are

some aspects of them that are very similar.

So some of the -- the obvious one is define;

it appears in both places, so I have

define, and I'm defining my problem.

Represent will often take place in a couple of places;

one of them may be when you're

creating the specifications and requirements.

It may also appear over in

creating the design concepts,

and possibly over in designing of the solution.

So represent kind of is all throughout there.

Planning tends to occur over here

in the designing of the solution.

Implement tends to appear over here,

in creating the prototype and to

an extent in designing the solution.

And evaluate tends to happen over here with

testing and validating the design.

So it's not quite a one-to-one comparison,

but you do see a lot of similarities

between problem-solving methodology

and the engineering design process.

So we shouldn't be venturing too far from

stuff that you're at least familiar with

in a cursory fashion.

So this is the engineering design process,

and we are going to go through and talk about

each of these aspects or each of these stages

one at a time here in the next few slides.

But I just want to give you the overall picture.

And one of the things that I want you to keep in mind

as we're going through each of these stages is

that this is not necessarily a linear process.

Just like problem-solving methodology,

you may be halfway through your evaluate,

and you realize that something was wrong

with your implementation.

And so you have to go back

to one of the earlier stages.

Similarly, in the engineering design process,

you may have be in the middle of

creating a prototype and realized that

you wanted two parts to occupy the same space.

We know that that can't really happen,

so maybe you're stepping back

over here into designing the solution.

Or maybe you're designing the solution and

you realize that your design is not

sufficiently constrained.

So you have to go all the way back over here

-- to creating specifications and requirements.

So at any point in this process,

you can jump back to any of the

previous stages as needed during the

design process.

Where does this design process

fit in the general lifecycle of a product?

Well, you start out with somebody needing something,

and then you design the product.

This is separate, for our purposes,

from implementing the project.

So you notice if you look back

at the engineering design process that

we stopped over here in testing and

validating the design;

we don't actually

go through to creating and releasing the

final product that's for our purposes

considered to be a separate step.

Once you've implemented the project, you're not done.

A lot of engineers think,

I've implemented the project, I'm done,

I can walk away and enjoy my beautiful product.

That's not what happens;

people break your products;

they will use anything as a hammer.

And in the process

your product breaks and you're going to

have to find a way to fix it,

or to modify the product so that it makes a

better hammer.

And then eventually your product is supported,

it's maintained and eventually it's used up and it's

disposed of or recycled in some fashion.

The rest of this presentation focuses

here on the engineering design process;

although the rest of the product

lifecycle is important, that's not what

we're going to be focusing on today.

So here we're in the stage where we are

just beginning out, and we need to define

what our problem is.

So we want to understand what the problem is

in some level of detail;

we're not necessarily

going to need every little specification,

every little requirement, but we want to

really get a good grasp on what's going

on with the project.

So you start out

with a general project needs statement

of what basically you need out of this

product that you're creating.

And the product -- again it doesn't have to be a

physical product; it could be a process;

it could be a software package,

lots of things it could be --

but you start out with some rough idea of what you want,

and then the goal of defining the

problem is narrowing this down into a

defined set of projects needs.

So this is going from saying that I need a phone

that is better than the other phones.

This is the stage where I define what

exactly it is I want better about that phone.

So am I looking for improved

coverage; is the wireless capabilities

supposed to improve, is it going to take

better photos, is it meant to be more

user friendly.

So you come down and you

figure out exactly what the project

needs are.

Then once I figured out roughly what the project needs are,

I then get down into the more nitty-gritty

specifications and requirements.

And this is a really important stage in the

engineering design process, because this

is really what lets me know when I'm done.

As an engineer you can design and

design and design and put more and more

time into your product,

but this specification and requirement stage

gives me an endpoint, so that, when I've

met these specifications and

requirements,

I know that I've reached my desired goal.

So this may be, I want to be

able to talk on my phone in this

specific location that tends to have

trouble with reception,

or I want to be

able to take a photo in, you know,

half a second without delay from when I press

the shutter button.

So these are my specifications,

and they really give me

my goals and my endpoints for my design.

And so once I have these specifications

and requirements,

I can also plan out a high-level project plan.

What are the components to my

project, how am I going to progress

through those stages, and design each of

those stages.

I can plan out my project

and it's really important that I give

myself milestones.

And some of them will be really being milestones,

some of them will be small milestones,

but my goal should really be

to break up what I'm doing into small

manageable pieces and give myself some

sort of deadlines along the way so that

I don't reach two days before the

project is due and realize that I have nothing done.

If I had milestones along

the way I probably could have prevented that.

Phase three involves creating the

design concepts.

So I now have my

specifications and requirements,

I have my high-level project plan,

and now I'm

going to think about all of the

different ways that I could approach

this problem and all of the different

solutions that I can come up with.

And there are lots of different methods that

are used in the stage.

A lot of people use brainstorming,

where you come up with

as many ideas as you can as quickly as

you can, there's no judgment,

so some really silly ideas sometimes come out,

but you end up with a good variety of

ideas from which to choose and build and

they can grow on each other.

I also want to create some sort of method by which

I'm going to evaluate these design

concepts that I've developed.

One method that is often used is called a design matrix,

where I have different criteria

that I plan on evaluating for my

different designs and I give each of

those a weight, so that I can evaluate

each idea based on these criteria, end up

with a total score, and from that total

score I can determine what my best

design is going to be.

Somehow through

some combination of coming up with

different ideas, thinking through them

evaluating them, I come up, then, with a

best solution.

And best solution can be a

little bit of a misnomer here because

it's what I think at this stage is the

best solution.

Chances are the first time you go

through this stage, the best solution

that you come up with is not going to be

the solution that you end up using,

But it's based on what you know so far, what

you think the best solution is going to be.

Once I've chosen this best so I then design the solution,

and so this is where I really sit down and plan

everything out and sketch out my design,

if it's a physical system or plan out my

algorithm; if it's software --

-- something like that,

this is where I get down into

the nitty-gritty design;

I spec components and I determine what the flow

of my code is going to be.

All of those things go on in this design solution stage.

Now I want you to realize that we

are now in stage 4 of 6 and we still

haven't built anything and that's

intentional.

This has all been preparation and planning and thinking

and designing.

This allows us to to save

money and not go down rabbit trails on

designs that we don't end up choosing as

our best design or designs that we

haven't thoroughly thought out.

Actually building things and going all the way

through that process is a fairly

labor-intensive process, so my goal

should be to have a well designed system

before I ever start actually building anything.

If I just sit down with a bunch

of materials and start putting them

together without a lot of forethought,

chances are I'm not going to end up with

a very good design.

And we want to avoid that,

and so we do spend a lot of time

here planning before we physically start

touching materials and building things.

Phase 5 is where we actually create the prototype.

So this may be code that's intended

to work with a subset of data,

or to perform a subset of the desired

processes, or work under very controlled

circumstances, or maybe this is a

mechanism that I build out of cardboard,

or rapidly prototype it, so this is a not

my final product.

This is a prototype

where I haven't spent all the time to

make it perfect and pretty.

It's just something that gives me a good

proof-of-concept to show that this

design that I've created is actually

going to work.

So then once I create this

prototype, I can test and validate my

design, and I can run my prototype

through all of my different

specifications and requirements and see

whether it meets those specifications

and requirements.

Once it meets the

specifications and requirements,

I have a validated design and I'm done and I can

I'm done with the design process.

Chances are the first time I reach this

stage, probably the second and third time

I reach this stage, the design that I've

created is going to fail my

specifications somehow.

And so at this stage,

it's fairly likely that I'm going

to have to run back to designing the

solution and maybe improving it somehow,

or even choosing an entirely different

design concept.

So in summary, engineers use the

engineering design process as a proven

way to make sure that you're meeting the

project's specifications and

requirements in regards to functionality,

on time and within budget.

And it seems like a somewhat cumbersome process when

you first sit down and start it, but this

is how experienced, expert engineers go

through this process in order to design things.

And the reason they do that is

because it works.

And so in class, we are

going to be going through an exercise

that helps step you through each of

these, so you have a more practical

understanding of what is entailed in

each of these stages.