A Canadian computer science thesis is structured around a system or a study, not around a generic five-chapter template: introduction, related work, design, implementation, evaluation, and conclusion, with the evaluation chapter carrying the real argumentative weight. Get the evaluation chapter’s research questions and baselines right and the rest of the structure follows.
What are the standard chapters of a Canadian computer science thesis?
- Introduction: the problem, why it matters, your contribution stated as one or two sentences, and a roadmap of the thesis.
- Related work: the existing systems, algorithms or studies your contribution improves on, organized by approach rather than by publication date.
- System design or methodology: the architecture, algorithm or model you propose, at a level of abstraction a reader could reimplement from.
- Implementation: the concrete engineering decisions, language, framework, dataset, that turned the design into a working system.
- Evaluation: the experiments, metrics and comparisons that test whether your contribution does what you claimed.
- Discussion and conclusion: what the results mean, the threats to validity, and the future work you are explicitly leaving open.
Some Canadian programs, University of Waterloo’s Master of Mathematics in Computer Science among them, allow a thesis built from one or more published or submitted papers with a connecting introduction and conclusion; check your school of graduate studies’ formatting guide before assuming the traditional monograph structure is the only option.
Which chapters you actually need also depends on whether your contribution is a system, an algorithm, or an empirical study of existing systems. A pure algorithms thesis often merges design and implementation into one theoretical chapter with a complexity or correctness proof standing in for an experimental evaluation; an empirical or measurement study, common in networking and security research, replaces the design chapter with a data collection methodology chapter describing how you gathered and validated the measurements you are analyzing. State which of these three shapes your thesis is in your introduction, since it changes what a reader should expect from every chapter that follows.
How do you write a related work chapter that is not just a list?
Organize by approach or by the design trade-off you are making, not by chronology or by author. A related work chapter that reads “Smith et al. did X. Then Jones et al. did Y. Then Lee et al. did Z.” tells an examiner you read the papers but not that you understood how they relate to each other or to your contribution.
Group papers into two or three families defined by a genuine methodological difference, for example systems that trade accuracy for latency against systems that trade latency for accuracy, and end each family’s discussion with the specific gap your thesis fills. The last paragraph of the chapter should state, in one sentence, exactly what no prior system in any family does that yours does.
How do you structure the system design chapter?
Present the design at the level of abstraction a competent reader could reimplement from, without yet committing to a specific programming language or library. State the problem formally where a formal statement is possible, describe the architecture with a labelled diagram, and justify each major design decision against at least one alternative you considered and rejected. A design chapter that presents only the option you built, with no discussion of alternatives, reads as description rather than as engineering judgment, and a committee member will ask what else you considered.
What belongs in the implementation chapter rather than the design chapter?
The implementation chapter is where the language, framework, libraries, dataset and deployment environment actually appear, along with the engineering decisions that were forced by real-world constraints your design chapter did not anticipate. State version numbers for every dependency that affects reproducibility, the hardware you ran on, including GPU model and memory where relevant, and any deviation from your original design that the implementation required, with a one-sentence justification for each.
Report scale honestly rather than implying more than you built: state the size of your codebase, the number of lines of code or modules where that figure is meaningful, and whether your system is a research prototype, a partial reimplementation of a published baseline, or a production-grade artifact. A committee member who later asks “does this actually work end to end, or only on the cases you showed” is really asking whether the implementation chapter answered that question already.
How do you structure the evaluation chapter?
Open with the specific research questions your evaluation answers, stated as questions, not as hypotheses about your system being “better.” Then, for each research question, state your baseline or baselines, your dataset and its provenance, your metrics, and your experimental protocol in enough detail that another researcher could rerun it.
- State the research question: what, specifically, are you trying to establish?
- Name your baseline: the existing system, algorithm or naive approach you are comparing against, and justify why it is the right comparison.
- Name your dataset: its source, size, and any preprocessing or filtering you applied, with the filtering criteria stated.
- Name your metrics and why they are the right ones for this research question, not simply the metrics your related work used.
- Report results with variance, not a single run: repeated trials with a mean and standard deviation, or a confidence interval, for any result subject to randomness.
- State significance where you are making a comparative claim: a difference between two systems needs a statistical test, not an eyeballed gap in a bar chart.
Where your evaluation involves a formal statistical comparison across conditions, the decision tree for which test to use is the same one used across quantitative research more broadly, covered in the guide to which statistical test to use, and once you have chosen a package to run it in, the trade-offs are set out in the comparison of statistics software for a Canadian thesis.
What is the ACM artifact review and badging system, and should you use it?
The Association for Computing Machinery runs a formal artifact review and badging scheme that many top systems and software engineering venues now apply, and it gives you a ready-made rigour standard to hold your own thesis to even if you are not submitting to one of those venues. The tiers run roughly: Artifacts Available (your code and data are published in a permanent archive), Artifacts Evaluated, Functional or Reusable (an independent reviewer confirmed the artifact runs and, at the Reusable tier, is documented well enough for others to build on), and Results Reproduced or Replicated (an independent party ran your artifact and obtained your reported results, either using your data, Reproduced, or a fresh version of your experiment, Replicated).
Stating in your methodology chapter that your artifact meets a specific ACM badge tier, and archiving your code accordingly on a permanent repository rather than only on a personal GitHub account, is a concrete, checkable claim of rigour that a Canadian thesis committee will recognize even outside a conference submission.
When does a computer science thesis need Research Ethics Board approval?
Whenever your evaluation involves human participants: a usability study, an A/B test with real users, an interview-based requirements study, or any data collection from identifiable people, even indirectly through logs of their behaviour. Purely algorithmic or systems work tested on public benchmark datasets typically does not require REB review, but the moment your evaluation chapter includes a user study, the approval pathway is the same Tri-Council process every other discipline follows, covered in the guide to REB approval and TCPS 2 rules in Canada. Budget for the approval timeline before you plan your evaluation schedule, not after your study design is finished.
How do you handle datasets and reproducibility?
State the exact dataset version or snapshot date you used, since many public datasets are updated over time and a later reader trying to reproduce your numbers on a newer version will get different results and rightly wonder why. Where you built your own dataset, state your collection and labelling protocol, your inter-annotator agreement if more than one person labelled it, and where the dataset itself is archived for other researchers to access. If your data involves personal or sensitive information, state your anonymization or aggregation procedure explicitly, since this is a point Canadian REBs specifically scrutinize.
How do you write the evaluation methodology paragraph?
Here is a worked example combining the elements above into the register a committee expects.
We evaluate our system against two baselines: a naive nearest-neighbour approach and the current state-of-the-art system of Chen et al. (2024), on the publicly available benchmark dataset (v2.1, accessed March 2026), filtered to exclude sequences shorter than ten tokens. We report mean average precision across five independent runs with different random seeds, and use a paired t-test to assess whether the difference between our system and each baseline is statistically significant at the p < .05 level. All code and the trained model checkpoints are archived at a permanent repository and meet the ACM Artifacts Available and Evaluated, Reusable criteria.
That paragraph belongs at the opening of your evaluation chapter, before any individual result is reported, inside the wider structure covered in the walkthrough of how to write the methodology chapter of a Canadian thesis. A civil engineering thesis validates a numerical model against experimental or benchmark data using the same logic under a different vocabulary, covered in the guide to writing the methodology chapter of a civil engineering thesis.
Can Tesify help you write your evaluation and design chapters?
Deciding on your baselines, your metrics and your architecture is engineering judgment only you can exercise, but drafting the related work synthesis, the design justification paragraphs and the evaluation methodology in the precise register a computer science committee expects is exactly what Tesify is built to help you write.
Draft your thesis chapters with Tesify
Frequently asked questions
Can my thesis be a collection of published papers instead of a monograph?
At several Canadian programs, yes, provided you add a connecting introduction and conclusion that frame the papers as a coherent contribution. Confirm the specific requirement with your school of graduate studies before choosing this format, since not every program permits it at every degree level.
How many baselines do I need in my evaluation?
At minimum one strong baseline representing the best existing approach, plus one simpler baseline, a naive or random approach, that establishes a reasonable floor. Two or three well-chosen baselines are more convincing than five weak ones.
Do I need to release my code publicly?
Not always, but doing so and meeting an ACM artifact badge tier strengthens your thesis’s claim to rigour considerably, and some Canadian supervisors and programs now expect it as standard practice for empirical computer science work.
What if my system has no directly comparable prior baseline?
State this explicitly and construct a defensible baseline yourself, commonly a simplified or ablated version of your own system, or the best available approach from an adjacent problem. An evaluation with no baseline at all is not defensible; an honestly constructed baseline is.
Do I need statistical significance testing for every result?
You need it for any comparative claim, my system outperforms the baseline, where the result could plausibly have arisen from randomness in training or sampling. A purely descriptive result, such as reporting your system’s runtime, does not require a significance test.
How much implementation detail is too much for the thesis body?
Enough to reproduce your results belongs in the body; exhaustive configuration files, full source listings and hyperparameter grids belong in an appendix, referenced from the implementation chapter rather than reproduced inline.
Does a systems thesis need a related work chapter if the field moves too fast for a literature review?
Yes, but keep it current and explicitly note its currency: state the date you last searched the literature, and focus on the two or three most directly comparable systems rather than attempting exhaustive historical coverage.
Is a user study enough evaluation on its own, without a benchmark comparison?
It can be, for systems whose contribution is fundamentally about usability or human factors rather than algorithmic performance, but state this scoping decision explicitly in your evaluation chapter rather than leaving a reader to wonder why no benchmark numbers appear.