direkt zum Inhalt springen

direkt zum Hauptnavigationsmenü

Sie sind hier

TU Berlin

Page Content

Tips For Preparing A Bachelor, Master, Diplom Or Whatsoever Thesis

This one does always apply: If you have questions you can always ask your advisor!

  • Before you start writing your thesis have a look at Writing a paper? Please check these guidelines. First nswer the afollowing quiz. [1] and Common Bugs in Writing [2].
  • In general, the group prefers theses in English so that the theses can be published for a larger audience.
  • Typical Outline
  • Detailed Outline
  • Basic Rules For Each Chapter, Each Section, And Most Of The Subsections
  • Orthography and Style
  • Basic Rules About Graphics And Tables And Such
  • LaΤεΧ Specific

Typical Outline

The following outline is just a suggestion. Certainly, some variation can sometimes be necessary. Especially the abstract, the introduction and the terminal part should be polished—but as the very last thing you do, just before you hand your thesis in.

Also take care for the demands of the department. Links will follows as soon as we found some information.

Statement On Oath

The following statement on oath is suggested by the "Prüfungsamt" (examination department):

chapter*{Eidesstattliche Erkl"arung}
addcontentsline{toc}{chapter}{Eidesstattliche Erkl"arung}

Die selbst"andige und eigenh"andige Ausfertigung versichert an Eides statt\
Berlin, den today




Short summary. It would be best to write it as the very last thing when the rest is already (nearly) done und you know exactly what you actually want to summarize. :)

Table of Contents

Obvious. :)

Chapter 1: Introduction

For the introduction (Einleitung) it is probably also best to write it later. But it depends on personal liking. persönlicher Geschmack. Structure:

  • What's it all about?
  • What is the problem?
  • Why is that a problem?
  • Why is it that exciting, to solve the problem? – The motivation is interesting in particular. (By the way, not just in your introduction.)
  • How did we solve it? (just a rough sketch)
  • What can the reader expect in the next chapters?
    In Chapter 2, I will provide background information for those readers who are not familiar with the concept of using semivariate hyperalgebrae for right-linear routing protocols. Chapter 3 will present an overview … blabla

Chapter 2: Background

This is for stuff that is necessary to understand your work but that your work doesn't really deal with, such as

  • a description of the software that you enhanced (e.g. Bro), or
  • a description of what others already did (but you can also put it into its own chapter).

Chapter 3: How Did I Approach The Problem?

This can, e.g., be an overview over a sketch of your own implementation if this is non-trivial.

If you bothered a lot about enhancements of your own implementation but you did not have enough time then you can spread your thoughts in this chapter and, e.g., sketch out what another developer has to take into account, or what would be a meaningful approach. Also, in your prospect (here: Chapter 7) you should refer to this part. On the other hand, eneral / indefinite "this enhancement would also be nice" statements should better be put solely into the last chapter (here: 7).

Chapter 4: Simple Results of Your Analysis

Which interesting data did your software produce?

Chapter 5: More Results of Your Analysis


Chapter 6: The Most Interesting Results of Your Analysis

Suspense curve

Chapter 7: Conclusion and Outlook

This chapter should logically be written at the end. E.g.

In this work we presented an approach for …/ a system for …/ blabla. The system is designed (blabla, summary of Chapter 3). Our results extended the works by (Chapter 2) and revealed that … (summary of Chapters 4, 5, 6).
Possible Extensions of (Chapter 3) would be to support / Future work should address (Stuff that occured to me while implementing and/or that I didn't manage to implement, too). Other interesting analyses, which would be beyond the scope of this diplom thesis, could investigate whether … (Things that occured to me at the end of my work when I didn't have the time to even try that, too, mostly because I had to rewrite most parts of my software.)


  • Roughly speaking, put into the appendix chapters technical details that you wanted to mention but your supervisor doesn't like it in the main part. :)
  • You can also put further background information into this chapter to avoid padding out Chapter 2.
  • A manual, an example session, or similar is also a good candidate for the appendix.



  • only if you have many figures: List of Figures
  • only if you have many tables: List of Tables
  • Glossary
  • Index

Always put the index at the very end. This is where the reader expects it. The order of the other three entries is not that fixed. Some people even put the lists of figures and tables in the beginning, right after the list of contents.

If you compile an index, please don't do that half-heartedly but list all appearances of a certain keyword. Better yet, all relevant, but all is still better than all of which I remembered to put them into the index. Well, and that works best if you go all the way from the very beginning – and, by the way, this becomes much more simple if you use the tips from the section on LaΤεΧ tips (indexify command).

