Mechanical Engineering — Strand 5: Design and Development (Deep Study Notes)

From Need to Requirements: Framing the Design Problem

Engineering design starts long before you sketch a part. The earliest decisions—what problem you’re solving, for whom, and under what constraints—shape everything that follows. Many “bad designs” are not bad because the mechanism is wrong; they’re bad because the team solved the wrong problem or never translated a vague need into measurable targets.

Needs, stakeholders, and the design brief

A need is the underlying reason a product/system should exist (for example, “reduce operator fatigue when lifting boxes”). A stakeholder is anyone affected by the design—end users, maintenance technicians, manufacturers, regulators, purchasing, bystanders, and even future recyclers.

A design brief is a short, plain-language statement that captures:

• The problem context (where and how the design will be used)
• The user and operational environment
• Success criteria at a high level
• Non-negotiable constraints (budget ceiling, envelope size, safety rules)

Why this matters: a clear brief prevents “feature creep” (adding attractive but unnecessary features) and helps you resolve conflicts later. If two stakeholders disagree, you can return to the brief and the priority of needs.

Requirements vs. specifications (and why the difference matters)

Students often mix these up, but in real design reviews the distinction is critical.

• A requirement is a must-have condition the design must satisfy. Requirements can be functional (“must lift a load”), performance-based (“must lift within a time”), or compliance-based (“must meet a safety standard”).
• A specification is a measurable, testable statement—often including a target value and allowable tolerance—that you can verify by inspection, analysis, or test.

A helpful way to think about it:

• Requirement: “The device must be portable.”
• Specification: “Total mass shall be less than $12\,kg$ and the largest dimension shall be less than $600\,mm$.”

Specifications matter because they make verification possible. If you can’t test it, you can’t confidently claim you met it.

Constraints vs. criteria

Another common confusion is between constraints and criteria.

• A constraint is a hard limit (must not exceed). Examples: maximum voltage, legal limits, fixed mounting interface, maximum cost.
• A criterion is something you want to optimize or score well on, often with trade-offs. Examples: lower mass is better, quieter is better, easier assembly is better.

In concept selection you often score criteria, but you filter out concepts that violate constraints.

Translating user needs into engineering metrics

A major design skill is translating subjective language into measurable quantities:

• “Easy to use” might translate to maximum number of steps, maximum force on a handle, or maximum training time.
• “Durable” might translate to a fatigue life, corrosion resistance targets, allowable wear, or drop-test survival.
• “Safe” might translate to maximum surface temperature, guarded pinch points, and compliance with relevant safety standards.

One structured tool used in industry is Quality Function Deployment (QFD), often represented as a “House of Quality.” The idea is to map:

• Customer/stakeholder needs (“WHATs”)
• Engineering characteristics (“HOWs”)
• Relationships between them (strong/moderate/weak)
• Competitive benchmarks (how current solutions perform)

Even if you don’t draw the full chart, the mindset is valuable: you’re continuously asking, “Which measurable engineering variables truly drive what the user cares about?”

Verification methods: inspection, analysis, and test

When you write a specification, you should already know how you’ll verify it:

• Inspection: measure dimensions, check materials, confirm labeling.
• Analysis: calculations or simulation (stress, deflection, thermal, flow).
• Test: physical experiment (load test, endurance test, environmental test).

A frequent mistake is writing specs that imply a test method you cannot perform (no equipment, too expensive, or unsafe). A strong designer writes specs that are ambitious and realistically verifiable.

Worked example: turning a vague brief into specs

Suppose the brief is: “Design a small hoist to lift a component for bench assembly.”

You interview stakeholders and learn:

• Load to lift: up to $30\,kg$
• Lift height: $0.6\,m$
• Operator: one person
• Power available: standard wall outlet (but they prefer manual if possible)
• Space: must fit on a bench footprint

You can convert this into initial specifications:

