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:
Engineering problems begin with needs and stakeholder expectations.
Needs must be translated into clear and verifiable requirements.
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:
Observed situation
Evidence of the need
Stakeholders
Desired outcome
Current performance
Possible causes requiring investigation
Functional requirements
Non-functional requirements
Constraints
Assumptions
Risks
Success measures
Verification approach
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
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
