How to write a literature review in engineering

An engineering literature review is usually a state-of-the-art review: a structured account of the methods, materials, or systems that already address your problem, what each achieves under what conditions, and why none of them fully solves it. Examiners read it as the justification for the entire project; if the gap is not convincing, the thesis that follows is answering a question nobody asked.

Engineering also reviews sources other fields rarely touch: standards that constrain the design space, patents that establish prior art, and datasheets that anchor real-world parameters. Handling them correctly is part of what is being examined.

This guide covers the engineering databases, the full range of source types, comparison-driven structure, gap analysis, when PRISMA applies, a worked outline, and how to keep every number in an AI-assisted review traceable to its source.

What an engineering literature review needs to do

Three jobs. First, establish the state of the art: the approach families that exist and the performance each has demonstrated. Second, justify your design decisions: why this method, this material, this architecture, given what the literature reports. Third, define the gap in measurable terms, because your objectives will be checked against it line by line.

This differs from a science review in emphasis. The question is not only what is known but what has been built and how well it performs. Performance parameters, operating conditions, and scale of demonstration carry the argument, which is why precision with numbers matters more here than in most fields.

Scope the review around requirements from the start. An engineering examiner reads the chapter asking one question: do these sections collectively prove that the stated requirements cannot be met by anything that already exists? Everything you include should serve that proof, and anything that does not can usually go.

Where to search: IEEE Xplore, Scopus, and Engineering Village

Engineering literature is split across publisher platforms, society libraries, and indexes, and no single one is sufficient:

CiteDash's Literature Finder searches an internal corpus plus live OpenAlex, Semantic Scholar, arXiv and PubMed in one pass, which covers the journal and preprint core and the citation graph. Use the society libraries, standards catalogues, and patent databases for the material only they index, and log those searches alongside.

Engineering search terms need extra care because the same concept travels under different names across subfields and industries. Search the scientific term, the industrial term, and the application phrasing, and note that older literature indexed in Compendex often uses vocabulary that has since shifted.

• IEEE Xplore: electrical, electronic, computing, control, and much of mechatronics
• Scopus and Web of Science: broad coverage and citation chasing across engineering disciplines
• Engineering Village, meaning Compendex and Inspec: the classic engineering indexes, strong for applied and older work
• Society libraries: ASCE, ASME, SAE, and similar bodies for discipline-specific journals and conference series
• arXiv: increasingly relevant for robotics, control, and computational subfields
• Patents and standards: Espacenet or national patent offices, plus the ISO, IEC, and ASTM catalogues

Source types: papers, standards, patents, and datasheets

Each engineering source type answers a different question, and examiners expect you to use them accordingly:

Cite standards precisely, with designation and edition, because requirements change between editions and an examiner who works to that standard will notice. Treat datasheet values as manufacturer claims, useful for design context but not equivalent to peer-reviewed measurements.

Read patents for their claims, not their abstracts. The claims section defines the legal scope of the prior art, and it is what your novelty argument must clear; the description is often broader than what is actually protected. Cite the patent number and, where relevant, the specific claim.

• Peer-reviewed journal articles: the archival record of methods and measured results
• Conference papers: often the first publication of a technique, standard practice in many subfields
• Standards: the constraints your design must meet, cited by designation and edition
• Patents: the prior-art record, essential when your contribution claims a novel device or process
• Technical reports and theses: implementation detail that journal pages compress away
• Manufacturer datasheets and handbooks: parameter context for design choices, not research evidence

Structure by technology or method, then compare

Organise the review by approach family, not by paper. For each family: the operating principle, the representative implementations, the reported performance, and the limitations. The sequence of families should build toward the comparison, which is where the review starts earning its place in the thesis.

The comparison lives in tables: approaches as rows, and as columns the parameters that matter for your application, such as efficiency, capacity, operating range, and scale of demonstration. Two rules make the table defensible. Every value traces to a source you hold, and every value carries its test conditions, because numbers measured under different conditions are not comparable and examiners look for exactly that mistake.

Close each approach-family section with a short verdict against your requirements: what the family can deliver, what it cannot, and under which conditions the evidence was produced. Those verdicts become the rows of your final comparison and the premises of your gap analysis, so writing them early keeps the chapter coherent.

Gap analysis: turn the review into your research justification