• Rated load: at least $30\,kg$ (often you’d add margin, e.g., design for $40\,kg$)
• Minimum lift height: $0.6\,m$
• Maximum footprint: for example, $600\,mm \times 400\,mm$
• Maximum operating effort (manual): for example, handle force less than $150\,N$
• Safety: include load-holding mechanism so load does not drop during power loss

Notice how each item is measurable and suggests a verification method.

Exam Focus

• Typical question patterns:
  • Given a scenario, identify stakeholders, constraints, and success criteria.
  • Convert qualitative needs into measurable specifications and propose verification methods.
  • Distinguish requirements vs. specifications and constraints vs. criteria.
• Common mistakes:
  • Writing specs that are not measurable (e.g., “high quality,” “user-friendly”) without metrics.
  • Missing non-user stakeholders (manufacturing, maintenance, safety regulators).
  • Treating “nice-to-have” criteria as hard constraints, which over-restricts solutions.

Concept Generation: Creating Options Before You Choose

Good design rarely comes from the first idea. Concept generation is about creating a range of feasible solutions, then refining. If you jump to a single concept too early, you risk optimizing the wrong architecture.

Functional thinking: what must the system do?

A powerful way to start is functional decomposition—describe the system in terms of functions rather than parts. For a lifting device, key functions might include:

• Support load
• Convert input effort into lifting motion
• Guide motion safely
• Hold position when released
• Communicate state (loaded/unloaded, locked/unlocked)

Why this matters: functions are stable even when the physical solution changes. “Convert effort into motion” could be a screw, pulley, hydraulic cylinder, or motor and gearbox.

A common output is a simple function diagram showing energy/material/signal flows. You don’t need fancy notation—the goal is to reveal what must happen and where interfaces occur.

Idea generation methods (and when each helps)

Different methods help you break “design fixation” (repeating what you already know).

• Brainstorming: best early, when you need breadth. Rules: defer judgment, build on ideas, seek quantity.
• Morphological chart: list sub-functions and multiple ways to achieve each, then combine into full concepts. This method is excellent for creating combinations you wouldn’t otherwise consider.
• Analogies and biomimicry: borrow ideas from other domains (e.g., ratchet mechanisms, tendon-like cable routing).
• TRIZ-style prompts (inventive principles): useful when requirements conflict (lightweight but strong, rigid but adjustable). Even without formal TRIZ, deliberately searching for contradiction-breaking ideas is valuable.

Feasibility screens: eliminate concepts that cannot work

Before detailed scoring, you typically do a concept screen:

• Does it violate any constraints (size, safety, budget)?
• Is it physically feasible with known principles?
• Can it be manufactured and assembled with available processes?

This stage prevents you from spending time comparing options that are dead-on-arrival.

Concept selection with decision matrices

When multiple feasible concepts exist, a weighted decision matrix (often called a Pugh matrix or scoring matrix) helps make trade-offs explicit.

How it works (step-by-step):

1. Define criteria (mass, cost, safety, ease of use, manufacturability, reliability).
2. Assign weights to criteria based on importance (weights should reflect stakeholder priorities).
3. Score each concept against each criterion using a consistent scale.
4. Multiply scores by weights and sum.
5. Perform a sensitivity check—if small changes in weights flip the outcome, you may need more data or a prototype.

Why this matters: matrices don’t “decide” for you—they force you to state assumptions clearly. The best teams use them to support discussion, not replace it.

Worked example: simple concept scoring (with a warning)

You have three lifting concepts:

• A: hand-crank screw jack
• B: block-and-tackle pulley
• C: electric winch

Criteria and weights (example): safety $0.35$, ease of use $0.25$, cost $0.20$, manufacturability $0.20$.

You score each from $1$ (poor) to $5$ (excellent). Suppose the winch scores high on ease of use but lower on cost and manufacturability.

The key learning isn’t the arithmetic—it’s recognizing why the winch costs more (motor, controls, guarding, compliance testing) and what risks it brings (pinch points, power failure behavior). A matrix that ignores these mechanisms can lead to a superficially “best” but practically risky choice.

