A Short Guide for Writing a Thesis

Thesis writing guideline is best summarized in the following advice, variously attributed to different authors: "First you tell 'em what you're going to tell 'em. Then you tell 'em. Then you tell 'em what you've told 'em."

v v v

The following are rough 'n ready guidelines to thesis writing.

1.   Structure

The following sections roughly correspond to the chapters of your thesis. You can have more or less chapters, but this seems to be the right number.

Every time you write a section or a chapter, re-visit these recommendations and check whether you fullfilled all the requirements.

1.1.   Thesis Abstract

The abstract should summarize the entire thesis. A common mistake is that abstract summarizes only the first chapter (Introduction) and says nothing about the content of other chapters.

The point I'm trying to make is not really in summarizing the content of all chapters, but rather the point is that the abstract should be very specific about the problem being solved, about the methods employed, and about the results achieved. (Interestingly, this last item is the one most often forgotten!)

A good abstract enumerates what you did. In other words, your abstract should have a lot of sentences starting with:
"We developed [this]", or "We designed [that]", or "We implemented [this] using [that]", or "We evaluated our system and obtained [such and such result]". State explicitly what you achieved in your work. Try using quantitative data, such as "improved performance by 30% compared to the existing methods," or "reduced effort needed to accomplish the task by 50%."
Do not explain how you did it in the abstract; such explantions should be left for the thesis document. If the reader is interested in what you did, they will read your thesis to find out how you did it.

1.2.   Introduction

A usual mistake that students commit in the Introduction chapter is to start from the beginning, I mean basics, and keep introducing the background without ever telling what this thesis actually does. Recall the first part of the above advice: "First you tell 'em what you're going to tell 'em." This literally means providing an "elevator speech" about your work. Describe at a high level what your thesis actually achieves and how, rather than talking in general about general about general ...

Describe why is this work relevant and worthy solving; why would anybody care about the problem that you're trying to solve? what use of it? What benefits would be accrued should your effort succeed? Justify the whole effort.

  1. What is the problem that you're solving?
  2. Why is it relevant and worthy solving?
  3. What is difficult about your problem?

Success Criteria -- Outline exact criteria for determining whether the progress is made or even all objectives are accomplished. These should be stated so that you'd be able to apply them to the work somebody else did for you and judge whether they actually solved the problem.

Briefly summarize how you plan to solve the problem.

Hypothesize what approach could be pursued and what kind of results should be expected.
State explicitly your intuitions and expectatations in the following form:
If this approach is taken, the resulting system/product will have faster performance, or shorter code, or smaller communication overhead, or the new approach will prevent user errors, or ...

Present a Roadmap of the thesis -- how it is organized, what the reader should expect in each chapter.

1.3.   Related Work

Review the prior art, what other researchers did so far to advance towards the goal you put forward in Chapter 1. Are you the first who tried to solve this problem?

Unfortunately, most students underemphasize the importance of this section. Bad idea! Keep in mind that people usually understand things incrementally. So, if you fail to tell them how is your work new relative to the work they already know about, you already lost them -- read: "you'll end up in trouble."

"Prior art" is jargon for whatever knowledge is considered obvious to those most familiar with the area in which a problem is being solved. Thus, to qualify for a thesis, the idea must somehow not be merely an obvious way to improve an existing solution.

Related work can be related in many ways:

Of course, at a certain level of abstraction, everything appears similar and related. That is why you have to employ your own judgement about the degree of relatedness and be very specific. Making such judgements is part of the thesis work.

If there is an existing work, explain clearly where they came short. How is your work different from theirs? What were they focused on and why do you think a different focus or approach would yield better results?

Try to organize the presentation chronologically: who did what first -> who improved upon it and how -> how do you expect to improve upon their work.

1.4.   Technical Approach

Provide a brief overview of the tools and methods that you will use to solve the problem. Here you provide a brief review of the software toolkits or libraries that you used. Or, network technologies, such as Motes, RFID, ZigBee protocol, or whatever are the tools that you employed to your purpose. Some of the details may be appropriate to put in the appendix (see Section 1.8 below). Cite references to more detailed sources about these tools and techniques.

Elaborate your idea for solving the problem, with all the details of software design or mathematical model derivation.
- Provide arguments why you believe your approach should work
- Describe the alternatives that you considered at every step
- Explain why you decided not to pursue the alternatives.

1.5.   Implementation and Results

Describe how you implemented your idea: software system or a simulation on a simulator.

Present all the measurements that are relevant for evaluation of the idea and the technical approach.

Discuss whether or not the expectations presented in the introduction are met. What makes you think so. Can you provide hard evidence to defend your answer?

NOTE: Hard evidence in engineering usually means some sort of measurement. If you claimed that the resulting system/product will have faster performance or smaller code or shorter communication overhead, then measure these and present the (quantitative!) results.
It may appear difficult to measure the "scalability" or "ease of use" of software. However, if such a claim is made, you should invest effort to make explicit any indicators by which it is possible to convince other people to the validity of your claims.

When presenting your results, it is not sufficient just to show numbers, tables, or charts. You should tell the reader what he/she should see in the chart, what to pay attention to. Offer your explanation why this occurs, and what is the significance and implications. You need to explicitly tell the reader how to understand your results. Do not expect the reader to invest effort and make such inferences, because they will not, or they may get it wrong.

Your results should be compared to the results achieved by researchers who previously worked on this or related problem.

1.6.   Conclusions

Briefly summarize what are the main contributions of your work. This is usually best done by restating the hypotheses and describing how the observed results met those expectations. Best format is a bulletted list.

Should somebody else follow up along the lines of your work, what would you recommend to do next. In other words, what would be a good topic or topics for a new thesis related to this problem.

1.7.   References

References should be ordered alphabetically, by the (first) author's last name.

Cite all the sources you use and provide full citations even for the webpage URL:

Author, "Title of the Work," Forum where it Appeared (journal, conference, web, ...), Year.

If you copy a figure or a method for solving a (small or large) problem, make sure you credit the source.

1.8.   Appendix

This section is optional, in case you want to attach a printout of the source code, or some involved mathematical derivations, or user's manual for running your system, or printout of simulation results, etc.

You may also want to put in this section description of the software toolkits or other technologies that you used.

2.   Document Formatting

The link below is Rutgers thesis and dissertation style guide:
http://gsnb.rutgers.edu/style_guide.php3

Note that you are required to follow the formatting guidelines. The graduate school staff will check the compliance and refuse to accept your thesis document if found not to comply.

v v v

You can find much more about this topic here:



Back to I. Marsic's Home Page

This page last updated: Tue Mar 23 11:43:02 EST 2004