Computer Science Dissertation Topics for MSc Students: 21 Research Projects With a Dataset, a Baseline and a Twelve-Week Scope

This page scopes twenty-one computer science dissertation topics for MSc students the way a supervisor scopes a project before agreeing to it. Each topic has a research question a measurement can answer, a public dataset or an open specification we opened on 26 September 2026, a published number to beat, a method, the metric that goes in the results chapter, a stretch goal, and a note on what fits in a twelve-week dissertation window. Topics whose data or specification did not open today are not on the page.

The list is for the dissertation, where the research question is what gets marked. Build-and-evaluate projects for a BSc final year or a taught MSc project module are in our separate list of final year projects for computer science and engineering students. Worked samples of the write-up sit in our computer science assignment samples, and our computer science assignment help page explains how we work on a dissertation once the topic is settled. For the write-up itself, our guide on how to write a dissertation takes a masters dissertation from the proposal to submission in eleven steps, with a real UK timetable.

Which Computer Science Dissertation Topics Work at MSc Level?

The topics that work at MSc level have four things: a research question a measurement can answer, data or a specification you can download today, a published number to beat, and a scope that fits your department's dissertation window. Every one of the twenty-one below has all four, because evaluation is where the marks are.

What this page holds

Dissertation topics

21

Module groups

6

Sources opened

37

Weeks in each scope note

12

That rule separates a dissertation from a build. "A recommender system for a bookshop" is a project: it has a deliverable and a demonstration. "Does a time-based split change which recommender wins on the Online Retail data, and by how much at k = 10?" is a dissertation: it has a comparison, a metric and an end. The first belongs on the final-year list linked above; the second belongs here. If you are still choosing between subjects rather than between topics, our guide to how to choose a dissertation topic gives the four tests a topic has to pass before it is worth scoping.

The twenty-one topics are numbered in one sequence across six areas, listed below with a link to each. Within each area the fields are the same seven, in the same order, so two topics can be compared line by line; the Sources section gives the link and the 26 September 2026 access date for every dataset, specification and paper.

Artificial Intelligence and Machine Learning

1. Zero-Shot Against Fine-Tuned Dense Retrieval on BEIR
2. Day-Ahead Wind Forecasting on Open Power System Data
3. Do Tree Ensembles Still Win on Tabular Data?
4. Fairness Under Distribution Shift With Folktables
5. Label-Efficient Medical Image Classification on MedMNIST

Systems and Cloud Computing

6. Filtered Vector Search: Recall Against Throughput
7. WebAssembly Against Native Code in 2026
8. Keep-Alive Policies for Serverless Cold Starts

Cyber Security

9. Concept Drift in Static Malware Detection on EMBER
10. Does a Cheap Defence Transfer Across Robust Models?
11. LLM Detectors Against Static Analysers on SmartBugs
12. Do OpenSSF Scorecard Checks Predict Later Vulnerabilities?

Human-Computer Interaction

13. Cookie Consent Dark Patterns on UK Sites, 2026 Against 2020
14. Passkeys Against Password Plus One-Time Code for First-Time Users
15. What LLM Summaries of Privacy Policies Leave Out

Data Engineering and Big Data

16. Late Data in a Streaming Pipeline
17. Open Table Formats Under an Update-Heavy Workload
18. Catching Schema and Distribution Drift Automatically

Software Engineering

19. Repository Context and LLM Issue Resolution
20. Does a Flaky-Test Classifier Transfer Between Languages?
21. Plausible Against Correct Patches on Defects4J

How Do Supervisors Choose and Mark a Masters Project?

Supervisors choose the project they can assess, and the criteria they publish are mostly about evaluation, analysis and literature rather than code. The University of Sussex publishes its MSc criteria, and its content rules say a literature survey on its own is not acceptable.

Six module groups: the artefact, the evaluation and the criterion that carries most weight

Point of comparison	The Artefact	The Evaluation	Criterion That Carries Most Weight
AI and machine learning	The Artefact A trained model and the script that trains it	The Evaluation A held-out score against a published number	Criterion That Carries Most Weight Quality of evaluation: choice of controls and conditions
Systems and cloud computing	The Artefact A benchmark harness	The Evaluation A curve measured on fixed hardware with the same warm-up	Criterion That Carries Most Weight Quality of evaluation: rigour of application
Cyber security	The Artefact A detector or a defence	The Evaluation Precision, recall or robustness against a paper's figure	Criterion That Carries Most Weight Engagement with the literature
Human-computer interaction	The Artefact A study protocol and a prototype	The Evaluation Participant or rater measures with agreement reported	Criterion That Carries Most Weight Quality of evaluation: choice of methods
Data engineering and big data	The Artefact A pipeline	The Evaluation Latency, cost and error against a batch truth	Criterion That Carries Most Weight Quality of programming and practical development work
Software engineering	The Artefact A classifier or a repair loop	The Evaluation Precision and recall on a shared benchmark	Criterion That Carries Most Weight Engagement with recent developments

Sussex's marking criteria for its MSc Advanced Computer Science dissertations list, in order: "application of or extension of MSc course skills, ideally beyond those taught in that course"; "engagement with the literature, including appropriate selection of papers and analysis of concepts"; "theoretical analysis and development of concepts"; "quality of programming, proofs and other practical development work", where the focus is "organisation, clarity, efficiency, application of advanced methods and novelty" and "a large volume of code is not, by itself, sufficient"; "quality of evaluation, including choice of methods, controls and conditions; rigour of their application, and analysis of data"; and project management, which "will be reflected in the outcomes of the dissertation" (University of Sussex, no date a). On originality the page is explicit: "novelty is not an absolute requirement of an MSc dissertation. However, the work undertaken should engage with recent developments in computer science."

