MENG 487/488 Detailed Design Review Guidelines

Minimum Content Expected

The primary purpose of a design review is to 1) decide whether you have sufficiently
engineered your design to minimize the use of time and resources in your project, maximize
the performance, and detailed most of the important aspects of your design. You are
presenting a complete design that exists only on paper and enough prototypes to justify the
specific design decisions you have made.
Your goal is to convince us, the instructors, that your selected concept well designed
and will work as expected
To do this, you will need engineering analyses, prototypes, and experiments to justify your
decisions.
In addition to this, we will be looking for a few essential types of data, common across all
fields of engineering. These are as follows:
 Updates to Problem Scope (summarize quickly and focus on changes and corrections
from last design review)
 Updates to projected business case (only present if applicable)
 Updates to system diagrams
o System architecture diagram (hierarchical function diagram OR component
diagram)
o Flow-block diagrams
 Diagram for the whole system
 Diagrams for each subsystem
o Circuit block diagrams
 Detailed Design Documentation
o FMEA
o Engineering models and/or experiments for all key functions and/or subsystems
o CAD models
o Circuit schematics
o Bill of Materials
o Customer feedback on design, if applicable
 Detailed Gantt chart, for the full year
 Detailed budget, for the full year
o Amount spent
o Amount remaining
 Individual team roles / functions defined
The instructors will give you detailed feedback regarding the strengths and weaknesses of
your proposed problem definition. You must have each instructor pass you (i.e. receive a
unanimous vote) in order to pass the design review. Details on what happens upon failing a
design review are outlined in the syllabus.
 MENG 487/488 Detailed Design Review Guidelines
Detailed Design Documentation
The purpose of this design review is to produce design documentation that reflects a detailed
level of design. In principle, this documentation should be a complete design, with the
nuance that you will likely need to update or change elements as you begin to prototype the
final design.
Failure Modes and Effects Analysis (FMEA)
Analyze what failure modes are likely for your design and change your conceptual design to
mitigate or eliminate these failure modes. Refer to the lecture on engineering safety for
instructions.
It is recommended that you perform this analysis prior to investing time in complex
engineering models since it will possibly change important aspects of your design.
Additionally, the FMEA will likely guide the choices of many of your engineering models.
Engineering models and/or experiments
You must prove out your concepts for all key functions and/or subsystems. You may use any
modeling or experimental approach that is valid for the particular design detail you are
evaluating. Talk with your mentors and the instructors to identify analyses and experiments
that are critical for your particular project.
While there is no minimum number of analyses, each team member should be responsible for
a significant aspect of the engineering analysis or experimentation effort. Be clear who
contributed to which analysis or experiment.
Unlike in prior design reviews, this content should be presented in a particular format.
Analyses
Each analysis should be written out with the following sections:
 Purpose of the model
o Binder review submissions (BRS), about one paragraph
o Presentations (PR), a brief sentence
 A list of assumptions
o BRS, as complete as is reasonable.
o PR, major, or unusual assumptions only.
 At least one free-body diagram (FBD), clearly labeled, with all applicable variables,
dimensions, vectors, etc. labeled. Use multiple FBD’s if needed. At least one model
should indicate the context for where the FBD fits into the system.
 A list of variables used in the model, indicating which variables are the independent
variables (the ones you vary), the dependent variables (the ones you measure), and
the control variables (the ones you set, but don’t change).
 The fundamental equations applicable to the model. If you are using FEA, describe
how the forces, fluxes, etc. are applied.
MENG 487/488 Detailed Design Review Guidelines
 The derivation of the final parameterized equation(s) for the model (i.e. in symbolic
values only, no numbers) Not applicable for FEA.
o BRS, derivation and parameterized equation
o PR, final parameterized equation only.
 BRS, Code (C, C++, Python or Matlab) for generating plots. Not applicable for FEA.
 Plots comparing the independent vs. dependent variables.
Experiments
Each engineering experiment should be reported as follows:
 Purpose of the experiment
o Binder review submissions (BRS), about one paragraph
o Presentations (PR), a brief sentence
 A list of assumptions or simplifications
o BRS, as complete as is reasonable.
o PR, major, or unusual assumptions only.
 A photo or schematic of the test bed, whichever is clearer
 At least one free-body diagram (FBD), clearly labeled, with all applicable variables,
dimensions, vectors, etc. labeled. Use multiple FBD’s if needed. At least one model
should indicate the context for where the FBD fits into the system.
 A list of variables used in the model, indicating which variables are the independent
variables (the ones you vary), the dependent variables (the ones you measure), and
the control variables (the ones you set, but don’t change).
 The fundamental equations applicable to the model.
 The method used to analyze the data.
 Analysis results, for example:
o Plots comparing the independent vs. dependent variables.
o Curve fit equations
o Photos of results
o Statistical tables
o etc.

CAD models
CAD models should include every part in the design except fasteners (i.e. nuts and bolts),
unless a fastener is expected to take a critical load.
Parts designed by you should be fully modeled. Off-the shelf parts should be represented
either with parts found online (McMaster provides CAD models of most of its parts, for
example), or with low-fidelity CAD models that preserve rough dimensions and key mating
features.
Circuit schematics
Circuit schematics should be made for all critical circuits. These schematics should include
drawings of each component with pin-outs and show wires connecting between pins.
 MENG 487/488 Detailed Design Review Guidelines
Bill of Materials
The bill of
materials
(BoM)
should
include
every part in
your design,
including
fasteners.
The purpose
of the BoM
is to help
you order
parts easily,
estimate
costs for
mass
manufacture,
and update
your budget.
Your BoM
should be
formatted as
shown
below. You
may add
additional
columns if
you need
them. I find
it is useful to
include
columns that
record key
specification
s for each
component.
XSubassembly ID Component ID Supplier Product # Link Quantity Cost per unit Total cost

File Structure and Version Control

As you build your detailed design, you will be producing a significant amount of
documentation. Some companies enforce a file structure, but not all. It is extremely helpful
for teams to have an enforced file structure in order to reduce the amount of time looking for
certain files. Accordingly, all teams will need to submit files with their binder submission,
MENG 487/488 Detailed Design Review Guidelines
and the files should be saved on a USB drive with the following file structure (expected files
are placed in parentheses):
 Project Overview
o (Problem statement, etc.)
o Research data
o Old (put old versions here)
 Presentations
 CAD
o Solid models
 Old (put old versions here)
 (System assembly file)
 Subsystem 1
 (part file 1)
 (part file 2)
 Subsystem 2
 (part file 1)
 (part file 2)
o Circuit Diagrams
 Old (put old versions here)
o System diagrams
 Old (put old versions here)
 (system architecture diagram)
 (function-flow block diagrams)
 Engineering Models
o Old (put old versions here)
o Model 1
 (model report)
 Data
o Model 2
 (model report)
 Data

You should label files in any way that makes sense to you, but you should append a version
number at the end of each file. Minor changes increase the version count by 0.1, and major
changes increment the version counter to the next integer.