Detailed Outline

Before you begin to write your thesis properly down you should think about an outline and talk it over with your supervisor.
At this you should think of the following:

  • If you need subsubsections (i.e., if "" appears in your outline) you should think about another structure.
  • If there are Chapter 4, Section 4.1, Section 4.2, and Subsections 4.2.1 to 4.2.19 and nothing else in in 4th chapter you should think about another structure.
  • If there is Section x.1 then you at least need Section x.2
  • If you feel you'd need Section x.0 you should have a note in your mind with everything that you'd put into x.0 and later put it into the text between x and x.1.
  • There has always to be some text between two section headings, at least one sentence (see below).

Basic Rules For Each Chapter, Each Section, And Most Of The Subsections

  • First, give a short introduction what it's going to be about, then, get started.
  • Always try to set up your text following the following rules:

    • What is the problem?
    • Why is that a problem?
    • Why is it that exciting, to solve the problem (… and to describe the solution in my work …)? — Motivation is always important!

  • By the way, inbetween two section headings has always to be some text, even if it's just a single sentence, e.g., the bold printed sentence in the following example
    6.   My Awesome Results
    In this chapter I will present my most awesome results of all.

    6.1   Awesome Results, Part 1

Orthography and Style

  • Footnotes are bad because they interrupt the flow of reading. We are no lawyers. Usually, we put our references into the text, not into footnotes.
  • Footnotes should be used for details that you would preferably in brackets but that are (a) to long for brackets, or (b) even less important than brackets, e.g., some little subtleties, that should be mentioned for correctness.
  • Avoid brackets. They make your text weak.
  • Avoid subjunctive forms, especially in English texts (because they also make your text weak); be bold and use the indicative: Never write "our approach could improve the situation" if you can also write "our approach can improve the situation".
  • Absolute statements ("the only solution for the problem is to …") are often difficult. Are you really sure that there is no alternative, not even a very uninvestigated one? Precisely.
  • An automatic spellchecker is something awesome and there are also spellcheckers that work with LaΤεΧ.
  • In case you write your thesis in German, these are three popular mistakes:

    • It's called "Standard" with a d at the end! (The "Standarte" is a flag!)
    • Noone writes "Leber Wurst", or "Spiegel Ei", or "Bundes außen Minister", or "Kraft fahr Zeug zu Lassung".
      As wrong are the often seen spellings "Routing Protokoll", "Update Information", or "BGP Konvergenz Analyse". In German you either write a compond or you use at least a hyphen.
    • By the way, it's "übrigens" without any d, not "übrigends".

  • In case you write your thesis in English:

    • Before and after "e.g." ("for example") and "i.e." ("that is") you always write a comma. Always!
    • Short forms such as "can't", "doesn't", "we'll" and so on are not used in written language. Instead, write "can not" (or "cannot"), "does not", "we will".
    • Either use british English ("colour", "minimise", "initialise", "disc", "grey" and so on) or american English ("color", "minimize", "initialize", "disk", "gray" usw.). But be consistent and don't mix it. If both in their pure forms make you feel bad, you can still use canadien English which uses elements of both (e.g., "colour", but also verbs with "-ize").

  • Speaking of English and German: In English it's "packet", but in German it's "Paket", without "c".
  • Exceeding long sentences which have many insertions, lists, dependent clauses—which are also quite popular—or a however mannered significantly raised syntactic complexity (maybe together with backets and foreign words) should especially be avoided in English but also in German texts since such tapeworm constructs are very uncommon in English language texts and, the other hand, also leave german readers behind in particular at a high nesting level of sentences in a nominal style that are begun at the beginning but are closed at the very end of the sentence, and make them read the sentence again and again.
  • Don't phrase your text as slangy as we did on this website.

Basic Rules About Graphics And Tables And Such

  • If I put a graphic into my work I have to reference it in my text and explain what is seen in that graphic.
  • Before I explain what is seen in the graph (e.g., "the system's disatrous behaviour without my improvements") I have to explain how you can see something at all (e.g., "the points that are interesting for us are located next to the origin; for now we can ignore the anomalies; large values of y are good for us, small values are evil"). In particular, if you plot non-trivial stuff—e.g., the logarithm of a relation as a function of the accumulated rate or something—you have to explain precisely what is plottet (and also, at best, why in this brain-twisting way).
  • If there is any text, symbols, etc. in your image you have to explain them somehow; either in your text, in the legend, or maybe also in the caption.
  • In principle, this applies for graphs:
    All axes have to be labelled; all axes have to have a scale—this is a very importand basic rule!
  • Graphs, in particular, should also be readable if the thesis is printed on a b/w printer. Red and green curves both become gray … so better work with different dashings and dottings, thicknesses of the curves, kinds of dots, etc. and use colours only additionally.

