Below is a complete, labelled worked example of a Computer Science FYP built as a system-development project — not a real thesis to copy, but a full annotated model showing what belongs in each of the five chapters, using an illustrative project called the Smart Hostel Maintenance Reporting System.
What “Complete Example” Means Here
This is a fully constructed illustrative model, chapter by chapter, built specifically to show structure and depth — not a document lifted from a real repository. If you want to see real completed theses for comparison, your faculty’s own repository (many Malaysian universities run one, often called the Institutional Repository or IR) is the only legitimate place to read actual student work; treat any FYP shared outside official channels as a plagiarism risk to both of you. This article is also a different shape from a Chapter 4-only guide: it walks the whole thesis, start to finish, using one running example so you can see how each chapter’s decisions carry forward into the next.
Step 1: Choose a System-Development Topic That Fits One Semester
The single biggest reason CS FYPs run out of time is a scope that needed a team of five, not one student in a single semester. A buildable topic has three properties: a clearly bounded set of user roles (two or three, not an entire organisation), one core workflow you can demo end to end, and a tech stack you already know or can learn in the first two weeks. The example below — a system for hostel residents to report maintenance issues and for wardens to track and close them — has exactly two roles (resident, warden), one core workflow (report → assign → resolve → close), and a standard web stack, which is why it works as a teaching example.
Step 2: Chapter 1 — Introduction
Chapter 1 sets up everything Chapters 2–5 must deliver on. Written short and specific, not as a general essay about technology:
- Background: At the illustrative hostel in this example, maintenance requests are still submitted via WhatsApp messages to a warden’s personal phone or a paper form left at the office — both untracked, both easy to lose, with no record of how long a request has been open.
- Problem statement: Residents have no way to check the status of a submitted report, and wardens have no dashboard showing which reports are overdue, resulting in repeated follow-up messages and reports that are forgotten entirely.
- Objectives (three, each matched to a chapter-4 deliverable): (1) to design and develop a web-based system for residents to submit and track maintenance reports; (2) to implement a warden dashboard for assigning and closing reports with status tracking; (3) to evaluate the system’s usability with a representative group of hostel residents and wardens.
- Scope: One hostel block, maintenance reports only (not billing, room allocation, or other hostel services), tested with a pilot group rather than the whole hostel population.
- Significance: A working prototype the hostel management office could pilot, and a documented system-development process the next student building a related system can reference.
Step 3: Chapter 2 — Literature Review
A system-development FYP’s literature review does two jobs a research-question FYP’s does not: it reviews academic literature on the problem domain (facilities/maintenance management systems, ticketing-system usability), and it reviews comparable existing systems as a requirements source, not just as citations. A comparison table is the expected artefact:
| System | Ticket status tracking | Role-based dashboard | Mobile-friendly | Gap this project addresses |
|---|---|---|---|---|
| Generic university helpdesk ticketing system | Yes | Yes | Partial | Not hostel-specific; no maintenance-category routing |
| WhatsApp-based reporting (current practice) | No | No | Yes | No status tracking, no accountability trail |
| Commercial facilities-management SaaS | Yes | Yes | Yes | Licensing cost and setup complexity unsuited to a single hostel block |
The literature review closes with the gap statement that justifies Chapter 1’s problem statement: none of the compared systems is both free to run and scoped to a single hostel’s actual workflow.
Step 4: Chapter 3 — Methodology
Name the actual development methodology and defend the choice against at least one alternative. For a solo one-semester build, an Agile/Scrum-inspired iterative approach with two-week sprints is defensible against Waterfall because requirements (which report categories, which notification channel) are likely to change once real hostel residents give feedback — a Waterfall sign-off-then-build sequence would not accommodate that. Chapter 3 for this example includes: requirement-gathering method (short structured interviews with 3 wardens and a 10-respondent survey of residents), a use-case diagram showing the resident and warden actors against the core workflow, an entity-relationship diagram for the reports/users/status-history tables, and the chosen stack stated explicitly (e.g. a relational database, a server-side framework, and a front end) with a one-line justification for each choice.
Step 5: Chapter 4 — Implementation and Testing
Chapter 4 for a system-development FYP documents what was built and how it was verified, not a results table from a survey. For the depth this chapter needs on screenshots, module breakdowns, and test-case tables, see the dedicated Chapter 4 guide linked below — the short version for this worked example: three modules (report submission, warden dashboard, status notification), a test-case table mapping each objective to a specific test (e.g. “resident can submit a report with a photo attachment — pass/fail”), and a short discussion of at least one implementation obstacle (for example, handling photo uploads within the university’s file-size limits) and how it was resolved.
Step 6: Chapter 5 — Discussion and Conclusion
Chapter 5 answers three questions in order: did the system meet its three objectives (referenced back to Chapter 1, one sentence per objective); what did the usability evaluation with the pilot group actually show (a short System Usability Scale score or structured feedback summary, not just “users liked it”); and what are the honestly stated limitations (a single hostel block, a short pilot window, no integration with the university’s existing student database) and the two or three most useful directions for future work (multi-hostel deployment, integration with the existing maintenance staff scheduling system).
The Reference List Shape
A system-development FYP’s reference list typically mixes three source types in APA 7th edition format: academic literature on the problem domain and on software engineering methodology (journal articles, conference papers), technical documentation for the frameworks and tools used (cited as a webpage with an organisation as author where no individual author is given), and any comparable systems referenced in Chapter 2 (cited as a webpage if reviewed from public marketing material, or as a software citation if you used it directly). The required number of sources is set by your faculty or supervisor; a sizeable share of technical documentation is normal for this project type and is not, on its own, a weakness.
A 14-Week Pacing Plan for This Example
The chapter order above is the order you write in, but it is not the order you build in — Chapter 3’s design work and Chapter 4’s implementation run in parallel with drafting, not strictly after it. An illustrative pacing plan for the Smart Hostel Maintenance Reporting System, assuming a 14-week build window (adjust it to your own programme’s calendar):
| Weeks | Focus |
|---|---|
| 1–2 | Confirm topic and scope with supervisor; draft Chapter 1; begin stack setup |
| 3–4 | Literature review and comparable-systems research; finalise Chapter 2 |
| 5–6 | Requirement gathering (interviews/survey); use-case and ER diagrams; draft Chapter 3 |
| 7–10 | Build core modules iteratively; write test cases as each module is completed |
| 11–12 | Pilot usability evaluation with residents and wardens; draft Chapter 4 |
| 13 | Write Chapter 5; revise all chapters for consistency; check every objective has a matching test result |
| 14 | Final formatting, reference-list check, submission |
The most common pacing mistake is spending weeks 1–6 on Chapters 1 and 2 alone and leaving only four weeks for the build — start setting up your development environment and a minimal working skeleton in week 2, well before Chapter 3 is finished, so implementation problems surface while there is still time to change scope.
What Makes Examiners Fail a Model Like This
- Objectives in Chapter 1 that Chapter 4’s testing never actually verifies — every objective needs a matching test case or evaluation result.
- A literature review with academic citations but no comparable-systems comparison, leaving the “why build a new system” question unanswered.
- A methodology chapter that names Agile but shows no evidence of iteration — no sprint log, no changed requirement, no version history.
- Screenshots in Chapter 4 with no accompanying explanation of what the screen demonstrates or which requirement it satisfies.
- A conclusion that claims success without the honest limitations a solo, one-semester, single-hostel pilot obviously has.
Frequently Asked Questions
Does my system have to be fully deployed on a live server, or is a local demo acceptable?
A local or university-lab demonstration is normally acceptable — what examiners check is that the system runs and the core workflow can be demonstrated live, not where it is hosted.
Can I use a no-code or low-code platform instead of writing custom code?
Check your faculty’s rules first; many computer science FYPs specifically require custom-coded implementation to demonstrate programming competency, while information systems or IT-management programmes may accept a configured platform if the configuration and integration work is substantial.
How many test cases does Chapter 4 need?
Enough to cover every core function tied back to an objective, plus the main edge cases and error handling — there is no fixed number, so agree the expected coverage with your supervisor.
What if my system doesn’t fully work by submission?
Document honestly what works, what doesn’t, and why in Chapter 5’s limitations — examiners generally penalise overclaiming far more heavily than an honestly reported incomplete feature.
Should Chapter 2 include a review of programming languages, or only of comparable systems?
Both, briefly — a short justified comparison of your chosen stack against one or two alternatives, plus the fuller comparable-systems review shown above.
Do I need a control group for the usability evaluation?
Usually not — many undergraduate CS FYPs use a single-group pilot evaluation (System Usability Scale or structured feedback) rather than a controlled experiment; a control group is more common in postgraduate human-computer interaction research.
Is UML required, or can I use a different diagramming notation?
UML (use-case, class, and ER-style diagrams) is widely expected in Malaysian CS faculties; check your own handbook, since some accept alternative notations if used consistently.
How is this different from a research-based (non-development) CS FYP?
A research-based CS FYP (for example, comparing two machine-learning algorithms on a dataset) follows a data-analysis structure closer to a science thesis, with Chapter 4 reporting statistical or experimental results rather than a built system and test cases — the two project types share Chapters 1, 2, and 5’s shape but differ substantially in Chapters 3 and 4.
Tesify can turn your own project’s Chapter 1 objectives and Chapter 3 methodology decisions into a full first draft across all five chapters — you still verify every technical claim it makes. Draft your FYP chapters with Tesify.
For the full depth on Chapter 4 screenshots, module documentation and test-case tables, see what goes in Chapter 4 of a computer science FYP if you built a system. For the proposal stage that comes before Chapter 1, see how to write a thesis proposal for a Malaysian FYP or postgraduate programme. For the general methodology-chapter structure this example adapts in Chapter 3, see how to write the methodology chapter of a Malaysian FYP or thesis. For how to report evaluation findings the way Chapter 4 above does, see how to write the results chapter of your FYP or thesis. For finding the academic sources Chapter 2’s literature review needs, see best AI tools for finding papers and building a literature review.