Learning by Patterns | Engineering | Pattern 01: Define the Problem Before Designing the Solution

Executive Summary

Engineering does not begin with a solution. It begins with a need that must be understood and translated into a clear, testable problem.

This becomes even more important when engineers work with AI. AI can generate designs, calculations, code, simulations, and alternatives quickly—but it can also solve the wrong problem convincingly when the context, requirements, or constraints are incomplete.

Engineering Pattern 01 is therefore:

Define the problem before designing the solution.

The practical sequence is:

Need → Stakeholders → Context → Requirements → Constraints → Success Criteria → Problem Definition → Solution Options

This pattern helps engineering students resist premature solution-making, use AI more purposefully, and produce designs that address real needs under real constraints.

---

Position Statement

In AI-enabled engineering, the quality of a solution depends not only on the intelligence used to generate it, but also on the quality of the problem definition guiding it.

AI increases the speed at which possible solutions can be produced. It does not automatically determine:

• Whose problem matters

• What outcome is actually required

• Which constraints must be respected

• What trade-offs are acceptable

• How success will be measured

• What risks or consequences must be considered

These remain engineering responsibilities.

The purpose of this first pattern is to help learners move from an unclear request to an evidence-based engineering problem definition before asking AI—or anyone else—to design a solution.

---

The Common Mistake: Starting with the Solution

Imagine that a college experiences water shortages in one of its buildings.

A student immediately proposes:

“We need a larger water pump.”

AI could quickly help the student:

• Select a pump

• Calculate capacity

• Compare suppliers

• Estimate energy consumption

• Create a maintenance schedule

• Draft an installation plan

But the actual problem may not be inadequate pumping capacity.

The cause could be:

• Leakage

• Irregular water supply

• Insufficient storage

• Poor pressure regulation

• Excessive consumption

• Faulty sensors

• Incorrect pipe sizing

• Operational practices

• A combination of several causes

A technically impressive pump design may therefore solve the wrong problem, increase energy use, raise costs, or create another failure elsewhere in the system.

The better starting question is:

What outcome is required, for whom, under which conditions—and what evidence shows that the present system is not achieving it?

---

Why This Is an Engineering Pattern

ABET defines engineering design as a process of creating a system, component, or process that meets needs within constraints. Its current engineering accreditation criteria also recognise that complex engineering problems may involve conflicting technical issues, multiple disciplines, several interacting components, no obvious solution, or significant consequences. (ABET, 2025–2026)

NASA’s systems-engineering guidance similarly begins with stakeholder expectations and technical requirements. It warns that engineers who misunderstand requirements risk implementing an unwanted solution based on the wrong interpretation. NASA therefore treats communication, validation, and iteration with stakeholders as essential parts of problem and requirements definition. (NASA Systems Engineering Handbook: System Design Processes)

The evidence supports three important principles:

1. Engineering problems begin with needs and stakeholder expectations.

2. Needs must be translated into clear and verifiable requirements.

3. Problem definition is iterative and may improve as evidence becomes available.

“Define before designing” does not mean that the problem statement can never change. It means that engineers should establish a sufficiently clear and testable definition before committing substantial effort to a solution—and continue refining it as they learn.

---

The Pattern

Pattern name

Define the Problem Before Designing the Solution

Purpose

To prevent premature solution-making and ensure that engineering effort addresses a real, relevant, and sufficiently understood need.

Signal

Activate this pattern when:

• Someone requests a new product, system, feature, or process

• A failure or performance gap is reported

• A team immediately begins discussing solutions

• An AI tool is asked to “design,” “optimise,” or “build” something

• Stakeholders describe the problem differently

• Requirements are vague or conflicting

• Success has not been defined

• Important constraints remain unknown

Core structure

Observed Situation + Stakeholder Need + Desired Outcome + Requirements + Constraints + Evidence + Success Measures = Engineering Problem Definition

---

The Engineering Problem Definition Sequence

1. Identify the need

Begin with what is happening and why attention is required.

Ask:

• What is the observed situation?

• What is not working as expected?

• What opportunity could be realised?

• What evidence shows that action is necessary?

• Is the request describing a need—or merely suggesting a solution?

“Install a larger pump” is a proposed solution.

“Maintain adequate water availability and pressure during peak demand” is closer to a need.

2. Identify the stakeholders

A system can affect more people than its immediate user.

Stakeholders may include:

• Users

• Customers

• Operators

• Maintenance personnel

• Owners

• Regulators

• Suppliers

• Nearby communities

• People affected by safety or environmental consequences

Different stakeholders may have different definitions of success. An operator may value reliability, the owner may prioritise cost, and users may care most about availability and ease of use.

