MENG 487/488 Conceptual 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 the previous design review, you successfully defined the
project scope, customer requirements, engineering specifications, relevant benchmarks, and a
rough business case. In this design review, you need to demonstrate that you have considered
promising ways of addressing your problem and that you have evaluated the alternatives. A
significant part of this is showing proof that your concept is viable.
Your goal is to convince us, the instructors, that your selected concept 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:
 Updates to Problem Scope (summarize quickly and focus on changes and corrections
from last design review)
o Updates to problem definition, problem statement
o Updates to technical benchmarking
o Updates to customer requirements
o Updates to engineering specifications
 Updates to projected business case (only present if applicable)
 System diagrams
o System architecture diagram (hierarchical function diagram OR component
diagram)
o Flow-block diagrams
 System level
 Diagrams for each subsystem
o Circuit block diagrams (NOT circuit schematics)
 Summary of concept generation
o Highlights of most important generated concepts
o Rationale for selecting specific concepts
o Proofs of concept for risky or uncertain concepts
o Backup plan in case the primary concept does not work as expected
o Customer feedback on concepts
 Detailed Gantt chart, for the full year
 Detailed budget, for the full year
 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.
 MENG 487/488 Conceptual Design Review Guidelines
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.

System Diagrams
The following information is required for the conceptual design review and all subsequent
design reviews.
 System architecture diagram (hierarchical function diagram OR component diagram)
 Function-flow block diagram
 Circuit block diagram (NOT circuit schematics)
System architecture diagram
A system architecture diagram is a hierarchical representation of the system, subsystem, and
components. An optional diagram is a hierarchical function diagram, which closely mirrors
the architecture diagram with the key difference that nodes are represented as functions
instead of subsystems and components.
Example:

Figure from “Performance Study of an In-Car Switched Ethernet Network without

Prioritization”, published March 2011, DOI: 10.1007/978-3-642-19786-4_15
MENG 487/488 Conceptual Design Review Guidelines
Function-Flow Block Diagram
A function-flow block diagram is a directed flow chart representation of the material,
information, and energy flows and transformations through a system. You track all inputs
and outputs and you indicate how these inputs are transformed into outputs as functions. You
should include a block diagram for the full system, at a high level of abstraction, and for each
subsystem. If it makes sense to do it, also include block diagrams for sub-subsystems.
Example:

Image extracted from Systems Engineering Fundamentals. Defense Acquisition University

Press, 2001
Circuit Block Diagram
A circuit block diagram is a representation of all the major components in an electrical
system and how those components are linked together. It does not necessarily represent
physical connections or pin outs between block elements. Your diagram should be explicitly
reviewed by Kevin Ryan.
Example:
 MENG 487/488 Conceptual Design Review Guidelines

Extracted from “Utilization of Simple Real-time Operating system on 8-bit microcontroller”,

published December 2010, by Dolinay, Vasek, and Dostalek.

Concept Generation
The following information is required for the conceptual design review, but NOT
subsequent design reviews.

 Technical benchmarking
 Summary of concept generation
o Highlights of most important generated concepts
o Rationale for selecting specific concepts
 Proofs of concept for risky or uncertain concepts
 Backup plan in case the primary concept does not work as expected
 Customer feedback on concepts
Technical Benchmarking

In the preliminary design review, you reported on relevant benchmarks. For this design
review, you should update your report to include

 any additional benchmarks,

 additional information on benchmarks previously described, and
 the working principle for a wide range of similar products, even if they are not
necessarily benchmarks.
MENG 487/488 Conceptual Design Review Guidelines
Summary of Concept Generation

When done properly, you will likely have hundreds of concepts. A few of these concepts will
be very different from one another, and a large portion of them will be small modifications to
other concepts. It is too difficult to comprehensively communicate every concept you and
your team generated and evaluated, so you will need to prioritize which to show. You should
NOT present a chronology of how each concept was developed.