The same school's content page says what a dissertation must contain: "relevant background research, typically drawing on computer science literature"; "some problem-solving aspect, usually with an element of programming", though the focus may be theoretical or experimental; and an evaluation of what has been produced, using tests, experiments, comparisons or analysis. "A literature survey by itself is not acceptable" (University of Sussex, no date b). Read those two pages together and the shape of a good topic falls out: a question, a build that answers it, and an evaluation with controls.

The window is shorter than most students plan for. Edinburgh's Informatics dissertation timetable for 2026 has students start work on 1 June "based on their IPP", the project proposal written earlier in the year, submit a progress report on 10 July and submit the dissertation on 21 August, with first and second markers finishing by 11 September (University of Edinburgh, 2026). That is just under twelve weeks from first line of code to bound copy, and it is the window every scope note below is written against. Your department's dates will differ; the arithmetic will not.

"Recall@10 against queries per second on two datasets, with and without a filter" is a sentence a supervisor can agree to in a meeting. "Explore vector databases" is not.

Artificial Intelligence and Machine Learning Dissertation Topics

Each of these five topics fixes a budget, a split or a label fraction and holds it constant.

1. Zero-Shot Against Fine-Tuned Dense Retrieval on BEIR

• Research question. On which BEIR domains does a small dense retriever fine-tuned on one dataset beat BM25 at nDCG@10, and does the gain survive when it is tested on four datasets it never saw?
• Data. BEIR, a zero-shot retrieval benchmark of 18 public datasets across retrieval tasks and domains, Apache-2.0 (Thakur et al., 2021).
• Prior work to beat. Table 2 of the BEIR paper gives BM25 nDCG@10 of 0.656 on TREC-COVID, 0.325 on NFCorpus, 0.329 on NQ, 0.236 on FiQA-2018 and 0.665 on SciFact; TAS-B, the strongest dense model in that table, scores 0.481, 0.319, 0.463, 0.300 and 0.643 on the same rows and averages 2.8 percent below BM25 across the benchmark. Zero-shot, the old method wins more often than students expect.
• Method. Run BM25 and a pretrained dense model, fine-tune the dense model on one dataset, then test on four others; report per dataset, never as a single average.
• Evaluation metric. nDCG@10 and Recall@100 per dataset.
• Stretch goal. Answer faithfulness on one question-answering subset when each retriever feeds the same generator.
• Twelve-week scope. Four to six of the 18 datasets, not all of them. Everything here runs on a CPU, so the budget is time, not hardware.

2. Day-Ahead Wind Forecasting on Open Power System Data

• Research question. By how much does a gradient-boosted or sequence model beat persistence and seasonal-naive forecasts at a 24-hour horizon for one country's wind generation, and does the margin hold across seasons?
• Data. The Open Power System Data time-series package, version 2020-10-06: 32 European countries, 2015 to mid-2020, at 15, 30 and 60-minute resolution, with a DOI and a citation line printed on the package page (Open Power System Data, 2020).
• Prior work to beat. There is no published figure for this exact task, and that is fine: persistence and seasonal naive are the conventional baselines in forecasting, so you compute them on your own split and they become the number.
• Method. A LightGBM model on lagged and calendar features against a small sequence model, both scored on a held-out year.
• Evaluation metric. MAE, RMSE and a skill score against persistence.
• Stretch goal. A probabilistic forecast scored by pinball loss.
• Twelve-week scope. One country, one series. The data ends in mid-2020, so the dissertation is about method and says nothing about the 2026 grid; write that limit into the introduction.

3. Do Tree Ensembles Still Win on Tabular Data?

• Research question. Under an equal tuning budget, does a recent tabular neural model close the gap to XGBoost and LightGBM on a slice of OpenML-CC18?
• Data. OpenML-CC18, a curated suite of 72 classification tasks in which each dataset has 500 to 100,000 rows, at most 5,000 features and a minority-to-majority class ratio above 0.05 (Bischl et al., 2019).
• Prior work to beat. Grinsztajn, Oyallon and Varoquaux (2022) benchmarked 45 datasets and found that tree-based models still lead on medium-sized tabular data of around 10,000 samples, even before their speed advantage is counted (Grinsztajn et al., 2022).
• Method. Fix a tuning budget in evaluations per model, run gradient-boosted trees and one tabular neural model on ten to fifteen tasks, and rank them.
• Evaluation metric. Accuracy or AUC per task, mean rank across tasks and a critical-difference plot.
• Stretch goal. A tabular foundation model added under the same budget.
• Twelve-week scope. Ten to fifteen tasks. The equal budget is the contribution, so document it before the first run and never relax it for one model.

4. Fairness Under Distribution Shift With Folktables

• Research question. How much do demographic-parity and equal-opportunity gaps change when a model trained on one US state is applied to another, and does a fairness intervention transfer with it?
• Data. Folktables, five prediction tasks built from the American Community Survey (ACSIncome, ACSPublicCoverage, ACSMobility, ACSEmployment and ACSTravelTime); the code is MIT-licensed and the data is governed by the Census Bureau's terms of use (Ding et al., 2021).
• Prior work to beat. The repository's own worked example: a logistic-regression model on ACSEmployment has an equality-of-opportunity violation of 0.0871 for Alabama against 0.0397 for Texas.
• Method. Train in one state, test in two to five others, then apply reweighting before training and a post-processing threshold after it.
• Evaluation metric. Demographic-parity difference, equal-opportunity difference and accuracy, always reported together.
• Stretch goal. Reweighting against post-processing on the same state pairs.
• Twelve-week scope. One task, two to five states. A submission that reports fairness without accuracy is not finished; a marker will ask what the fairness gain cost.