What goes wrong: false precision and biased scoring

Decision matrices can fail when:

• Scores are guesses presented as facts.
• The team chooses weights to justify a favorite concept.
• Criteria overlap (double-counting). For example, “low cost” and “simple manufacturing” may strongly correlate.

A good habit is to record the justification for each score (one sentence is enough). That turns the matrix into a traceable argument.

Exam Focus

• Typical question patterns:
  • Generate multiple concepts from a functional description (often requiring at least three distinct approaches).
  • Use a decision matrix to justify a chosen concept given criteria and weights.
  • Explain trade-offs between concepts (why one scores higher on manufacturability but lower on performance).
• Common mistakes:
  • Producing “three concepts” that are actually the same concept with minor cosmetic differences.
  • Scoring without defining what the scale means (what makes something a $5$?).
  • Forgetting to screen for constraints first—then picking a concept that violates a hard limit.

Embodiment Design: Turning a Concept into a Workable Mechanical System

Once you pick a concept, you enter embodiment design—deciding the physical layout, key mechanisms, materials, and interfaces. This stage is where mechanical engineering becomes very concrete: loads, stresses, motion, tolerances, and safety features.

Architecture, interfaces, and load paths

A mechanical design must have a clear load path—how forces travel from the applied load to supports and into the structure. If you can’t describe the load path, you can’t confidently size components.

Interfaces are equally important:

• How does the device mount to its environment?
• How are forces transmitted between parts (bolts, pins, keys, splines, friction clamps)?
• How will it be assembled and serviced?

Many failures happen at interfaces (bolted joints loosening, pins wearing, misalignment causing bending) rather than in the “main body.”

Materials selection: properties, not labels

Material choice is not “steel vs. aluminum” in the abstract; it’s choosing properties that match failure modes and environment.

Key property families:

• Strength (yield/ultimate) for static failure prevention
• Stiffness (elastic modulus) for deflection control
• Toughness for impact resistance
• Fatigue strength for cyclic loading
• Corrosion resistance for environment
• Density for mass constraints
• Manufacturability (weldability, machinability, formability)

Why this matters: two materials can have similar strength but very different stiffness, cost, corrosion behavior, and fatigue performance.

Safety factors and design allowables

Real loads and material properties vary. A factor of safety accounts for uncertainties and consequences of failure.

A common definition is:

$n = \frac{\sigma_{\text{allow}}}{\sigma_{\text{max}}}$

where $\sigma_{\text{max}}$ is the maximum expected stress in service and $\sigma_{\text{allow}}$ is an allowable stress (often based on yield strength divided by a code factor).

Why it matters: choosing $n$ is not just math—it’s a risk decision. Higher consequence of failure (lifting devices, medical devices) typically demands larger margins and stricter verification.

Core sizing calculations (what they mean, not just how to plug in)

Even when you use simulation, you should understand the “first-principles” relationships.

Axial stress

If a member carries a tensile or compressive force through its cross-section, the average normal stress is:

$\sigma = \frac{F}{A}$

• $F$ is axial force
• $A$ is cross-sectional area

This equation is simple, but misused when the member is actually bending or when stress concentrations dominate (holes, sharp corners).

Bending stress (conceptual)

In bending, stress varies across the thickness: one side in tension, the other in compression. The classic relationship used for beams is:

$\sigma = \frac{M y}{I}$

• $M$ is bending moment at the section
• $y$ is distance from the neutral axis
• $I$ is second moment of area

The key understanding: changing geometry often improves stiffness/strength more effectively than changing material. For example, increasing section depth can dramatically increase $I$.

Deflection and stiffness

Design isn’t only about “not breaking.” Excess deflection can ruin function (misalignment, poor user feel, seal leakage). A common cantilever case (end load) is:

$\delta = \frac{F L^3}{3 E I}$

• $\delta$ is end deflection
• $L$ is length
• $E$ is elastic modulus

This shows why long, slender parts feel “springy” even if they are strong enough.

