Defining the Engineering Question Before Building the Model — Engineering Practice

The Wrong Question

A technically sophisticated answer to the wrong question is still the wrong answer. This is the single most common and most expensive failure mode in engineering analysis. It is more damaging than a mesh that is too coarse, a boundary condition that is slightly off, or a material property that is imperfectly known, because it invalidates the entire body of work that follows. An analysis that answers a question nobody needed answered consumes engineering effort, occupies review time and may mislead the decision it was intended to support. The remedy is not better modelling — it is better problem definition. Before any model is built, before any mesh is generated, before any load is applied, the analyst must know precisely what technical question the analysis is required to answer and what decision that answer will support.

DEFINE THE DECISION BEFORE DEFINING THE MODEL. THE MODEL EXISTS TO ANSWER THE QUESTION, AND THE QUESTION EXISTS TO SUPPORT THE DECISION. INVERTING THIS ORDER PRODUCES ANALYSES THAT ARE TECHNICALLY ELABORATE BUT ENGINEERING-IRRELEVANT.

Poor Questions vs Better Questions

The quality of an engineering question can be judged by whether it specifies the decision, the configuration, the failure mode, the response quantity and the required confidence. Vague questions invite vague — or worse, misleading — answers. The examples below show how the same component can be analysed for very different purposes, and how the phrasing of the question determines whether the analysis will be useful.

Questions to Ask Before Building the Model

Before any geometry is idealised, the analyst should work through the following questions. These are not administrative preliminaries — they are the engineering work that determines whether the analysis will be worth doing. If any of these questions cannot be answered, the analysis is not yet ready to begin, and the time spent obtaining the answers will be repaid many times over in avoided rework.

• What is being decided? — Is the analysis supporting a sizing decision, a qualification decision, an investigative finding, a comparison of options, or a determination that further test is needed?
• What failure mode matters? — Yielding, ultimate failure, buckling, fatigue, fracture, excessive deflection, instability, thermal distress, vibration, acoustic response, or a combination?
• What response quantity is needed? — Stress, displacement, reaction, frequency, temperature, strain, load factor, margin, or a derived quantity such as fatigue life?
• What load cases apply? — Limit, ultimate, fatigue spectrum, thermal, dynamic, crash, fault, or service loads? What is the source and revision of each?
• What accuracy is required? — Is a rough scale sufficient, or is a precise margin required? What is the consequence of being wrong?
• What evidence already exists? — Previous analyses, test data, service experience, hand calculations, handbook methods, comparable designs?
• What uncertainty matters? — Which inputs, assumptions and load cases dominate the result? Where should effort be concentrated?
• What does success look like? — What result would allow the decision to be made with confidence? What result would require redesign, further analysis or test?

The Engineering Question Template

The template below provides a structured way to capture the engineering question before modelling begins. It should be documented and reviewed before the model is built. If the template cannot be completed, the analysis is not ready to start. Each field forces the analyst to confront an aspect of the problem that, if left vague, will propagate through the analysis and emerge as an unreviewable assumption or an uninterpretable result.

• Decision — What technical decision will this analysis support?
• Configuration — What geometry, revision and assembly state is being analysed?
• Operating condition — What phase of operation, flight regime or service condition applies?
• Loads/environment — What loads, temperatures, pressures and environmental conditions apply, and from what source?
• Failure modes — What failure modes must the analysis address?
• Required outputs — What response quantities must be extracted?
• Existing evidence — What prior analyses, tests or service data are available for comparison?
• Known uncertainties — What inputs or assumptions are known to be uncertain?
• Required confidence — What level of confidence is needed in the result, and what is the consequence of error?
• Deliverable — What form must the output take to support the decision?

The Engineering Question Matrix

Different engineering questions demand different starting methods and produce different required outputs. The same component may require a global load-path model, a detailed local strength model and a buckling assessment — each answering a different question. The matrix below maps common engineering questions to the method that should start the analysis and the output that must result.

The Same Component, Many Questions

A single component can be the subject of multiple legitimate engineering questions, each leading to a different analysis approach. The diagram below shows how the same structural component — an engine mounting bracket — gives rise to different questions, each demanding a different starting method and producing a different output. The analyst must know which question is being asked before selecting the method.

                    ┌─────────────────────────────┐
                    │  ENGINE MOUNTING BRACKET    │
                    │  (one component)            │
                    └──────────────┬──────────────┘
                                   │
          ┌────────────┬───────────┼───────────┬────────────┐
          │            │           │           │            │
          ▼            ▼           ▼           ▼            ▼
   ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
   │ Question │ │ Question │ │ Question │ │ Question │ │ Question │
   │    A     │ │    B     │ │    C     │ │    D     │ │    E     │
   │          │ │          │ │          │ │          │ │          │
   │ Load     │ │ Local    │ │ Fatigue  │ │ Buckling │ │ Modal    │
   │ path?    │ │ strength │ │ life?    │ │ of web?  │ │ response?│
   │          │ │ at fillet│ │          │ │          │ │          │
   └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
        │            │           │           │            │
        ▼            ▼           ▼           ▼            ▼
   ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
   │ Beam     │ │ Solid FE │ │ Stress   │ │ Linear   │ │ Modal    │
   │ model +  │ │ submodel │ │ history  │ │ buckling │ │ analysis │
   │ free-    │ │ + stress │ │ + SN     │ │ + imperf. │ │ + FRF    │
   │ body     │ │ conc.    │ │ curve    │ │ sensitivity│ │          │
   └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
        │            │           │           │            │
        ▼            ▼           ▼           ▼            ▼
   ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
   │ Member   │ │ Margin   │ │ Fatigue  │ │ Critical │ │ Freq.    │
   │ forces;  │ │ vs       │ │ life in  │ │ load     │ │ separation│
   │ load     │ │ allowable│ │ cycles   │ │ factor   │ │ from     │
   │ path map │ │          │ │          │ │          │ │ excitation│
   └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘

BEGINNING WITH A DETAILED SOLID FE MODEL BEFORE DECIDING WHAT TECHNICAL QUESTION THE MODEL MUST ANSWER INVERTS THE ENGINEERING PROCESS. THE MODEL IS BUILT TO ANSWER A QUESTION — NOT THE QUESTION RETROFITTED TO JUSTIFY A MODEL THAT HAS ALREADY BEEN BUILT.

Why This Matters

The cost of building the wrong model is not merely the computational time wasted — it is the opportunity cost of the engineering effort that could have been spent on the right model, the review time consumed by an analysis that does not support the decision, and the risk that a misleading result influences the decision in the wrong direction. In many organisations the review process will catch a modelling error or a numerical error, but a wrong-question error is harder to detect in review because the analysis may be internally consistent and superficially convincing. The reviewer sees a well-executed analysis and may not ask whether it answers the question that needed answering. This is why the engineering question must be defined, documented and agreed before the model is built — so that both the analyst and the reviewer are working towards the same decision.