ECTE350

ENGINEERING DESIGN AND

MANAGEMENT

Lecture 4 Autumn 2020

• Engineering Design Process

• Project Selection & Identification
• Requirement Specification
• Concept generation & Design Methodologies
Lecture 2 Outline

 2.1 Engineering Design Process

 2.2 Project Selection & Identification
 2.3 Requirement Specification
 2.4 Concept Generation & Design Methodologies

 References & Sources

 Ford & Coulston, Design for ECE Engineers
 Prof. Scott Umbaugh Notes, Souther Illinois Univ.
2.1 Engineering Design Process
Definition
Engineering design
is the process of devising (i.e. inventing, creating) a
system, component, or process to meet desired
needs. It is a decision-making process (often
iterative), in which the basic sciences, mathematics,
and engineering sciences are applied to convert
resources optimally to meet a stated objective.
Engineering Design Processes

What is a design process?

Among the fundamental elements of the design

process are the establishment of objectives and
criteria, analysis, synthesis, construction, testing,
and evaluation.
Achieving Excellent Project
 To achieve success in executing
engineering and design projects,
it takes an understanding of the
design process, strong knowledge
of design tools, and professional
skills.

Success of Product:

Yesterday  Competing cost

Today  Quality
Tomorrow  Design
Engineering
 Engineer: One versed (i.e. expert/skilled) in the
design, construction, and use of machines
 Engineers use methodical application of scientific
knowledge and technology
 Math, Sciences and Fundamental Technologies

Innovation + Methodical Application of Science

Effective Engineering/Design
General types of design processes

 Prescriptive
 Exact process or systematic recipe, for realizing a
system
 Algorithmic in nature and expressed on flow charts
with decision logic

 Descriptive
 Less formal, describing typical activities involved in
realizing designs with less emphasis on exact
sequencing.
Design Process: Prescriptive or Descriptive?

 Prescriptive process for problem identification and

requirements selection
 Formal, exact sequences are defined
 All aspects are clear
 Good for defined problems and solutions

Do Yes
Identify Problem Determine
requirements
& Needs Requirements
satisfy needs?

No
 Design Process: Prescriptive or Descriptive?

 Descriptive overview of the

design process
 Less formal
 Describing typical activities
involved in realizing designs
with less emphasis on exact
sequencing

A typical design is somewhere

between Descriptive and
Prescriptive Design Process
VLSI Design Process

System
Specification Logic Design Circuit Design Layout
Architecture

 Divide-and-conquer approach
 The system is divided into subsystems

Is this prescriptive or descriptive?

Embedded Systems Design Process

Requirements
Analysis
 Not everything
is sequential
Specifications

Prescriptive or
System
Architecture
descriptive?
Software Design Hardware Design
Interface Design
 Application  Architecture
 Software Drivers
 Operating System  Synthesis
 Hardware Drivers
 Compiler  Compiler

Integration
and Test
Design Processes

What is the value of the design process?

How much does it cost to correct problems as process

proceeds?
Cost to Implement Changes

Cost to
implement
changes

Project lifetime
Design Process
 Problem ID & customer needs
 Research/Problem Analysis

 Requirements Specification

 Concept Generation & Evaluation Design Phase

 Prototype, Construct, & Test

 System Integration

 Maintenance
Four types of design
Repeat Order Design Path
Variant design path
Innovative design path
Strategic design path
2.2 Project Selection & Identification
Types of Design Projects
 Creative Design
 Represents new and innovative products
 Variant Design
 Variations of existing designs, where the intent is to improve
performance or add features to an existing system
 Routine Design
 Represents the design of devices for which theory and
practice are well- developed.
 Often components of more complex creative and variant
designs
Engineering Projects
 Systems Engineering & Integration
 Large-scale, many people
 Testing
 Does system meet requirements?
 Experimental Design
 Design experiment or apparatus to determine
characteristics of system
 Analysis
 Correct
problem, i.e.
FMEA(FAILURE MODES AND EFFECTS ANALYSIS )
Engineering Research Projects
Discover or create something novel
 Technology evaluation

 Applied Research

 Fundamental Research (no intended

application)
Project Selection

Use of Analytical Hierarchy Process

