A computer science research proposal has to convince a departmental committee, before any code is written, that the project is technically sound, scoped to finish in the time available, and actually contributes something beyond a working app. This is a full, section-by-section worked example of a South African computer science dissertation research proposal, annotated throughout, built as a labelled illustrative model rather than a real proposal.
This is a fictional, illustrative example. The topic, the numbers in brackets like [n] and the references are invented or generic to show structure only. Build your own proposal around your own topic and your own supervisor’s guidance.
What a South African CS research proposal committee is actually checking
Before a topic is approved, a departmental research committee is checking three things: that the problem is real and specifically scoped (not “build an AI system” but a named, bounded task); that the method is feasible with the data, compute and time a student actually has; and that the contribution is stated in one sentence a non-specialist could repeat back. A proposal that fails any one of these three gets sent back before data collection even starts — so each section below is built to answer one of them directly.
Section 1: Title
Working title (illustrative): “A Machine Learning Approach for Detecting Fraudulent Transactions in South African Mobile Money Systems”
A strong CS title names the method (machine learning approach), the task (detecting fraudulent transactions) and the context (South African mobile money systems) in one line — an examiner should be able to guess the whole proposal’s shape from the title alone.
Section 2: Background and problem statement
Background (illustrative): Mobile money adoption has grown rapidly across Southern Africa, and fraud detection methods built for card-based banking transactions do not transfer cleanly to mobile money’s transaction patterns [cite]. Problem statement: existing fraud detection models evaluated on South African or comparable African mobile money datasets are scarce, and models trained on international card-fraud data show reduced accuracy when applied to mobile money transaction patterns [cite]. This creates a gap between what fraud detection literature offers and what South African mobile money providers can actually deploy.
Section 3: Aim, objectives and research questions
Aim: To develop and evaluate a machine learning model for detecting fraudulent transactions in a South African mobile money dataset.
Objectives: (1) to review existing fraud detection approaches and identify which are suited to mobile money’s transaction structure; (2) to build a model trained and tested on a representative mobile money transaction dataset; (3) to evaluate the model against at least one established baseline method.
Research questions: RQ1 — Which features best distinguish fraudulent from legitimate mobile money transactions in the dataset used? RQ2 — Does the proposed model outperform the chosen baseline on precision and recall?
Section 4: Literature review (preview)
A proposal does not need the full literature review — it needs enough of one to prove the gap exists and that the student has read the field. A workable preview structure: (1) established fraud detection methods generally (rule-based systems, supervised learning, anomaly detection); (2) what has been published specifically on mobile money or comparable African financial-inclusion contexts; (3) the specific gap this study fills, stated as one sentence. Two to three paragraphs is enough at proposal stage — the full chapter comes later.
Section 5: Proposed methodology
Research paradigm: design science, following the framework South African information systems and computer science departments commonly use — see the site’s own guide to when a software project is accepted as a computer science dissertation for the structure this implies.
Data: an anonymised or synthetic mobile money transaction dataset [source, e.g. a public Kaggle synthetic mobile money fraud dataset, or a partnering institution’s anonymised extract] — see the site’s own roundup of data sources for a South African computer science dissertation for real options.
Method: supervised classification (e.g. gradient-boosted trees or a neural network), trained on a labelled subset, with class imbalance handled explicitly since fraud is rare relative to legitimate transactions.
Evaluation: precision, recall and F1-score rather than raw accuracy alone, because a model that predicts “not fraud” for every transaction can still score high on accuracy in an imbalanced dataset — examiners in this field specifically check that a student understands this trap.
Tools: Python, scikit-learn or a comparable library, version control via Git, documented in a public or supervisor-shared repository.
Section 6: Expected contribution
Stated in one sentence, as the committee will expect: this study contributes an evaluated fraud detection model benchmarked on a mobile money transaction pattern, and — where the dataset allows — a comparison showing where card-fraud-trained models under- or over-perform on mobile money data specifically.
Section 7: Ethics considerations
Even where no human participants are directly recruited, a CS proposal using financial transaction data must address data protection: anonymisation, POPIA compliance if any personally identifiable information is present even indirectly, and data-sharing agreements if the dataset comes from a partnering institution rather than a public source — see the site’s guide to applying for research ethics clearance for the general process this sits inside. Departmental ethics committees increasingly ask CS candidates to address this explicitly rather than assuming “it’s just data” exempts the study.
Section 8: Timeline (illustrative)
Check your own department’s exact deadlines. Months 1–2: literature review and dataset sourcing/access agreement. Month 3: data cleaning and exploratory analysis. Months 4–5: model development and baseline comparison. Month 6: evaluation and write-up of results. Months 7–8: full write-up and supervisor review rounds.
The proposal seminar or defence
Many South African computer science departments require a short proposal presentation to the departmental research committee or a panel of two to three academics before formal approval, typically 10–15 minutes plus questions. The questions asked tend to cluster around the same three checks described above: where exactly the data comes from, what happens if the chosen method underperforms the baseline, and how the timeline survives a setback (a dataset access delay, a model that will not converge). Preparing one slide per section of the written proposal — problem, objectives, method, timeline — and rehearsing answers to “what if this part fails” for the data and method sections specifically, covers most of what a panel actually asks.
Choosing a feasible topic in the first place
Most rejected CS proposals fail before the writing stage, at topic selection. Three checks worth running before you draft a single section. First, the data check: can you name, right now, where the dataset or corpus will come from, and have you at least attempted to access a sample of it? “I will find data later” is a common reason a topic gets sent back for rescoping. Second, the compute check: does the proposed method (a large language model fine-tune, a computer-vision pipeline on high-resolution imagery) fit what your department’s lab, your own laptop, or a free-tier cloud service can actually run inside your deadline? Third, the comparison check: is there at least one existing method, paper or system you can benchmark against, so “my model works” has a number to beat rather than existing in isolation?
How this proposal differs by degree level
An honours-level CS project proposal in South Africa is typically scoped narrower than the master’s example above — often a smaller, single-technique study (apply one established algorithm to one new dataset) rather than a full comparative evaluation. A master’s proposal, as modelled here, is expected to compare at least one baseline against the proposed approach and justify the choice of both. A PhD-level proposal in computer science goes further still: it must argue not just that the method works on a new dataset, but that the method itself, or the evaluation framework, is a genuine addition to what is known in the field — a distinction examiners at doctoral level check closely, and one honours and master’s candidates are not expected to meet.
Common reasons a CS proposal is sent back
- The problem is stated too broadly (“build a fraud detection system”) instead of scoped to a specific dataset, task and evaluation metric.
- No baseline method is named — without one, “the model works” cannot be shown to mean anything.
- The dataset does not yet exist or is not confirmed accessible — committees want to see a named, realistic data source before approving a proposal built on it.
- Evaluation metrics are not matched to the problem — accuracy alone on an imbalanced fraud dataset is a common giveaway that the student has not yet engaged with the field’s own pitfalls.
A worked Harvard reference
Conference paper, the form most machine learning sources will take:
Dal Pozzolo, A., Caelen, O., Le Borgne, Y.A., Waterschoot, S. and Bontempi, G. 2014. Learned lessons in credit card fraud detection from a practitioner perspective. Expert Systems with Applications, 41(10), pp.4915–4928.
In-text: (Dal Pozzolo et al., 2014). Check your department’s exact Harvard variant for how it handles more than three authors and DOI formatting — this differs between UCT, Wits and Stellenbosch’s computer science departments; see the site’s Harvard vs APA comparison if your department allows a choice.
A proposal this specific takes real structuring work before a single model is trained — Tesify helps lay out each section in the order a committee expects, while the dataset, method and results stay entirely your own.
Frequently asked questions
Does a CS dissertation proposal need a working prototype before submission?
No — the proposal describes the planned method and data; the prototype and results come after approval, during the study itself.
Can I propose a topic without a confirmed dataset?
It is a common reason committees send proposals back. Confirm access to real or realistic data — even a public or synthetic dataset — before submitting, or state a clear fallback plan if the intended source falls through.
What is the difference between a CS research proposal and a software project proposal?
A software project still needs a research question and an evaluation method attached to it — a working system alone is not a research contribution. See the site’s guide to when a software project is accepted as a computer science dissertation for the fuller distinction.
How long should a South African CS dissertation proposal be?
There is no single national figure — departments set their own range, commonly a few thousand words covering the sections above. Confirm your own department’s exact requirement rather than assuming a generic length.
Which referencing style do South African CS departments use?
Most use a Harvard variant, though some computing departments follow IEEE style for conference-paper-heavy fields — check your own department’s guide before your first draft.
Do I need to name a specific dataset before my proposal is approved?
Committees strongly prefer it. A proposal naming a real, checked data source — even a public one with known limitations — is far more likely to pass on the first attempt than one that describes data collection only in general terms.
Can I change my methodology after the proposal is approved?
Minor adjustments are normal as a project develops, but a substantial change to the method, dataset or research questions usually requires notifying your supervisor and, depending on your department’s rules, a formal amendment — do not simply switch approach without checking first.
What happens if my proposed dataset turns out to be unusable?
Say so early, to your supervisor, rather than after months of work — most departments would rather approve a scoped amendment to the data source than see a project stall silently until close to the deadline.