2 Problem Definition and Engineering Problem Solving
Learn how to define an engineering problem around a real need, account for stakeholders and constraints, and check and revise the framing before developing designs.
Start with the
Engineering problem solving begins with a , not with choosing a device or design. A sound definition explains what must be met, whose it is, what limits apply, and how success will be judged. Framing the problem too narrowly or around a favored solution can lead to a technically functional result that does not address the real .
A describes the gap between a current situation and a desired outcome. For example, “students wait too long to receive lunch” states a , while “install another serving line” proposes a solution. Keeping the solution-neutral leaves room to consider and compare different approaches.
A useful definition clarifies the context in which the problem occurs; the scope and boundaries, including which systems, users, locations, and life-cycle stages are included or excluded; and the evidence that shows the problem exists and indicates its scale. It also makes assumptions and unknowns visible and describes the desired outcome.
Identify stakeholders
A is anyone affected by a project, interested in its outcome, or able to influence it. Stakeholders may include customers, direct users, operators, maintainers, owners, regulators, nearby communities, and people affected later by product disposal. Customers and users are not always the same: a buyer may set priorities, while users or maintainers experience day-to-day effects.
Identify stakeholders early and elicit their expectations, , and intended uses. Consider who will use, operate, maintain, pay for, approve, or be affected by a solution; who will provide essential information, resources, or access; and who may face risks or consequences if the project succeeds or fails.
Ask each group about its needs and priorities rather than assuming those priorities are identical. Expectations may conflict: users may want faster service while operators a manageable process with existing staff. Record conflicts and clarify who has authority to resolve trade-offs.
Set and
describe what a successful solution must accomplish or how well it must perform. They should be clear and, where possible, measurable and verifiable. For each proposed criterion, specify both a measure and a way to check it. “Reduce waiting” is vague; “reduce the median wait to no more than four minutes during the lunch period” is testable. The four-minute target is appropriate only if stakeholders agree that it is feasible and suitable for the project.
are limits that the solution must work within. They may include budget, schedule, available space, required interfaces, applicable rules, or operating conditions. describe desired performance; bound the acceptable design space. Identify separately, record their source, and determine whether they are fixed or negotiable. Legal or physical limits may be fixed, while a requested feature or initial budget may sometimes be reconsidered. Verify instead of treating every preference as an unchangeable limit.
For a school lunch-service problem, an illustrative is that students have too little time to eat because queues are long. Relevant stakeholders could include students, cafeteria staff, school administrators, and facilities staff. An illustrative criterion is a median wait of at most four minutes during lunch; illustrative are not extending the lunch period and staying within the approved budget and available serving area. These targets and limits must be checked with the people responsible for the actual project. An open question is whether the longest waits result from serving capacity, payment, menu choice, or another factor. Separating from helps prevent a preference from being mistaken for a hard boundary and makes trade-offs easier to discuss.
Frame the problem
Bring the , stakeholders, scope, , , and uncertainties together in a brief, solution-neutral framing. One useful question format is: “How might we improve [desired outcome] for [users] in [context], while respecting [key limits]?” The question should be specific enough to guide investigation but open enough not to imply a particular design.
For the school lunch example, a framing could be: “How might the school reduce students’ lunch-service waiting time during the existing lunch period, while meeting the agreed service target and operating within the approved budget and serving area?”
Review and revise the framing
Before developing concepts or requirements, review the framing with stakeholders. Check that it describes a real , includes relevant users and operating context, does not quietly prescribe a solution, and uses that can be evaluated. Also check whether are genuine, assumptions are visible, and conflicting priorities have been acknowledged.
Develop needs, goals, objectives, and before turning them into requirements or designs. As expectations are developed into requirements and designs, validate them and maintain traceability.
is iterative. Research or feedback may show that the initial was misidentified, a boundary was too narrow, or a success measure is unrealistic. Revising the framing is a normal part of engineering, not a failure to follow a plan.