How to Write a Data Science Dissertation Methodology
How do I write a data science dissertation methodology that my supervisor will accept? Do I paste my Python code in? How much should I explain about my dataset, my train/test split and my choice of metric?
A data science dissertation methodology is the chapter where you explain, in the past tense and in a logical order, what you did with your data and why each choice was defensible. It is not a code listing and it is not a tutorial. Your reader should be able to judge whether your results can be trusted, and ideally repeat your work.
This guide walks through each part of the chapter in the order you would write it. If you want the general version first, read our guide to writing a methodology for a dissertation.
What the methodology chapter must show
Universities mark the thinking behind your choices, not only the model you ended up with. For example, the University of Surrey’s MSc Data Science dissertation module (2026/7) expects “a justification of the data to be collected and the methodology used, and a critical evaluation of the results obtained”. The word to notice is justification.
The University of Southampton library’s writing guide gives two useful rules. Write the methodology in the past tense, and present it in a linear order that links back to your research questions. Together they give you a simple test: every paragraph should answer “what did I do, and why?” for one of your questions.
The order the chapter follows: Research question, then data, then preparation, then split, then model, then metric, then limits.
Method, methodology and code: what goes where
Students often mix these up. A short table keeps them apart.
| Term | What it means in your chapter | Where it belongs |
|---|---|---|
| Methodology | The overall approach and the reasons behind it (framework, data strategy, evaluation logic) | Methodology chapter |
| Methods | The specific techniques you applied (for example, k-fold cross-validation or a random forest) | Methodology chapter, each with a reason |
| Code | The scripts that implement your methods | Appendix or a repository, referenced in the chapter |
For a deeper definition of the difference, see our explainer on what research methodology is.
Choosing a framework for your data science project
Pick one named framework and use it to organise the chapter. A framework gives your supervisor a familiar map, and it gives you a ready-made reason for your order of work. Which one depends on what kind of project you are running.
| Framework | Best when | What to say in the chapter |
|---|---|---|
| CRISP-DM | You are analysing a dataset to answer a business or research question | Walk through its six phases and say which ones you covered |
| CRISP-ML(Q) | Your project involves machine learning and you want to show quality checks | Same flow, plus how you checked quality at each stage |
| Design Science Research (Peffers et al.) | You are building and evaluating an artefact, such as a tool, pipeline or dashboard | Map your work to the six activities, from problem identification to communication |
| Plain experiment | You are comparing models or settings under a controlled setup | State hypotheses, the controlled variables and the evaluation protocol |
CRISP-DM in plain terms
CRISP-DM was described by Wirth and Hipp (2000) and published as a step-by-step guide by Chapman et al. (2000). It has six phases: business understanding, data understanding, data preparation, modelling, evaluation and deployment. Each phase maps naturally onto a section of your chapter.
One honest point helps you here. Reviews of studies that use CRISP-DM find that most omit the deployment phase. If your dissertation stops at evaluation, say so and explain why. That is normal for a student project, and saying it openly looks more credible than pretending otherwise.
When to use CRISP-ML(Q) or design science
CRISP-ML(Q) adds the quality assurance that the original CRISP-DM lacks, so it suits machine learning work where you want to show how you checked quality. Design Science Research Methodology suits projects that produce something. Peffers et al. (2007) set out six activities: problem identification, solution objectives, design and development, demonstration, evaluation and communication.
Whichever you choose, write one short paragraph that names the framework, cites it, and explains why it fits your question. Then use its stages as your sub-headings.
Describing your data: source, licence and provenance
Tell the reader where the data came from, who may use it, and how you obtained it. This is the part many students skip, and it is where a marker can quickly lose trust. State it for every dataset you use.
| Data source type | What to state in the chapter |
|---|---|
| Open government data (for example ONS) | The dataset name, publisher, access date and licence. ONS content is mostly published under the Open Government Licence v3.0, which requires attribution |
| Safeguarded data (UK Data Service) | That you registered, accepted the End User Licence, and the access level. UK higher and further education students can often register through their institutional login |
| Controlled data (UK Data Service SecureLab) | The approval route and the secure-environment conditions you worked under |
| Kaggle or similar platforms | The licence shown on the dataset’s own page. Competition data follows the competition rules |
| Data you collected yourself | The collection method, the sample, consent arrangements and the date range |
A few notes on that table:
- The UK Data Service groups data into three access levels: open, safeguarded and controlled. See its types of data access page for the rules on each.
- The Open Government Licence does not cover personal data, so check what a dataset contains before you assume it is free to use.
- On Kaggle, each dataset carries its own licence. Read it on the dataset page and quote it.
Also record provenance: who created the data, when, and for what original purpose. A dataset built for marketing may carry biases that matter for your research question. One or two sentences on this show your reader that you thought about the data critically.
If you are still choosing a topic and want ideas that come with accessible data, see our list of data science dissertation topics.
Cleaning and feature engineering: write decisions, not code
Your methodology should describe the decisions you made about the data, and the reason for each. The code that carries them out belongs in an appendix or repository. A marker wants to know what you chose, not which pandas function you called.
For each preparation step, cover three things:
- What you did. For example, you removed duplicate rows, or filled missing values with the median.
- Why you did it. Tie it to the data or the question, not to habit.
- What it affected. Say how many rows or columns changed, so the reader can see the scale.
The usual decisions to report are:
- How you handled missing values, and why that approach suits this variable.
- How you treated outliers: removed, capped, or kept, with a reason.
- How you encoded categorical variables and scaled numeric ones.
- Which features you created or dropped, and the thinking behind them.
- How you dealt with class imbalance, if your target is skewed.
One timing rule matters here. Anything that learns from the data, such as a scaler or an imputer, should learn from the training data only. The next section explains why, and it is the single most common source of inflated results.
A useful habit is to keep a short data log as you work. Each time you change the data, write one line saying what and why. When you write the chapter, that log becomes your draft.
Splitting data, cross-validation and data leakage
Split your data before you preprocess it, and never let the test set influence any decision. The scikit-learn documentation explains why: a model evaluated on the data it learned from can look perfect and still fail on new data. That is overfitting, and the standard defence is a hold-out test set.
In the wrong order, the scaler or imputer learns from every row, including rows that later become the test set. In the right order, preprocessing is learned from training data only and then applied to the test data. scikit-learn recommends Pipelines to keep this order safe, including inside cross-validation. Its common pitfalls guide shows the pattern.
What to write in the chapter
- The split. Say how you divided the data and in what proportions, and why.
- The validation method. If you tuned a model, say you used a validation set or k-fold cross-validation. The scikit-learn cross-validation guide notes that 5 or 10 folds are generally preferred over leave-one-out.
- Special structure. If your data is a time series or has groups (for example, several rows per patient), use a time-aware or group-wise split. A random split would let related rows sit on both sides.
- Imbalanced classes. If your classes are imbalanced, say whether you used stratified splitting.
- The test set. State that you used it once, at the end.
A sentence such as “All preprocessing was fitted on the training folds only, using a pipeline” answers the question most supervisors will ask.
Justifying your model and metric
Choose your metric from your research question, then explain the choice. The scikit-learn metrics and scoring guide puts it simply: if a scoring function is given, use it, otherwise consider the ultimate goal of the prediction. Your chapter should show that you did the second.
Also justify each model in one or two sentences. Say why it suits the data type, the sample size and the question, and name at least one simpler baseline you compared it with. A model that beats nothing proves nothing.
| Metric | Use it when | Watch out for |
|---|---|---|
| Accuracy | Classes are roughly balanced | Looks high on imbalanced data even for a poor model |
| Balanced accuracy | Classes are imbalanced | Hides which class is being missed |
| Precision | A false positive is costly | Ignores missed cases |
| Recall | A missed case is costly | Ignores false alarms |
| F-measure | You need a balance of precision and recall | Report how you averaged across classes (macro, weighted or micro) |
| RMSE | You predict a continuous value | Sensitive to large errors, so check for outliers |
The averaging method matters for multi-class problems. Macro, weighted and micro averaging can give different numbers on the same predictions, so name the one you used.
Finally, say how you tuned the model. If you searched for hyperparameters, report the search space and the validation method, and make sure the final test set stayed untouched until the end.
Ethics and personal data
Keep this section short, factual and specific to your data. State whether your data contains personal information, and explain the steps you took to protect people.
One point trips up many students. The UK Information Commissioner’s Office (ICO) states that pseudonymised data is still personal data. Removing names is not the same as anonymising a dataset.
What to include:
- Whether the data is personal, and the lawful or licensed basis for your use of it.
- Whether you collected it yourself or used an existing source with its own terms.
- How you stored and protected it.
- Whether your university required ethics approval, and the reference if so.
Universities differ on whether secondary data needs ethics approval, so check your own ethics handbook or ask your supervisor. The ICO is also updating its guidance on research provisions, so read its current pages rather than relying on older articles.
Reproducibility and limitations
A reader should be able to repeat your work and see where it might not hold. Reproducibility is a checklist job, so treat it as one.
- Set a fixed integer seed wherever randomness appears, and remove every
random_state=Nonein scikit-learn estimators and splitters. - Report the seed values you used. scikit-learn notes that fixing an integer seed inside an estimator can reduce the robustness of cross-validation results, so say what you did and why.
- List the language, library names and versions.
- Record the data version or access date.
- Share code in an appendix or a repository, and cite it in the chapter.
Then write an honest limitations paragraph inside the methodology. Typical limits are a small or unrepresentative sample, a single dataset, no deployment phase, or a split that could not account for time. Naming a limit does not weaken your work. It shows that you understand the boundaries of your claims, which is what a marker is looking for.
An illustrative methodology paragraph
The paragraph below is an invented example, written only to show tone and structure. Replace every detail with your own, and never copy it as your own work.
Illustrative example only. This study followed the CRISP-DM framework (Chapman et al., 2000), omitting the deployment phase because the project ended at evaluation. The dataset was obtained from a safeguarded collection after accepting the provider’s End User Licence, and the access date was recorded. Missing values in numeric columns were replaced with the training-set median, because the variables were skewed. The data was split into training and test sets before any preprocessing, and all transformations were fitted on the training set only. Models were compared using five-fold cross-validation, and balanced accuracy was chosen as the main metric because the outcome classes were imbalanced. All random seeds are reported in Appendix B.
Notice the pattern. Each sentence states an action in the past tense and gives its reason. That is the whole skill.
Frequently asked questions
How long should a data science methodology chapter be?
Follow your department’s guidance and your supervisor’s advice. Length matters less than whether every choice is justified and linked to your research questions.
Should I include code in the methodology chapter?
Describe your decisions in the chapter and place the code in an appendix or a repository that you cite.
Can I use a Kaggle dataset?
Often yes, but check the licence on the dataset’s own page and cite it. Also explain how the data was originally collected.
Do I need ethics approval for secondary data?
It depends on your university and the data. Check your ethics handbook or ask your supervisor, and do not assume either way.
Conclusion
A strong data science dissertation methodology explains the thinking behind the work. Name a framework, describe the data and its licence, record your cleaning decisions, split before you preprocess, justify your metric, handle personal data carefully, and make the work repeatable.
If you want an expert to review your chapter or your project plan, our data science dissertation help service can support you.