1. Determine selection criteria
2. Determine the criteria weightings
3. Identify and rate alternatives relative to criteria
4. Compute scores
5. Review the decision
Four Step Need ID Process
1. Gather raw data
2. Translate to marketing requirements
3. Organize the needs into a hierarchy
4. Rank the Needs
5. Review the outcomes
Step 1: Gather Raw Data
Some methods are:
 Interviews

 Focus Groups

 Observation

 Technology push-pull
 (an automated retrieval of data from the Internet,
corporate data sources and e-commerce web sites, is
delivered directly to specific user populations in a
personalised manner)
 Trends
Step 2: Translate Need to Marketing
Requirements
Marketing Requirements
 Statement of Customer Needs in language of
customer.
 What the product should do, NOT how it should be
achieved.
 Short, action-oriented phrases

 Example - “The system should have high quality

audio.”
Step 3: Organize Needs Into Hierarchy

 Organize needs by functional similarity, not by

importance!
 What is functional similarity?
Tool: Objective Tree Portable Audio
Device

High-Quality Easy to Use

Portable
Audio (0.14)
(0.62)
(0.24)
Limited
Low Distortion Lightweight
Controls
(0.67) (0.33)
(0..25)
Multiple Data
Low Noise Small
Formats
(0.33) (0.32)
(0.50)

Ergonomic Long Operating

(0.16) Time
(0.25)

Environment
(0.19)

Outdoor
Temperatures
(0.32)
Runner’s
Shock
(0.10)

Drop Resistant
(0.14)

Water Resistant
(0.38)
Step 4: Rank The Needs
 Rank the needs to determine the relative
importance of each of the needs.
 Systematically compare each need to all other
needs.
 Who should do this?
Tool: Pairwise Comparison Matrix

High- Weight
Easy-to-
Quality Portable
Use (normalized)
Audio
High-
Quality 1 1/3 2 0.24
Audio

Portable
3 1 4 0.62

Easy-to-
Use 1/2 1/4 1 0.14
Step 5: Review the Outcome
 This is just a process that embodies a good practice.
 It is ultimately for making decisions about what is
important to the end-user.
 In the end ask yourself – “Does this make sense?” If
not, you should make it so that it does or determine
why not.
Research Survey
 You need to become the experts on the problem and
state-of-the-art in this area.

 If you don’t, then you re-invent the wheel.

 If you don’t, then you don’t look too smart.

Objective of the Research Survey
 What is the basic theory behind the concept?
 How is it currently being done?
 What are the limitations of the current designs or
technology?
 What are the similarities/differences between your
concept and current systems?
 Are there existing or patented systems that are
relevant to the design?
Needs Statement
The need statement should
 Briefly and clearly state the need to be met

 Do not provide a solution to the problem

 Provide supporting statistics or anecdotes

 Describe current limitations

 Describe any supporting processes.

Example: Need Statement
According to AppleInsider, approximately 10.3 million people owned iPods at
the end of 2004 and many of the owners used them while operating their
automobiles. The National Highway Traffic Safety Administration estimates
that driver distraction is a contributing cause of 20 to 30 percent of all
motor vehicle crashes – or 1.2 million accidents per year. One research
study has estimated that driver inattention may cause as many as 10,000
deaths each year and approximately $40 billion in damages. iPods can
present a distraction to drivers that is similar to cell phones in that the
driver’s attention is divided between controlling the steering wheel,
watching the road, and navigating controls on the iPod. A system is needed
to allow users to navigate among the music selections of their iPod without
distracting their attention from the road.
From the iPod Hands-Free Device Design Report by Al-Busaidi, Bellavia, and
Roseborough [Alb07].
Objective Statement
The objective statement should
 Summarize what is being proposed to meet the
need
 Provide some preliminary design objectives

 Provide a preliminary description of the technical

solution, avoiding a detailed description of the
implementation.
Example: Objective Statement
The objective of this project is to design and prototype a device
that will make the iPod safer to use while driving an
automobile, by allowing hands-free control of the iPod. The
device will interact with the user using spoken English
commands. The user will be able to issue simple voice
commands to the device to control the operation of the iPod. In
turn, the device will communicate information verbally, such as
song titles that are displayed on the iPod screen, to the user.
From the iPod Hands-Free Device Design Report by Al-Busaidi,
Bellavia, and Roseborough [Alb07].
Project Application: The Problem
Statement
Problem Statement Contents
 Need

 Objective

 Background (Research Survey)

 Marketing Requirements

 Objective Tree
2.3 Requirement Specification
 Overview of Process [IEEE-STD 1233]

Raw (Marketing) Requirement

Customer
Customer Feedback

Customer Representation Develop Technical Feedback

System
Requirements

Constraints & Technical

