The documents you will be asked for
| Document | Purpose | When to write it |
|---|---|---|
| Synopsis / abstract | One-page summary of problem, approach and outcome | Before development, refined at the end |
| SRS | Numbered functional and non-functional requirements | After design review, before coding |
| Design document | Architecture, ER diagram, UML set, screen designs | Alongside implementation of each module |
| Test document | Test cases with expected and actual results | As each module is completed |
| Project report | The full narrative from problem to conclusion | Chapter by chapter throughout |
| User manual | How to install and operate the system | Final two weeks |
Write in this order, not front to back
- Start with the implementation chapter as each module is finished — the details are fresh and it is the hardest chapter to reconstruct later.
- Write the design chapter next, correcting the diagrams to match what you actually built rather than what you planned.
- Add the testing chapter as tests are run, capturing real outputs rather than idealised ones.
- Write the literature survey and the existing-system study when you have time between build milestones.
- Write the results and conclusion once the system is complete and measured.
- Write the abstract last. It is a summary of what exists, and writing it first guarantees it will be wrong.
Diagrams that are actually required
- System architecture: components and how data moves between them. Every report needs this one.
- ER diagram: entities, attributes and relationships with cardinality marked.
- Data flow diagram: level 0 and level 1 at minimum, for departments that require DFDs.
- Use case diagram: actors and what each can do — the fastest way to show role separation.
- Sequence diagram: for your two or three most important flows, such as login or booking.
- Class diagram: for object-oriented projects, and expected in most MCA submissions.
- Deployment diagram: where components run, particularly for cloud and IoT projects.
Screenshots that look professional
- Crop to the relevant region. Full desktop captures with a visible taskbar look careless.
- Use realistic seed data. Screens filled with test1, test2 and asdf undermine the whole report.
- Number and caption every figure, and refer to each one from the body text.
- Keep a consistent window size across captures so the report looks composed rather than collected.
- Include error states, not only success states — showing validation working is evidence of quality.
Writing test cases panels accept
A test case table needs an identifier, the input, the expected result, the actual result and a pass or fail status. Tables where every row passes look invented; include the failures you found and fixed, with a note that they were resolved.
| ID | Test case | Input | Expected | Actual | Status |
|---|---|---|---|---|---|
| TC-01 | Login with valid credentials | Registered email and password | Dashboard loads | Dashboard loads | Pass |
| TC-02 | Login with wrong password | Valid email, wrong password | Error message, no session | Error message shown | Pass |
| TC-03 | Book an already-taken slot | Slot booked by another user | Booking rejected | Rejected with message | Pass |
| TC-04 | Submit form with empty required field | Blank name field | Validation error | Initially accepted — fixed in v1.2 | Pass |
Citations and academic honesty
Cite every dataset, paper, library and code source you used. A report with no references reads as though nothing was researched; a report with references you clearly did not read reads worse, because panels ask what a specific paper concluded.
Where you adapted existing code, say so and describe what you changed. This is normal engineering practice and is treated far better than an undisclosed copy discovered during the viva.
Formatting details that cost marks
- Follow your department's template exactly — margins, font, line spacing and heading style.
- Number every figure and table, and reference each from the text.
- Keep a consistent tense: past tense for what you did, present tense for what the system does.
- Do not paste generic definitions of well-known technologies; explain how you used them instead.
- Check page numbers, the table of contents and the list of figures after the final edit — these break silently.