Engineering Drawing & Design

Chapter 13
Engineering Design Process and Decision Methods

Bachelors Program in Electrical Engineering
Engineering Drawing & Design   •   Bachelor

Engineering Design Process and Decision Methods

Introduction

Engineering design is a structured process for converting human, organizational, and technical needs into a safe, useful, economical, and sustainable product or system. In electrical engineering, the process may concern a power converter, protection device, embedded controller, sensor network, motor drive, or complete energy system.

Design is not simply the selection of components. It involves interpreting stakeholder needs, defining measurable requirements, generating and comparing alternatives, managing risk, testing assumptions, and iterating toward an acceptable solution. Because design decisions are made with incomplete information, engineers must combine technical analysis with judgment, communication, ethics, and transparent decision methods.

A sound design process is generally iterative rather than strictly linear. Requirements may change after testing; a manufacturing constraint may require a new architecture; or a safety analysis may reveal that an apparently attractive concept is unacceptable.

Iterative engineering design process Stakeholderneeds Specificationsand constraints Concepts andanalysis Prototype, test,and release Feedback and iteration
Iterative engineering design process
Figure: Iterative engineering design process

Figure: Engineering design as an iterative transformation from needs to verified solutions.

Learning objectives

After studying this chapter, students should be able to:

  1. Translate stakeholder needs into measurable engineering specifications.
  2. Decompose a system into functions and generate alternative concepts.
  3. Use Quality Function Deployment (QFD) to relate customer needs to technical characteristics.
  4. Construct and interpret a weighted decision matrix.
  5. Assess design risk using failure modes, effects, and criticality indicators.
  6. Plan verification, validation, and design iteration while considering safety, usability, cost, sustainability, and ethics.

1. From stakeholder needs to engineering requirements

Stakeholders include users, customers, operators, maintainers, manufacturers, regulators, owners, and communities affected by a design. Their statements are often subjective: “The device should be easy to use,” “the system must be reliable,” or “energy consumption should be low.” Such statements are valuable, but they are not yet testable requirements.

A requirement should describe a necessary condition without prescribing an unjustified solution. Good requirements are specific, measurable, achievable, relevant, traceable, and testable. A useful form is:

The system shall perform [function] under [conditions] with [measurable performance] and [constraint].

For example, “The controller shall regulate the output voltage to 24 V ± 0.5 V for input voltages from 36 V to 48 V and loads from 0 to 2 A.” This statement identifies the function, operating range, tolerance, and load condition.

Requirement attributes

Requirement classification should distinguish the requirement itself from its attributes and its compliance method.

Requirement categoryExample
FunctionalThe inverter shall convert 48 V DC to 230 V AC.
PerformanceEfficiency shall be at least 92% at rated load.
InterfaceThe unit shall communicate using CAN at 500 kbit/s.
SafetyAccessible surfaces shall not exceed the specified temperature limit.
EnvironmentalThe enclosure shall operate from −10 °C to 50 °C.
RegulatoryThe design shall comply with applicable electrical-safety standards.
PhysicalThe mass shall not exceed 4 kg.
EconomicProduction cost shall remain below the approved target.

Important requirement attributes include priority, source, rationale, owner, status, verification method, and traceability identifier. Verification is not normally a requirement type; it is a compliance method or attribute. Typical verification methods are inspection, analysis, demonstration, and test. Validation asks whether the right problem has been solved for the intended user; verification asks whether specified requirements have been satisfied.

Quality of requirements

Requirements should be independent where possible. “The product shall be lightweight, inexpensive, and highly reliable” combines several attributes and is difficult to verify. These should be separated into individual statements. Ambiguous words such as “minimal,” “adequate,” and “user-friendly” require operational definitions.

A requirements traceability matrix links stakeholder needs to specifications, design elements, verification evidence, and identified risks. Traceability helps prevent requirements from being lost during design changes and provides evidence for audits and certification.

2. Functional decomposition and concept generation

Functional decomposition describes what a system must do rather than how it will do it. At the highest level, an electrical product may be represented as:

Input energy or information → Condition or convert → Control → Deliver output → Communicate status

The top-level function is divided into subfunctions. For a battery-powered monitoring node, the decomposition may be:

  • accept electrical energy;
  • protect against overvoltage and reverse polarity;
  • regulate supply voltage;
  • sense physical variables;
  • process and store data;
  • transmit information;
  • indicate status;
  • manage enclosure and thermal paths.