INCOSE describes systems engineering as an integrative approach spanning the successful realisation, use, and retirement of engineered systems. This lifecycle view makes stakeholder identification important beyond the initial design stage. (INCOSE: About Systems Engineering)

3. Understand the context

The same apparent problem may require different solutions under different conditions.

Study:

• Where and when the problem occurs

• Frequency and duration

• Operating environment

• Existing system and interfaces

• Usage patterns

• Previous interventions

• Available data

• Applicable standards

• Social and environmental conditions

Context prevents a generic solution from being mistaken for an appropriate one.

4. Separate symptoms from possible causes

A symptom is what is observed.

A cause explains why it is happening.

For example:

• Symptom: A motor repeatedly overheats.

• Possible causes: Excessive load, inadequate cooling, incorrect voltage, poor lubrication, misalignment, or control failure.

Do not accept the first explanation simply because it sounds plausible. Generate competing hypotheses and test them against evidence.

AI can assist by suggesting possible causes, but these remain hypotheses—not established facts.

5. Translate needs into requirements

A requirement states what the solution must achieve.

Good requirements should be as clear, measurable, feasible, and verifiable as the stage of the project permits.

Compare:

• Weak: “The bridge should be safe.”

• Better: “The bridge shall satisfy the applicable loading, safety, durability, and serviceability requirements specified by the relevant engineering standards.”

NASA describes technical requirements definition as the process of transforming stakeholder expectations into validated technical requirements that can guide design. It also emphasises that objectives should focus on what must be achieved, rather than prematurely prescribing how to implement the solution. (NASA: Technical Requirements Definition)

6. Identify constraints

Requirements describe what must be achieved. Constraints limit how the outcome may be achieved.

Common engineering constraints include:

• Safety

• Cost

• Time

• Materials

• Energy

• Space

• Weight

• Reliability

• Manufacturability

• Maintainability

• Accessibility

• Environmental impact

• Regulations and standards

• Available skills and infrastructure

Constraints may conflict. Improving performance may increase cost or energy use. Reducing weight may affect strength or durability.

Recognising these tensions early allows engineers to make trade-offs deliberately.

7. Define success criteria

A problem is not adequately defined until the team knows what evidence would count as success.

Success criteria should answer:

• What must improve?

• By how much?

• Under which operating conditions?

• How will it be measured?

• Who will accept the result?

• What level of risk is tolerable?

• Which requirements are mandatory?

Examples include:

• Maximum response time

• Minimum efficiency

• Allowable temperature range

• Required reliability

• Acceptable lifecycle cost

• Compliance with a specified standard

• Reduction in waste or energy consumption

• User acceptance under defined conditions

8. Write the problem definition

A practical engineering problem definition can use this structure:

[Stakeholder] needs [desired outcome] in [context] because [evidence of the need]. A successful solution must satisfy [key requirements] while respecting [constraints]. Success will be demonstrated through [measures and tests].

Example:

The users and facilities team need reliable water availability on the upper floors during peak periods. Measurements show that pressure falls below the required operating level between 8:00 and 10:00 a.m. A successful solution must maintain the specified pressure and supply, comply with applicable plumbing and electrical requirements, operate within the approved cost and energy limits, and be maintainable by the existing facilities team. Performance will be verified through pressure, flow, energy, reliability, and user-service measurements.

Only after this definition is established should solution options such as leak repair, storage, control changes, pipe modification, demand management, or pump replacement be compared.

---

The Role of AI

AI can strengthen problem definition when it is used as a thinking partner rather than as an automatic answer machine.

AI can help learners:

• Generate stakeholder questions

• Organise observations and interview notes

• Identify missing information

• Suggest possible causes for investigation

• Convert needs into draft requirements

• Detect vague or unmeasurable language

• Surface possible constraints

• Generate alternative problem framings

• Construct a requirements traceability table

• Propose verification methods

• Challenge assumptions

• Compare the problem definition with relevant standards

However, AI does not directly experience the operating environment, bear professional accountability, or automatically know which local information is accurate.

An AI-generated problem definition is therefore a draft to be investigated and validated.

---

The Human Role

The learner or engineer remains responsible for:

• Observing the real situation

• Speaking with stakeholders

• Gathering trustworthy evidence

• Selecting appropriate standards

• Identifying social and environmental consequences

• Resolving conflicting needs

• Protecting confidential information

• Deciding which trade-offs are acceptable

• Verifying requirements

• Accepting professional responsibility

AI may expand the problem space. The engineer must establish what the real problem is.

---

Applying TAJ

Think

Clarify the situation, stakeholders, evidence, requirements, constraints, risks, and intended outcome.

Ask

Use AI to identify gaps, develop questions, generate possible causes, improve requirements, and consider alternative framings.

Judge

Verify the AI’s suggestions against measurements, stakeholder evidence, engineering principles, standards, and real-world conditions.