5. Label-Efficient Medical Image Classification on MedMNIST

• Research question. At 1, 10 and 100 percent of labels, does self-supervised pretraining beat ImageNet transfer on one MedMNIST 2D dataset?
• Data. MedMNIST v2, 12 two-dimensional and 6 three-dimensional datasets, about 708,000 2D and 10,000 3D images, offered at 28, 64, 128 and 224 pixels; CC BY 4.0 except DermaMNIST, which is CC BY-NC 4.0 (Yang et al., 2023).
• Prior work to beat. The published ResNet-50 at 28 pixels scores AUC 0.990 and accuracy 0.911 on PathMNIST, and 0.997 and 0.956 on BloodMNIST.
• Method. Pretrain on the unlabelled training split, fine-tune at the three label fractions, and compare with an ImageNet-initialised model at the same fractions.
• Evaluation metric. AUC and accuracy at each label fraction.
• Stretch goal. Expected calibration error, because a medical classifier that is confident and wrong is the failure that matters.
• Twelve-week scope. One or two datasets at 28 or 64 pixels. A single GPU or a Colab session is enough, and the 1 percent runs finish in minutes.

Systems and Cloud Computing Dissertation Topics

In these three topics the controls are the whole project: the same hardware, the same data, the same warm-up, written down before the first run.

6. Filtered Vector Search: Recall Against Throughput

• Research question. How does the recall-versus-queries-per-second curve of an HNSW index and an IVF index change as a metadata filter becomes more selective?
• Data. ann-benchmarks, precomputed HDF5 datasets including glove-100-angular (1,183,514 training vectors, 10,000 queries, 100 dimensions) and sift-128-euclidean (1,000,000 vectors, 10,000 queries, 128 dimensions), MIT (Aumüller, Bernhardsson and Faithfull, 2019). The page states that "ann-benchmarks is no longer actively maintained" and points to VIBE; say so in the dissertation.
• Prior work to beat. The published recall-against-throughput curves for the same two datasets, which you reproduce first.
• Method. Attach a synthetic attribute to each vector, filter at 50, 10 and 1 percent selectivity, and rerun both index families with pre-filtering and post-filtering.
• Evaluation metric. Recall@10 against queries per second, index build time and memory.
• Stretch goal. Reproduce the unfiltered curves on VIBE, the successor the page names.
• Twelve-week scope. Two datasets, two libraries, the single-CPU setting the benchmark tool specifies. A laptop is enough, which is rare for a systems topic.

7. WebAssembly Against Native Code in 2026

• Research question. Has the slowdown measured in 2019 narrowed for a standalone runtime and a current browser?
• Specification. The W3C WebAssembly Core Specification, a W3C Recommendation of 5 December 2019, which defines WebAssembly as "a safe, portable, low-level code format designed for efficient execution and compact representation" (W3C, 2019), and PolyBench/C, a suite of 30 numerical kernels released under GPLv2 (Pouchet and Yuki, 2025). Version 1.0 is still the only Recommendation; the 2.0 specification is a Candidate Recommendation Draft, so say which features your toolchain uses.
• Prior work to beat. Jangda, Powers, Berger and Guha (2019) found SPEC CPU programs compiled to WebAssembly ran "slower by an average of 45% (Firefox) to 55% (Chrome), with peak slowdowns of 2.08× (Firefox) and 2.5× (Chrome)" (Jangda et al., 2019).
• Method. Compile each kernel natively and to WebAssembly, run in Wasmtime and one browser, five repetitions each, and report the ratio.
• Evaluation metric. Slowdown ratio per kernel and its distribution across kernels, not a single average.
• Stretch goal. The same kernels through the WASI component model.
• Twelve-week scope. Ten to fifteen of the 30 kernels. PolyBench is GPL-licensed, so no SPEC licence stands between you and the data.

8. Keep-Alive Policies for Serverless Cold Starts

• Research question. Under a fixed memory budget, which keep-alive policy minimises cold starts on the 2019 Azure Functions trace, and does the 2021 invocation trace change the answer?
• Data. AzurePublicDataset: the 2019 Functions trace (July 2019, per-minute invocation counts for each anonymised function, with execution-time and memory distributions) and the 2021 invocation trace (two weeks from 31 January 2021), released under CC-BY-4.0 and MIT (Microsoft Azure, no date).
• Prior work to beat. Shahrad et al. (2020) report "an 8-order-of-magnitude range of invocation frequencies"; in their simulation the 75th-percentile application sees cold starts 50.3 percent of the time on a fixed 10-minute keep-alive and 25 percent at one hour, and their hybrid histogram policy with ARIMA cuts the share of applications that always cold-start from 10.5 to 5.2 percent (Shahrad et al., 2020).
• Method. A trace-driven simulator that replays one week and scores fixed keep-alive windows against the hybrid policy.
• Evaluation metric. Cold-start fraction against wasted memory-time, plotted as a frontier.
• Stretch goal. The 2021 trace as a second week, to see whether the frontier moved.
• Twelve-week scope. One week of trace and no cloud spend.

Cyber Security Dissertation Topics

Each of these four topics has a paper whose number you must beat or explain, and a chapter that only describes the attack surface earns nothing.

9. Concept Drift in Static Malware Detection on EMBER