Tolerances, fits, and why manufacturing variability is a design issue

No manufacturing process makes perfect dimensions. Tolerance is the allowed dimensional variation. A design with unrealistic tolerances becomes expensive or impossible to manufacture.

Two key ideas:

• Function drives tolerance: specify tight tolerances only where they control performance (alignment, sealing, bearing fits).
• Tolerance stack-up: multiple parts in an assembly accumulate variation.

A simple worst-case stack-up adds absolute tolerances. If total length is:

$L_{\text{total}} = L_1 + L_2 + L_3$

then worst-case tolerance is:

$T_{\text{total}} = T_1 + T_2 + T_3$

This is conservative but safe. Statistical methods (root-sum-square) exist, but you should only use them when variability is well-characterized and independence assumptions are justified.

Worked example: sizing a simple tension member

You need a steel tie rod to carry $F = 8\,kN$ in tension. You choose an allowable stress $\sigma_{\text{allow}} = 80\,MPa$ (based on material and safety considerations).

1. Use the axial stress relationship:

$\sigma = \frac{F}{A}$

2. Rearrange for area:

$A = \frac{F}{\sigma_{\text{allow}}}$

3. Substitute values (convert units consistently):

$F = 8\,kN = 8000\,N$

$\sigma_{\text{allow}} = 80\,MPa = 80 \times 10^6\,Pa$

$A = \frac{8000}{80 \times 10^6} = 1.0 \times 10^{-4}\,m^2$

4. Convert to $mm^2$ for intuition:

$1.0 \times 10^{-4}\,m^2 = 100\,mm^2$

So you need at least $100\,mm^2$ of tensile area. If you use a circular rod, $A = \frac{\pi d^2}{4}$, so:

$d = \sqrt{\frac{4A}{\pi}} = \sqrt{\frac{4 \times 100}{\pi}} \approx 11.3\,mm$

In practice, you would choose a standard size above this (and consider threads, stress concentrations at shoulders, fatigue, and corrosion).

What goes wrong: ignoring stress concentrations and real load cases

Two frequent pitfalls:

• Stress concentrations: holes, sharp corners, keyways, and threads raise local stress beyond average formulas.
• Unexpected loading: off-axis loads introduce bending; dynamic loads increase peak forces; assembly preload changes joint forces.

A good embodiment design includes fillets, avoids abrupt section changes, and anticipates misuse or off-nominal conditions.

Exam Focus

• Typical question patterns:
  • Identify load paths and likely failure locations in a mechanism or structure.
  • Perform basic sizing using stress/deflection relationships and justify a safety factor.
  • Explain how tolerances and fits affect assembly and function.
• Common mistakes:
  • Using $\sigma = \frac{F}{A}$ when the part is actually bending-dominated.
  • Choosing a safety factor without explaining uncertainty/consequence.
  • Applying tight tolerances everywhere “to be safe,” which increases cost and may still not improve function.

Modeling and Analysis: Using Calculations and Simulation Wisely

Mechanical design decisions should be supported by analysis, but analysis is only as good as its assumptions. The goal is not to “get a colorful plot”—it’s to predict real behavior sufficiently well to make decisions.

Hand calculations vs. computer-aided engineering (CAE)

You can think of analysis tools in layers:

• Hand calculations: fast, transparent, ideal for early sizing and sanity checks.
• Spreadsheet models: structured parametric studies (change thickness, see mass/stress effect).
• Finite Element Analysis (FEA) and other simulations: detailed stress/deflection/thermal predictions for complex geometry and loading.

Why this matters: FEA can produce precise-looking numbers that are wrong if boundary conditions or mesh quality are poor. Hand calculations keep you honest.

CAD as a design communication tool (not just geometry)

Computer-Aided Design (CAD) models do more than represent shape. In professional workflows they support:

• Assembly relationships and motion checks
• Interference detection (parts colliding)
• Mass properties (center of mass, inertia)
• Drawing generation and tolerancing
• Bills of materials (BOMs)