A function tree, block diagram, or morphological chart can expose alternative means for each subfunction. For example, communication may use wired Ethernet, RS-485, Wi-Fi, or a low-power radio. Energy storage may use a lithium-ion cell, supercapacitor, or external supply. Combining alternatives creates candidate concepts, but combinations must be checked for compatibility, safety, manufacturability, and cost.

Divergent and convergent thinking

Concept generation is deliberately divergent at first. Brainstorming, morphological analysis, analogy, sketching, design heuristics, and consultation with users can produce alternatives. Early criticism should be limited so that unconventional but feasible concepts are not rejected prematurely.

Convergence follows. Concepts are screened against non-negotiable constraints, such as electrical isolation, legal compliance, available voltage, maximum dimensions, or an absolute cost ceiling. A concept that violates a hard constraint should not be rescued by a favorable score in other categories unless the constraint itself is renegotiated and documented.

3. Quality Function Deployment

Quality Function Deployment translates the “voice of the customer” into technical characteristics. Its best-known representation is the House of Quality, although QFD is more accurately understood as a sequence of deployment matrices.

The main steps are:

  1. list customer needs;
  2. assign importance ratings;
  3. identify measurable engineering characteristics;
  4. map the strength of relationships between needs and characteristics;
  5. study interactions and conflicts among characteristics;
  6. compare competing products or concepts;
  7. establish engineering targets and priorities.

A relationship matrix commonly uses 9 for strong, 3 for medium, 1 for weak, and 0 for no relationship. If customer need i has importance wi and technical characteristic j has relationship value rij, a simple priority measure is:

Pj = ∑i=1n wi rij

Here, Pj is the unnormalized priority of characteristic j, wi is the importance of need i, and rij is the relationship score. The result is meaningful for comparing characteristics within the same QFD study; it is not a physical unit and should not be interpreted as a probability.

For example, if three needs have importance ratings 5, 4, and 3, and a characteristic has relationship scores 9, 3, and 1, then:

P = (5 × 9) + (4 × 3) + (3 × 1) = 60

QFD does not replace engineering judgment. A technically high-priority characteristic may conflict with another characteristic, increase cost, or create safety concerns. The “roof” of the House of Quality records positive and negative correlations, such as the conflict between increased heat dissipation and reduced enclosure size.

4. Weighted decision matrices

A weighted decision matrix compares alternatives against explicit criteria. It is useful when no single equation determines the best concept. The method should be applied after hard constraints have been screened.

Let wj be the normalized weight for criterion j, with:

∑j=1m wj = 1

Let rij be the rating of alternative i against criterion j. For a benefit criterion, a higher rating is better. The weighted score is:

Si = ∑j=1m wj rij

For a cost or risk criterion, either rate the alternatives so that a higher rating still means better performance, or transform the raw measure before scoring. Mixing “high-is-good” and “high-is-bad” ratings without adjustment is a major source of error.

Worked decision-matrix example

An engineering team is comparing two isolated 24 V power-supply concepts. Hard requirements for isolation and output voltage have already been met. Five benefit-oriented criteria are assigned equal weights of 0.20. Ratings use a 1–5 scale, including half-point ratings when evidence lies between scale anchors.

CriterionWeightConcept A ratingA weighted valueConcept B ratingB weighted value
Efficiency0.204.50.904.750.95
Reliability potential0.204.00.804.250.85
Cost position0.204.00.804.00.80
Serviceability0.203.50.703.50.70
Sustainability0.203.750.753.750.75
Total1.003.954.05

Thus, Concept B ranks first, although the difference is small. The calculation for Concept A is 0.90 + 0.80 + 0.80 + 0.70 + 0.75 = 3.95, while Concept B gives 0.95 + 0.85 + 0.80 + 0.70 + 0.75 = 4.05. The ranking should not be treated as decisive when score uncertainty is comparable with the 0.10 difference. Sensitivity analysis can vary the weights or ratings to determine whether the conclusion is robust.

Decision matrices can create false precision. A score of 4.0 is not necessarily twice as desirable as a score of 2.0, and criteria may not be independent. The team should record rating definitions, evidence, assumptions, and dissenting opinions. A matrix supports judgment; it does not remove accountability.

5. Risk assessment and FMEA