• Research question. How much does a LightGBM detector trained on EMBER 2017 degrade on EMBER 2018, and how small a 2018 sample recovers it?
• Data. EMBER, features from 1.1 million Windows PE files for 2017 (900,000 training: 300,000 malicious, 300,000 benign, 300,000 unlabelled; 200,000 test: 100,000 and 100,000) and 1 million for 2018, feature version 2 (Anderson and Roth, 2018). The repository warns that "different selection criteria were applied when choosing samples from 2017 and 2018", the 2018 sets having been chosen to be harder to classify, so part of any drop is design, and the dissertation says so.
• Prior work to beat. The EMBER LightGBM baseline, which the paper reports "outperforms MalConv" without hyper-parameter tuning.
• Method. Train on 2017, test on 2018, then add 2018 samples in steps of 1,000 and retrain.
• Evaluation metric. AUC and the false-positive rate at a fixed true-positive rate.
• Stretch goal. Attribute the drift to feature groups by ablation.
• Twelve-week scope. Features only, no binaries. The feature files need tens of gigabytes of memory, so a lab machine, not a laptop. For the introduction's setting in another domain, our report on security challenges in connected vehicles reviews how intrusion detection is evaluated there.

10. Does a Cheap Defence Transfer Across Robust Models?

• Research question. Does an input-side defence raise accuracy under AutoAttack on models from the RobustBench zoo, or only on the model it was tuned on?
• Benchmark. RobustBench, a leaderboard of more than 120 models evaluated with AutoAttack, "an ensemble of white- and black-box attacks", across four threat models: CIFAR-10 at ℓ∞ 8/255 and at ℓ2 0.5, CIFAR-100 at ℓ∞ 8/255 and ImageNet at ℓ∞ 4/255 (Croce et al., 2020).
• Prior work to beat. The top CIFAR-10 ℓ∞ entry in the repository's table, a WideResNet-94-16 from Bartoldson and colleagues, reports 93.68 percent clean accuracy and 73.71 percent accuracy under AutoAttack.
• Method. Tune a JPEG-compression or bit-depth defence on one zoo model, then apply it unchanged to two others and re-run AutoAttack.
• Evaluation metric. Clean accuracy and AutoAttack accuracy for every model, with and without the defence.
• Stretch goal. An adaptive attack: give the attacker the defence and see how much of the gain survives.
• Twelve-week scope. CIFAR-10, two or three models, one GPU, a fixed test subset per model. The transfer question is answered by three models; more is decoration.

11. LLM Detectors Against Static Analysers on SmartBugs

• Research question. On the annotated SmartBugs contracts, does an LLM-based detector beat nine static tools on precision and recall per vulnerability category, and what does it cost in false positives on unlabelled contracts?
• Data. SmartBugs Curated, 69 annotated Solidity contracts (Durieux et al., 2020), labelled under nine DASP categories: reentrancy, access control, arithmetic, unchecked low-level calls, denial of service, bad randomness, front running, time manipulation and short addresses; the project files are Apache-2.0 and the contracts keep their original licences (SmartBugs, no date).
• Prior work to beat. Durieux, Ferreira, Abreu and Cruz (2020) ran nine tools over 47,518 contracts: "only 42% of the vulnerabilities from our annotated dataset are detected by all the tools", Mythril the most accurate at 27 percent, and 97 percent of contracts were tagged vulnerable by at least one tool (Durieux et al., 2020).
• Method. Prompt one model per contract with a fixed output schema, compare its labels with the annotations and with the nine tools' published results.
• Evaluation metric. Precision, recall and F1 per category; false-positive rate on a 500-contract unlabelled sample.
• Stretch goal. Chain the model behind a static tool as a filter and measure what the second stage removes.
• Twelve-week scope. The 69 annotated contracts plus the sample. Write the API bill into the plan, because it is the constraint that decides how many prompts you can afford.

12. Do OpenSSF Scorecard Checks Predict Later Vulnerabilities?

• Research question. For one package ecosystem, do a project's Scorecard check scores predict a subsequent advisory in OSV?
• Data. The weekly OpenSSF Scorecard scan of "the 1 million most critical open source projects judged by their direct dependencies", each check scored 0 to 10 and published in BigQuery as openssf:scorecardcron.scorecard-v2, Apache-2.0 (OpenSSF, no date); OSV.dev, a distributed vulnerability database with an API queried by package version or commit hash, using the OSV schema, version 1.9.0 of 6 August 2026 (OSV, 2026).
• Prior work to beat. Zahan et al. (2023) collected Scorecard results for 832,422 npm and 191,483 PyPI packages and found that only 3.2 percent of npm and 2.5 percent of PyPI packages had a security policy file, and that the Maintained check failed for more than 85 percent of npm and 75 percent of PyPI packages (Zahan et al., 2023). They measured practices, not prediction, so your baseline is a null model that ignores the checks.
• Method. Join scan history to OSV advisories by repository, fit a logistic model on the check scores at one date, and predict an advisory within the following year.
• Evaluation metric. AUC and an odds ratio per check.
• Stretch goal. Survival analysis on time to first advisory.
• Twelve-week scope. One ecosystem, the BigQuery free tier, no scraping of GitHub. The join is the hard part; budget three weeks for it.

Human-Computer Interaction Dissertation Topics

Of these three topics, two need ethics approval and the third does not, but the crawl still has terms to respect.

13. Cookie Consent Dark Patterns on UK Sites, 2026 Against 2020

