For a student with a draft methodology chapter in an engineering thesis or dissertation, whether the work is a design, an experiment, a simulation or a mix of these. This page sets out what the chapter has to show in engineering: how a design choice is justified, what a reader needs to repeat a test or rebuild a model, how verification differs from validation, and how measurement uncertainty is reported. It quotes guides from Finland, Germany and Canada, and two US agencies. For other chapters, see thesis chapter feedback.
From within your field, Esmond points out where your findings claim more than your method can show and where your design choices contradict each other.
An engineering thesis can combine a design process with an investigation: you choose or build a solution, then test it by experiment, simulation or both. The methodology chapter has to account for both parts. Why this design, and how do you know how well it works? The general shape of a methodology chapter is on the thesis methodology chapter page; this page covers what engineering adds.
Aalto University's School of Engineering lists this among the criteria on which a master's thesis is evaluated: “The student demonstrates ability to choose justified methods for reaching the goals”. A reader can check two things in that line: each method has a stated reason, and the reason refers to a goal or requirement set earlier in the thesis.
A hypothetical example of a commentYour methodology says the finite element mesh was refined until the results converged, but no element sizes or stress values are given. Which numbers show the convergence?
A first comment on one part of your own draft, right away and without an account.
Get a free previewThe work report guidelines of the University of Waterloo's Department of Civil and Environmental Engineering ask the main section of a work-term report to move from the problem to the course of action, including “an analysis of any alternative solutions, and, finally, the justification for the solution selected”. The guideline is written for work-term reports; the same logic applies in a thesis, where it means three things on the page: requirements with values (a load, a range, a limit), the alternatives you considered, and the criteria and weights you used to choose between them.
A weighted decision matrix is one way to show the choice. In this made-up example, three actuator concepts are rated from 1 to 5 against four criteria, and each rating is multiplied by the weight.
| Criterion (weight) | Linear motor | Ball screw | Pneumatic cylinder |
|---|---|---|---|
| Positioning accuracy (0.4) | 5 | 4 | 2 |
| Cost (0.2) | 2 | 4 | 5 |
| Maintenance effort (0.2) | 4 | 3 | 3 |
| Load capacity (0.2) | 3 | 5 | 4 |
| Weighted total | 3.8 | 4.0 | 3.2 |
Three questions come back. Where do the weights come from: a requirement, the client, a standard? Does a rating of 4 rest on a calculation, a datasheet or a guess? And would a small change in weights change the choice? In the example, the ball screw leads by 0.2. With accuracy weighted 0.5 and cost 0.1, the totals become 4.1 for the linear motor and 4.0 for the ball screw, and the order flips. A thesis that shows this check, and says why the chosen weights hold, gives the reader the answer in the chapter itself.
The Institute of Computer Science at Warsaw University of Technology lists, among the typical shortcomings in graduate theses, “unjustified assumptions, requirements, criteria, decisions, etc.” Named design methods such as the German VDI 2221 guideline or the systematic approach of Pahl and Beitz give the steps a structure. If you follow one, say so, and say where you departed from it.
Western University's mechanical engineering MEng guidelines give the test for a description of apparatus and procedure: “Remember that another person with your knowledge and experience should be able to duplicate your experiments from the descriptions given.” TUM's Chair of Urban Water Systems Engineering is specific about instruments: “Provide information on all instruments used in your work, including model, manufacturer and country.”
For a simulation, the method section describes the model setup. A reader expects the geometry and its simplifications, material models with parameter values and their sources, boundary and initial conditions, the mesh or time step, the solver and its settings, and the software name and version. Someone with the same software should be able to rebuild the model from the chapter and its appendix.
Two checks belong in this part. Solution verification asks whether your numbers are a converged solution of the model you set up: a mesh or time-step study, often with three or more levels, showing how the output you report changes. Validation asks whether the model represents the physical system: a comparison with measurements, under the conditions the thesis makes claims about, with the measurement uncertainty shown. The Online Writing Lab of TH Nürnberg puts the aim of the methods part in one line: “Describe materials and methods in such detail that the work could be reproduced based solely on this description.”
The two words have related meanings in two traditions. In systems engineering, the NASA Systems Engineering Handbook defines: “Verification is a formal process, using the method of test, analysis, inspection or demonstration, to confirm that a system and its associated hardware and software components satisfy all specified requirements.” Validation testing compares the product with its intended use: “Validation testing is conducted under realistic conditions (or simulated conditions) on any end product to determine the effectiveness and suitability of the product for use in mission operations by typical users and to evaluate the results of such tests.”
In modeling and simulation, verification means checking that the software solves the model's equations correctly, and validation means comparing the model's predictions with experimental data for the intended use. In both traditions, passing verification says nothing about validation. A model can be converged and still wrong because a boundary condition or a material parameter is wrong.
| Verification | Validation | |
|---|---|---|
| Question | Was it built right? Are the equations solved right? | Was the right thing built? Does the model fit this use? |
| Compared against | Requirements, specifications, closed-form solutions | The intended use; measurements on the real system |
| Evidence in a thesis | A requirement-by-requirement test table; a mesh study; a benchmark case with a known answer | Lab or field tests under realistic conditions; model-versus-measurement plots with uncertainty |
| Mix-up a reader looks for | A mesh study described as validation | A model validated against the same data used to tune its parameters |
A measured value without its uncertainty can't be compared with a requirement or with a model. NIST's summary of its guidelines, which follow the ISO Guide to the Expression of Uncertainty in Measurement, sets the basis: “Each component of uncertainty, however evaluated, is represented by an estimated standard deviation, termed standard uncertainty”. Components evaluated statistically from repeated readings are Type A; components from other information, such as a certificate, an instrument's resolution or a manufacturer's specification, are Type B.
A made-up example: a thermocouple reading at one set point. Its reference certificate states ±0.5 °C at a coverage factor k = 2, so the Type B standard uncertainty is 0.25 °C. Ten repeated readings have a standard deviation of 0.30 °C, so the Type A standard uncertainty of their mean is 0.30/√10 = 0.095 °C. The combined standard uncertainty is √(0.25² + 0.095²) = 0.267 °C, and the expanded uncertainty with k = 2 is 0.53 °C, which corresponds to about 95% coverage if the distribution is close to normal.
| Part of the chapter | Question a reader asks |
|---|---|
| Requirements | Does each requirement have a value and a source? |
| Alternatives and selection | Which options were compared, on which criteria, and does the choice survive a change in weights? |
| Test setup | Could someone repeat the test from this description and the appendix? |
| Model setup | Are parameters, boundary conditions and software version all stated? |
| Verification | Is there a convergence study or a benchmark case, with numbers? |
| Validation | Is the model compared with measurements that were not used to tune it? |
| Uncertainty | Is each reported value given with its uncertainty and coverage factor? |
| Reproducibility | Are seeds, versions and parameter tables given, and is it said where code and data are kept? |
These fragments are made up. None of them comes from a real thesis.
Esmond evaluates every assignment before you submit. It never writes it.
Esmond is an AI tool that doesn't write for you. If your course doesn't allow any AI tools, don't use Esmond for that work. If you're unsure, ask your instructor or advisor.
In an engineering methodology chapter, Esmond can flag, in the text you upload, a design choice without stated criteria, a mesh study presented as validation, comparisons between results that differ by less than their stated uncertainty, and parameters or software versions the chapter leaves out, with comparisons across chapters where the results are in the same file. Open the sample report to see the form of the comments, or read how Esmond works.
Esmond reads what you upload. If the file holds the whole draft, it can set this chapter against the others; if it holds one chapter, the review stays within that chapter and may raise a point that another chapter already answers.
Esmond doesn't rerun your simulation, recompute your uncertainty budget or verify your design; it reads what the chapter says. Which comments you act on is your decision.
The account of how you reached your results: the design process and the choices in it, the experiments or simulations, how you checked them, and how certain the results are. The Aalto School of Engineering criterion quoted above sums up the test: methods chosen with a justification that refers to the goals.
A structured route from requirements through concepts and selection to detailed design and testing. Named versions exist: the German VDI 2221 guideline, and the systematic approach of Pahl and Beitz, with the phases task clarification (planning), conceptual design, embodiment design and detail design. In a thesis, say which one you followed, show the selection step with its criteria, and note where you departed from the method.
Verification checks a product or model against its specification: did you build it right, or solve the equations right? Validation checks it against its intended use or against the real system: did you build the right thing? A thesis can pass the first and fail the second.
If you compare measured values with each other, with a requirement or with a model, a reader needs the uncertainty to judge the comparison. How detailed the budget has to be depends on the work; ask your supervisor what your department expects.
Western University's mechanical engineering guidelines give the test: another person with your knowledge and experience should be able to duplicate the experiments from your description. Long parameter lists, drawings and instrument lists can go to an appendix, as long as the chapter points to them.
Read on November 8, 2026.
Get your paper evaluated before you submit