A common novice mistake is treating CAD as the design itself. The CAD model is a representation of decisions about function, manufacturing, and assembly.

The basic workflow of FEA (conceptually)

Even if you never run FEA yourself, you should understand what the tool is doing.

1. Pre-processing: clean geometry, define materials, apply loads and boundary conditions.
2. Meshing: divide geometry into small elements. Smaller elements can capture gradients better but increase computation.
3. Solving: compute displacements, then derive strain/stress from displacement fields.
4. Post-processing: interpret results—identify hotspots, check deflections, compare to allowables.

The hardest part is step 1, not step 3. Real-world loads and constraints are rarely obvious.

Boundary conditions: the source of many wrong answers

A boundary condition is how you represent supports and connections. Over-constraining a model (making a surface “fully fixed” when it’s actually compliant) can artificially reduce deflections and distort stress.

A good habit is to ask:

• What physically prevents translation/rotation?
• Is that restraint stiff or flexible?
• Is the connection closer to a pin, a clamp, or a spring?

If you don’t know, build sensitivity checks—run multiple plausible boundary conditions and see whether conclusions change.

Verification and validation (V&V)

These two terms are often used casually, but they mean different things:

• Verification: did you solve the equations correctly? (mesh convergence, correct units, correct setup)
• Validation: are you solving the right equations for the real world? (does simulation match experiments?)

A robust design process often uses both: verify the model numerically, then validate at least one key case with a physical test.

Worked example: a sanity-check loop for a bracket

Suppose you simulate a bracket and FEA reports maximum stress $\sigma_{\text{FEA}} = 40\,MPa$ under a load $F = 1000\,N$.

A sanity-check approach:

• Compute average stress in the narrowest cross-section using $\sigma = \frac{F}{A}$. If your average estimate is, say, $5\,MPa$, a peak of $40\,MPa$ might be plausible if there’s a notch or fillet region.
• Double the mesh density near the hotspot and see whether peak stress stabilizes. If the peak keeps increasing without convergence, you may be observing a numerical singularity (common at sharp corners or point loads).
• Check whether the load was applied as a point force (unrealistic) rather than distributed over an area.

This loop is less about getting a single “right” number and more about building confidence that the model represents reality.

What goes wrong: chasing peak stress without understanding it

Students often panic at the maximum stress shown by FEA. But peak stress can come from:

• A sharp corner that would be filleted in manufacturing
• A point load or point constraint (nonphysical)
• A local contact artifact

Engineering judgment is distinguishing between a real failure risk and a modeling artifact. You generally care about stresses over physically meaningful regions and whether changes in geometry/load modeling change the conclusion.

Exam Focus

• Typical question patterns:
  • Explain when to use hand calculations vs. simulation and what each contributes.
  • Identify likely boundary condition errors in a described simulation setup.
  • Interpret analysis results: stress hotspots, deflection limits, and design changes.
• Common mistakes:
  • Treating simulation outputs as automatically correct without checking assumptions or units.
  • Using unrealistic constraints (fully fixed where a joint should rotate).
  • Ignoring deflection/functional failure while focusing only on “stress below yield.”

Prototyping and Testing: Learning Fast and Reducing Risk

Prototypes are not just for showing a final product. In a strong design process, prototypes are learning tools—built to answer specific questions and reduce uncertainty.

Types of prototypes (and what each is for)

Different prototypes serve different goals:

• Proof-of-concept prototype: demonstrates the core physical principle works (often crude).
• Form and fit prototype: checks size, ergonomics, clearances, and assembly access.
• Functional prototype: operates like the intended product to test performance.
• Production-representative prototype: built with near-final materials and processes to validate manufacturing and reliability.

Why this matters: building a production-level prototype too early wastes time and money. Building only crude prototypes can miss manufacturing and durability issues.

Test planning: what question is the test answering?

A good test plan starts with a hypothesis tied to a requirement/specification.

For each test, you should be able to state:

• The requirement/spec being verified
• The test setup and instrumentation
• The loading profile (static, cyclic, impact)
• Acceptance criteria (pass/fail thresholds)
• Data to record and how you’ll analyze it

A common student error is running tests that produce lots of data but don’t answer a decision-critical question.

Measurement, uncertainty, and repeatability (conceptual)

All measurements have uncertainty—from instrument resolution, calibration, human reading, and environmental effects.

Two key ideas:

• Repeatability: do you get similar results when repeating under identical conditions?
• Reproducibility: do different operators or setups produce consistent results?

If a test result is close to the pass/fail threshold, uncertainty becomes a design issue—you may need better measurement, larger margins, or redesigned acceptance criteria.

Design of Experiments (DOE) mindset: vary factors deliberately

You don’t need advanced statistics to use the DOE mindset. The core idea is: change one or more factors (material, thickness, speed, lubrication) deliberately to see their effect on a response (force, temperature, wear rate).

Even a simple factorial approach (testing high/low levels of two factors) can reveal interactions that “one-factor-at-a-time” testing misses.

Worked example: turning a performance spec into a test

Spec: “Handle force shall be less than $150\,N$ while lifting $30\,kg$ at steady speed.”

A practical test:

• Load the device with $30\,kg$.
• Use a force gauge inline with the handle or at the grip point.
• Lift at a defined speed (or define “steady” as constant angular speed).
• Record peak and average handle force over several lifts.

Acceptance: measured force less than $150\,N$ for all trials (or define a statistically justified acceptance rule if appropriate).

What you learn: if force spikes occur at startup, you may need better bearings, lubrication, or a different mechanical advantage.

Failure testing and root cause thinking

When prototypes fail, the goal is not “replace the broken part.” The goal is to identify the failure mode:

• Overload yielding?
• Fatigue crack initiation at a notch?
• Wear leading to backlash?
• Fastener loosening?
• Thermal softening?

Root cause methods like “5 Whys” help you avoid superficial fixes. For example, a bolt loosening problem might be caused by vibration, insufficient preload, joint slip, poor surface finish, or wrong locking method.

Exam Focus

• Typical question patterns:
  • Choose the appropriate prototype type for a given design stage and learning goal.
  • Design a test plan that verifies a stated specification.
  • Interpret test results and propose design iterations.
• Common mistakes:
  • Building prototypes without a clear question to answer.
  • Confusing a demonstration with verification (a single successful run is not necessarily proof).
  • Ignoring measurement uncertainty—especially when results are near acceptance limits.

Design for Manufacture, Assembly, and Lifecycle (DFMA + Lifecycle Thinking)

A design that works in CAD but cannot be produced reliably is not a successful engineering design. DFMA is about designing so that manufacturing and assembly are straightforward, robust, and cost-effective—without sacrificing performance.

Design for Manufacture (DFM): choose shapes that match processes

Different processes “like” different geometries:

• Machining can make precise prismatic shapes but complex internal cavities may be difficult.
• Casting can create complex shapes but needs draft angles and careful thickness transitions.
• Sheet metal favors uniform thickness and bends with appropriate radii.
• Additive manufacturing can create complex internal geometry but may have surface finish limitations and anisotropic properties.

Why this matters: if you design without process awareness, you may specify impossible features (tool cannot reach, draft impossible, tolerances unrealistic) or end up with high cost.

Design for Assembly (DFA): reduce parts and simplify joining

Assembly cost is often driven by part count and handling difficulty. DFA principles include:

• Reduce the number of unique parts (especially small fasteners).
• Use self-locating features (chamfers, pilots) to prevent misalignment.
• Design parts to be symmetric or clearly keyed to prevent wrong orientation.
• Prefer fastening strategies that are quick and robust (but balanced against serviceability needs).

A classic misconception is “fewer parts is always better.” Sometimes additional parts improve serviceability, modularity, or safety. DFA is about minimizing complexity consistent with lifecycle needs.

Tolerancing as a cost lever