LaΤεΧ Specific

If you use something different than LaΤεΧ then you're—carefully said—very brave on the one hand, and on the other hand you have a good chance that your thesis will typographically look very ugly. You have been warned!

You can also use our LaTeX template [3].

Making your thesis nicer

  • usepackage[bf,small]{caption}
  • usepackage{url}: Then you can use the useful command url{http://blabla.blub/xyz/} which typesets URLs in texttt and seperates long URLs at symbols such as . or _ or / or - if the line is at its end. By the way, this is not just useful for URLs but also for Paths (path{}), names of variables, etc.
  • If you want to play with fonts:

    • Please use usepackage{mathptmx} instead of packages pslatex or times.
    • Please use usepackage{mathpazo} instead of package palatino.

Optimizing your workflow

  • Use BibΤεΧ.
  • With marginpar{foobar} you can write comments onto the margins, e.g., "write some more, here", "reword / extend", or "maybe shift elsewhere", etc.
  • With newcommand you can define new commands that make your life easier. If you are tired writing very_long_wordindex{very_long_word you can define a macro newcommand{indexify}[1]{index{#1}#1} and use it with indexify{very_long_word}.
  • A make file can decrease your work.
  • Just ask the members of the groups for further hints.

Typography (certainly also applies for non-LaΤεΧ users)

  • Dashes (breaks) are typeset in English like that: "Word1---Word2", and in German like that: "Wort1 -- Wort2". That gives "Word1—Word2" (English) and "Wort1 – Wort2" (German).
  • On the other hand, for component terms you use in both, English (rarely) and German, no breaks but the normal hyphens "-", e.g. "steady-state model", "BGP-Tabelle", "Update-Sturm".
  • Abbreviations are typeset either as in e.,g., or (if you're lazy) e.g., but better not as e.~g. or, even worse, e. g..
  • The word "Figure" may be shortend. Get used to the following notation: "in Fig.~ref{greatpic} we see …". The tilde is important: a linebreak looks just silly at that position.
    By the way, "figure"/"table" is only written lower case in English if it's not a certain figure or table, e.g.: "As we can examine in the second figure/table, nothing …". But if you specify the figure/table, you have to capitalize it: "As shown in Figure/Table 6.14 …". (And in this case you can also write "Fig.".)
  • Quotation marks are typeset in an English text like ``blabla'' and in a German text like "`blabla"'. (The latter only works in a German environment, e.g. when you use usepackage{ngerman}. If you want german quotation marks in an english environment, use glqq ("german left quote quote") and grqq ("german right quote quote").)
    Note in both cases the difference between ` (back tick) and ' (apostrophe)!
  • Before any punctuation mark (e.g., before a dot, exclamation mark or colon) is never a space ! Therefore, the previous sentence is typogrically as wrong as this one : too many spaces .
    Only exception: before an opening bracket certainly always is a space.
    (D'ailleurs, en francais, c'est la typographie correcte … !)
  • Behind a punctuation mark, on the other hand, always is a space (except english dashes (see above) and—certainly—closing brackets).
  • If you want to set suspension marks (but what should be avoided …) please us ~ldots instead of just writing three dots. That causes the right spaces between the dots.

Lehre / Teaching, SoSe 18

  • Internet Control Plane (VL) [4]
  • Routerlab (PR) [5]
  • Internet Security (VL) [6]
  • Internet Measurement (VL) [7]
  • NA: Internet Measurement (SE) [8]

Ständiges / Permanent courses

  • Projects and Theses [9]
  • Final talks [10]
  • Project group meeting (PGT) [11]
  • Recent talks and student talks [12]

Teaching @ FG INET

Damien Foucard
+49 30 314 75739
MAR 4-4
Room 4.027
e-mail query [13]
Website [14]
------ Links: ------

Zusatzinformationen / Extras

Quick Access:

Schnellnavigation zur Seite über Nummerneingabe

Auxiliary Functions

Copyright TU Berlin 2008