In this guide
Your synopsis is the first formal document of your project — and the cheapest place to fix a bad idea. A weak synopsis approved without scrutiny becomes a weak project defended under pressure. A strong one gives you a contract: build what you promised, and the examiners judge what you promised. Aim for 2–4 tight pages, not a padded ten.
The five elements of an approvable synopsis
1. Problem statement: one paragraph, one specific gap
Open with a single paragraph that names a real, specific problem — not "the world needs IoT" but "small dairy farmers in our district lose milk to spoilage because they can't monitor chilling-unit temperature remotely." Name the gap: what exists, and what specifically is missing. If you can't state the gap in two sentences, you don't have a topic yet — go back to how to choose a final-year project topic before writing another word.
2. Objectives: 3–5, and checkable
Objectives are the heart of the synopsis — they are what approval locks in, and what your viva will be judged against. Each objective must be checkable: a reviewer should be able to tell, at the end, whether you met it.
| Weak objective | Checkable version |
|---|---|
| To study IoT sensors | To interface a DHT22 sensor with an ESP32 and log temperature/humidity every 10 minutes |
| To make the system efficient | To keep measurement error within ±2% of a calibrated reference across 50 samples |
| To develop an app | To build an Android app showing real-time readings with 24-hour history graphs |
Three to five objectives is the sweet spot: fewer looks thin, more looks unfocused. And fix them before approval — changing objectives later usually means resubmission.
3. Methodology: a plan, not a technology list
"We will use Arduino, sensors, and IoT" is not a methodology — it's a shopping list. A methodology is a plan written in phases: first the literature and component survey, then hardware design and interfacing, then firmware development, then calibration and testing, then documentation. For each phase, say what you will do and what comes out of it. Reviewers reading a real plan think "this student has thought it through." Reviewers reading a tech list think "this student will figure it out later" — which is exactly what gets a synopsis sent back.
4. Literature review: short and gap-oriented
You don't need twenty references — you need five to eight good ones, organised around the gap. For each piece of existing work, one line on what it did and one line on what it missed. The review should read as an argument: "others did A and B; nobody did C; my project does C." That argument is what justifies your topic's existence. Cite properly and keep full references for the final report — you'll expand this section later.
5. Timeline: realistic and backward-planned
Include a simple phase-wise timeline working backward from submission: documentation and testing blocked out first, then the build. Reviewers check whether your plan fits the semester — an eight-phase plan in a twelve-week semester with no testing block is an instant red flag. See how to pick a project that fits your timeframe for the method.
Tip: Write the objectives first, then the problem statement, then everything else. The objectives are the load-bearing wall — when they're checkable and right-sized, the rest of the synopsis almost writes itself around them.
Why synopses get rejected
| Rejection reason | What the reviewer saw | Fix |
|---|---|---|
| Vague objectives | "To study," "to understand," "to explore" | Rewrite every objective so it's checkable |
| No identifiable gap | Topic already done identically elsewhere | Narrow to a specific, honest differentiation |
| Tech list as methodology | Components named, no plan described | Rewrite as phased plan with outputs per phase |
| Unrealistic scope | Six subsystems in one semester | Cut to what fits; note future scope separately |
| Copied synopsis | Familiar text from a known source | Start from your own problem statement — it's obvious when it's borrowed |
Before you submit
Read the whole document once asking a single question: "could someone build the wrong project from this?" If the objectives are checkable and the methodology is a real plan, the answer is no — and you're ready. Get your guide's informal read before the formal submission; a ten-minute review now saves a rejection cycle later. Once approved, treat the objectives as fixed and build exactly what you promised.