Tight tolerances increase cost because they require:

• More precise processes
• More inspection
• More scrap/rework

A good design places tight tolerances only on critical interfaces—like bearing seats or sealing surfaces—while leaving non-critical dimensions looser.

Standard components and design reuse

Using standard bearings, fasteners, seals, and profiles reduces risk and cost. Standards exist because they encode proven geometry and manufacturing knowledge. Even when you design custom parts, designing around standard components improves supply chain reliability.

Reliability and maintainability

Lifecycle thinking includes:

• Reliability: how likely the system is to perform its function over time.
• Maintainability: how easily it can be inspected, serviced, or repaired.

Design choices that improve maintainability:

• Provide access to wear parts.
• Use modular subassemblies.
• Include alignment features that make reassembly consistent.
• Make inspection points visible.

Sustainability and end-of-life

Increasingly, designs must consider environmental impact:

• Material choice (recyclability, embodied energy)
• Longevity and repairability
• Minimizing waste in manufacturing
• Designing for disassembly (separating materials, avoiding permanent bonds where recycling is needed)

A common error is assuming sustainability only means “use less material.” Sometimes a slightly heavier part that lasts twice as long has lower overall impact.

Worked example: DFA reasoning on a simple enclosure

Suppose an enclosure uses $12$ screws plus separate washers. A DFA improvement might be:

• Switch to captive screws (washers integrated) or a snap-fit where appropriate.
• Add alignment bosses so the cover self-locates, reducing assembly time and cross-threading risk.

You’re not just “saving screws”—you’re reducing assembly steps, tool changes, and variability.

Exam Focus

• Typical question patterns:
  • Given a part geometry and manufacturing method, identify DFM issues (draft, undercuts, tool access, thickness changes).
  • Propose DFA improvements that reduce assembly time and error.
  • Explain how tolerances affect cost and assembly yield.
• Common mistakes:
  • Selecting a manufacturing process after finalizing geometry (process should influence geometry early).
  • Over-tolerancing: specifying tight tolerances globally rather than functionally.
  • Ignoring service/maintenance needs while minimizing part count.

Managing the Development Process: Planning, Risk, and Design Control

Design and development is a project as well as a technical activity. Many real failures come from schedule pressure, uncontrolled changes, and weak documentation rather than poor physics.

Iterative development and stage-gate thinking

Design is inherently iterative: you propose, analyze, prototype, test, learn, and revise. Many organizations structure iterations with stage-gates—formal review points where you must show evidence (requirements met, risks reduced) before moving forward.

Common gate deliverables include:

• Requirements/specification document
• Concept selection rationale
• Preliminary analysis and risk assessment
• Prototype test results
• Updated drawings/BOM

Why this matters: gates prevent “late surprises,” where manufacturability or safety issues appear after commitments are made.

Scheduling and resource planning (conceptual)

Tools like Gantt charts help you track dependencies:

• You can’t run a load test before the prototype is built.
• You can’t release drawings before design review.
• You can’t finalize tolerances without process capability knowledge.

The key skill isn’t drawing the chart—it’s identifying the true critical path and building time for iteration.

Risk management and FMEA

Risk management is systematic identification and mitigation of what could go wrong. A widely used tool is Failure Modes and Effects Analysis (FMEA).

FMEA mindset:

• Identify failure modes (how a function could fail).
• Identify effects (what happens if it fails).
• Identify causes (why it would fail).
• Identify controls (how you prevent/detect it).

Even without the full scoring system, the structured thinking helps you prioritize design effort. For example, in a lifting device, “load drops unexpectedly” is high severity, so you prioritize redundant load-holding features and rigorous testing.

Configuration control: managing changes without chaos

As designs evolve, you need revision control:

• Drawings and CAD models must have versions.
• Bills of materials must match released drawings.
• Changes should be documented with an engineering change request/order.

Without this, teams end up manufacturing from outdated files or assembling mismatched revisions—leading to expensive rework and safety risks.

