MENG 487/488 Preliminary Design Review Guidelines

Minimum Content Expected

The primary purpose of a design review is to 1) decide whether a project should continue to
receive funding and 2) make corrections to the project direction to improve the chances that
the project will be successful. In this course, the instructors have carefully selected projects
such that they have the potential of meeting the requirements for the course, but the second
purpose listed above is still relevant to you and your team.
Your goal is to convince us, the instructors, that your problem definition is worth
pursuing.
To do this, you will need evidence and logic 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:
 Project scoping
o Problem definition, problem statement
o Technical benchmarking
o Customer requirements
o Engineering specifications
 Expected critical functions
 Projected business case
o Market size / production volume
o Market price range
o Target markets (i.e. purchasers) / potential markets
 Preliminary Gantt chart
 Preliminary budget
 Individual team roles / functions defined
In addition to this, you will need to review the information, data, etc. that justifies the
numbers and decisions you have presented.
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.

Problem Statement, Problem Definition, and Problem Background

For your design review, you will need to present the problem background, problem
statement, and problem definition. You will also need to submit these elements as written
sections in your team project binder.
 MENG 487/488 Preliminary Design Review Guidelines
Problem Statement
A problem statement is a short paragraph or two detailing what issue will be addressed by the
design process, why the problem is important to solve, what the criteria or goal for success is,
who the primary customers / stake holders are, and where the design will be implemented.
A problem statement shares many similarities with an elevator pitch.
We provided an incomplete problem statement when you selected your team project. You
will need to adapt this for your own purposes and justify changes you make to it.
Problem Definition
A problem definition is an abstract statement of how the problem will be solved. The
problem definition introduces design constrains, the project scope, the project timeline, and
concrete goals for the project which will be used to measure success.
A problem definition shares many similarities with a prospectus or abstract, but focuses
much more on administrative details.
At the beginning of a design project, this is by far the most difficult document to draft well.
A good problem statement will be specific and detailed while simultaneously avoiding
proposing a specific solution for the problem. This takes practice to get right, and you should
consult with the teaching staff early to draft this properly.
Problem Background
The problem background is an extended evidence-based justification for why the problem is
important to solve, the history of prior attempts to solve the problem, an analysis of why
those prior attempts failed or what room is left for future improvement, and an analysis of
technical benchmarks related to the problem.
When commercializing a product, it is very common to conduct extensive market research
prior to generating concepts. For example, NSF grants for entrepreneurship require a
minimum of 200 interviews with potential customers. For your project, you need to identify a
significant number of potential customers and interview them to gain a better understanding
of what the customer needs really are. Quality interactions with potential customers are better
than the number of interviews, and the point is to extract insights into the design problem that
can only be seen as an outsider. Customers, as used here, is a broad term, and includes the
person who purchases the design, the person who uses the design, the person who sells the
design, and others who may be affected by the design decisions.
A problem background also often includes a market analysis to justify the project, and may
be used as the first step in developing a business plan. While this is not required for this
class, it is a good idea to learn more about this and incorporate it if you can.

Customer Requirements and Technical Specifications

The following information is required for the preliminary design review and all subsequent
design reviews.
MENG 487/488 Preliminary Design Review Guidelines
1. Customer Requirements
2. Project Specifications
3. Project Objectives (by category)
4. Table of Weighted Objectives

This information forms constraints, i.e. real-world limitations, on your possible solution
“space”. Some of these constraints are absolute, some are relative to the context, and some
are tradeoffs between two desired metrics. Constraints are highly dependent on the specific
project, but common sources of limitations are physics, materials, costs, or technology
readiness. An example of a tradeoff in engine design is mass and power. A designer may
want to decrease mass and increase power, but increasing power also requires an increase in
mass. Thus it is important to understand which constraints are more important to a customer.
Customer Requirements
To generate customer requirements, you should gather customer feedback, cluster/sort and
analyze it, gain insights, seek refined feedback, etc. Gathering customer requirements is time-
consuming, but there is no one right way to do it You should also produce relative weights
for how each customer would prioritize the customer requirements. For later design methods,
it is best if these weights sum to 100%.
Customer requirements should be in the “voice of the customer”, which means that as much
as possible, the requirements you list should be paraphrased quotes from actual potential
users or purchasers of your device.
Examples of methods to generate customer requirements include:

 Role-playing as a potential customer

 Extracting customer needs from online product reviews for products in a similar