• Research question. What share of top UK sites now show a reject option on the first layer of the consent banner, compared with the 11.8 percent that met minimal requirements in 2020?
• Data. The Tranco list, one million domains built by averaging Cisco Umbrella, Majestic, Farsight, the Chrome User Experience Report and Cloudflare Radar over 30 days, with a permanent ID for every generated list (Le Pochat et al., 2019). The rule to code against is the ICO's guidance on storage and access technologies, finalised on 29 April 2026 after the Data (Use and Access) Act 2025, whose checklist reads "Our consent mechanism makes it as easy to refuse consent as it is to accept" and shows equally prominent "accept all" and "reject all" options as good practice (ICO, 2026).
• Prior work to beat. Nouwens, Liccardi, Veale, Karger and Kagal (2020) scraped the five most popular consent platforms on the top 10,000 UK sites (n = 680) and found "only 11.8% meet the minimal requirements"; removing the opt-out button from the first page raised consent by 22 to 23 percentage points (Nouwens et al., 2020).
• Method. A Playwright crawl of 500 to 1,000 UK domains from a dated Tranco list, a screenshot of each first layer, then manual coding of a sample by two raters.
• Evaluation metric. Share with a first-layer reject option; Cohen's kappa between raters.
• Stretch goal. The same share across three Tranco rank bands, to see whether compliance falls with popularity.
• Twelve-week scope. No participants, so no panel, but respect robots files and site terms and keep only what the coding needs. The 2020 figure was for a different rule, so the comparison is descriptive, and the dissertation says so.

14. Passkeys Against Password Plus One-Time Code for First-Time Users

• Research question. How do completion rate, time to sign in and System Usability Scale score compare between passkey sign-in and a password with a one-time code, for people using a passkey for the first time?
• Specification. Web Authentication Level 3, a W3C Recommendation of 25 August 2026, which defines "an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications" (W3C, 2026).
• Prior work to beat. Lassak, Pan, Ur and Golla (2024) interviewed 28 chief information security officers and authentication managers and found the barriers were "account recovery, friction, technical issues, regulatory requirements, and security culture" (Lassak et al., 2024). There is no first-time-user completion figure on the pages we opened, so your study supplies it.
• Method. A within-subjects lab study of 16 to 24 participants on a demo relying party you build in weeks 1 to 3, with the order of the two conditions counterbalanced.
• Evaluation metric. Completion rate, time, error count and SUS per condition.
• Stretch goal. A return visit a week later to measure whether participants can repeat the passkey flow unaided.
• Twelve-week scope. Ethics application in week 1; the study runs in weeks 6 to 9; three weeks are left for analysis and writing. Recruit before the prototype is finished, not after.

15. What LLM Summaries of Privacy Policies Leave Out

• Research question. What fraction of the data practices annotated in OPP-115 does an LLM summary preserve, and which practice types are dropped most often?
• Data. OPP-115, 115 website privacy policies, each "read and annotated by three graduate students in law", released for research, teaching and scholarship "in the spirit of" a Creative Commons Attribution-NonCommercial licence (Wilson et al., 2016).
• Prior work to beat. The annotations are the ground truth. No published recall figure for LLM summaries against OPP-115 appears on the pages we opened, so state that in the literature review and treat your first run as the baseline.
• Method. Summarise each policy with one model and a fixed prompt, then have two raters map each summary sentence to the annotated practices.
• Evaluation metric. Recall of annotated practices per category, and agreement between raters.
• Stretch goal. Schema-constrained prompting that forces the model to answer every practice category, scored the same way.
• Twelve-week scope. Thirty to fifty policies. The raters are colleagues reading public documents, so the ethics check is light, but it still goes in; the API cost goes in the plan.

Data Engineering and Big Data Dissertation Topics

Two of the three topics run on one public source, the New York taxi trip records, so the data question is settled on day one; the third runs the benchmark's own workload.

16. Late Data in a Streaming Pipeline

• Research question. What do watermark and allowed-lateness settings cost in latency and correctness when out-of-order taxi events are replayed?
• Data. The New York City Taxi and Limousine Commission trip records: yellow, green, for-hire and high-volume for-hire vehicles, in Parquet, from 2009 to July 2026, published monthly about two months in arrears (TLC, 2026). The TLC "makes no representations as to the accuracy of these data", and your data chapter repeats that sentence.
• Specification. The Dataflow model, which sets out event-time windowing, watermarks and triggers on the premise that "we will never know if or when we have seen all of our data" (Akidau et al., 2015).
• Prior work to beat. A batch computation over the same month is the ground truth; the streaming result is measured against it.
• Method. An Apache Beam or Flink pipeline that consumes replayed events with injected delays at three lateness settings.
• Evaluation metric. End-to-end latency, the fraction of late events dropped, and error against the batch answer per window.
• Stretch goal. A second event type with a different delay distribution.
• Twelve-week scope. One month of yellow-taxi data on one machine.

17. Open Table Formats Under an Update-Heavy Workload

• Research question. How do Apache Iceberg and Delta Lake compare on compaction cost and time-travel query latency when the workload is updates rather than appends?
• Benchmark. LST-Bench, a framework for benchmarking log-structured tables that supports Delta Lake, Apache Hudi and Apache Iceberg, Apache-2.0 (Camacho-Rodríguez et al., 2024).
• Prior work to beat. The paper's own comparison. Reproduce one of its runs at a small scale before adding a workload of your own.
• Method. Single-node Spark, the same table loaded in both formats, an update-heavy phase followed by compaction and time-travel queries.
• Evaluation metric. Query latency, storage amplification and compaction time.
• Stretch goal. Repeat on an object store to see what latency the storage layer adds.
• Twelve-week scope. A small scale factor on one machine.

18. Catching Schema and Distribution Drift Automatically

• Research question. Can Deequ's suggested constraints and anomaly detection catch a real schema change in the taxi files and injected distribution drift at a low false-alarm rate?
• Data and tool. The same TLC monthly files, 24 months, which contain a real drift event: "for 2025 data onwards, a cbd_congestion_fee column has been added" to the yellow, green and high-volume files (TLC, 2026). Deequ, "unit tests for data" on Apache Spark, with constraint suggestion, anomaly detection and a metrics repository, Apache-2.0 (Schelter et al., 2018).
• Prior work to beat. No published detection rate exists for this data; the baseline is a hand-written schema check that flags any new column, which catches the real event and none of the injected ones.
• Method. Learn constraints on the first twelve months, run them on the next twelve, inject three distribution shifts of known size, and record what fires.
• Evaluation metric. Detection rate, false alarms per month, and months from onset to detection.
• Stretch goal. The same run on the green-taxi files, to test whether constraints learned on one series transfer to another.
• Twelve-week scope. Twenty-four files. For a worked example of a data project written up as a dissertation, read our data mining for e-commerce personalisation sample, which shows the shape of the results chapter.

