How to actually write a literature review for your CS dissertation
Nearly every dissertation I read has the same weak spot, and it’s almost always the literature review. Not because students haven’t done the reading. They usually have. It’s because they write down what they read instead of building an argument out of it. A review that lists papers one after another reads like a stack of index cards. A review that compares them, weighs them, and points at a gap reads like someone who’s ready to do research.
So before you open a single database, get this straight: the literature review isn’t a summary of everything you’ve read. It’s the chapter where you show what’s already known, where people disagree, and why your project is worth the effort. In a computing dissertation it usually lands as chapter two, and it does the quiet work of justifying your research question and your choice of methods. Get it right and the rest of the dissertation almost writes itself.
Here’s how I’d go about it.
Start by narrowing the question
A fuzzy topic gives you a fuzzy review. “Machine learning for security” is a research area, not a question. “How well do transformer models detect malware they’ve never seen before?” is something you can actually answer, and something you can search for.
Spend a bit of time up front deciding your boundaries: roughly what timeframe (the last five to eight years is a sensible default, plus the odd older paper that everyone still cites), which sub-field, which platform or dataset. Write your scope down in one line and keep it somewhere you’ll see it. Every source you’re tempted to include should pass that line. If it doesn’t, it doesn’t go in.
Search like you mean it
One Google search won’t cut it, and neither will whatever your supervisor happened to mention. Go to the databases that actually index computing research: IEEE Xplore and the ACM Digital Library are the core two. Scopus or Web of Science are good for seeing how often something’s been cited. Google Scholar is fine for chasing citations, just don’t let it be your only source. arXiv is handy for the newest work, but remember a lot of it hasn’t been peer-reviewed yet, so treat it with a bit of caution.
A few things that make searching less painful:
-
- Build proper search strings with AND, OR and NOT rather than typing a sentence.
- Try synonyms and both spellings, like “neural network” and “deep learning”, or “behaviour” and “behavior”.
- Snowball. Read a key paper’s reference list to go backwards, and check who has cited it to go forwards. This is how you find the papers a keyword search misses.
- Keep a log: which database, the exact query, the date, how many hits. Future-you will be grateful when you need to explain how you found things.
Be picky about what you keep
You’ll turn up far more than you can use, and that’s fine. The skill is throwing most of it back. Screen on the title and abstract first, and only open the full paper if it survives. Lean towards peer-reviewed journal and conference papers over blog posts and vendor white papers. Mix the foundational, heavily-cited work with the recent state of the art, so your review has both roots and a pulse.
Then ask the awkward questions of each paper: is the method described clearly enough to follow, is the dataset named, could someone reproduce this, is the code available? A paper that can’t answer those isn’t worthless, but its limitations belong in your write-up.
How many sources? At BSc level, somewhere around 20 to 40 well-chosen papers you’ve genuinely read beats a bibliography of 90 you skimmed. Ask your supervisor, but don’t chase a number for its own sake.
Read with a pen, not a highlighter
Highlighting feels productive and teaches you nothing. Read with questions in your hand instead. For every paper, jot down the problem it tackles, the method, the data, the result, the limitations, and, most importantly, how it connects to your question.
Two tools save hours here. Get a reference manager going on day one, Zotero or Mendeley, so your citations and PDFs are handled automatically and you’re not retyping author names at 2am. And build a synthesis table: one row per paper, a column for each thing you care about. Something like this:
| Author (year) | Method / data | Key finding | Limitation |
|---|---|---|---|
| Smith (2021) | CNN, EMBER dataset | 97% on known families | Weak on zero-day |
| Chen et al. (2023) | Transformer, private data | Beats CNN baselines | No code, not reproducible |
| Patel (2022) | SHAP on random forest | Analysts trust the flags | Tiny study (n=12) |
Once that table has a dozen rows, patterns start jumping out at you. That’s the point. The “limitation” column, in particular, is where your critical argument quietly assembles itself.
Organise by idea, not by paper
This is the one that makes me sigh when I mark it. The shopping-list review: paragraph, paper, paragraph, paper, in the order they were read, no thread running through. Don’t do that.
Instead, take your table and group the rows into themes: detection methods here, datasets there, evaluation, explainability. Within each theme, put the papers in conversation with each other. What do they agree on? Where do they clash, and why (different datasets, different metrics, different assumptions)? Order the themes so they build towards your gap, so the reader can feel it coming before you say it.
Find the gap and point straight at it
Synthesis just means saying something the individual papers don’t. Read across your themes and look for three things: what almost everyone agrees on (state it briefly and move on), where the results genuinely conflict, and what nobody has tested, or has tested badly. That last one is usually your gap.
Then make the link explicit. Don’t leave the reader to guess. “Because none of these approaches has been evaluated on unseen samples, this project will…” The gap should flow straight into your aims, so your methodology chapter feels inevitable rather than bolted on.
A structure that holds up
If you want a reliable skeleton for the chapter:
- A short intro saying what the review covers and how it’s organised.
- A brief background on the core concepts your reader needs, and brief is the operative word.
- The thematic sections, one theme at a time, comparing and judging as you go.
- The gap, pulled together from the threads above into the specific problem you’re taking on.
- A short summary that hands over to your methodology.
And write like a critic, not a narrator. Describe the work, then evaluate it: “Chen et al. report higher accuracy; however, their dataset is private, so the result can’t be reproduced.” Use signposting words, like however, in contrast, or building on this, to show how sources relate. You’re the one making the argument. The papers are your evidence, not your narrator.
Referencing without the tears
Pick one style and stick to it. IEEE’s numbered style is common in computing, but check what your department wants. Cite anything that isn’t your own idea or common knowledge. Paraphrase in your own words and still cite. Keep direct quotes rare. And let your reference manager format the bibliography, because that’s exactly the sort of fiddly, error-prone job software should be doing instead of you.
Before you hand it in
Leave the draft alone for a day, then read it with fresh and slightly unkind eyes. Is every section built around an idea rather than a paper? Does each theme actually compare and judge, or just describe? Is the gap stated out loud and tied to your aims? Are the sources credible and current, with the classics included? Is every claim cited? Does the whole thing read as one argument that ends by setting up your methodology? If you can tick all of those, you’re done.
The mistakes I see most
- The shopping list: paper by paper, no synthesis.
- Pure summary: reporting findings without ever judging them.
- Taking every published result at face value.
- Scope creep, drifting into topics that never connect back to the question.
- Leaving it late. The review shapes the whole project, so start it early and keep updating it as you go.