The gap should fall out of the comparison: a region of the parameter space no approach reaches, an assumption every implementation shares, a scale nothing has demonstrated. If the gap does not follow from your own tables, the justification is assertion rather than analysis.

State the gap in measurable terms and map your research objectives onto it one to one. Examiners check that mapping, and a thesis whose objectives outrun its established gap invites the question of why those objectives exist at all.

Be honest about near misses. If one approach almost meets the requirement, say so and quantify the shortfall, because a gap defended by ignoring the closest competitor will not survive an examiner who knows the field.

Justify design decisions from the literature

Design-oriented theses make choices constantly: a material, a control strategy, a manufacturing route. Each significant choice should trace back to the review: the alternatives considered, the reported performance of each, and the reason your requirements favour one. A choices-to-evidence mapping, even as a small table, makes the methods chapter almost self-justifying.

This is also where the review protects you at the viva. When an examiner asks why you did not use a competing approach, the answer should already exist in the chapter, with sources, rather than being improvised on the day.

When PRISMA applies in engineering reviews

Formal systematic reviews are increasingly common in areas like construction management, energy, and transportation. If you claim one, the machinery comes with it: named databases, exact strings, criteria fixed before screening, counts at every stage, and a PRISMA flow diagram.

A standard state-of-the-art chapter does not need PRISMA, but it still needs a defensible search. Record where you searched, with what terms, and when, so that a viva question about coverage has a documented answer.

Whatever the format, put the full search record in an appendix: databases, strings, dates, and counts. It costs a page and removes an entire category of examiner doubt.

A worked outline for an engineering literature review

Here is an outline for a thesis on battery thermal management, adaptable to most design-oriented projects:

The requirements section early in the chapter is an engineering habit worth keeping: it gives every later comparison a fixed reference, so judgements read as engineering rather than preference.

Swap the approach families for your own domain's, but keep the shape: requirements early, evidence in the middle, comparison and gap at the end, objectives last.

• Introduction: the engineering problem, the requirements, and the scope of the review
• Requirements and constraints: relevant standards and the operating envelope
• Approach family 1: air-based cooling, principle, implementations, reported performance
• Approach family 2: liquid cooling, principle, implementations, reported performance
• Approach family 3: phase-change and hybrid systems
• Cross-comparison: parameters, test conditions, and scale of demonstration across families
• Gap analysis: the unmet requirement and why existing approaches cannot meet it
• Research objectives: how each objective closes part of the gap

Get the numbers right

Engineering reviews quote values constantly, and this is where AI assistance goes wrong most often: a plausible number recalled from training data instead of read from the paper, or a real number detached from its test conditions. General chatbots also fabricate references outright, a failure mode we unpack in why AI makes up citations.

The working rule is simple: every number in the review has a source you hold, and you can point to the table or page it came from. If you cannot, the number does not go in.

Watch units as closely as values. Literature spanning decades and regions mixes unit systems freely, and a conversion slip inside a comparison table is exactly the error a technical examiner catches. Convert everything to one system, state it in the table caption, and keep the original values in your notes.

How CiteDash grounds an engineering literature review

CiteDash enforces that rule structurally. Every citation is a database object that resolves to a real paper, with no free-text references anywhere. Save papers to your library by PDF upload or DOI, then use Ask and extract to pull parameters, conditions, and results with sentence-level provenance, so each value binds to the exact passage that reports it.

Build the cross-comparison as an evidence matrix in the Synthesis Lab: approach families and parameters across your included papers, each cell traceable to its source. When you draft, the Fact Checker verifies claims against the full-text PDFs you hold and flags anything it cannot verify. Retracted papers are badged and blocked from citation before they can contaminate the record.

For the write-up itself, the Reference Manager formats citations in IEEE and Vancouver among its 12 supported styles, and the Thesis Assembler compiles the finished document to DOCX, PDF, or LaTeX with the bibliography built in.

Mistakes examiners flag in engineering reviews

The recurring failures in engineering reviews are concrete:

Avoid them and the chapter does its real job: it convinces an examiner that the problem is real, the existing approaches genuinely fall short, and your project is the reasonable next step. That is what a state-of-the-art review is for.

• Comparison tables that mix values measured under incompatible conditions
• Standards cited without designation or edition
• No patent search in a thesis claiming a novel device or process
• A gap stated so vaguely that no measurement could confirm or deny it
• Papers described in isolation with no cross-comparison
• Objectives that do not map onto the gap the review established