Standards Representation Technical
Environment
Community
Engineering Requirements Properties

Properties:
1) Abstract
• Specify what system will do, but not how it will be
implemented.

2) Verifiable
• Should be a way to measure or demonstrate that
the requirement is met in the final system
realization
Engineering Requirement Properties (Con’t)

3) Unambiguous
 Each requirement should have a single unambiguous
meaning
 Stated with short complete sentences

4) Traceable
 Valid in marketing requirements.
Example
Does the following requirement meet the four
desirable properties? (abstract, verifiable,
unambiguous, traceable)

“The robot must have an average forward speed of 0.5

feet/sec, a top speed of at least one foot/sec, and
the ability to accelerate from standstill to the average
speed in under one second.”
A Fifth Property - Realism
 IMPORTANT – Your requirements for your project
must also be REALISTIC.

 => You need to demonstrate that the target you have

selected is technically feasible.

 How are you going to do this?

Constraints
 Constraint: design decision imposed by the
environment or a stakeholder that impacts or limits
the design.

 Example constraint: The system must use a PIC18F52

microcontroller to implement processing functions.
Standards
 A standard is established way of doing things that
ensure interoperability (e.g. TCP/IP, USB)
 Question is, what standards are relevant to your
project and how do you use them?
 Different levels of usage
 User
 Implementation
 Developer
 Types: safety, testing, reliability, communication,
data, documentation, design, metastandards and
etc…
Identifying Engineering Requirements

 Structured workshops and brainstorming

 Interviews and surveys
 Observation of processes and devices in use
 Benchmarking and market analysis
 Prototyping and simulation
 Research survey
Engineering Requirement Examples

 Need to know what type of requirement to select

for a given system.

 These are EXAMPLES – you must determine the

correct ones for your system!
Engineering Requirement Examples

Performance
 The system should detect 90% of all human faces in an
image.
 The amplifier will have a total harmonic distortion less

than 1%.
Reliability & Availability
 The system will have a reliability of 95% in five years.

 The system will be operational from 4AM to 10PM, 365

days a year.
Engineering Requirement Examples

Energy
 The system will operate for a minimum of three hours
without needing
Environmental
 The system should be able to operate in the
temperature range of 0°C to 75°C.
 The system must be waterproof and operate while
submersed in water.
 to be recharged.
Developing The Requirements Specification

Steps to follow to develop the requirements specification:

 Identify requirements from the customer, environment
and technical community
 Ensure the engineering requirements are well formed

 Organize the requirements. Similar requirements should

be presented together and relationship btwn.
Engineering and marketing requirements identified.
 Validate the requirements specification.
Properties of the Requirements Specification

 Normalized/Orthogonal
 Shouldno overlap or redundancy between engineering
requirements.

 Complete Set
 Addresses all the needs of the end user and also those
need required for system implementation.
Properties of the Requirements Specification

 Consistent
 Should not be self-contradictory

 Bounded
 Determining the min acceptable bound for target
values

 Modifiable
How do you VALIDATE requirements?

 Ask the customer if the requirements meet their

needs
 Usually done in teams
 For each engineering requirement
 Traceable?
 Verifiable?
 Realistic & technical feasible?
 For the complete Requirements Specification
 Orthogonal?
 Complete?
 Consistent?
Case Study: Car Audio Amp
Marketing
Requirements Engineering Requirements Justification
1, 2, 4 1. The total harmonic distortionBased upon competitive
should be <0.1%. benchmarking and existing amplifier
technology. Class A, B, and AB
amplifiers are able to obtain this level
of THD.
1–4 1. Should be able to sustain an This power range provides more than
output power that averages ≥ adequate sound throughout the
35 watts with a peak value automobile compartment. It is a
of ≥ 70 watts. sustainable output power for
projected amplifier complexity.

2, 4 1. Should have an efficiency (η) Achievable with several different

>40 %. classes of power amplifiers.
3 1. Average installation time for Past trials using standard audio and
the power and audio power jacks demonstrate that this is a
connections should not reasonable installation time.
exceed 5 minutes.
Case Study, cont’d
1–4 1. The dimensions should not Fits under a typical car seat. Prior
exceed 6” x 8”x 3”. models and estimates show that
all components should fit within
this package size.
1–4 1. Production cost should not This is based upon competitive
exceed $100. market analysis and previous
system designs.
Marketing Requirements
[Link] system should have excellent sound quality.
[Link] system should have high output power.
[Link] system should be easy to install.
[Link] system should have low cost.
Advanced Requirements Analysis
 Examined more advanced methods that are
