The synopsis is the document you submit for approval before you write a single line of code. It is a proposal: it tells your guide what you intend to build, why it is worth building, and that you have a realistic plan to finish it in a semester. Get it signed and you have a green light. Get it wrong and you lose weeks arguing about the idea instead of building it.
Your department has a format document, and it overrides everything below on length, margins and section order. What follows is the structure almost every Indian college converges on, and what actually belongs in each section so the synopsis is approved on the first pass.
1. Title and problem statement
- A title that is specific and buildable, not a slogan
- The problem stated concretely — who has it and why it matters
- What people do today, and where that falls short
A guide approves a synopsis they can picture as a finished system. “Smart AI-based platform for everything” is not that. “A web app that lets a small blood bank match donors to requests by blood group and location” is. The title should already hint at the scope.
2. Objectives you can be held to
- A numbered list, usually three to five items
- Each objective is something the finished system will do
- Phrased so a panel can check whether you met it
Write objectives as outcomes, not activities. “To learn React” is not an objective. “To let a user register, list their available stock, and receive a request notification” is — every clause is testable, and later maps straight to a module and a test case.
3. Scope and what is out of scope
- What the project covers, in plain terms
- An explicit list of what it deliberately does not do
- The user roles the system supports
The out-of-scope list is the cheapest defence you will ever write. It stops the scope creeping during the build, and it answers the viva question “why does it not do X” before it is asked. Declare it now while you still have the leverage to say no.
4. Proposed system
- A plain-language description of what you intend to build
- A simple block or architecture sketch — boxes and arrows are enough
- How it improves on the existing options you named earlier
This is the heart of the synopsis. Keep it concrete. One clear diagram of the parts and what flows between them tells a guide more than three paragraphs of adjectives, and it becomes the seed of your report’s design chapter.
5. Tools and technologies
- Language and framework, named specifically
- Database, and why it fits the data you are storing
- Key libraries or services you already know you will need
List the stack you will actually use, not every technology you have heard of. A menu of ten frameworks signals that you have not decided. A short, deliberate list signals that you have. Pick tools you can already use — the semester is for building, not for learning a stack from zero.
6. Modules
- Four to seven modules the system breaks into
- A one-line description of what each module does
- An indication of which are core and which are optional
Modules are how you show the work is bounded. They map one-to-one onto your objectives and, later, onto the chapters of your report. If you cannot break the system into clean modules on paper, the scope is not clear enough yet.
7. Feasibility
- Technical — the stack is known to you and the problem is solvable
- Economic — it runs on free or already-available tools
- Time — the scope genuinely fits the semester
Keep this honest and short. A guide has seen enough over-ambitious synopses to value one that admits its limits. Time feasibility is the one students underestimate most — a plan that only works if nothing goes wrong is not feasible.
8. Timeline
- A week-by-week or phase-by-phase plan from approval to submission
- Build phases mapped to your modules
- Time reserved at the end for testing, the report and the deck
A Gantt chart or a simple phase table both work. The point is to show the work is planned rather than improvised. Reserve real time at the end for documentation and testing — the students who run out of time run out of it here, not in the build.
9. References
- A handful of real sources — papers, documentation, existing systems
- In your department’s citation style
For MCA and M.Tech, cite actual papers. For BCA and diploma, a survey of the existing applications you are improving on is usually enough. Either way, keep them real — a padded reference list is easy to spot and adds nothing.
The mistakes that get a synopsis sent back
- Scope too large for one semester. The single most common reason. A guide would rather approve a small project done well than a grand one that will never ship.
- A vague problem. If the problem could describe any app, the objectives will be vague too, and nothing can be checked at the end.
- Objectives that cannot be measured. “To make a user-friendly system” is not something a panel can verify. Rewrite it as a specific thing the system does.
- A rebuild of an existing app with nothing new. Another clone of a shopping site with no problem behind it reads as a tutorial, not a project. Name the gap you are closing.
- A stack you cannot yet use. Proposing a technology you have never touched, on a deadline, is a time-feasibility risk the guide can see even if you cannot.
Every project on this site ships with the synopsis, the report, the diagrams and the deck already written to match the code — because the synopsis is where the whole project is either scoped to finish or quietly set up to fail. See the projects, then read the report format chapter by chapter and how to choose a project worth building. If the scope in your head is bigger than your semester, a custom build comes scoped, documented and walked through in live sessions.