This document provides an introduction to engineering design. It discusses how design involves both analysis and synthesis skills. Design can be viewed as an optimization process, but is complicated by factors like conflicting objectives, nonlinear relationships, and component variations. Requirements are important to guide design, but not all requirements are equal constraints - some may be softened based on feasibility. Specifications provide measurable definitions to test if a design meets requirements. The document aims to expand the reader's view of all that is involved in engineering design.

1. Elec3017:
Electrical Engineering Design
Chapter 1: Introduction to Design
A/Prof D. S. Taubman
July 24, 2006
1 Purpose of this Chapter
The purpose of this chapter is to introduce you to the nature of design, the
processes which it involves and the breadth of skills which it embraces. An im-
portant goal of this first chapter is to expand your view of design. Before long,
you will find that the number of skills and disciplines involved in design can
become too large to keep track of in a systematic way. For this reason, many
texts on design begin to read like lists of good ideas, rather than well organized
methodologies. To address this difficulty, the next chapter provides you with
a helpful framework to manage the conceptual complexity of your rapidly ex-
panding view of design. That chapter should also help you to understand the
relationship between design and your studies in the Electrical Engineering and
Telecommunication disciplines.
2 Design: The Art of the Engineer
One, arguably oversimplified, distinction between a scientist and an engineer is
that the scientist is concerned with analyzing the behaviour of existing things,
while the engineer is concerned with the synthesis of new things. Of course,
analysis and synthesis go hand in hand; if you cannot analyze the behaviour
of a system, then you cannot hope to design a system which achieves a desired
behaviour. This is why an engineering degree involves so much fundamental
science. You must learn how to analyze an electronic circuit, for example, to
determine the DC bias levels, the frequency response, the stability, the power
dissipated in each component, the maximum votage presented across the termi-
nals of sensitive components, and so forth. These are the sort of activities with
which you have been most concerned up until this point.
Design, however, will move you into unfamiliar territory. You must find a
way to synthesize new circuits which achieve a complex array of objectives. An
1

2. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 2
easily overlooked aspect of design is the need to carefully identify and eventually
quantify what these objectives are. This is the subject of Section 3.
Assuming for the moment that it is easy to identify the design objectives
(something which is far from true in practice), one could argue that the skills
of analysis are all you need for design. The gist of the argument is captured in
the following dialogue.
Scientific products company: “We’ve got everything electrical engineers
need to design the world’s best products. We have developed an advanced
set of simulation tools which can predict the behaviour of any combination
of electrical components, no matter how complex.”
Engineer: “Sounds pretty impressive.” (thinks to himself: “sounds impossi-
ble”) “How could I use it to build an audio amplifier?”
Scientific products company: “No problem. Just try all combinations of
active and passive devices — you know, resistors, capacitors, transistors,
inductors, transformers and so on, simulate the result and see which one
comes closest to your design specs. Our simulator can produce an output
in less than 1 minute. You might want to write a script for automating
the process for generating potential circuits — or you could get a bunch of
trained monkeys to do this.”
Engineer: “Hmm. What about a design for the combat systems in a new
fighter plane?”
Scientific products company: “No problem. Same approach ...”
Hopefully, you can see how ridiculous it is to suggest that analysis itself is
sufficient for design. In fact, the absurdity of this suggestion gives us some
insight into the art of design:
Engineers develop skills which enable them to narrow the set of pos-
sibilities which must be explored.
While simulation tools are very important to the design engineer, hopefully you
can also see from the above argument that over-reliance on simulation tools is
not helpful.
An important element in this process is the ability to recognize sub-problems
which have been solved before. For example, if you need to develop an electronic
tuning fork, it is very helpful to know that you can construct an oscillator from
a tuned LC circuit (possibly locked by a crystal) and an active element which
provides positive feedback at the frequency of interest.
In this way, a good design engineer can break a problem into sub-problems,
classifying them as routine, already solved, challenging or potentially infeasible.
Part of what we call “engineering knowhow” is an awareness of what problems
have been solved before, or are already packaged up in VLSI circuits or algo-
rithms. In this way, initial design activities can focus on those sub-problems
which are the most challenging or could prove to be infeasible.

3. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 3
Another important element in the design process is the ability to transform
complex problems into alternate representations. For example, if you want to
develop a device to sample ECG signals, it is very helpful to know that the
problem you want to avoid is aliasing and that this is best understood in the
frequency domain. In fact, the frequency domain is the natural representation
in which to understand and manipulate the signals produced for or by systems
which are linear and time invariant (a vast class of interesting physical and
artificial systems). Armed with this knowledge, the engineer is able to design
an appropriate pre-filter by manipulating the poles and zeros of an RLC circuit.
2.1 Design as an Optimization Process
One way to think of design is as an optimization problem. Once the objectives
(requirements and specifications) are established, the problem is to find the
circuit configuration and component values which optimize these objectives.
This optimization task is plagued by the following difficulties, however:
1. Some objectives may be difficult to define precisely (e.g., “it must be easy
to use”).
2. Multiple objectives may be conflicting or at least have different levels of
importance.
3. Even where objectives can be numerically quantified (e.g., “maximize the
signal-to-noise level” or “minimize the power consumption”), they are of-
ten related non-linearly to circuit parameter values. As all engineers know,
non-linear optimization problems are the hard ones, having numerous lo-
cal optima which prevent us from being sure of finding a globally optimal
solution. Fortunately, electrical and telecommunications engineers have
developed many excellent strategies for solving commonly occurring non-
linear optimization problems, such as filter design, but these are applicable
only to small sub-problems of the overall design.
4. While the behaviour of the system may vary continuously with parameter
values, major design decisions (e.g., which technology to use) have a dis-
continuous impact on the behaviour of the system. This typically means
that the engineer must embark on a preliminary analysis of a variety of
quite different high level designs in order to find a good solution.
5. The behaviour of the actual components used will inevitably vary from
their ideal designed values. Engineers must understand the impact of
these variations and design systems which are able to work correctly within
known component tolerances. This dramatically complicates the design
problem, particularly for analog circuits. This problem is largely avoided
within digital electronics, but virtually all products must ultimately inter-
act with the real world through analog interfaces. Custom laser trimming
of component values at manufacturing time can also simplify the design
problem here, but it may add unnecessary cost to the product.

4. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 4
In view of the above issues, engineers do not usually kid themselves into
believing they can find the best solution to anything other than the simplest
of design problem. Instead, engineers blend the analytical tools available to
them with a judicious sampling of promising design approaches, progressively
narrowing their options until a good design is achieved.
3 The Role of Requirements
As discussed in the previous section, design must have an objective. More
commonly, there are multiple objectives and the designer is often faced with the
difficult task of trading one against the other. Recognizing that some objectives
are more important than others, it is common practice to identify the “really
important” ones as requirements.
Requirements play a very important role in industrial design. Many prac-
titioners believe that it is fruitless to start the design process before you have
fully documented the requirements you are trying to satisfy. Requirements also
play a central role in the development of standards, but we shall return to this
issue in a later chapter.
Commercially successful activities must satisfy the real or perceived needs
of a customer who is prepared to pay for them. However, the need for require-
ments extends beyond commercial product development (e.g., the development
of military hardware).
3.1 Deriving Requirements
Salt and Rothery [1, Ch. 3] and Ulrich and Eppinger [2, Chapter 4] describe
a number of strategies for deriving requirements for a product. In the sim-
plest case, a knowledgeable group of end-users is able to identify the functions
which are central to the success of the product. Consider, for example, the
development of sensing and recording equipment for nerve signal to assist in
neuro-surgery. In this case, the end-users (neuro-surgeons) may be able to pro-
vide an excellent description of the functionality they require: signal rise and
fall times, user interface features, logging capabilities, etc. Consulting firms
often find themselves designing solutions for such knowledgeable clients.
In many cases, however, deriving requirements is not so simple. Here are
some of the methods which can prove useful:
1. Survey potential consumers. This is one of the least reliable sources of
information, in part because survey respondents are likely to represent a
biased cross section of the market (e.g., people who are too polite to say
“no”). Surveys are usually non-interactive, so respondents may not get a
chance to properly understand the envisaged product.
2. Focus groups. These are interactive discussions with groups of potential
consumers — usually paid for their time. A facilitator guides the discussion
in order to get people to verbalize their requirements. A common problem

5. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 5
with both surveys and focus groups is that of selecting good questions. In
Appendix ??, we suggest some questions which can facilitate the process
of deriving requirements.
3. Observe existing similar products in use. For new products, this could
potentially be done with a prototype or even a mock up (non-functional
prototype).
4. Analyze existing similar products. Understanding how people use existing
similar products can provide some of the most reliable information on user
needs. In some cases, features offered by existing products may become
indispensible in the mind of the user, making them requirements for future
similar products. An example of this is text messaging for mobile phones.
In addition to user requirements, products may need to comply with regu-
latory (government) or other industry standards (usually for interoperability).
The manufacturing process may impose its own requirements. In fact, designing
a product for ease of manufacture (including ease of factory testing) is an art in
itself. Electronics firms often have their own internal design standards, which
form part of their quality assurance system.
3.2 The Danger of Exceeding Requirements
Although the notion of requirements makes perfect sense, it is often difficult to
separate true requirements from just attractive features. The temptation, then,
is to clutter the requirements list with features which are not really necessary.
The problem with adding unnecessary features is that each feature adds com-
plexity and cost. Of these, complexity is the greater evil, since it makes the
product more difficult to design, more likely to fail, harder to maintain, and
much more difficult to test.
ASIC (Application Specific Integrated Circuit) design provides an excellent
example of the cost of complexity. Here, each added feature may double the
number of test vectors, or worse. To highlight the significance of this problem,
it is worth noting that the test regime for a complex design could take weeks of
computer time to run.
At the same time, it is important to remember that the success of a new
product in the market place may depend upon its having a suitable array of
features, even if they are not requirements. The digital camera market is an
excellent example of this. Many consumers will not purchase a camera if it
does not offer options for manual control of the focus, exposure, lens aperture,
metering modes, fill flash level, over/under exposure, etc. On the other hand,
few of these consumers ever use these modes more than a few times, if at all,
over the lifetime of the camera.
The centrality of requirements is perhaps strongest in professional markets,
such as medical, military and scientific products. Consulting engineers often
must be guided principally by requirements, since these form the cornerstones
of their contract with the client. In many consumer markets, however, the

6. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 6
requirements can be harder to precisely identify and an extra (not required)
feature might provide the Unique Selling Point (USP) needed to break into an
existing market.
3.3 The Danger of Treating all Requirements as Con-
straints
In the previous sub-section, we used the word “true requirements” to distin-
guish them from desirable features. In reality, however, not all requirements
are equal. It is hard to separate the user’s needs from the user’s wants, so that
some requirements end up being softer than others. Requirements must also be
tempered by feasibility, cost and their impact on other requirements.
Consider, for example, the design of a watch with integrated GPS (Global
Positioning System) capabilities. One requirement may be that the product be
no larger than a diving watch. A second requirement, derived from focus group
input, might be that the device’s batteries should last at least 8 days without
recharging, since this is a minimum expected capability of similar devices such
as mobile phones. These two requirements may well conflict, since the small size
of the device necessitates the use of a very small battery. In the event that both
requirements cannot be satisfied, it is more likely in this case that a reduced
battery life will be tolerated. Of course, we could go on to include additional
requirements, such as GPS positioning accuracy, maximum acceptable cost, etc.,
each of which imposes new pressures on the design. If we treat all requirements
as hard constraints, the product may turn out to be impossible to design, or at
least not commercially viable.
Evidently, there is a grey zone between requirements and desirable features.
We must remember that design is a narrowing process. It is safest, therefore,
to start with a minimal set of broad requirements, which are hard to dispute,
particularly during the concept development phase. Once a design concept has
been selected which can satisfy these requirements, focus groups might be re-
engaged to deliberate the need for additional (perhaps softer) requirements. In
some cases, this is done by creating “mock ups” (non-functional prototypes) for
focus groups to work with.
4 The Role of Specifications
To emphasize the importance of starting broad and narrowing our options as
the design proceeds, it is good practice to draw a distinction between product
requirements and detailed product specifications. At one level, the distinction
between requirements and specifications is really one of detail. However, there
are some useful rules of thumb which can help you to distinguish between re-
quirements and specifications:
1. Requirements should be expressed in non-technical language, to the extent
that they can be readily comprehended by the consumer. This is a useful

7. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 7
rule of thumb, since it means that requirements can be generated and
analyzed by groups of potential consumers (e.g. focus groups).
2. In contrast to requirements, specifications should define the measurable
behaviour of the product or of sub-systems within the product. This is
also a useful rule, since it means that the specifications can be used in
testing to validate a design. It is worth noting that some requirements
may already be specifications in this sense. For example, the battery life
of a mobile phone is a quantified requirement which is readily understood
by the consumer, but it is also a specification which can be directly tested.
3. Requirements alone may form a sufficient basis for high level design de-
cisions, such as the type of technology to be employed — e.g., sensing
technologies, digital vs. analog processing, operating principles, etc. On
the other hand, specifications are involved in the selection of specific com-
ponent values, ratings, clock speeds, etc.
4.1 From Requirements to Specifications
To move from requirements to specifications, the design engineer must translate
needs, typically expressed in everyday language, into numerical quantities. For
example, an electric heater may be required to heat a 16 m2 room to 20◦ C
during the Sydney winter. The engineer needs to translate this into a power
output specification. To do this, the engineer must obtain information on the
coldest expected winter day in Sydney (to estimate the temperature gradient),
the thermal conductivity of surfaces in typical Sydney homes, typical ceiling
heights, and so forth.
As a much more complex example, a person with hearing impairments might
require a cochlear implant which will enable her to understand speech. The en-
gineer must translate this requirement into specifications for the number of
stimulating electrodes in the cochlear transducer, the dynamic range of the
electrode amplifier, and so forth. This translation is far from trivial, requiring
extensive psychophysical studies, information collected from animals with simi-
lar auditory structure to the human, and ingenuity. Even then, numerous trials
may be required before specifications for the product can be deduced.
4.2 Other Sources of Specifications
As you have probably gathered from the above discussion, the translation of re-
quirements into specifications can be a very difficult process. Fortunately, there
are often other useful sources of information which can simplify the process.
Where similar products already exist, others may have already done much of
the work of translating common requirements into specifications. In this case,
it may be legitimate to borrow many of your own product’s specifications from
those of the other product. In some cases, existing products set the benchmark
against which your own product must measure favourably in order to succeed in
the market place. For example, consumers demand scanners which provide at

8. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 8
least 1200 dpi resolution, simply because this is what is offered by most exist-
ing products. In reality, few consumers actually need anything more than 300
dpi resolution, but the specifications have been fixed by existing products and
market perception.
Another very important source of specifications is standards. The need to
comply with one or another regulatory or inter-operability standards may fix
many of the specifications of your device. What this means is that other groups
of experts have already done the work of translating real requirements into
appropriate specifications.
4.3 Specifications for Design and Testing
Specifications will be used to select both the internal parameters of the design
and their allowable tolerances. For example, specifications on the frequency
response of an analog filter might be expressed in terms of its maximum and
minimum gain within a specified passband and its maximum gain within a
specified stopband. This leads to the selection of a filter order and inductance,
capacitance and resistance values for the circuit. This may be the simplest
part of the design. A more complex analysis is required to determine tolerances
for the component values, such that the filter can be guaranteed to satisfy the
design specifications.
As already mentioned, specifications should be testable. In the above exam-
ple, this allows us to test each filter’s characteristics at the point of manufacture,
if necessary; indeed this approach may be the only way to actually guarantee
that the specifications are satisfied, if component tolerances cannot be reliably
deduced during the design phase.
More generally, complex systems are normally best partitioned into simpler
sub-systems, translating the overall product specifications into specifications for
each sub-system. This facilitates both the design and testing processes. The
potential drawback of modular design is that it can obscure interactions between
the sub-systems which could potentially be exploited to make the overall design
more efficient, less power hungry, and so forth. In most cases, the small losses
in overall system efficiency which might be attributed to modular design are
heavily outweighed by the benefits of design simplicity, module re-usability,
reliability, testability and so forth.
5 Design Constraints
In this section, we take the opportunity to elaborate on hard constraints which
might be imposed on the product design process. These may fall into the falling
categories:
Safety Regulations: The sale of products which contravene safety standards
is usually illegal. Standards Australia is the body responsible for creat-
ing and maintaining standards of this type, which may be referenced by

9. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 9
legislation. Of course, Standards Australia does not create the legislation
itself. Standards are created by working groups of experts from industry
and academia who are qualified to participate.
Other Regulatory Standards: Standards regulating allowable levels of elec-
tromagnetic interference, use of the communication spectrum and copy
protection enforcement all belong to this category.
Inter-operability Standards
In-house Design Guidelines:
Patent Infringement: The rapidly growing number of broad patents places
increasing constraints on new product design, especially where the prod-
uct developer does not control its own patents in a similar area or have
patent treaties with other organizations. In law, patents are equivalent
to property. As a result, in certain areas, creating new products can be
like trying to build a new trainline through a densely populated suburb —
almost all the land is already owned.
Legal Liability: A corporation is not exempt from liability just because it
follows relevant safety standards. Companies may (and should) be hessi-
tant to create products which have unknown potential to cause personal
harm or damage property. The development of medical products can be
particularly constrained by considerations of potential liability.
Time to Market: In a rapidly changing technological marketplace, many
products are not worth designing unless they can be brought to market
within a reasonable period of time (e.g., 1 to 2 years).
6 Design Phases and Narrowing
A good design process typically involves the following phases:
1. Needs assessment — determine what types of products customers need
2. Requirements analysis — determine what features a product requires
3. Problem statement — a concise & useful statement of the design problem
4. Concept generation — lateral thinking, creativity stimulation, ...
5. System design — high level design
6. Specifications analysis — refined from requirements
7. Detail design — detailed schematics, component selection, mechanical de-
signs, ...
8. Prototyping

10. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 10
9. Testing
We shall consider these design phases more carefully throughout the course.
In practice, smooth flow from one design phase to the next is rarely achieved
due to missing or incomplete information. For example, it may happen that
none of the design concepts which you explore during the system design phase
seem likely to satisfy all of the requirements. Indeed requirements often place
competing pressures on the design. In this event, you would need to revisit the
requirements to determine whether or not some of them can be softened. This
might be done by engaging or re-engaging consumer focus groups, this time
presenting them with less choice regarding what can and cannot be achieved.
Even if the requirements can all be achieved, it is a good idea to return to the
requirements analysis phase once a high level design concept has been selected.
At this point, it may be possible to specify the requirements in more detail.
Potential consumers may be given a more concrete idea of how the product will
work, and this in turn will inspire them to consider things that had would not
have crossed their minds earlier.
Evidently, it is frequently necessary to revisit earlier design phases in an
iterative fashion. To say that design is an iterative process, however, is too
obvious to be all that helpful. The central effect is that of narrowing: narrowing
of the requirements; narrowing of the feature set; narrowing of design choices;
narrowing of the remaining time; narrowing of the remaining budget; etc. It is
important to start broad, but it is equally important to progressively commit to
choices until a single solution is finally reached. The design phases mentioned
above certainly follow a narrowing trend, but narrowing also happens as we are
forced to revisit them.
7 Documenting the Design Process
Documentation plays an important role in the design process. On one hand,
the discipline of documentation forces you to think through each of the design
phases in a methodical manner. On the other hand, documents record the
information you will need for testing, continuously improving, communicating,
marketing and manufacturing your design. Here are some of the documents
that would typically be produced as part of a good design process:
1. Statement of the problem being solved
2. Operational description of the product (e.g., a draft users manual)
3. Requirements analysis
4. Technical specifications
5. System specification, including block diagram and block interface docu-
mentation.

11. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 11
6. Detailed design documents, including schematics, PCB design, mechanical
drawings, etc.
7. System test plan
8. Service and maintenance plans, if required
9. User manual
10. Manufacturing plans
11. Marketing/advertising brochures
8 Why do it?
This is probably a good point to reflect on why you are emarking on the de-
sign process in the first place. In most cases, the potential for commercial
return is the main driving factor, but this is not the only one. I have been
reliably informed that engineers at Sony developed the “Aibo” robot, because
they thought it was a cool thing to do and they thought that other engineers
like themselves would like to have one. In other words, it was not the product
of a sound marketing strategy at all. It turned out, however, to be much more
successful than anyone had imagined.
Whatever the motivation for designing a new product, it is important to
remember that some ideas are better than others. Limited design and manu-
facturing resources, competition and the budget limitations of consumers mean
that many ideas will not make it to prototypes and many prototypes will not
make it to marketable products. As a result, it is important to evaluate the
market potential of product concepts at multiple points in the design cycle so
as to eliminate unpromising candidates as early as possible. This is broadly
known as the “go/no go decision.”
Even if a product could be a success, the development and manufacture of
that product may stand in the way of developing another, even more successful
product. As Jack Knight (of the consulting firm Sinclaire Knight Mertz) is fond
of saying,
Sometimes, the most important decision you can make is the decision
not to pursue an opportunity.
In this course, we will explore a number of methodologies to help you evaluate
and re-evaluate the go/no go decisions of product design.
9 Reality Check
Seems like a lot to digest! Are you up to it? Can you succeed in the ELEC3017
design project without a team of experts guiding you through the requirements
analysis, concept development, detailed design and testing phases? Don’t stress!
Remember:

12. c
°Taubman, 2006 ELEC3017: Introduction to Design Page 12
• The big picture only emerges slowly, as you emerse yourself in the process.
• You can’t know it all from the beginning, but you have to start somewhere.
Each completed design expands your ability to identify similar blocks in
the design of later products.
• The next chapter of your notes provides you with a useful framework on
which to hang all the material covered in this course (and others). After
reading that chapter, try to see where the material covered in these notes
fits in. Much of this material will be expanded as we go on.
References
[1] Salt, J. E. and Rothery, R., Design For Electrical and Computer Engineers:
John Wiley & Sons, 2002.
[2] Ulrich, K. T. and Eppinger, S. D., Product Design and Development 2 ed ,
McGraw Hill, 2000.