How to Document Your FYP Project
A finished project becomes useful to future students and recruiters only when its problem, choices, evidence, and limits are easy to understand.
Document an FYP as a short case study: name the user problem, define the project boundary, explain the one technical decision that mattered, show the evidence, and state the limitations honestly. Lead with what changed for the user, not a list of technologies.
A repository, screenshots, and a technology list do not explain an FYP. They show that work exists, but not why it mattered or whether it achieved anything. Good project documentation turns the final submission into a case study a person outside your department can follow.
Lead with the problem and the boundary
Open with one plain sentence: who had a problem, what made it difficult, and what your project changed. Then state what the project does not try to do. This boundary stops a showcase description from becoming an inflated list of features.
For example, an attendance system might verify a student in one lecture room from a fixed camera. It is not a complete university identity platform. The narrower description makes the technical and evaluation choices understandable.
Show the decision that required reasoning
Every project has routine pieces and one or two choices where the trade-off mattered. Explain those choices: why you selected a model or architecture, how you obtained data, what alternative you rejected, and which constraint shaped the result.
Use evidence, not adjectives
“Accurate,” “fast,” and “user-friendly” are claims, not results. Replace them with a small, honest number: accuracy on a held-out set, average task time, a comparison against the old process, or feedback from a defined group of users. Name the conditions of the test so readers know what the number means.
Show the workflow, state the data or test group, compare against a baseline where possible, and include one screenshot or short recording that makes the working result visible. Remove any personal, private, or client data first.
State limits and next steps clearly
A limitation is not an apology. It tells a reader where the current result is reliable and what needs testing next. A classifier tested on one dataset may not generalise to another campus. A prototype may support one role but not administrators. These details demonstrate engineering judgment.
Finish with the next sensible experiment, not an imaginary product roadmap. That may be collecting a larger dataset, testing with another course, reducing a latency bottleneck, or comparing a second approach.
Publish for the next batch
Use the MyUni FYP Showcase to study how finished projects communicate their scope, then publish a clear account of your own work when it is ready. Students who are still choosing a direction can compare realistic boundaries in FYP Ideas before committing.
Frequently asked questions
What should an FYP project write-up include?+
Start with the user problem, then explain the solution boundary, the important technical decision, the evidence that it worked, its limits, and what you would do next. A reader should understand the project without opening the code.
How is an FYP showcase different from a project report?+
A report records academic detail for assessment. A showcase is a concise case study for a supervisor, recruiter, or junior student. It should lead with the problem and result, then link to the deeper report or repository where appropriate.
Should I include limitations in my FYP portfolio?+
Yes. Honest limits make the work more credible. State what the system was tested on, where it may fail, and the next experiment that would reduce the uncertainty. Do not describe unfinished features as completed work.
Start your project on MyUni
Browse notes from Operating Systems, Machine Learning, Computer Vision and more, or publish your own work to the project showcase so the next batch can learn from it.