market space
 Interviewing customers about their experiences related to your chosen problem
 Observing customers solving the problem without interacting with them
 Surveying many customers

Project Specifications
Specifications are the numerical values associated with the anticipated behavior or
performance of your system. Some specifications are shared between all products, such as
mass, volume, etc. Others will be specific to your project. All engineering specifications
should be associated with a unit of measurement and a target value or range. These
specifications will be what you are testing when you perform engineering experimentation in
the second semester. You should avoid qualitative specifications for now, such as color,
unless they are relevant to the primary function of your design.
You should generate enough specifications that your problem scope is well defined.
Typically, this means that the critical functions of the design have associated specifications.
You can have too many specifications too early into a project.
 MENG 487/488 Preliminary Design Review Guidelines
Certain projects will have critical specifications that are determined by the physics or
technology. For example, in aerospace design, cruise altitude and thrust are two critical
engineering specifications.
Project Objectives
Project objectives are qualitative requirements, not able to be expressed in numeric metrics.
Often, objectives are the “wants” that are subordinate to the primary function. A few generic
examples that should be covered during your design review include:

 Levels of Performance
 Size Restrictions
 Weight Restrictions
 Safety
 Maintenance
 Cost

There will likely be additional categories that are important for your project, and those
should be addressed.
House of Quality (Table of Weighted Objectives)
Create a house of quality including all the above material, following the in-class example and
using the provided template.
The full chart should be included in your binder, but the chart is likely too bulky for the
design review.

Project Plan and Budget

For your first design review, you must have a project plan in the form of a Gantt chart and a
project budget. While these are plans and therefore tentative, you should make these as useful
to you as possible.
Project Planning
Each team must submit a Gantt chart for the design process over the full academic year. We
have provided recommended milestones in the course schedule. You can use these as an
initial framework for your chart, but you should modify these to be specific for your project.
As much as is possible at this stage, break the overall design into subsystems, and track the
progress for each subsystem. For each subsystem, the Gantt chart must do the following:
 identify specific tasks that need to be completed;
 estimate the time required for each task;
 identify the person responsible for each task;
 sequence the tasks; and
 indicate deadlines (milestones) that mark when that subsystem is tested/completed.
MENG 487/488 Preliminary Design Review Guidelines
To create your team’s Gantt chart, you can use freeware such as GanttProject
(www.ganttproject.biz) or shareware such as Project Libre (www.projectlibre.org), both of
which mimic most of the functionality of MS Project. To learn how to use either software,
consult the tutorial videos and documentation at these websites. When you submit your
team binder for the Design Review Submission, include an image of your Gantt chart.
Project Budget
We recognize that for this stage of the project, the budget is a preliminary estimate of costs.
You do NOT need specific line items until you have a bill of materials at the end of the
semester. The goal of creating a budget at this point in the project is to see if you have
realistic expectations for your design.
Each team must establish a budget of the parts/materials for the design, providing estimates
(in approximately $50 increments, unless you already know more detail). As much as is
possible at this stage, break the budget into subsystems.
Submitting a budget is mandated by the SEAS Dean's Office. The maximum budget per
project team is $2000. Project funding is for purchasing materials only. You are not allowed
to use it for medical tests, cloud storage, legal/marketing fees, equipment rental, etc.
Your budget is a plan, not a commitment. Some items you include in your budget may turn
out to be unnecessary. You may have other unforeseen expenses as the semester progresses.  
That is understandable, but do the best you can with the information you have to create your
budget.
If you foresee needing to purchase a particularly expensive item (e.g., engine), ask the
teaching team whether you can omit that item from your budget, as we are likely to be able
to find something that we already have on hand to serve as a stand-in.
When writing your budget, please follow these guidelines.
 Put your name(s), course title, and project title at the top of the page.
 For each item, give a description and an approximate cost.
 If an item is inexpensive, you don't have to give much detail (e.g., "Miscellaneous
