Your department has a format document. It overrides everything below — get it, read it, follow it exactly on margins, font, line spacing and binding, because those are the marks nobody should ever lose. What follows is the structure almost every Indian college converges on, and more usefully, what actually belongs inside each chapter.
One rule matters more than all of the structure: the report must describe the code you are submitting. The most common way students lose marks here is a report describing a system slightly different from the one on the laptop. Panels check, and a mismatch reads as evidence that neither was made by you.
Front matter
- Title page in your college’s exact format
- Certificate from your guide, signed
- Declaration that the work is your own
- Acknowledgement
- Abstract — 200 to 300 words, written last
- Table of contents, list of figures, list of tables
The abstract is written last and is the only page many examiners read closely before meeting you. It should state the problem, what you built, the technologies, and the outcome — in that order, without adjectives.
Chapter 1 — Introduction
- The problem, stated concretely rather than in generalities
- Why it matters and who it affects
- Objectives, as a numbered list you can be held to
- Scope — and explicitly, what is out of scope
- Organisation of the report
Write the out-of-scope list properly. It is the cheapest defence you have in a viva: “why does it not do X” is fully answered by pointing at a scope you declared in chapter one.
Chapter 2 — Literature survey / existing system
- What already exists — real named systems, not vague statements
- What each one does badly, specifically
- How your project addresses that gap
- Comparison table of existing systems against yours
For MCA and M.Tech this chapter should cite actual papers. For BCA a survey of existing applications is usually enough. Either way, be specific — a panel that recognises the systems you are dismissing will ask whether you used them.
Chapter 3 — System analysis
- Feasibility: technical, economic, operational
- Functional requirements, numbered
- Non-functional requirements — performance, security, usability
- Hardware and software requirements
- Use case diagram and use case descriptions
Number your functional requirements. It lets you map each one to a test case in chapter six, and that mapping is one of the easiest ways to look rigorous.
Chapter 4 — System design
The chapter that carries the most marks. It needs:
- Architecture diagram — the boxes and what flows between them
- ER diagram matching your actual database
- Data flow diagrams, level 0 and level 1 at minimum
- Class diagram or sequence diagram for the core flow
- Database schema — every table, column, type, and constraint
- Interface design — screen layouts and navigation
Include a short justification under each major decision: why this database, why this table is separate, why this flow is asynchronous. Two sentences each. Those sentences are your viva answers, written down in advance while you still remember the reasoning.
Chapter 5 — Implementation
- Technologies used and why each was chosen
- Module-by-module description of what was built
- Key algorithms, in pseudocode
- Selected code snippets — the interesting parts only
- Screenshots of the working application
Do not paste your entire codebase. Nobody reads a forty-page appendix of source, and it signals padding. Include the parts that required a decision, with a paragraph explaining each.
Chapter 6 — Testing
- Testing strategy — unit, integration, system, user acceptance
- A test case table: input, expected output, actual output, pass or fail
- Screenshots of tests running or of validation being triggered
- Known bugs and limitations
Include tests that fail gracefully — invalid input, unauthorised access, empty submission. A test table containing only passes looks fabricated. A table showing that bad input is caught and handled looks like engineering.
Chapter 7 — Results and discussion
- What the system achieves against each objective from chapter one
- Performance figures, if relevant
- For ML projects: metrics, confusion matrix, and error analysis
- An honest discussion of limitations
Chapter 8 — Conclusion and future scope
Short. What was built, what was learned, and three or four specific extensions. Make the future scope concrete — “add multi-language support using the existing translation layer” rather than “the system can be enhanced further”.
Back matter
- References in your department’s citation style
- Appendices — full schema, extended code, questionnaires
The five mistakes that actually cost marks
- Diagrams that do not match the code. An ER diagram with seven tables and a database with four. This is the single most common reason a viva turns hostile.
- Padding. Forty pages of pasted source, three pages on the history of the internet. Examiners have read hundreds of these and spot it instantly.
- Screenshots with placeholder data. “asdf” and “test test” in every field. Seed realistic data before you capture screenshots.
- No limitations section. Every system has limits. Claiming none invites the panel to find them for you, in front of everyone.
- Format violations. Wrong margins, wrong font, missing certificate. Free marks, thrown away at the printer.
Every project on this site ships with the report, the synopsis, the diagrams and the deck already written to match the code — because a report that matches the code is exactly the thing students run out of time to do. See the projects, or read the viva questions panels actually ask.