Design reviews: technical communication under scrutiny

Design reviews force you to justify decisions using evidence. Effective review artifacts include:

• Clear drawings with critical dimensions identified
• Requirements traceability (which design features satisfy which specs)
• Key calculations and assumptions
• Test results and what was learned

A common misconception is that reviews are “presentations.” In engineering, they are structured critiques aimed at finding problems early.

Worked example: turning a test failure into a controlled design change

Suppose a prototype fails a fatigue test due to a crack at a sharp internal corner.

A controlled process:

1. Document failure location, load history, and observations.
2. Propose design change: add fillet radius and adjust thickness.
3. Update CAD and drawing revision.
4. Re-run analysis and/or targeted test.
5. Record results and close the risk item.

This approach prevents the “quiet fix” problem—where a change is made informally and later nobody knows why the geometry differs.

Exam Focus

• Typical question patterns:
  • Describe an iterative design process and justify when to revisit earlier stages.
  • Identify major risks in a development scenario and propose mitigations.
  • Explain why documentation and revision control matter for safety and quality.
• Common mistakes:
  • Treating iteration as “mistakes” rather than planned learning cycles.
  • Listing risks without linking them to mitigation actions or verification.
  • Making changes without updating drawings/BOM and tracking revisions.

Professional, Ethical, and Legal Responsibilities in Design and Development

Mechanical designs affect safety, finances, and the environment. Engineers have responsibilities that go beyond making something that works once in a lab.

Safety and duty of care

A designer should assume real users may:

• Misuse the product in predictable ways
• Skip instructions
• Operate under fatigue or distraction

This is why safety features often include:

• Guarding (prevent access to pinch points)
• Fail-safe behavior (safe state if power is lost)
• Redundancy for high-consequence functions
• Clear labeling and instructions

In high-risk systems, safety is not a “feature”—it is a fundamental requirement that shapes architecture choices.

Standards, codes, and compliance (conceptual)

Many products must comply with standards or regulations (for example, machine guarding, pressure equipment, electrical safety). The key learning is not memorizing specific code numbers, but understanding that:

• Compliance can impose design constraints (materials, testing, documentation).
• Standards often define verification tests and acceptance criteria.
• Designing to standards reduces liability and improves interoperability.

A common student error is treating standards as optional. In professional practice, ignoring applicable standards can make a design unusable regardless of performance.

Intellectual property (IP) basics

Design and development can create IP with business value:

• Patents protect novel and non-obvious inventions (functional ideas and implementations).
• Trademarks protect brand identifiers.
• Copyright protects original creative works (drawings/text), though functional aspects are generally not protected the same way.
• Trade secrets protect confidential know-how if it is kept secret.

Why this matters: engineers must respect others’ IP and protect their organization’s IP through documentation, disclosures, and confidentiality.

Ethics: honesty in data and claims

Engineering ethics includes:

• Reporting test results accurately (including failures and uncertainty)
• Not cherry-picking data to “pass” a design
• Being transparent about assumptions in analysis
• Escalating safety concerns even when inconvenient

A frequent pitfall is unintentional self-deception: if you “need” a result to be true for schedule reasons, you may unconsciously overlook contradictory evidence. Good processes (peer review, traceable documentation) protect against this.

Worked example: ethical reporting of a borderline test

Suppose a device must withstand $5000$ cycles, and your prototype fails at $4800$ cycles. An unethical response is to rerun until you get a passing result and report only that. An ethical response is to report all trials, investigate variability, and either redesign for margin or revise claims/specifications through proper channels.

Exam Focus

• Typical question patterns:
  • Identify ethical issues in a scenario (data integrity, safety shortcuts, misrepresentation).
  • Explain how standards/regulations affect design choices and testing.
  • Describe IP types and what design outputs they can protect.
• Common mistakes:
  • Treating compliance as “paperwork” rather than a design constraint.
  • Assuming one successful test demonstrates safety or reliability.
  • Confusing patents (functional invention) with copyright (expression of an idea).