Accomplish

Produce an agreed and testable engineering problem definition that can guide design.

Learn

Update the definition as prototypes, tests, new evidence, or stakeholder feedback reveal more about the problem.

---

Pattern Artifact: Engineering Problem Definition Canvas

The learner should produce a one-page canvas containing:

1. Observed situation

2. Evidence of the need

3. Stakeholders

4. Desired outcome

5. Current performance

6. Possible causes requiring investigation

7. Functional requirements

8. Non-functional requirements

9. Constraints

10. Assumptions

11. Risks

12. Success measures

13. Verification approach

14. Final problem definition

This artifact makes the learner’s reasoning visible and provides a reference for later design decisions.

---

Power Prompt

Use the following prompt only after providing AI with sufficient non-confidential context:

Act as an engineering problem-framing assistant. Do not propose a solution yet. Help me distinguish the observed symptoms, underlying need, stakeholder expectations, possible causes, requirements, constraints, assumptions, risks, and success measures. Identify missing evidence and ask one question at a time. Treat proposed causes as hypotheses until supported. Then help me draft a measurable, solution-neutral engineering problem definition. Clearly label anything that requires validation by an engineer, stakeholder, measurement, standard, or domain expert.

The phrase “Do not propose a solution yet” is important. It keeps AI focused on understanding before generation.

---

How to Assess the Pattern

A learner has not mastered the pattern merely by writing a problem statement.

Assessment should examine whether the learner can:

• Distinguish a need from a proposed solution

• Identify relevant stakeholders

• Separate symptoms from unverified causes

• Gather and interpret evidence

• State measurable requirements

• Identify important constraints

• Define success and verification methods

• Use AI without accepting unsupported claims

• Revise the definition after feedback

• Explain how the definition guides later design choices

A strong test of transfer is to give the learner an unfamiliar problem from another engineering context and ask them to apply the same pattern.

---

Boundary: When This Pattern Can Be Misused

“Define before designing” should not become an excuse for endless analysis.

Some situations require:

• Rapid experiments

• Emergency action

• Early prototyping

• Parallel investigation and design

• Iterative discovery

Even in these cases, the team should state its current understanding, assumptions, constraints, and success criteria.

Problem definition and solution development often influence each other. A prototype may reveal that a requirement is unrealistic. Testing may expose a hidden constraint. Stakeholder feedback may change the desired outcome.

The pattern is therefore not:

Define once → Never change

It is:

Define sufficiently → Explore → Test → Learn → Refine

---

Contemporary Engineering Scenario

Suppose a manufacturing unit asks a student team to create an AI-based predictive-maintenance system.

A premature response would be to select sensors, train a model, and build a dashboard.

Applying Pattern 01 first would reveal questions such as:

• Which equipment failures cause the greatest operational harm?

• What decisions should the prediction support?

• How much warning time is useful?

• What failure data are available?

• What is the cost of a false alarm?

• What happens if the system misses a failure?

• Who will act on the alert?

• Can the available sensors detect the relevant conditions?

• How will model performance be monitored after deployment?

• When must a human override the recommendation?

The real need may not be “build an AI model.”

It may be:

Reduce unplanned downtime on specified critical equipment by providing maintainers with sufficiently early, reliable, and explainable warnings within defined operational, safety, data, and cost constraints.

That is a much stronger foundation for engineering.

---

The Accomplishment Proposition

A fast solution to a poorly defined problem is not engineering accomplishment.

The engineering value chain begins earlier:

Observe → Understand → Define → Design → Build → Test → Deploy → Monitor → Improve

Pattern 01 protects the beginning of this chain.

It ensures that AI’s speed is directed towards the right need, that design alternatives can be evaluated against explicit criteria, and that outcomes can be verified rather than merely admired.

Pattern: Define the problem before designing the solution.
Artifact: Engineering Problem Definition Canvas.
Evidence: Validated requirements, constraints, and success measures.
Outcome: A defensible foundation for engineering design.

---

Sources

• ABET — Criteria for Accrediting Engineering Programs, 2025–2026

• NASA — Systems Engineering Handbook: System Design Processes

• NASA — Stakeholder Expectations Definition

• NASA — Technical Requirements Definition

• INCOSE — About Systems Engineering

• INCOSE — Using Stakeholder Analysis to Define the Problem

Note: “Learning by Patterns,” “Pattern Learning Unit,” the Engineering Problem Definition Canvas, and their integration with TAJ are proposed AI YING educational constructs. The cited sources support the underlying engineering principles; they do not constitute direct empirical validation of the complete framework.

#LearningByPatterns #EngineeringEducation #PatternAI #ProblemDefinition #SystemsEngineering #EngineeringDesign #AIInEngineering #TAJ #AIYING