design-process

# Engineering Design Process

Engineering is not invention by accident. It is the disciplined, iterative transformation of a human need into a working solution that satisfies constraints. The engineering design process is the backbone of every engineered artifact, from a bridge to a microprocessor. This skill covers the full design cycle with worked examples, decision tools, and integration with the college engineering concept graph.

**Agent affinity:** brunel (integrated design vision), polya-e (pedagogical scaffolding)

**Concept IDs:** engr-design-cycle, engr-problem-definition, engr-ideation-techniques, engr-design-communication

## The Design Cycle at a Glance

| Phase | Purpose | Key outputs |
|---|---|---|
| 1. Define | Identify the need, stakeholders, and success criteria | Problem statement, stakeholder map |
| 2. Research | Understand existing solutions, physics, regulations | Literature review, prior art, standards list |
| 3. Specify | Translate the need into measurable requirements | Requirements document, constraint matrix |
| 4. Ideate | Generate multiple design alternatives | Sketches, morphological chart, concept variants |
| 5. Analyze | Evaluate alternatives against requirements | Pugh matrix, trade study, feasibility assessment |
| 6. Prototype | Build a testable representation of the chosen design | Physical or digital prototype |
| 7. Test | Measure prototype performance against specifications | Test reports, data analysis |
| 8. Iterate | Refine the design based on test results | Updated design, revised specifications |
| 9. Communicate | Document and present the final design | Engineering drawings, specifications, reports |

The cycle is not linear. Phases 4 through 8 repeat until the design meets all requirements or the project constraints (budget, schedule) force a decision. The critical discipline is knowing when to iterate and when to converge.

## Phase 1 -- Define the Problem

A well-defined problem is half-solved. Engineering problem definition translates a vague need ("we need a better bridge") into a precise engineering problem statement with measurable criteria.

**Template.** Design a [system/component] that [primary function] for [stakeholders] subject to [key constraints], measured by [success criteria].

**Worked example.** *Design a pedestrian bridge that spans a 30-meter river crossing for a rural community subject to a $200K budget and 12-month timeline, measured by load capacity (minimum 500 kg/m), deflection limits (L/360), and 50-year design life.*

**Common mistake.** Jumping to solutions before defining the problem. "We need a suspension bridge" is a solution, not a problem statement. The problem statement must be solution-neutral to preserve the design space.

### Stakeholder Analysis

Every engineering project has stakeholders beyond the end user. A bridge serves pedestrians but must also satisfy regulators, maintenance crews, the funding authority, and adjacent property owners. Missing a stakeholder leads to requirements gaps that surface late, when they are expensive to fix.

Map stakeholders using: **Who uses it? Who pays for it? Who maintains it? Who regulates it? Who is affected by it?**

## Phase 2 -- Research

Before generating new designs, understand what exists. Research covers:

- **Prior art:** What solutions exist for similar problems? What worked and what failed?
- **Physics and materials:** What physical principles govern the problem domain?
- **Standards and codes:** What regulatory requirements constrain the design?
- **Failure history:** What engineering failures in this domain provide lessons?

Research is not optional. Skipping it leads to reinventing known solutions or, worse, repeating known failures. The Hyatt Regency walkway collapse (1981) resulted from a design change that no one analyzed against structural principles -- a failure of research and review, not of engineering knowledge.

## Phase 3 -- Specify Requirements

Requirements are the contract between the problem and the solution. They must be:

- **Measurable:** "Strong enough" is not a requirement. "Withstand 500 kg/m distributed load with deflection less than L/360" is.
- **Testable:** Every requirement must have a corresponding test. If you cannot test it, you cannot verify it.
- **Traceable:** Each requirement links back to a stakeholder need and forward to a design feature.
- **Prioritized:** Must-have (the design fails without it) vs. should-have (the design is degraded without it) vs. nice-to-have (improvement, not essential).

### Functional vs. Non-Functional Requirements

| Type | Definition | Example |
|---|---|---|
| Functional | What the system must do | "The bridge shall support pedestrian traffic in both directions simultaneously" |
| Non-functional | How well the system must do it | "The bridge shall have a design life of 50 years with annual maintenance cost below $5K" |

### Constraint Matrix

Constraints are non-negotiable boundaries. They differ from requirements in that they cannot be traded off -- they are binary pass/fail.

| Constraint type | Example |
|---|---|
| Physical | Maximum span: 30 meters (river width) |
| Regulatory | Must comply with AASHTO pedestrian bridge standards |
| Budget | Total project cost shall not exceed $200K |
| Schedule | Construction complete within 12 months |
| Environmental | No permanent in-water structures (fish habitat protection) |

## Phase 4 -- Ideate

Generate multiple design alternatives before committing to one. The goal is divergent thinking -- quantity of concepts, not quality.

### Brainstorming Rules

1. **No evaluation during ideation.** Criticism kills creativity. Evaluate later.
2. **Build on others' ideas.** "Yes, and..." not "No, but..."
3. **Encourage wild ideas.** They often contain seeds of practical solutions.
4. **Go for quantity.** More concepts increase the probability of finding a good one.

### Morphological Chart

A morphological chart decomposes the design into independent su