Software Engineering Dissertation Topics

Across these three topics the marks are in the manual judgement each one asks for, which is where a lecturer sees whether you understood what the tool produced.

19. Repository Context and LLM Issue Resolution

• Research question. How much does retrieved repository context raise a small open model's resolved rate on SWE-bench Verified, per dollar spent?
• Data. SWE-bench, 2,294 problems drawn from real GitHub issues and pull requests across 12 Python repositories (Jimenez et al., 2024), and SWE-bench Verified, "a subset of 500 samples from the SWE-bench test set, which have been human-validated for quality" (SWE-bench Verified, no date); the repository and dataset are MIT-licensed.
• Prior work to beat. In the original paper "the best-performing model, Claude 2, is able to solve a mere 1.96% of the issues"; take the current Verified leaderboard entry for your chosen model as the second number and date it.
• Method. Run one open model with no retrieval, BM25 retrieval and embedding retrieval, at the same budget per instance.
• Evaluation metric. Percentage resolved and cost per instance.
• Stretch goal. A failure taxonomy of 50 unresolved instances, coded by hand.
• Twelve-week scope. One hundred to two hundred Verified instances under a stated budget. Write the budget in the proposal before the first run; a results chapter that stopped when the money ran out is a results chapter with a hole in it.

20. Does a Flaky-Test Classifier Transfer Between Languages?

• Research question. Does a vocabulary-based classifier trained on IDoFT's Java flaky tests transfer to its Python tests?
• Data. The International Dataset of Flaky Tests, Java tests from Maven and Gradle projects and Python tests, each labelled with a category such as order-dependent (OD), implementation-dependent (ID), non-idempotent-outcome (NIO), non-deterministic (NOD), time-dependent (TD) or time-zone-dependent (TZD) (Lam et al., 2019). The counts are not on the page, so we counted the CSV rows on 26 September 2026: 8,075 in the Maven file, 1,029 in the Gradle file and 1,618 in the Python file. Implementation-dependent tests dominate the Maven file (5,191 rows) and order-dependent categories dominate Python (804 OD-Vic and 322 OD-Brit rows), so the two languages are not balanced the same way, and the transfer question has to account for that.
• Prior work to beat. Pinto et al. (2020) ran 64,000 tests 100 times each, 6.4 million executions, built a classifier on stemmed identifier tokens and reached an F-measure of 0.95, with Random Forest and Support Vector Machines the best learners (Pinto et al., 2020).
• Method. Reproduce the vocabulary classifier on the Java rows, test it unchanged on Python, then retrain on Python and compare.
• Evaluation metric. Precision and recall per category, cross-project and cross-language.
• Stretch goal. Which tokens carry the transfer and which are Java-only.
• Twelve-week scope. Source-level classification only, no reruns, which is why the whole thing fits the window. The balancing decision above is a methods-chapter paragraph, not a footnote.

21. Plausible Against Correct Patches on Defects4J

• Research question. Among plausible patches from an LLM repair loop, what fraction are correct, and does a generated-test filter raise precision?
• Data. Defects4J version 3.0.1, "854 bugs (plus 10 deprecated bugs)" from 17 open-source Java projects, MIT (Just, Jalali and Ernst, 2014).
• Prior work to beat. Defects4J's own test suites decide plausibility; correctness is a manual judgement against the developer's patch, and that manual step is the contribution a marker will read most closely.
• Method. Generate candidate patches for each bug, keep those that pass the failing tests, then add generated tests as a second filter.
• Evaluation metric. Plausible count, correct count after manual review, and precision before and after the filter.
• Stretch goal. Inter-rater agreement on correctness with a second reviewer.
• Twelve-week scope. Two or three projects, about 100 bugs. Manual review is slow, so cap it in the plan and say what the cap cost.

How Do You Turn a Topic Into a Proposal?

Take the seven fields of one topic and write them into the nine sections a computer science proposal uses: project definition, aims and objectives, research questions, hypothesis, expected outcomes, background, tools and technologies, a dated plan, and ethics and data approval. The research question, the prior number and the scope note fill most of them.

From a scoped topic to a proposal in seven steps

1. 1 Write the research question One sentence that a measurement can answer, with the comparison named.
2. 2 Open the data or the specification Read the licence, the citation it asks for and the size; record the date you opened it.
3. 3 Find the number to beat A table row in a paper or a leaderboard entry; if none exists, name the baseline you will compute.
4. 4 Fix the method and the metric What is built, what it is compared against, and the number the results chapter reports.
5. 5 Cut the scope to the window The smallest version that answers the question inside your department's dates; the rest is the stretch goal.
6. 6 Settle the ethics route Participants, raters, personal data, site terms or licence conditions; the form goes in during week one.
7. 7 Fill the nine proposal sections Project definition through ethics and data approval, each fed by one of the fields above.

Those nine sections are the ones our computer science dissertation sample writes in full for a real-time web application, so read it beside this table for the register each section takes. For the shape of a proposal in a different subject, with the literature review and methodology written out, our dissertation proposal example is the fuller model.