Risk is commonly described as a combination of the likelihood of harm and the severity of its consequences. A qualitative risk process identifies hazards, hazardous situations, initiating events, existing controls, and residual risk. In electrical design, hazards may include electric shock, arc flash, overheating, fire, stored energy, electromagnetic interference, software malfunction, and loss of protective control.

Failure Modes and Effects Analysis (FMEA) examines how components or functions can fail. For each failure mode, the team records its local effect, system effect, cause, existing controls, and recommended action.

A traditional Risk Priority Number is:

RPN = S × O × D

where S is severity, O is occurrence likelihood, and D is the detection rating, meaning the difficulty of detecting the failure before it causes harm. Ratings are often from 1 to 10, but the scale definitions must be stated. A high D means poor detectability or greater difficulty of detection; it does not mean that detection is good.

For example, if severity is 8, occurrence is 3, and detection difficulty is 6:

RPN = 8 × 3 × 6 = 144

RPN is a prioritization aid, not a complete probability model. Two failure modes with the same RPN may have very different safety implications. A catastrophic hazard may require action even when its occurrence rating is low. Modern practice therefore supplements RPN with severity thresholds, fault-tree analysis, event-tree analysis, diagnostic coverage, and engineering judgment.

Risk controls should follow a hierarchy: eliminate the hazard where possible; substitute a safer approach; use inherently safe design; add guards and protective devices; provide warnings and instructions; and specify personal protective equipment where residual risk remains. Safety-critical functions should be designed to fail safely and should not rely only on user behavior.

6. Verification, validation, and iteration

Verification demonstrates that the design outputs satisfy specified requirements. Validation demonstrates that the completed system meets the intended use and stakeholder need in its operational context. A prototype may pass a laboratory voltage test yet fail validation because users cannot install it correctly or maintain it safely.

A verification plan should identify:

  • requirement identifier;
  • verification method;
  • test conditions and equipment;
  • acceptance criterion;
  • responsible person;
  • required records and calibration status.

For a power converter, verification may include input-range testing, load regulation, efficiency, thermal rise, insulation resistance, dielectric withstand, electromagnetic compatibility, abnormal-operation tests, and mechanical inspection. Test limits must include tolerances and measurement uncertainty where relevant.

Iteration should be evidence-driven. A failed test may indicate an incorrect requirement, inadequate concept, poor implementation, or an invalid test method. Engineers should identify the cause before changing the design. Configuration control is essential: each prototype, drawing, firmware version, and test record must be uniquely identified.

7. Safety, usability, cost, and sustainability

Design optimization is multi-objective. Improving one attribute can degrade another. Higher switching frequency may reduce magnetic-component size but increase electromagnetic interference and switching losses. More robust materials may improve life but increase embodied energy or cost.

Usability includes understandable controls, clear status indication, accessible connectors, error recovery, maintainability, and protection against foreseeable misuse. Human factors should be considered during concept development, not added as cosmetic improvements at the end.

Cost analysis should include more than component price. Relevant categories include development, tooling, manufacturing, testing, installation, energy consumption, maintenance, downtime, disposal, and warranty exposure. A design with a low purchase price may have a high life-cycle cost.

Sustainability considerations include material selection, repairability, modularity, energy efficiency, packaging, hazardous substances, supply-chain resilience, and end-of-life recovery. Life-cycle thinking prevents shifting environmental impact from the use phase to manufacturing or disposal. Engineers should avoid unsupported environmental claims and document the boundaries and assumptions of any assessment.

8. Applied case: illustrative industrial monitoring node

Background

This fictional illustrative case concerns a battery-powered node that monitors temperature and vibration on industrial motors. The node must send periodic data to a supervisory system and operate for at least one year without battery replacement.

Problem

Stakeholders initially requested a “small, cheap, reliable wireless monitor.” The phrase was insufficient for design because it did not define measurement accuracy, environment, communication range, service method, or acceptable downtime.

Analysis

Interviews produced the following needs: dependable measurement, simple installation, long battery life, safe operation near machinery, and low maintenance. These were translated into preliminary specifications: temperature accuracy of ±1 °C over the stated range, vibration measurement bandwidth of at least 1 kHz, enclosure protection appropriate to the installation environment, a minimum twelve-month operating life under a defined sampling schedule, and a documented installation procedure.

