\chapter{Structure of the Thesis}

Most of the recommendations for the structure of the work are derived from the book Scientific Writing 2.0~\cite{lebrun2011scientific}.

\section{Introduction}

There are two main ways to write the introduction, i) driven by a problem statement, ii) driven by a research question / hypothesis.
Either way, it should be clear what the purpose of the work is and why it has been conducted.

The introduction may consists of four parts, plus two optional parts:
i) answer the question as to why now?, ii) answer the questions of why this?,
iii) answer the question as to why this way, and finally, iv) make clear why the reader should care.
The last point is also called impact and refers to what is now possible thanks to the work.

Additionally, the introduction may also contain the list of main research questions.
It may also contain the list of main contributions that are generated thanks to the work.

Often, the introduction ends with a short table of contents (for example, in chapter 2 the background...).
This part can be omitted, if the work follows the usual structure, and is only necessary, if the structure of the work deviates from the common norm.

The introduction is typically written in the present tense.

\section{Related Work}

\subsection{Background}

Explain all concepts used in your work.
What are the main underlying technologies?
If you use certain (textbook) algorithms, briefly explain how they work.

The idea of this section is to give non-experts explanations for the main techniques being used in the work.

References to Wikipedia\footnote{\url{http://en.wikipedia.org} (Accessed on: 2018-02-13)} and other online resources are okay in this sections.
Please use footnotes to refer to online references.

If there are tools, that solve (part of) the problem, there are listed in this section.
Screenshot will help the reader to get an understanding of them. 

\subsection{State of the Art}

How well is the problem solved so far?
Please cite existing scientific work (publications, books).
Use bibtex for proper citations.
Ask your advisor for how to search for relevant literature.

Typically, the beginning of this section is devoted to describe the methodology, of how relevant literature is researched.
For example, which sources (e.g., Google Scholar), are being used and which searches were submitted.
Often, there will be an overview table of how many publications have been found in total, how many were considered to be relevant and how many have been studied.

The quality of this section is an important aspect for judging the overall quality of the thesis.
This section demonstrated that you value the work of others.
In short, this section should demonstrate that the author is capable of:
\begin{itemize}
    \item Research relevant literature 
    \begin{itemize}
        \item ... and identify the key terms used in the scientific community
    \end{itemize}
    \item Read and understand (scientific) literature
    \item Summarise the key findings of the literature in own words
    \item Put the literature in the context in relation to the own work (thesis)
    \item Create a coherent storyline over all cited source
\end{itemize}


This section is more important in Master thesis.

\section{Use Cases \& Requirements}

For software engineering thesis, there might be a section dedicated to the use cases.
For other types of thesis, this section can be omitted.

Often such section will start with personas or narratives of the planned systems.
From there a number of use cases can be derived.
Out of the use cases, the (functional, non-functional, contextual) requirements can be described.
Optionally, also list important quality attributes that need to be addressed (for example, usability, security, ...).

This section may also host mock-ups of a the user interface of the system.

\section{Method}

Alternative names: Approach, System

Describe the approach in this section, how the solution looks like?
It should be sufficiently detailed as to allow others to replicate the presented findings.
Please do not write this section as a protocol of what you did (report style), but as a way how the system/method can be replicated.

Typically, this sections is organised in a way to go from abstract concepts to more detailed information.
Often the section is then split into a ``Concepts'' and an ``Implementation'' subsection.
The concepts will describe relevant definition, often in mathematical notation.
Alternatively, the concepts will contain system architecture diagrams.
Flow charts are another tool to present how the components work together.
How does the system work in principle/in general and how do the system components interact?

The implementation subsection will then more fine grained.
Pseudo code, or even snippets from the code will be presented here.
The libraries being used (together with their version number - as footnotes) are presented in this section.
The reader should be able to replicate the system as good as possible.
In this subsection, often UML diagrams will be used (class level).

This section is mostly written in the presence tense.

\section{Evaluation}

Alternative names: Experiments

Often, this section starts with a description of the evaluation methodology (how is the method being tested).
The methodology should cover all aspects relevant to assess how well the problem is being solved.
If the system/method has multiple parameters, these should be individually being tested/reported.

A good evaluation needs to include a baseline as reference.
Typically, this will be either the current state-of-the-art (how well is the problem solved so far), or an artificial baseline.

Alternatively, human baselines can be given (for example, using interrater agreement), these can be often seen as upper bound for the achievable performance.

Then, the used data sets are being described in detail, for example the size of the data set, class distributions, number of instances.
Generally, the more (diverse) data sets and the bigger the data set are - the better.
Optimally, combine an artificial data set with real-life data sets.

\subsection{Results}

Report of the achieved results, typically in form of tables and charts.
The way the results are displayed depends on how well a chart/table is suited to convey the main message.
The findings in this subsection are objective - no room for interpretation.

\subsection{Discussion}

This subsection than puts the achieved result into perspective.
Is the problem solved; how well is the problem solved?
Subjective assessments can be done here, but expressed appropriately (hedging), for example the results indicate that [...].

An additional subsection is ``Lessons Learnt'', which contains information of what went well, and what did not work out as expected.
Often, multiple iterations of the solutions are presented here.
This subsection is more often found in Bachelor thesis, rather than Master thesis.

\section{Conclusions}

Wrap up of the whole work. There should be no new information here.
Try to avoid a conclusion that reads like: ``First I did that, then I did that, next I did, ...''.
Focus on the main results and insights.
The conclusions are a direct answer to the questions raised in the introductions, e.g. How well is the problem solved? 
Ideally, one can read just the introduction and the conclusions and get a good picture of the whole work.

This section is written in the past tense.

\subsection{Future Work}

What parts of the problem are not solved yet? How to progress further?

This is an optional subsection.

\section{Bibliography}

Should be automatically generated by this template using the \texttt{.bib} file.

\section{Appendix}

Optional section, contains additional source code fragments (for example long regular expressions), additional tables and charts.