In this guide
How to Write a Literature Survey for Your IEEE Base-Paper Project
Quick answer
A literature survey is the section of your project report that shows you understand the research your project builds on. It is not a list of paper summaries. It is an argument, built from earlier work, for why your project is needed and what exactly it adds.
Start from your base paper, group supporting papers by theme, compare their methods and limits in a table, and end with one gap that your own feature addresses. A list of summaries proves you read papers; a themed comparison proves you understand how they relate and where your project fits.
| Survey style | What it looks like | What a guide takes from it |
|---|---|---|
| Summary list | One paragraph per paper, in no particular order | That you read papers, but not that you understood how they relate |
| Thematic synthesis | Papers grouped by approach, compared on the same points | That you can judge methods against each other |
| Base-paper-anchored survey | Base paper first, supporting papers grouped by what they explain, challenge, or extend | That your project has a clear starting point and a defensible gap |
Why the survey is read first
In a base-paper project, the survey does a job no other section does. It proves three things before any code or hardware exists: that the base paper is real and recent enough to build on, that you know what came before it, and that your own feature is a response to a gap rather than a random addition. Guides therefore read it early and closely. A weak survey makes every later claim harder to believe, because the reader has no reason to trust that you know the field.
If you have not yet settled your base paper, read the guide on how to get your base paper approved in one meeting first. If you have a paper but have not read it deeply yet, the weekend paper-reading method gives you the notes this survey is built from.
Step 1: Fix the anchor, then build the supporting set
Every base-paper survey has one anchor: the paper your project implements and extends. Name it in the first paragraph of the survey, with its full citation, and state plainly what you are taking from it. Everything else in the survey is organised around that anchor.
Then collect supporting papers in three groups:
- Foundations — the earlier methods the base paper itself builds on. Two or three are usually enough to show the lineage.
- Alternatives — papers that solve the same problem differently. These are what make your comparison honest. A survey with no alternative is a sales pitch, not a survey.
- Neighbours — papers from adjacent problems whose method, dataset, or evaluation idea you borrow. These often supply the seed of your own feature.
A workable Phase-1 set is often the base paper plus roughly eight to fifteen supporting papers, but treat that as practical guidance only. Your department template and your guide's instruction override any number in this guide. Fifteen thin summaries are worse than eight papers you can genuinely compare.
Use only papers you have actually read at least to the method-and-results level. A citation you cannot explain in one sentence will be found in a review, and it damages the credibility of the citations you do understand.
Step 2: Take a paper note before you write a word
Do not write the survey from memory of the abstracts. For each paper, fill in one paper note with the same five fields every time. The discipline of identical fields is what makes comparison possible later.
| Field | What to record | Example prompt to yourself |
|---|---|---|
| Problem | The exact problem, in one sentence | What would still be unsolved if this paper did not exist? |
| Method | The approach, in your own words, in two to three sentences | What does it actually compute or build? |
| Evidence | Dataset or setup, metric, and the paper's own headline result, labelled as the paper's claim | What did the authors test, and what do they claim? |
| Limits | What the authors admit, plus one limit you can see yourself | Where does it fail, and on what kind of input? |
| Use in your project | Borrow, adapt, compare against, or reject — and why | Does this change what you build, or only what you cite? |
Keep the notes in one document as you read. Students who skip this step almost always end up writing the survey as a sequence of summaries, because by writing time they remember only the abstract of each paper.
Step 3: Organise by theme, never by paper
The single most common survey mistake is organising by paper: Paper A did this, Paper B did that, Paper C did something else. That structure cannot produce a gap, because gaps live between papers, not inside any single one.
Organise by theme instead. Themes are the questions your project must answer. For a defect-detection project, themes might be: how defects are represented (images, features, or learned embeddings), how much labelled data each method needs, and how results are explained to a human inspector. Each theme section then compares several papers on the same points, and ends with what remains unresolved.
A theme section has a shape worth copying:
- One opening sentence stating the question the theme answers.
- Two or three papers compared on method, data need, and limits.
- One closing sentence stating what is still missing. That missing piece is a candidate gap.
If a paper fits no theme, it probably does not belong in the survey. Cut it, however interesting it seemed when you found it.
Step 4: Compare on the same points, in a table
A comparison table forces honesty. Prose lets a writer praise each paper on a different axis; a table makes every paper answer the same questions. Build one table per major theme, or one overall table if your set is small.
| Comparison point | Why it matters | What to write |
|---|---|---|
| Problem and setting | Shows whether papers are even comparable | Application, input type, operating conditions |
| Method in one line | Stops vague praise | The core mechanism, not the paper's marketing phrase |
| Data and labels needed | Decides whether you can reproduce it | Dataset type and labelling burden, in plain words |
| Stated limits | Shows you read critically | The authors' own limits plus one you identified |
| Relevance to your project | Connects the survey to your build | Borrow, adapt, compare, or reject, with a reason |
Do not copy numbers into the table unless you also copy the conditions they were measured under. A result without its dataset, split, and metric is not evidence; it is decoration. Where the paper's conditions do not match your project, say so in the table rather than quietly dropping the mismatch.
Step 5: Turn gaps into your own feature, on paper first
The last section of the survey is the bridge to the rest of the project. It should name one gap — or at most two — and state the own feature that addresses each. Use a gap table so the link is visible rather than implied.
| Gap found in the survey | Evidence for the gap | Own-feature candidate | What would prove it works |
|---|---|---|---|
| Method needs far more labelled data than a student team can produce | Several surveyed methods assume large labelled sets; your setting has few labels | A low-label approach adapted from the base paper | Reproduction on the same split, then the same test with the feature added |
| Results are not explained to the user | Surveyed methods report a decision with no reason a human can check | An explanation layer on top of the base method | Side-by-side cases where the explanation changes the user's decision |
| Method was tested on one kind of input only | Surveyed evaluations cover a narrow input range | An extension to a second input type your project actually faces | The same evaluation repeated on the new input type |
This table is the most valuable page in a Phase-1 document. It is also the page a guide will question hardest, so every row must trace back to papers discussed earlier in the survey. A gap with no survey evidence behind it is just an opinion, and a feature with no gap behind it is just a wish.
Note what this guide does not do: it does not guarantee that any particular gap or feature will be approved. Final approval always rests with your own guide and college, and a guide may reject a gap you consider strong. The survey's job is to make the case as clearly as possible, not to force the decision.
Worked example: anchoring a survey on two verified papers
Consider a team whose base paper is Marino and colleagues' self-supervised and interpretable anomaly detection work using network transformers, published in IEEE Transactions on Industrial Informatics in 2025 (DOI 10.1109/TII.2025.3534443). Their survey anchor paragraph would state the problem the paper addresses, the self-supervised framework it proposes, and what the team takes from it — the framework, transferred to a new setting — without claiming the paper's results as their own.
A second verified paper can supply the comparison axis. ECLoRA, on federated LoRA fine-tuning of large language models, published in IEEE Transactions on Neural Networks and Learning Systems in 2025 (DOI 10.1109/TNNLS.2025.3586545), is a different problem, but it illustrates a theme the survey can use: how a method reduces a resource burden — labelled data in one case, communication and compute in the other — and what it gives up to do so. The survey compares the trade, not the domains.
The gap the team then argues for must come from their own reading of the defect-detection literature around the base paper: what the base method does not cover in their setting, and what their feature adds. This guide deliberately does not invent that gap for them. A borrowed gap is the easiest thing in a survey to expose, because the student cannot defend a sentence they did not reason through.
Step 6: Write it so a stranger can follow the argument
Once the notes, themes, table, and gap table exist, the writing itself is mostly assembly. A structure that works for most Phase-1 surveys:
- Introduction (one short section). The problem, why it matters, and the base paper in one paragraph. End with a sentence stating what the survey will conclude.
- Theme sections (the bulk). One section per theme, each ending with what remains unresolved.
- Gap and proposed direction (one section). The gap table in prose, naming the own feature and what evidence would support it.
- Summary (one short section). What the literature collectively shows, and what your project will do about it. No new papers appear here.
- References. Every paper cited in the text, in IEEE numbered style, in citation order. No paper in the list that the text never mentions, and no paper mentioned in the text that is missing from the list.
Write in your own words throughout. Copying sentences from papers — even with a citation attached — is still copying, and college plagiarism checks compare text, not intentions. When a paper's phrase is genuinely the standard term for a method, use the term and explain it; do not lift the sentence around it.
IEEE numbered citations work like this in practice: the first paper you cite becomes [1], the next new paper [2], and later mentions reuse the same number. Keep the numbering in order of first appearance, and check it after every edit, because inserting one citation early renumbers everything after it. A reference manager removes most of this pain, but the check still belongs to you: open each reference and confirm the authors, year, journal, and DOI match the paper you actually read.
Common mistakes that cost marks
- The annotated bibliography. A list of summaries with no comparison and no gap. Fix: rewrite by theme and add the comparison table.
- The base paper as the only paper. A survey that cites the base paper and little else proves nothing about the field. Fix: add foundations and at least one genuine alternative.
- Results without conditions. Numbers quoted with no dataset, split, or metric. Fix: add the conditions or drop the number.
- The gap that appears from nowhere. A feature proposed in the last paragraph with no survey evidence. Fix: trace every gap row back to a theme section.
- Citations the student cannot explain. Papers added to look thorough. Fix: cut any paper you cannot summarise in one sentence from your own notes.
- A survey written after the build. When the survey is written last, it describes what was built instead of justifying it. Fix: write the survey before finalising the feature, and revise it if the build changes direction.
What to check before submitting
Read the survey once as your guide will read it, and answer honestly:
- Can a stranger state your base paper and your gap after reading only the introduction and the gap section?
- Does every comparison table row answer the same questions for every paper?
- Is every number in the survey accompanied by its conditions, and labelled as the paper's claim where it is one?
- Does the reference list match the citations exactly, in order, with no extras and no gaps?
- Is there any sentence you could not explain or defend in a review meeting? If so, rewrite or cut it.
If the answer to any of these is no, fix that section before submitting. A survey that passes this check is also much easier to defend later: the viva guide on defending a base-paper project builds directly on the base-versus-own map this survey creates.
Frequently asked questions
How is a literature survey different from a literature review?
In student project documents the terms are often used interchangeably. Strictly, a survey maps what exists; a review judges it. A base-paper survey should do both jobs in miniature: map the field by theme, then judge each theme well enough to name a gap. If your department template uses one term, follow the template's section headings and do not argue terminology with it.
How many papers should a Phase-1 survey cite?
There is no universal number, and any guide that states one as a rule is inventing it. Department templates and your guide's instruction set the expectation. As practical guidance, a base paper plus roughly eight to fifteen supporting papers gives most teams enough material to compare by theme without collapsing into summaries. Quality of comparison matters more than count.
Should the survey mention papers I disagree with?
Yes, especially those. An alternative you engage with and reject for stated reasons strengthens your gap more than an alternative you ignore. Ignored alternatives are the first thing a knowledgeable reader notices, because they suggest the survey searched only for agreement.
Can I cite a paper I have only read the abstract of?
Do not cite it as if you read it. Either read it to the method-and-results level before citing, or leave it out. A citation is a claim that you understood the work well enough to place it in your argument. Abstract-only citations fail under the first serious question about them.
What if my base paper has very few papers around it?
That is itself a finding, and it should be stated carefully. A genuinely new area has a thin literature; a badly searched area only looks thin. Show the search you did — the terms, the venues, and the neighbouring fields you checked — before concluding the gap is real. Your guide can then judge whether the thinness is a strength or a warning.
Does the survey need to mention my own feature in detail?
No. The survey names the feature and the gap it addresses; the design, implementation, and evaluation belong in later sections. A survey that drifts into full design detail loses its argument shape and duplicates work the report does elsewhere. One gap table and one paragraph per gap is enough.
Limitations
This guide describes a survey method, not your department's template. Templates differ on section names, citation style details, page limits, and how many papers Phase-1 expects, and the template wins every time it conflicts with this guide. The worked example uses two tracker-verified papers only to illustrate structure; it does not claim their results, and it does not supply a gap for your project. Your gap must come from your own reading. Finally, a strong survey improves your chances in review; it does not guarantee approval, publication, or any particular result, and no survey can rescue a base paper that is not implementable with the data and compute you actually have. If that is your situation, the reproduction guide on reproducing a base paper's results first will surface the problem earlier, when it is still cheap to change direction.
Get help with an IEEE base-paper project
If you want Projectech to build your IEEE base-paper project, send a WhatsApp enquiry describing your topic, your base paper if you have one, and the scope you need: base-paper selection or approval support, baseline reproduction, your own-feature build, and Phase-1 to Phase-2 documentation including the literature survey. We will reply with a quotation covering that scope, the price set after your topic, base paper, and compute needs are locked, and delivery across Phase-1 to Phase-2. Final approval of your topic and documents always rests with your own guide and college.
Related reading: IEEE base paper vs regular project, choosing a dataset for your base-paper project, and Phase-1 vs Phase-2 submissions. The live base-paper builds behind these guides include the self-supervised ViT defect-detection project and the federated LoRA fine-tuning project.