Engineering MakingFrom "Make It Better" to a Real Problem Statement
Atlas the engineer-guide stands at a whiteboard in a bright makerspace, circling a vague sticky note and rewriting it into a measurable spec on one side, while pinning a constraints list beside the prototype on the other
- Distinguish a vague need from a precise engineering problem statement
- Write at least two measurable criteria with units for a given need
- Identify at least two constraints that limit acceptable solutions
- Convert one ill-defined request into a complete problem statement
Key terms
- Need
- A fuzzy, unmeasured desire for improvement that has not yet been sharpened into a solvable problem.
- Problem statement
- One precise sentence binding the user, the need, the criteria, and the constraints together.
- Criterion
- A measurable performance goal, stated with a number and unit, that a good solution should achieve.
- Constraint
- A hard external limit a solution must not cross, or it is automatically disqualified.
- Verification
- The act of proving with a test or measurement that a solution actually meets a stated criterion.
Why Vague Needs Cannot Be Engineered
Words like better, comfortable, or premium feel meaningful but cannot be tested, so two engineers reading the same brief will build to different targets and argue forever about whether the goal was met. Sharpening a need into measurable criteria does more than enable testing; it surfaces hidden disagreements early, when changing direction is cheap. A precise problem statement is therefore both a technical artifact and a contract that aligns the customer, the team, and the test plan around one shared definition of done.
Criteria Versus Constraints
Both criteria and constraints often use the word must, which is why they are easily confused, yet they play different roles. A criterion ranks how well competing solutions perform, so a lighter backpack scores better than a heavier one even when both are acceptable. A constraint is a pass-fail boundary: a backpack over the $40 budget is disqualified no matter how excellent it is otherwise. The diagnostic question is whether crossing the line eliminates the design (constraint) or merely lowers its score (criterion).
Making Every Goal Measurable
Each criterion needs a measurable quantity, a unit, and a verification method, because a goal you cannot measure is a goal you cannot honestly claim to have met. Convert lighter into weighs under 1.2 kg on a kitchen scale, and convert charges quickly into reaches 80 percent charge within 30 minutes measured by a battery tester. Specifying the verification method alongside the number forces you to confirm the goal is testable with the tools you actually have, which prevents writing criteria that sound rigorous but can never be checked.
Worked examples
Convert the vague need 'make a better water bottle for hikers' into a complete engineering problem statement.
- Identify the user and the core need: hikers who want a durable, leak-free bottle that is light to carry.
- Write measurable criteria with units: holds at least 750 mL, weighs under 150 g empty, survives a 1.5 m drop onto rock without leaking.
- Write hard constraints: costs under $25 to manufacture, uses only food-safe BPA-free materials.
- Classify each line by testing whether crossing it disqualifies the design (constraint) or lowers its score (criterion).
- Tie everything into one sentence binding user, need, criteria, and constraints.
Answer: Design a water bottle for hikers that holds at least 750 mL, weighs under 150 g empty, and survives a 1.5 m drop without leaking, while costing under $25 and using only food-safe BPA-free materials.
Activity
Sort each statement into Criterion (measurable goal), Constraint (hard limit), or Vague (needs a number)
Practice
Rewrite the vague need 'the classroom chair is uncomfortable' as a problem statement with two criteria and one constraint.
For a phone case project, classify three given requirements as criterion, constraint, or still-too-vague.
Common mistakes to avoid
- A criterion and a constraint mean the same thing.A criterion ranks how well a design performs, while a constraint is a hard boundary that disqualifies any design crossing it.
- A goal can be a criterion without a number.Until a goal has a measurable quantity and unit, it is still a vague need and cannot be tested or scored.
Check your understanding
Which of these is a properly stated CRITERION rather than a vague wish?
A team writes: "Build a phone case that is durable and looks great." What is the main problem with this as an engineering problem statement?
What is the key difference between a criterion and a constraint?
Which constraint correctly limits acceptable solutions for a school robot project?
Recap
Engineers convert a fuzzy need into a solvable problem by writing measurable criteria with numbers and units, identifying hard constraints that disqualify any violating design, and binding the user, need, criteria, and constraints into one precise problem statement. The test for a criterion is whether you can measure it; the test for a constraint is whether crossing it eliminates the design.
Reflect
Think of something you wish worked better and try to name one measurable criterion and one constraint for improving it.