Functional decomposition identified sensing, signal conditioning, processing, wireless communication, power management, enclosure, and mounting functions. Three concepts were generated: continuous high-rate wireless transmission; local storage with periodic transmission; and event-triggered transmission with local storage.

The decision matrix favored event-triggered transmission because it reduced energy use while preserving information about abnormal vibration. FMEA identified battery undervoltage, sensor detachment, water ingress, communication loss, and firmware lock-up. Controls included undervoltage shutdown, sensor plausibility checks, a sealed enclosure, store-and-forward memory, watchdog recovery, and a visible installation indicator.

Approach and solution

A prototype was tested in a laboratory and then in a representative motor environment. Testing included sensor calibration, radio range, battery discharge, enclosure inspection, thermal behavior, and recovery from communication interruption. Field validation involved maintenance personnel installing the device without engineering assistance.

Outcome

The first prototype met measurement accuracy but failed the installation usability objective because the mounting orientation was unclear. The design was iterated with keyed mounting hardware and a polarity-resistant connector. The second prototype passed the defined verification tests and was accepted for a controlled pilot. The case illustrates that technical performance alone does not establish design success.

Learning points

  • Stakeholder language must be converted into measurable specifications.
  • Functional decomposition reveals alternative architectures.
  • Risk analysis should include misuse, maintenance, and software failure.
  • Validation with real users can reveal failures absent from laboratory tests.
  • A small decision-matrix score difference should prompt sensitivity analysis rather than automatic commitment.

9. Professional practice and contemporary tools

Modern design teams use computer-aided design, requirements-management systems, simulation, digital twins, configuration databases, automated testing, and collaborative version control. Artificial intelligence can assist with requirements classification, retrieval of prior failures, design-space exploration, and anomaly detection. However, AI-generated suggestions may contain hidden assumptions, biased training data, intellectual-property risks, or unsafe omissions. Engineers remain responsible for checking calculations, sources, compliance, and physical behavior.

Good governance requires documented decision rationales, independent review of safety-critical choices, protection of confidential data, accessibility consideration, and compliance with applicable standards and law. A design should never be approved solely because an optimization algorithm produces a high score. Human oversight is particularly important where failure can injure people, damage infrastructure, or discriminate against users.

Challenges and limitations

The design process is affected by incomplete stakeholder knowledge, changing requirements, uncertain ratings, correlated criteria, immature technology, schedule pressure, and organizational bias. QFD can become bureaucratic if matrices are completed without genuine customer evidence. Decision matrices can hide value judgments behind numerical scores. FMEA can overlook common-cause failures, interactions, or hazards outside the team’s experience. Verification can be weak if test conditions do not represent actual use.

These limitations are managed through iterative review, explicit assumptions, sensitivity analysis, representative testing, independent safety assessment, and post-deployment monitoring. The objective is not to eliminate uncertainty, which is impossible, but to expose and control it.

Chapter Summary

Engineering design transforms stakeholder needs into traceable, measurable, and testable requirements. Functional decomposition separates what a system must do from the means used to do it and supports systematic concept generation. QFD links customer priorities to technical characteristics, while weighted decision matrices compare feasible concepts using explicit criteria and documented assumptions. Risk assessment and FMEA identify failure modes and guide preventive or protective actions; in the RPN equation, the detection rating represents the difficulty of detecting a failure. Verification confirms compliance with specifications, whereas validation confirms suitability for intended use. Effective design is iterative and must balance safety, usability, cost, reliability, sustainability, ethics, and regulatory obligations.

Key Terms

Stakeholder: Person or organization affected by, responsible for, or interested in a design.

Requirement: A documented need or condition that a design must satisfy.

Specification: A measurable technical statement used to define or control design performance.

Traceability: Ability to follow a requirement through design elements, tests, and evidence.

Verification: Confirmation that specified requirements have been satisfied.

Validation: Confirmation that the design meets intended user and operational needs.

Functional decomposition: Division of a system function into smaller subordinate functions.

Concept: A preliminary technical arrangement capable of satisfying requirements.

QFD: A structured method for translating customer needs into technical priorities.

House of Quality: A QFD matrix relating customer needs to engineering characteristics.

Decision matrix: A table that compares alternatives against weighted criteria.

Sensitivity analysis: Examination of how changes in assumptions or weights affect a decision.

FMEA: Failure Modes and Effects Analysis, a structured study of possible failures.

