A UK computer science dissertation normally runs 8,000–12,000 words across six chapters: introduction, background/literature review, requirements and design, implementation, evaluation, and conclusion. Here is a full annotated model built around one worked project, so you can see exactly what goes in each chapter and how they connect.
Step 1: Choose one project to model the whole dissertation around
This model uses a single illustrative project throughout: a machine-learning classifier that detects phishing emails from message text and header features. It is a labelled teaching example — not a real submitted dissertation, and no results, accuracy figures or code in it are genuine findings. The shape below scales up or down for a web application, a mobile app, a systems/networking project, or a theoretical/algorithmic dissertation; where the content genuinely differs by project type, it is flagged.
If you have not settled on your own project yet, the strongest CS dissertation topics share three traits: they are scoped to something buildable and evaluable in the time available (not “build a better internet”), they have an existing body of work to compare against (so your evaluation has a baseline), and they let you make and defend at least one non-obvious design decision. A project with no comparable prior work sounds ambitious but is genuinely harder to evaluate rigorously than a more modest, well-scoped one. A supervisor’s early “can you actually finish this by the deadline?” is usually worth taking seriously — scope creep on a build-a-tool project is one of the most common reasons an implementation chapter runs out of runway before the evaluation is properly done.
Step 2: Write the introduction chapter
The introduction states the problem (phishing remains one of the most common initial-access vectors in cyber incidents), why an automated classifier is worth building (manual detection does not scale, existing filters miss adapted attacks), your aim in one sentence, three or four objectives that are individually testable (e.g. “implement a classifier achieving at least 90% precision on a held-out test set”), and a one-paragraph roadmap of the chapters that follow. Objectives written as measurable claims here become the checklist your evaluation chapter proves or disproves later — write them so a marker could tick each one off.
Step 3: Write the background / literature review chapter
This chapter does two jobs: it explains the technical background a reader needs (what phishing detection approaches exist, how classifiers of this kind are typically evaluated), and it reviews related work critically — not just “X did Y,” but what each approach’s limitation is and how your project responds to it. For a CS dissertation this review sits closer to a technical literature survey than a social-science one: expect to synthesise papers, existing tools and datasets rather than policy documents. End the chapter by stating the specific gap your project fills (for the illustrative example: most public phishing datasets are old and do not reflect current attacker language, so part of the contribution is a refreshed feature set).
Step 4: Write the requirements and design chapter
State your functional and non-functional requirements explicitly, then justify your design decisions against them. A labelled fragment of what that requirements table looks like for the illustrative project:
| Type | Requirement | How it is tested |
|---|---|---|
| Functional | The system shall classify an email as phishing or legitimate | Unit test against a labelled sample set |
| Functional | The system shall flag the specific features that drove a classification | Manual review of explanation output on 20 sample emails |
| Non-functional | Classification shall complete in under 200ms per message | Timed benchmark over 1,000 messages |
| Non-functional | The training pipeline shall be reproducible from a fixed random seed | Re-run and compare output hashes |
Then justify your design decisions against these rows — which algorithm family you chose and why (for a phishing classifier: logistic regression as a transparent baseline, then a gradient-boosted or transformer-based model for the main result), your data pipeline, and your system architecture as a labelled diagram. For a build-a-tool project (web app, mobile app), this chapter carries UML or wireframe diagrams instead; for an algorithmic/theoretical dissertation, it carries the formal problem definition and the algorithm design instead of a system architecture diagram. Whichever shape your project takes, every design decision in this chapter should trace back to a requirement stated at its start — an unjustified design choice is one of the most common reasons this chapter under-marks.
Step 5: Write the implementation chapter
Implementation is not a code dump. Markers want the interesting decisions: how you handled a specific technical challenge, what you tried and rejected, how the pieces of the system fit together. A practical structure: one section per major component (data pre-processing, feature engineering, model training, the interface, if any), each stating what it does, one implementation decision worth discussing, and one problem encountered and how you solved it. Include short, labelled code snippets only where they illustrate a genuine design decision — not as padding. State your tech stack and tooling explicitly and briefly here; the tool stack for a computer science dissertation compared covers version control, environments and reproducibility choices in depth if you have not settled these yet.
Step 6: Write the evaluation chapter
This is the chapter that separates strong CS dissertations from weak ones, and it deserves a full treatment on its own — see how to write the evaluation chapter of a computer science dissertation for the complete method (defining criteria, choosing between benchmark and user evaluation, reporting honestly, writing the critical reflection). In outline, report your metrics against the objectives you stated in the introduction, compare against at least one baseline, and discuss honestly where the system fails. For the illustrative project, that table might look like this:
| Model | Precision | Recall | F1 | Notes |
|---|---|---|---|---|
| Baseline: keyword rule list | 0.71 | 0.58 | 0.64 | Fails on adapted phrasing |
| Logistic regression (this project) | 0.85 | 0.79 | 0.82 | Transparent, fast to explain |
| Gradient-boosted model (this project) | 0.93 | 0.88 | 0.90 | Best F1, slower to explain individual decisions |
A dissertation that only reports success (only the best row, with no baseline and no discussion of the trade-off between the two of your own models) rarely convinces an examiner it was evaluated rigorously — the value is in showing you can compare, not just achieve a single number.
Step 7: Write the conclusion
Short, under 500 words. Restate what you built and whether it met its objectives (yes, partially, or no, each stated plainly), the main contribution in one sentence, the main limitation, and two or three named directions for future work that follow specifically from what you found — not generic suggestions any project in the field could make.
What do markers actually expect, and where does that come from?
UK computing programmes are informed by the QAA’s Computing Subject Benchmark Statement (2022), which sets out what graduates in computing subjects are expected to know, do and understand by the end of their studies; individual departments translate this into their own marking criteria, so always check your own module handbook for the exact weighting your programme uses rather than assuming the split below is universal. Broadly, across UK CS dissertations, the evaluation and critical-reflection content (Steps 6–7) tends to carry more weight than the implementation effort itself — a working system with a thin evaluation typically scores lower than a more limited system evaluated rigorously.
How much time should each chapter realistically take?
Across a typical two-semester final-year project, implementation absorbs the largest single share of calendar time (commonly 8–10 weeks once the design is settled), but it should not absorb the largest share of your writing effort — the evaluation chapter, though shorter, usually needs more drafting and redrafting because the argument (not just the numbers) has to be right. A common failure pattern is spending so long building that the evaluation is rushed in the final week; building in a hard stop for implementation, with two to three weeks reserved purely for evaluation and write-up, protects the chapter that carries the most marks.
What mistakes cost the most marks?
Four recur across UK computer science dissertations. First, an implementation chapter that reads as a guided tour of the codebase rather than a discussion of decisions — markers can read the code appendix themselves; the chapter should explain why, not what. Second, an evaluation with no baseline, so a reported number has nothing to be judged against. Third, requirements stated in the design chapter that are never actually tested against in the evaluation chapter — every requirement you state should reappear as something you checked. Fourth, treating the literature review as a list of tools and papers rather than a critical argument for why your approach is justified given what already exists.
How does this compare with other dissertation shapes?
A computer science dissertation is normally a design-and-build project — distinct from the empirical (survey/interview-based), literature-based, and doctrinal shapes other disciplines use. See undergraduate dissertation structure by subject for how the design-and-build shape compares chapter-by-chapter with those other structures, and for its six worked subject skeletons.
How does Tesify help with a dissertation shaped like this?
Tesify can draft your background review from a reading list, structure your evaluation chapter around the metrics you actually collected, and turn implementation notes into a readable chapter without inventing results you did not obtain.
Frequently asked questions
Does every computer science dissertation have to build something?
No. Design-and-build is the most common shape, but algorithmic/theoretical dissertations (proving a property of an algorithm, or a formal analysis) and systematic-review-style dissertations of an active research area are both accepted at many UK universities. Check your own department’s approved project types.
How long should a UK computer science dissertation be?
Most programmes set 8,000–10,000 words for the written report, with code submitted separately and not counted toward the word limit. Always confirm the figure and what counts toward it in your own handbook.
Should I include all my code in the dissertation body?
No — include short, labelled snippets that illustrate a specific design decision, and submit the full codebase separately (a repository link or a code appendix, per your department’s submission process).
What is the difference between the requirements/design chapter and the implementation chapter?
Design states and justifies what you decided to build and why, before you built it; implementation reports what actually happened when you built it, including the problems you hit and how you solved them.
Do I need a baseline for comparison in my evaluation?
Almost always, yes. A result reported without any point of comparison (a simpler model, an existing tool, or a published benchmark) is very hard for an examiner to judge as good, mediocre or poor.
What if my system does not work as well as I hoped?
Report it honestly and explain why. A rigorous evaluation of a partially successful system, with a credible account of what went wrong, generally scores higher than an implausibly perfect result with no discussion of limitations.
Can I use a project idea from a company or client?
Yes, many CS dissertations are client- or placement-based; the chapter structure above still applies, with an added early section on requirements gathering from the client, and usually a data-confidentiality note in the ethics/appendix material.
How many related-work papers should the background chapter review?
There is no fixed number, but fifteen to twenty-five relevant sources, critically discussed rather than just listed, is typical for an undergraduate CS dissertation background chapter.
Do I need formal ethics approval for a build-a-tool project?
Usually only if your project involves human participants (a user study, usability testing) or personal data. A purely technical build with no human subjects and no personal data typically needs only a lighter self-assessment; check your department’s ethics process, since this varies by institution.
Should the dissertation report negative or null results?
Yes, if that is genuinely what you found. A well-reasoned account of why an approach did not outperform a baseline, with a credible explanation, demonstrates the same critical-evaluation skill as a positive result — hiding a negative finding, or quietly dropping a metric that came out badly, is more likely to be noticed and penalised than the negative result itself.