Two of the rows need more care than the rest. The hypothesis row is where students overreach: "the neural model will beat the trees" is a hypothesis you can lose, and losing it is a fine result if the evaluation was fair; "the neural model is better" is an opinion. The ethics row is where they underreach. Anything with participants or raters goes to a panel, and approval takes weeks, so the form is a week-one task; our dissertation writing tips explain how to get ethics approval before you collect data and what happens to a schedule that leaves it until week six.

If the proposal is due before the topic is settled, our thesis and dissertation help page describes how we work on a proposal chapter by chapter, and the sample above shows the standard.

Need help scoping, planning or writing up a computer science dissertation or project? Message us on WhatsApp with the module, the topic you are leaning towards and the submission date, and we will tell you what we can do and what it would cost.

Sources

• Thakur, N., Reimers, N., Rücklé, A., Srivastava, A. and Gurevych, I. (2021) BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models, NeurIPS 2021 Datasets and Benchmarks Track. Paper: arxiv.org/abs/2104.08663 (Table 2, nDCG@10); repository: github.com/beir-cellar/beir, Apache-2.0 (both accessed 26 September 2026).
• Open Power System Data (2020) Data Package Time series, version 2020-10-06. data.open-power-system-data.org, DOI 10.25832/time_series/2020-10-06 (accessed 26 September 2026).
• Bischl, B., Casalicchio, G., Feurer, M., Gijsbers, P., Hutter, F., Lang, M., Mantovani, R. G., van Rijn, J. N. and Vanschoren, J. (2019) OpenML Benchmarking Suites, arXiv:1708.03731. arxiv.org/abs/1708.03731; inclusion criteria from docs.openml.org/benchmark; the 72-task count from the suite record openml.org/api/v1/json/study/99 (all accessed 26 September 2026).
• Grinsztajn, L., Oyallon, E. and Varoquaux, G. (2022) Why do tree-based models still outperform deep learning on tabular data?, arXiv:2207.08815. arxiv.org/abs/2207.08815 (accessed 26 September 2026).
• Ding, F., Hardt, M., Miller, J. and Schmidt, L. (2021) Retiring Adult: New Datasets for Fair Machine Learning, Advances in Neural Information Processing Systems 34. Repository: github.com/socialfoundations/folktables, MIT, with the Alabama and Texas example figures (accessed 26 September 2026).
• Yang, J. et al. (2023) MedMNIST v2: A large-scale lightweight benchmark for 2D and 3D biomedical image classification, Scientific Data 10, 41. Dataset site: medmnist.com, with licences and the ResNet-50 (28) benchmark table (accessed 26 September 2026).
• Aumüller, M., Bernhardsson, E. and Faithfull, A. (2019) ANN-Benchmarks: A Benchmarking Tool for Approximate Nearest Neighbor Algorithms, Information Systems. Repository: github.com/erikbern/ann-benchmarks, MIT, including the maintenance notice and the dataset table (accessed 26 September 2026).
• Jangda, A., Powers, B., Berger, E. D. and Guha, A. (2019) Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code, USENIX Annual Technical Conference 2019. usenix.org (accessed 26 September 2026).
• W3C (2019) WebAssembly Core Specification, W3C Recommendation, 5 December 2019. w3.org/TR/wasm-core-1; the 2.0 specification is a W3C Candidate Recommendation Draft dated 12 October 2026 (accessed 13 October 2026): w3.org/TR/wasm-core-2 (both accessed 26 September 2026).
• Pouchet, L.-N. and Yuki, T. (2025) PolyBench/C, version 4.2.1-beta, 30 kernels, GPLv2. sourceforge.net/projects/polybench (accessed 26 September 2026).
• Microsoft Azure (no date) AzurePublicDataset: AzureFunctionsDataset2019 and AzureFunctionsInvocationTrace2021, CC-BY-4.0 and MIT. github.com/Azure/AzurePublicDataset (accessed 26 September 2026).
• Shahrad, M., Fonseca, R., Goiri, Í., Chaudhry, G., Batum, P., Cooke, J., Laureano, E., Tresness, C., Russinovich, M. and Bianchini, R. (2020) Serverless in the Wild: Characterizing and Optimizing the Serverless Workload at a Large Cloud Provider, USENIX Annual Technical Conference 2020. Abstract: usenix.org; the cold-start figures are from the paper PDF, microsoft.com (both accessed 26 September 2026).
• Anderson, H. S. and Roth, P. (2018) EMBER: An Open Dataset for Training Static PE Malware Machine Learning Models, arXiv:1804.04637. arxiv.org/abs/1804.04637; repository with the 2017 and 2018 descriptions and the selection-criteria warning: github.com/elastic/ember (both accessed 26 September 2026).
• Croce, F., Andriushchenko, M., Sehwag, V., Debenedetti, E., Flammarion, N., Chiang, M., Mittal, P. and Hein, M. (2020) RobustBench: a standardized adversarial robustness benchmark, arXiv:2010.09670. arxiv.org/abs/2010.09670; site: robustbench.github.io; the CIFAR-10 ℓ∞ table with the Bartoldson et al. (2024) WideResNet-94-16 entry at 93.68 / 73.71: github.com/RobustBench/robustbench (all accessed 26 September 2026).
• SmartBugs (no date) SmartBugs Curated: nine DASP categories, Apache-2.0 for project files; the count of 69 annotated contracts is from Durieux et al. (2020). github.com/smartbugs/smartbugs-curated (accessed 26 September 2026).
• Durieux, T., Ferreira, J. F., Abreu, R. and Cruz, P. (2020) Empirical Review of Automated Analysis Tools on 47,587 Ethereum Smart Contracts, ICSE 2020, arXiv:1910.10601. arxiv.org/abs/1910.10601 (accessed 26 September 2026). The abstract reports 47,518 contracts analysed and "a dataset of 69 annotated vulnerable smart contracts".
• OpenSSF (no date) Scorecard: the weekly scan, the 0 to 10 check scores and the BigQuery dataset openssf:scorecardcron.scorecard-v2, Apache-2.0. github.com/ossf/scorecard (accessed 26 September 2026).
• OSV (2026) OSV.dev: A distributed vulnerability database for Open Source. osv.dev; Open Source Vulnerability schema, version 1.9.0, 6 August 2026: ossf.github.io/osv-schema (both accessed 26 September 2026).
• Zahan, N., Kanakiya, P., Hambleton, B., Shohan, S. and Williams, L. (2023) OpenSSF Scorecard: On the Path Toward Ecosystem-wide Automated Security Metrics, arXiv:2208.03412, final version June 2023. arxiv.org/abs/2208.03412; the package counts and the Security-Policy and Maintained figures are from the paper PDF (accessed 26 September 2026).
• Le Pochat, V., Van Goethem, T., Tajalizadehkhoob, S., Korczyński, M. and Joosen, W. (2019) Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation, NDSS 2019. List site: tranco-list.eu (accessed 26 September 2026).
• Nouwens, M., Liccardi, I., Veale, M., Karger, D. and Kagal, L. (2020) Dark Patterns after the GDPR: Scraping Consent Pop-ups and Demonstrating their Influence, CHI 2020, arXiv:2001.02479. arxiv.org/abs/2001.02479 (accessed 26 September 2026).
• Information Commissioner's Office (2026) Guidance on the use of storage and access technologies, published 20 December 2024, finalised 29 April 2026; chapter "How do we manage consent in practice?". ico.org.uk (accessed 26 September 2026).
• W3C (2026) Web Authentication: An API for accessing Public Key Credentials, Level 3, W3C Recommendation, 25 August 2026. w3.org/TR/webauthn-3 (accessed 26 September 2026).
• Lassak, L., Pan, E., Ur, B. and Golla, M. (2024) Why Aren't We Using Passkeys? Obstacles Companies Face Deploying FIDO2 Passwordless Authentication, USENIX Security Symposium 2024. usenix.org (accessed 26 September 2026).
• Wilson, S. et al. (2016) The Creation and Analysis of a Website Privacy Policy Corpus, Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics, Berlin. Corpus page: usableprivacy.org/data (accessed 26 September 2026).
• New York City Taxi and Limousine Commission (2026) TLC Trip Record Data. nyc.gov: Parquet files from 2009 to July 2026, the accuracy disclaimer and the 2025 cbd_congestion_fee note (accessed 26 September 2026).
• Akidau, T., Bradshaw, R., Chambers, C., Chernyak, S., Fernández-Moctezuma, R. J., Lax, R., McVeety, S., Mills, D., Perry, F., Schmidt, E. and Whittle, S. (2015) The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing, Proceedings of the VLDB Endowment 8(12), pp. 1792-1803. vldb.org (accessed 26 September 2026).
• Camacho-Rodríguez, J., Agrawal, A., Gruenheid, A., Gosalia, A., Petculescu, C., Aguilar-Saborit, J., Floratou, A., Curino, C. and Ramakrishnan, R. (2024) LST-Bench: Benchmarking Log-Structured Tables in the Cloud, Proceedings of the ACM on Management of Data 2(1). Repository: github.com/microsoft/lst-bench, Apache-2.0 (accessed 26 September 2026).
• Schelter, S., Lange, D., Schmidt, P., Celikel, M., Biessmann, F. and Grafberger, A. (2018) Automating Large-Scale Data Quality Verification, Proceedings of the VLDB Endowment 11(12), pp. 1781-1794. Repository: github.com/awslabs/deequ, Apache-2.0 (accessed 26 September 2026).
• Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O. and Narasimhan, K. (2024) SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024, arXiv:2310.06770. arxiv.org/abs/2310.06770; repository, MIT: github.com/SWE-bench/SWE-bench (both accessed 26 September 2026).
• SWE-bench Verified (no date) princeton-nlp/SWE-bench_Verified, 500 rows. huggingface.co (accessed 26 September 2026).
• Lam, W., Oei, R., Shi, A., Marinov, D. and Xie, T. (2019) iDFlakies: A Framework for Detecting and Partially Classifying Flaky Tests, ICST 2019, pp. 312-322. Dataset: International Dataset of Flaky Tests, github.com/TestingResearchIllinois/idoft; row counts from pr-data.csv, gr-data.csv and py-data.csv as downloaded (accessed 26 September 2026).
• Pinto, G., Miranda, B., Dissanayake, S., d'Amorim, M., Treude, C. and Bertolino, A. (2020) What is the Vocabulary of Flaky Tests?, 17th International Conference on Mining Software Repositories (MSR 2020), DOI 10.1145/3379597.3387482. Author's copy: gustavopinto.org (accessed 26 September 2026).
• Just, R., Jalali, D. and Ernst, M. D. (2014) Defects4J: A Database of Existing Faults to Enable Controlled Testing Studies for Java Programs, ISSTA 2014. Repository, version 3.0.1: github.com/rjust/defects4j, MIT (accessed 26 September 2026).
• University of Sussex (no date a) Marking criteria MSc ACS, School of Engineering and Informatics, MSc dissertations and projects. sussex.ac.uk (accessed 26 September 2026; the page carries no date).
• University of Sussex (no date b) Dissertation content, School of Engineering and Informatics, MSc dissertations and projects. sussex.ac.uk (accessed 26 September 2026; the page carries no date).
• University of Edinburgh (2026) DISS: MSc Dissertation (Informatics), INFR11077, course timetable for 2026. opencourse.inf.ed.ac.uk/diss (accessed 26 September 2026).