Structure and Content of a Thesis/Dissertation/Report
Title Page
The title page of your work.
Summary/Abstract
Here you are listing a brief summary of the motivation (perhaps phrased as a “problem”), the methods you used to attack this problem, a summary of key results and your strongest conclusion(s).
Contents Page
This is usually automatically generated by your word processing solution.
Chapter: Introduction
This section starts out with your motivation, assumptions and first thoughts on what to do. This is then followed by a literature review, and then a (re)statement of your specific objectives.
In these highlighted textboxes, I try and illustrate with a pretend example. Let’s say you and your supervisor(s) came up with the following (crazy) idea to test:
Street entertainment is boring and can be improved with real-time application of economic theory.
Here we have a motivation (make street entertainment better) with an assumption (economic theory can help). Now we need some ideas for a good research question to ask, what our specific goals will be in this work and how these goals break down into smaller objectives.
Statement of Research Intent/Hypothesis: Street entertainment can be improved by providing the performers with real-time forecasts of the NZ Stock Exchange.
Goals: Enable the throughput of economic forecasting in real time to a street performer.
Initial Objectives: (i) Identify NZX shares which correlate with juggling in public, (ii) Write code to predict 3-day forecast on these NZX share prices, (iii) construct a portable unit to convey feedback to the street performer.
You could choose to state these initial objectives prior to the literature review and show how they were modified by the state of the art. Usually though, people just have these in their head and don’t document them. They are usually sketched out in your preliminary discussions with your supervision team.
At the end of this initial discussion/brain-storming session, you will have a bunch of key words on which to base your literature search. You might also have a pile of literature that your supervisor has handed you. On the basis of these key words and known documents, you start searching for, and reading, the literature.
The literature review should be exactly that: a review of the literature — not pulling out specific technical information (i.e. formulas) from the literature. The literature review should be “Amos and Flint (2009) described a system to do XXX, which performed better compared to the earlier work by Jones and Jones (2005). However we note that the latter did not contemplate specifically YYY. The reason for this is the development in ZZZ (see e.g. Twerp et al 2010)”. In none of that did we learn of the specific details or background theory of anything to do with XXX, YYY or ZZZ. At the end of your literature review you can review and discuss your Statement of Research Intent in light of the literature.
The Literature Review might include who has done what on (i) street entertainment (perhaps a review article), (ii) juggling as performance art, (iii) relationship of application of real-time data for improving juggling performance, (iv) improvements in chip computing, (v) previous works on the relationship between stock prices and juggling, (vi) real-time feed-back systems.
It’s almost certain that, after reading dozens of articles, papers, reviews and other resources, that your original objectives will need revising.
“Refined Objective(s): BASED ON OUR LITERATURE REVIEW, this work will comprise writing software which embodies convolutional neural networks and blockchain, fed real-time data for NZX stocks A, B and C, implemented on a raspberry pi which also controls an electroshock system.”
The Introduction section should tell a story of how the research question was developed from the broadest concepts, through to a goal, through to specific tasks.
In our example, notice how we’ve gone from the broadest context (street entertainment is boring) progressively to a goal (provide real-time economic forecasting — implicitly to improve street entertainer performance), through to specific tasks, i.e. what you propose to do in this work. Also, general objectives have been refined — for example the original objective “feedback” has been amended to the more specific “electroshock” feedback. Can you see a subtle limitation or bias in our work which has shown up so far?
Chapter: Background
This is where a lot of what people write in their Literature Review should reside. Notice that the Background section only contains background material which is relevantfor this work. There will be material you have read which turned out to have no relevance to your work — and these works have no place in your Literature Review section. There may be material referenced in the Literature Review that has no relevant material for the reader in the context of your specific goals and objectives, but the details in these works have no place in your Background section.
Continuing our example, our reader needs to know about the specifics of convolutional neural networks, blockchain, raspberry pi, electroshock theory. Each of these could be specified in a separate subsection. For example:
“Electroshock therapy
Equations 45–56 from [ref] quantify the pain response and memory retention profile for a standard human. This is modified by a coefficient, k, which is set at a value according to Table 3 which contains empirical data for different styles of juggling.
Defining quality of street performance
Referring to Barnum and Bailey (1863) street performance can be quantified by Equation 101, wherein…”
Chapter: Methodology
The methodology section is where you set out the steps you took to obtain the results. Ideally, all this methodology will be set out early in your project. Practically, this never happens — you tend to modify the methodology in light of results and you iteratively amend your methodology. A good report will keep a track of initial methodologies, their amendments and the motivation for the amendments.
Continuing our example, we could choose to separate out the steps based on the elements of the whole experiment:
Software
1. steps that will be done to install software UUU, that provides a framework for defining a convolutional neural network,
2. steps that will be done to test this software on canned examples
3. steps that will be done to adapt this software for our purposes
4. steps to iteratively improve the metaparameters on our software to hit specific performance goals
5. steps to determine if we are ready to run for final results…
Hardware
1. steps to obtain necessary hardware the raspberry pi (version z)
2. steps that will be taken to test it
3. steps that will be taken to embed code
4. steps that will be taken test it
Preparation of experiment
1. steps to take to apply for ethics approval
2. prepare for plan B in the event that plan A is scuttled
3. steps to take to obtain volunteers
4. etc. etc.
Preparation of analysis
1. steps to install python library “jugglemath”
2. steps to analyse results
Chapter: Results
This is where you record the output of running your methodology. Data are usually provided in tables and figures. Did the methodology have to be amended and re-run? Why? What was missed/wrong the first time? Were the assumptions still valid?
Chapter: Discussion
Here you will include a description of the reliability and accuracy of your results, a description of the results in the context of the subject of the topic and set out the limitations of the experiment.
(Chapter: Further Work)
Some people choose to have a whole chapter dedicated to what are the next steps in this research. Otherwise, the further work should be a part of the Discusssion.
Chapter: Conclusion
Draw conclusions from the discussion (was the hypothesis supported or not by the results?).
Propose other objectives (for this work) to improve the acquisition of goals (of this work)
Set this work in CONTEXT — i.e. the next steps would include using your system in a systematic way to collect data and examine to what extent these data support the broader goal (i.e. beyond the scope of this work). What are the caveats? What are the assumptions? What would you warn users of your software against?