used to analyze and refine requirements

 Addresses tradeoffs between engineering and

marketing requirements, tradeoffs between
engineering requirement themselves and
benchmarking
Engineering-Marketing Matrix

Output Power

η, Efficiency

Install Time

Dimensions
THD

Cost
- + + - - -
1) Sound Quality + ↑↑ ↓ ↓↓ ↓↓
2) High Power + ↓ ↑↑ ↑ ↓↓ ↓
3) Install Ease + ↓ ↑↑ ↑ ↓
4) Cost - ↓↓ ↓ ↓ ↓ ↑↑
Engineering Tradeoff Matrix

Output Power

η, Efficiency

Install Time

Dimensions
THD

Cost
- + + - - -
THD - ↓ ↓ ↓
Output Power + ↑ ↓ ↓
η, Efficiency + ↑ ↓
Install Time - ↓
Dimensions - ↓
Cost -
Competitive Benchmarks

Apex Audio Monster Amps Our Design

THD 0.05% 0.15% 0.1%

Power 30W 50W 35W

Efficiency 70% 30% 40%

Cost $250 $120 $100

Project Application: The Requirements Specification

A complete requirements document will contain:

 Needs, Objectives, and Background.

 Requirements.
 marketing requirements
 engineering requirements
 Should be abstract, verifiable, and traceable
 Some maybe constraints
 Some may be standards
 Advanced analysis
 Engineering-marketing tradeoffs
 Engineering-engineering tradeoffs
 Benchmarks
2.4 Concept Generation & Design Methodologies
Concept Generation and Evaluation
 Explore many solutions
 Brainstorm
 Select the best solution
 Based on needs and constraints
 Creativity
 Development of new ideas
 Innovation
 Bringing creative ideas to reality
Barriers to Creativity
 Perceptual blocks
• Limiting problem space
 Emotional blocks
• Fear of failure – “fail early and often”
 Environmental blocks
• Engineering cultural bias
 Intellectual and expressive blocks
• Understand tools
Strategies to Enhance Creativity

 Lateral thinking
 Question
 Practice
 Suspend judgment
 Allow time

 Think like a beginner

Concept Generation

 Substitute – new elements

 Combine – existing elements
 Adapt – different operation
 Modify – size, shape, function
 Put to other use – other app domains
 Eliminate – parts or whole
 Rearrange or reverse – work better
Design Considerations

1) WORST CASE DESIGN

 Component variation

 Environmental conditions

 Use computer simulations

Design Considerations

2) RELIABILITY
 measured by MTBF (mean time between failures)
 failure rate = 1/MTBF
 mechanical parts fail first
 design redundancy into system
 simple system/fewer parts = more reliable
Design Considerations

3) SAFETY
 identify failure modes
 provide protection

4) TEST
 design for ease of test

5) PRODUCTION/MANUFACTURING
 consider ease of assembly
Design Methodologies: Top-Down

 Also called “functional decomposition“

 implementation details considered only at the lowest
level
 top-down design, is not so clean and linear in practice

 Often implementation-level commitments are made at

high levels in the design process
Design Methodologies

CASE-BASED:
 Research a specific, similar design case study
 Model your process on that

INCREMENTAL REDESIGN:
 Find an existing design and "unravel" the design from the
bottom up
 Modify as required
 Detailed and least global aspects of the design are explored
and redesigned, if necessary, first
Design Methodologies

ITERATIVE REFINEMENT:
 An iterative top-down approach

 First a rough, approximate and general design is

completed
 Then we do it finer, more exact and more specific

 This process continues iteratively until the complete

detail design in done

Design Methodologies

BOTTOM-UP DESIGN:
 Opposite of top-down

 Start at the bottom with detail design

 To do this, you must have some idea of where you are going.
So, often this becomes...

HYBRID DESIGN:
 Combines aspects of both top-down and bottom-up

 More practical design approach then pure top-down

 Start with a top-down approach, but have feedback from the

bottom
Design Methodologies

"EXPLORER" METHOD:
 Typically used for new design ideas or research. It is useful in
initial design and specification stages, and is often used when
in "unfamiliar territory":
1) Move in some direction; e.g. toward the library, telephone, domain
expert's office, etc.
2) Look at what you find there.
3) Record what you find in your notebook.
4) Analyze findings in terms of where you want to be.
5) Use results of analysis to choose next direction.
6) Back to 1) and continue exploring