Failure mode: A specific way in which a component or function can fail.

RPN: Risk Priority Number calculated from severity, occurrence, and detection ratings.

Risk control: A design or procedural measure that reduces likelihood or consequence of harm.

Usability: The effectiveness, efficiency, and satisfaction with which users operate a system.

Life-cycle cost: Total cost incurred during acquisition, use, maintenance, and disposal.

Sustainability: Meeting present needs while limiting environmental, social, and resource impacts.

Configuration control: Management of identified versions and authorized design changes.

Review Questions

Short Answer Questions

  1. Why must stakeholder needs be translated into measurable requirements?
  2. Distinguish verification from validation.
  3. What is the purpose of functional decomposition?
  4. What does the detection rating represent in an RPN calculation?
  5. Why should hard constraints be screened before applying a weighted decision matrix?

Long Answer Questions

  1. Explain the complete process of developing requirements from stakeholder interviews, including traceability and verification attributes.
  2. Describe how QFD relates customer needs to engineering characteristics and discuss its limitations.
  3. Explain the construction and interpretation of a weighted decision matrix, including the danger of false precision.
  4. Describe FMEA and compare RPN-based prioritization with a broader risk-management approach.
  5. Discuss how safety, usability, cost, and sustainability can conflict during electrical-system design.

Analytical / Application Questions

  1. Develop a functional decomposition and three alternative concepts for a solar-powered remote electrical sensor. State at least five measurable requirements.
  2. Construct a weighted decision matrix for two battery-management architectures. Define the criteria, weights, rating scale, assumptions, and sensitivity of the final choice.
  3. For an industrial control panel, identify five failure modes, assign severity, occurrence, and detection-difficulty ratings, calculate RPN values, and recommend controls. Explain why the highest RPN should not automatically receive the first safety action.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes verification from validation?

A. Verification checks user satisfaction, while validation checks component cost.

B. Verification checks specified requirements, while validation checks intended use and stakeholder needs.

C. Verification occurs only after production, while validation occurs only before design.

D. Verification concerns safety only, while validation concerns performance only.

Correct Answer: B. Verification checks specified requirements, while validation checks intended use and stakeholder needs.

Question 2

In a weighted decision matrix, the weights should normally satisfy which condition?

A. Their sum equals zero.

B. Each weight must be greater than 5.

C. Their sum equals one when normalized.

D. All weights must be negative for cost criteria.

Correct Answer: C. Their sum equals one when normalized.

Question 3

Using the worked example, what is Concept A’s total score?

A. 3.50

B. 3.85

C. 3.95

D. 4.05

Correct Answer: C. 3.95

Question 4

In the RPN expression RPN = S × O × D, what does D represent?

A. Design duration

B. Detection rating or difficulty of detection

C. Delivered energy

D. Demand rating

Correct Answer: B. Detection rating or difficulty of detection

Question 5

Which QFD relationship score is commonly used for a strong relationship?

A. 0

B. 1

C. 3

D. 9

Correct Answer: D. 9

Question 6

Which activity is an example of functional decomposition?

A. Assigning a product selling price only

B. Dividing a monitoring system into sensing, processing, communication, and power functions

C. Selecting the highest-rated concept without screening

D. Replacing all requirements with sketches

Correct Answer: B. Dividing a monitoring system into sensing, processing, communication, and power functions

Question 7

If severity is 8, occurrence is 3, and detection difficulty is 6, what is the RPN?

A. 17

B. 48

C. 144

D. 384

Correct Answer: C. 144

Question 8

Which is normally a requirement attribute or compliance method rather than a requirement type?

A. Functional

B. Environmental

C. Verification method

D. Physical

Correct Answer: C. Verification method

Question 9

Why should a small difference between two decision-matrix totals be treated cautiously?

A. Weighted scores are always probabilities.

B. The difference may be smaller than uncertainty in ratings or weights.

C. The lower score is always preferable.

D. Decision matrices cannot compare more than one concept.

Correct Answer: B. The difference may be smaller than uncertainty in ratings or weights.

Question 10

Which action follows the preferred hierarchy of risk control most directly?

A. Eliminating the hazard through design

B. Adding a warning while leaving the hazard unchanged

C. Relying only on personal protective equipment

D. Ignoring low-frequency hazards

Correct Answer: A. Eliminating the hazard through design

Engineering Drawing & Design
Chapter 13 of 15