fasteners: $20").
 For any item over $50, state briefly why you need it and where you got its
approximate cost.
 Keep shipping in mind when estimating costs of heavy and/or fragile items. Don't
make a separate line item in your budget for shipping, though. Instead, increase the
estimated cost of the item by the estimated cost of shipping, and add a short
explanation (e.g., “includes $15 for estimated shipping”).
You are strongly encouraged to run your budget by the teaching staff to make sure you aren't
forgetting anything important. Of course, it’s possible that some items you include in your
budget may turn out to be unnecessary in the long run, while at the same time you may have
 MENG 487/488 Preliminary Design Review Guidelines
other unforeseen expenses as the semester progresses.   That is understandable, but do the
best you can with the information you have.
If the direction of your project changes significantly, you may be asked to submit an updated
budget.
Format
There is no template for the budget, but see the guidelines given in “Requirements” above.
Do NOT use the purchase template for your budget.
An example of a budget broken down by subsystems is provided below.

subsystems budget estimate actual cost

subsystem one $329.00 $0.00

subsystem two $236.00 $0.00
subsystem three $155.00 $0.00

total $720.00 $0.00

subsystem one subsystem two subsystem three

parts/materials budget estimate actual cost parts/materials budget estimate actual cost parts/materials budget estimate actual cost
1 $100.00 1 $33.00 1 $33.00
2 $24.00 2 $55.00 2 $44.00
3 $123.00 3 $77.00 3 $34.00
4 $14.00 4 $5.00 4 $44.00
5 $35.00 5 $33.00 5
6 $33.00 6 $33.00 6
Total $329.00 $0.00 Total $236.00 $0.00 Total $155.00 $0.00

Binder Submission
Producing good documentation is an essential part of being an engineer. In this class, you
produce both a printed binder with the essential documentation and a digital submission on a
USB drive with additional information that does not make sense to print, such as code or
CAD files.
While design reviews are ungraded and are on a pass/fail basis only, your documentation
contained in the team binder is graded. Each project binder submission represents about
13% your semester grade. You will submit a team binder 7 days after a passed design
review. If the binder is submitted after 7 days, the late penalties described in the syllabus will
be applied.
Because the binder is required to be printed, this can potentially represent a large cost to print
the documentation. You should NOT use your own personal funds to print the
documentation for the binder. Glenn has a printer and other printing services for the use of
this class. Additionally, arrange printing posters or Gantt charts with Glenn.
MENG 487/488 Preliminary Design Review Guidelines
Binder Content and Structure
At the end of the school year, your final deliverable will be a prototype and a team binder
with complete documentation of the design process and documentation for that prototype.
Each design review builds on the prior design review, and subsequently builds content for
that final submission.

The team binder must include printed versions of the content covered in the design review.
All the expected minimum content for the design review must be present, in addition to any
necessary information important for your particular project. The binder documentation
should be written in a way that someone could reproduce what you have done so far.

 Problem Statement
o This section includes 2-3 page write-up of the problem statement, background,
and problem definition. Include references at the end of this section as needed.
 Design Documentation
o This documentation will detail various aspects of the design and analysis for the
project. This documentation helps others understand your design decisions.
o Have a separate subsection for each type of content from each design review in
the lists of minimum expected content (see the list at the top of this document, for
example)
 Each section should include a short write-up explaining the content and
important decisions or conclusions based on the presented evidence and
content
 The goal is to orient the reader to what they are looking at.
 e.g., there should be a section for customer research, a section for
benchmarks, a section for market research, etc.
 Include supporting evidence and data, if it makes sense to print it off.
Otherwise, include it in the digital submission only.
o Write-ups do NOT need to include transitions between binder sections
 3-9 reports – Weekly 3-9 reports
 Drawings – system-level CAD printouts, wiring diagrams, and programming flowcharts

File Structure and Version Control for Digital Submissions

As you generate your 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, 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)
MENG 487/488 Preliminary Design Review Guidelines
 Design Documentation
 3-9 Reports
 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
 Media (pictures, schematics, videos, etc.)

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. Keep file names descriptive and
avoid abbreviations if there is room for confusion.