Writing the Literature Review for an Engineering Project: Lecture Notes
Who these notes are for: final-year B.E./B.Tech. and M.Tech./MSc students preparing a project report or thesis chapter. Time needed: one session to read, two to three weeks to do properly.
Why we begin here
Let me start with something I tell every project group in the first week. Your examiner will read your literature review first, and they will read it with one question in mind: does this student know what has already been done? If the answer is yes, they will trust the rest of your report. If the answer is no — if the review is a list of summaries copied from abstracts — they will read everything that follows with suspicion.
A literature review is not a formality before the “real” work. It is the argument for why your project is worth doing. By the end of it, the reader should be able to finish this sentence without your help: “Previous work has done A and B, but not C — and that is what this project does.”
Keep that sentence in front of you. Everything below is a way of earning it.
Part 1. Define the question before you search
Students often start by typing their project title into a search engine. That produces thousands of results and no direction.
Instead, break your project into three to five concepts. Suppose your project is a small wheeled robot that detects obstacles using an ultrasonic sensor and sends video over Wi-Fi. The concepts are:
- mobile robot / wheeled robot
- obstacle detection — ultrasonic sensing
- wireless video transmission
- embedded controller (the board you are using)
For each concept, list synonyms and related terms. Engineers are inconsistent with vocabulary, and a search that uses only your words will miss half the field.
| Concept | Terms to search |
|---|---|
| mobile robot | “mobile robot”, “wheeled robot”, “unmanned ground vehicle”, UGV |
| obstacle detection | “obstacle detection”, “obstacle avoidance”, “collision avoidance”, ultrasonic |
| video transmission | “video streaming”, “wireless video”, “real-time video”, Wi-Fi |
Part 2. Search systematically — and keep a log
Combine concepts with AND, synonyms with OR, and use quotation marks for phrases:
("mobile robot" OR "wheeled robot" OR UGV)
AND ("obstacle avoidance" OR "obstacle detection")
AND ultrasonic
Run the same search in at least two places — for example IEEE Xplore (if your institution subscribes) and Google Scholar, plus an open database such as OpenAlex or Semantic Scholar.
Now the habit that separates careful students from the rest: keep a search log. A simple spreadsheet will do.
| Date | Database | Search string | Filters | Results | Kept |
|---|---|---|---|---|---|
| 2 Oct | Google Scholar | (as above) | 2019– | 1,240 | 14 |
This log costs you five minutes and saves you days. When your supervisor asks, “Did you look for X?”, you can answer precisely. In a thesis, a short account of your search method is itself a sign of rigour.
Part 3. Read in three passes
You will not read fifty papers in full. Nobody does. Read in passes:
- Screen (2 minutes). Title, abstract, figures. Is it relevant? Keep or discard.
- Skim (15 minutes). Introduction, the method section’s first paragraphs, results, conclusion. What did they do, how, and how well?
- Study (1–2 hours). Only for the eight to fifteen papers closest to your project. Read everything, including the limitations — the limitations section is where your project’s opportunity usually hides.
For every paper you keep, fill in one row of a synthesis matrix:
| Paper | Problem | Method / hardware | Data / test setup | Key result | Limitation |
|---|
Write in your own words from the start. If you copy sentences into your notes “for now”, they will end up in your report, and that is how honest students commit accidental plagiarism.
Part 4. Organise by idea, not by paper
Here is the most common weakness I see:
“Author A (2019) built a robot with an ultrasonic sensor. Author B (2020) used an infrared sensor. Author C (2021) used a camera…”
This is a list, not a review. It tells the examiner what you read, not what you understood.
Look at the columns of your matrix instead. The patterns there become your sub-headings:
- Sensing approaches — ultrasonic vs. infrared vs. vision: accuracy, cost, failure cases.
- Communication — how video is transmitted, what latency is reported, under what conditions.
- Evaluation — how systems were tested, and whether results are comparable at all.
Then write across papers:
“Ultrasonic sensing is the most common low-cost approach in the studies reviewed, but most were evaluated indoors on flat surfaces, and few report behaviour with soft or angled obstacles, where ultrasonic echoes are weak. Vision-based approaches address this but demand more processing than a low-cost microcontroller provides.”
Notice what that paragraph does: it compares, it judges, and it quietly points to a gap.
Part 5. Write the gap, then the aim
Close the review with a short section — often titled Research gap or Summary and motivation — that states plainly:
- what the literature has established,
- what remains unresolved or untested,
- how your project addresses part of that.
Be modest and specific. “No one has ever built a robot like this” is almost never true and invites the examiner to prove you wrong. “Few low-cost systems reviewed report tests on angled obstacles; this project evaluates…” is defensible.
Part 6. Cite correctly and only what you have read
- Use the style your department requires (engineering departments commonly use IEEE numbered style — see our IEEE citation reference).
- Use a reference manager (Zotero is free) from day one.
- Cite only what you have read. If you have only seen a paper through someone else’s reference list, either find and read it or cite it as a secondary source.
- If a paper’s link no longer works, see How to Find a Paper When the Journal Website Has Disappeared.
- Check your sources. A review built on weak venues is weak; our guide on evaluating a journal will help.
Common mistakes examiners notice
- Summaries in sequence, with no comparison.
- Old sources only — or recent sources only, with the foundational work missing.
- Claims without citations (“It is well known that…”).
- Citations without claims (a sentence that exists only to hold a reference).
- Copied phrasing from abstracts.
- A “gap” that the review itself never demonstrated.
- Inconsistent or incomplete references.
Exercises
- Break your own project into concepts and build a synonym table (Part 1).
- Run one search in two databases and record both in a search log. Why do the results differ?
- Complete a synthesis matrix for five papers. Which column reveals the most disagreement?
- Rewrite a paragraph of “Author A… Author B…” into a paragraph organised by idea.
- Draft your gap statement in three sentences. Ask a classmate whether the review you have written actually supports it.
These notes describe general good practice. Your department’s handbook and your supervisor’s guidance take priority wherever they differ.