The Final Report

Number everything, and refer by number. Figure 4.3, Table 6.2, section 3.5, FR-11, NFR-1, ADR-5. A report whose text says "as shown in the diagram above" cannot survive a page break, and page breaks move when anything is edited.

Use the styles, not the ruler. Heading 1, Heading 2, body, caption: then the contents page, the list of figures and the list of tables are generated and correct. Hand-formatted headings mean a contents page that is wrong by the second edit, and every student who has typed one twice knows it.

Write the abstract last, and twice. Half a page: the problem, what was built, what was measured, what remains. The first version is written after the report and the second after somebody else reads it and cannot tell you what the project does.

Originality and citations

Two different obligations, and students usually meet neither.

Cite what you used. Every standard, source, tool and library that the report leans on, with the version and the date you read it, because a web page today is not the page of six months ago. The worked report's references, in the form the book's own sources file keeps them:

OWASP, Password Storage Cheat Sheet, OWASP Cheat Sheet Series, read 30 September 2026.

W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, read 30 September 2026.

NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication, read 30 September 2026.

OWASP, Application Security Verification Standard 5.0, chapter V6 Authentication, read 30 September 2026.

OWASP, Top 10, 2025, read 30 September 2026.

Michael Nygard, Documenting Architecture Decisions, 15 November 2011.

Peter Pin-Shan Chen, The Entity-Relationship Model: Toward a Unified View of Data, ACM Transactions on Database Systems 1(1), March 1976, pages 9 to 36.

ISO/IEC/IEEE 42010:2022, Software, systems and enterprise architecture description, second edition, November 2022, catalogue entry read 30 September 2026.

Agile Business Consortium, MoSCoW Prioritisation, read 30 September 2026.

Oracle, MySQL 8.0 Reference Manual, and the MySQL product lifecycle page, read 30 September 2026.

Notice the last line of several: read on a date. And notice what the ISO entry says: the catalogue entry was read, not the standard, because the standard is sold. Say what you read, not what you would like to have read; an examiner who asks "what does 42010 require of an architecture description?" is asking exactly this.

Cite code you did not write, in the file and in the report: a function copied from an answer on a forum, a stylesheet from a tutorial, a licensed word list. This project has one such item, the common-password list, and data/README.md records where it came from and under what licence (Chapter 46). A library installed with npm needs no citation beyond the lock file; code pasted into your own files does.

Originality is about the numbers. Copying another group's report is obvious and fatal, and it is not the interesting case. The interesting case is a report that says "the average wait fell to 4 minutes" when nobody measured it, or a limitations section copied from a template, or a chapter of smooth prose that nobody in the group can explain. All three are found in the same way: the examiner asks how you know. Every number in the report must be one you took, and every sentence one a member can defend at the viva (Chapter 76).

The declaration you sign says the work is your own. Signing it while a section is not is worse than a low mark.

The checks before it is bound

Print this page, tick it, and do the ticking with the code and the screenshots open beside you:

Two of those are worth a sentence each. Check 1 is the one that fails, because the code moved after the report was drafted; that is why the code freeze is fourteen days before (Chapter 70). And check 11 needs other people's time: a guide who is away for three days can cost you the deadline, so ask in week 13.

Binding, copies and the deadline

MU prints no format, so this is your college's to answer, and Chapter 70's three questions are the ones to ask: how many printed copies, whose signatures, and whether the examiner reads the repository or a soft copy. Common practice is spiral binding for a mini project and hard binding for a final-year project, one copy for the department and one per student, plus a PDF; but common practice is not a rule, and the only safe source is your guide.

Two practical notes that cost nothing and save a day. Print two days early, because a printer that jams on the last afternoon is a story every teacher has heard. And submit the PDF by email as well if that is allowed, so that there is a timestamp of the version you handed in.

Do this for your project

1. Keep every document as you produce it; the report is their assembly.
2. Work in one document, with styles, and generate the contents page.
3. Number every figure, table and section, and refer to them by number.
4. Cite every standard and source with its version and the date you read it, and say what you read.
5. Cite code you did not write, in the file and in the report.
6. Make sure every number is one you took, and every section defensible by a member.
7. Write the abstract last, and again after somebody else reads it.
8. Run the fourteen checks with the code open, a week before the deadline.
9. Chase signatures early; print two days early; keep a spare copy and the PDF.

Mistakes that cost marks

A report assembled in one night, in four voices, with three names for the same screen.

A contents page typed by hand, wrong by the second edit.

"As shown above", after the layout moved.

Sources with no version and no date, or a claim about a standard nobody read.

A number nobody measured, which the viva finds in one question.

An unsigned certificate, or a guide asked for a signature on the last day.

The college's or the guide's name misspelled.

A PDF whose fonts were not embedded, printed with different ones.

Quick revision

• The report is assembled from documents that already exist; the appendices are almost half of it.
• Contents page: front matter, nine numbered sections, references, appendices A to E; 30 + 23 = 53 pages.
• One document, one voice, styles, generated contents; number everything and refer by number.
• Cite with version and date, and say what you actually read; cite code you did not write.
• Every number is one you took; every section defensible at the viva.
• Fourteen checks before binding, the first being that report, code, screenshots and slides are one version.
• MU prints no format: copies, signatures and soft copy come from your guide.

Questions you must be able to answer

1. Why is the final report described as assembly rather than writing? Because the proposal, feasibility report, SRS, UML set, architecture document, test plan and reports, user manual and screenshots were all produced as the work was done. What remains is the introduction, results, limitations and conclusion, and the editing that makes many documents one.

2. What does a contents page tell an examiner before they read anything? Whether the project was managed: whether design, implementation and testing each have their own substantial section, whether results and limitations exist at all, and whether the appendices hold the evidence the text will lean on.

3. How should a source be cited in a report like this? Author or issuing body, title, version or edition, and the date you read it, because online standards and pages change. If you read a catalogue entry rather than the standard itself, say so: it is what you can defend.

4. What counts as a failure of originality here, beyond copying another report? A number nobody measured, a section copied from a template, or prose no member can explain. All three are found by the same question at the viva, which is how you know.

5. Which of the pre-binding checks fails most often, and why? That the report, the code, the screenshots and the slides describe the same version. The report is drafted while the code is still moving, which is why the code freeze comes first in the last fortnight.

6. What should you ask your guide, and when? In week 13: how many printed copies, whose signatures the certificate needs, and how the examiner will see the repository. All three need other people's time, and none of them is printed in the syllabus.