A software project is accepted as a South African computer science dissertation when it follows a recognised design science research method — almost always Hevner’s seven guidelines together with Peffers’s six-activity process — produces a genuine, stated research contribution beyond the working artefact, and is evaluated against explicit criteria rather than demonstrated as a finished product. Code alone, however sophisticated, is not a dissertation.
Computer science departments accept artefact-based research more readily than most fields, which is exactly why students under-argue it: a working system feels like proof enough. Examiners do not read it that way. What follows is what actually turns a build into a dissertation.
What makes a software project a dissertation rather than just a working system?
The difference is the argument wrapped around the artefact, not the artefact’s polish. A dissertation states a problem the artefact solves that was not already solved, designs the artefact as a deliberate response to that problem with alternatives considered and rejected, and then evaluates whether the artefact actually solves it — against criteria fixed before the evaluation, not chosen afterward because the results looked good against them. A final-year software engineering capstone can be excellent engineering and still fail as a dissertation if none of that argument is written down; conversely, a modest prototype with a tightly reasoned problem statement, design rationale and evaluation regularly outperforms a more polished system with none.
Which design science framework do South African CS departments actually use?
Most South African computer science and informatics departments that accept software artefacts as dissertations anchor the methodology chapter in two combined sources from the design science research literature: Hevner, March, Park and Ram’s seven guidelines (2004), which set out what counts as rigorous design science — design as an artefact, problem relevance, design evaluation, research contributions, research rigour, design as a search process, and communication of research — and Peffers, Tuunanen, Rothenberger and Chatterjee’s Design Science Research Methodology (2007), which sequences the work into six activities: problem identification and motivation, objectives of a solution, design and development, demonstration, evaluation, and communication.
Departments that also examine behavioural information-systems dissertations often teach both traditions side by side; the parallel behavioural route, and how the two differ chapter by chapter, is set out in our guide to structuring an information systems master’s dissertation. A pure computer science software artefact almost always sits in the design-science tradition rather than the behavioural one, because the research question is about the artefact’s performance or capability, not about how people adopt technology.
What must the written dissertation contain alongside the software artefact?
Examiners expect a document, not a README. The chapters that carry the argument, mapped to Peffers’s activities:
| Peffers activity | What the chapter argues | Common failure |
|---|---|---|
| Problem identification and motivation | A real, evidenced gap — a limitation in existing tools or techniques, stated precisely enough to be falsified | A generic problem (“developers need better tools”) too broad to design against |
| Objectives of a solution | What the artefact must do to count as solving the problem, stated as testable objectives | Objectives restated as features, with no way to check whether they were met |
| Design and development | The architecture, the alternatives considered and rejected, and why the chosen design follows from the objectives | A build log rather than a design rationale — what was built, with no defence of why |
| Demonstration | The artefact working on a realistic instance of the problem, described precisely enough to be repeated | A demo video substituted for a written, reproducible account |
| Evaluation | Measurement against the stated objectives, using a method appropriate to the claim — benchmarks, a controlled comparison, expert review, or a user study | Evaluation criteria chosen after seeing results, or no comparison baseline at all |
| Communication | The contribution stated in terms the field’s literature would recognise, and situated against related systems | A conclusion that restates what was built rather than what was learned |
Output: six chapters or chapter sections, each doing the specific argumentative work Peffers assigns it, not six headings filled with narrative about the build process.
How is the artefact itself evaluated by examiners?
Hevner’s guideline on design evaluation is explicit that the artefact must be rigorously evaluated, and South African examiners apply it literally: they look for a named evaluation method appropriate to the type of claim being made. A performance claim (faster, more accurate, more scalable) needs benchmarking against a stated baseline under controlled conditions. A usability or adoption claim needs a user study with a description of participants, tasks and measures. A novel algorithm or technique needs either a formal proof or an empirical comparison against the state of the art on standard datasets or problem instances, cited by name. “It worked when I tried it” is not an evaluation method an examiner will accept at any level above undergraduate.
What research contribution counts, beyond the code?
The contribution examiners look for is a design knowledge claim, not the software itself: a novel algorithm or technique, a new architecture or design pattern for a known problem, a validated way of applying an existing technique to a new context, or an empirically grounded set of design principles that other researchers or practitioners could reuse even without your specific codebase. State this contribution as one or two sentences your literature review has set up and your evaluation chapter closes the loop on — if a reader could not summarise, in a sentence, what the field now knows that it did not know before your dissertation, the contribution has not been argued clearly enough yet.
Which types of software projects are accepted?
South African computer science and informatics departments commonly accept, within the design-science tradition: a novel algorithm or optimisation technique with empirical or formal evaluation; a machine-learning model applied to an under-served problem or dataset, evaluated against established baselines; a mobile, web or embedded application that instantiates and tests a design principle rather than existing purely as a product; a security tool, protocol or vulnerability-detection technique with a threat model and evaluation; and a developer tool or framework evaluated for the specific claim it makes about developer productivity or code quality. What is rarely accepted on its own: a straightforward business application with no stated design contribution, however well engineered, and a literature-only survey presented as if it were an artefact-based study.
Do I need a supervisor with software engineering expertise, or will any CS supervisor do?
Design science evaluation methods differ enough by sub-field — a machine-learning evaluation looks nothing like a systems-performance benchmark, which looks nothing like a security evaluation — that a supervisor whose own research sits in your artefact’s sub-field will catch evaluation-design problems long before an examiner does. If your department assigns supervisors by availability rather than fit, raise a co-supervisor or an external reader from the relevant sub-field early; departments are usually receptive when the request is specific (“I need someone who has run a controlled performance benchmark study”) rather than general (“I want a better supervisor”).
How is a design-science dissertation examined differently from a behavioural one?
A behavioural information-systems dissertation is examined primarily on its research model, its hypotheses and its statistical analysis; a design-science computer science dissertation is examined primarily on the artefact’s design rationale and the rigour of its evaluation, with statistics playing a smaller, more targeted role — typically confined to the evaluation chapter’s benchmark comparisons rather than running through the whole document. Examiners with a design-science background will interrogate your choice of baseline and your evaluation metric closely; examiners without that background sometimes default to behavioural-dissertation expectations, which is why a design-science methodology chapter should explicitly explain the framework and justify why it, rather than a behavioural design, fits the research question.
What common reasons do CS software-project dissertations get sent back for major revisions?
Four patterns recur across South African CS examiner reports: an evaluation baseline that was not a genuine comparator (comparing a new technique to a naive or outdated approach rather than the current state of the art); objectives stated so vaguely that the evaluation chapter cannot show whether they were met; a literature review that surveys the field but never positions the specific gap the artefact fills; and a communication chapter that restates the build rather than stating, in the field’s own terms, what is now known. All four are argument problems, not engineering problems — the code can be sound and the dissertation can still fail on any of these grounds.
Turning a working system into an examinable dissertation
The gap between a working system and a defensible dissertation is almost always the written argument around it — the problem statement, the design rationale, the evaluation method and the contribution claim — which is exactly the writing Tesify is built to help structure once you supply the artefact, its objectives and your evaluation results. It builds the six Peffers sections in the order your department expects, keeps the contribution claim consistent from your introduction through to your conclusion, and leaves the design and the code entirely yours. There is a free plan.
Structure your design-science dissertation with Tesify
If your project sits closer to the behavioural information-systems tradition than the design-science one, the chapter-by-chapter comparison in our guide to structuring an information systems master’s dissertation works through both routes side by side, and the statistics that support a behavioural evaluation follow the same logic set out in our answer to which statistical test to use for your dissertation.
Frequently asked questions
Can I submit an open-source project I already built before registering?
Only if you can retrofit a genuine research argument onto it — a problem statement, objectives and a rigorous evaluation the original build did not include. Departments distinguish between a research artefact designed to test a claim and a product built for its own sake; the latter needs substantial reframing, not just a written report bolted on afterward.
Does the code itself get marked, or only the written dissertation?
Both, but differently. The written dissertation carries the research argument and is what an external examiner reads in full; the code is usually assessed by your supervisor or an internal examiner against the design described, checking that the artefact does what the dissertation claims. Departments vary on whether code quality itself is separately graded, so check your own department’s rubric.
Is a systematic literature review alone acceptable as a computer science dissertation?
Some departments accept a rigorous systematic review as an alternative to an artefact, particularly at honours or coursework master’s level, but it is a different research design with its own method (typically PRISMA-style reporting) rather than a lighter version of a design-science study. Confirm with your supervisor which type your registration commits you to before choosing.
What counts as a “baseline” if my technique is genuinely novel with nothing directly comparable?
Examiners still expect a comparator — the best available existing approach, even if imperfectly analogous, or a naive baseline stated explicitly as a lower bound rather than a serious comparator. State plainly why a closer comparator does not exist; an unexplained absence of any baseline reads as an evaluation gap rather than genuine novelty.
How long should the design and development chapter be?
Long enough to let a competent reader in your sub-field understand the architecture and rebuild the key components without your codebase, typically several thousand words with diagrams, not a code listing. Full source code belongs in an appendix or a linked repository, referenced but not reproduced at length in the chapter itself.
Can two students submit dissertations built on the same shared codebase?
Only if each dissertation stakes out a clearly separate research contribution, problem and evaluation — shared infrastructure with genuinely distinct research questions is common in supervised research groups, but overlapping contributions between two submissions is treated as an academic integrity concern by most faculties. Clear this explicitly with both supervisors before it becomes an issue at examination.