The goal of summarizing your concept generation is to demonstrate

1) That you considered a wide range of options

2) That you selected the options best suited to your customer requirements

To do this, you should highlight a few generated concepts from a few iterations that
demonstrate a wide variety of ideas the rationale for choosing particular concepts to move
forward. You should briefly explain which methods you used to generate concepts, show a
few of the results, and show how you eliminated or modified concepts.

It is important to demonstrate the rationale for selecting specific concepts, and you should
use the framework provided in the lecture on selecting concepts for describing your decision
making. One major part of this rationale will be the weighted decision matrix, which will
help you distinguish between concepts that have passed go/no-go decision making steps.

Proofs of concept for risky or uncertain concepts

Some of the concepts you consider will be risky, in the sense that the likelihood of success
will be uncertain. This will especially be the case when considering which technology to use
to achieve a particular function.

As much as possible, you should use small-scale or simple experiments or prototypes to test
ideas. The goal here is to demonstrate some reasonable proof that a concept is viable. These
proofs can come in many forms, but any proof should be gathered with the goal of reducing
ambiguity or answering a specific design question.

Backup plan in case the primary concept does not work as expected

Because some concepts can be risky or uncertain, it is useful to have a backup concept or
plan to rely on in the event of the preferred concept failing. You should describe this in your
design review briefly.

Customer feedback on concepts

Gather feedback on early concepts from potential customers and present this data. Be careful
to not ask customer what they think about your idea, since this will lead to unreliable results.
 MENG 487/488 Conceptual Design Review Guidelines
Instead, ask customers how they imagine they would use this concept, how they would
change it, and what concepts they might think of instead.

This should be done early into the concept generation process to give the team time to
incorporate feedback.

Important Notes

Generally, teams can generate more and better concepts if individuals generate concepts first
and then the team meets to discuss and combine concepts into another round of concepts.

Concepts should be represented as annotated sketches. DO NOT USE CAD at this stage!
Computer graphics take too much time to make relative to sketches, and forces designers to
make detailed decisions that are better to defer, such as dimensions or the relative placement
of components in a system. Designers who prematurely use CAD also limit the breadth of
ideas they consider, negatively influencing design outcomes. Sketches do not need to be
artistic, but they should be clear and annotated in order to maximize their ability to
communicate the idea. Include length scales to indicate size.

When presenting the final idea, you should include sketches of the primary subsystems and a
composite sketch of the overall project solution. The sketch should clearly show the
subsystems and include a scale to indicate the general size of the composite system.

Project Plan and Budget

For your second design review, you must have an updated project plan (Gantt chart) and
updated budget. While these are plans and therefore tentative, you should put as much detail
into these now as you can.
Project Planning
Each team must submit a Gantt chart for the design process over the full academic year. The
plan should address the development of each subsystem in your project. Each task should be
assigned an individual, and the tasks should be as detailed as possible.
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.
When you submit your team binder for the Design Review Submission, include an
image of your Gantt chart.
 MENG 487/488 Conceptual Design Review Guidelines
Project Budget
What’s new:
At this stage, the budget should fully describe each subsystem. You should include large
purchases or expensive parts, and leave a buffer for components that are not defined yet. You
do NOT need a complete list specific line items until you have a bill of materials at the end
of the semester, but you should have as many as necessary at this point. Provide estimates in
approximately $50 increments, unless you already know more detail.
Same as before:
As before, 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. 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.
You are strongly encouraged to run your budget by the teaching staff to make sure you aren't
forgetting anything important. If the direction of your project changes significantly, you may
be asked to submit an updated budget.

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.
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.
MENG 487/488 Conceptual Design Review Guidelines
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)
 Design Documentation
 3-9 Reports
 Presentations
 CAD
o Solid models
 Old (put old versions here)
 (System assembly file)
 Subsystem 1
MENG 487/488 Conceptual Design Review Guidelines
 (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.