There are many different types of project and so it is
difficult to produce a detailed set of recommendations to
suit every single dissertation. Thus the dissertation
structure below is only a suggestion. Presentation and
writing issues are described
elsewhere but, in general, all dissertations should
be divided into a series of numbered chapters and
sections, each with titles and only these chapters count
towards the page limit. It may be helpful to peruse a few
previous dissertations to help see how the following
structure can be adapted.
It is usual to assume that the reader is familiar with
material all your fellow students will be familiar with
from the taught component (so you cannot assume your
reader will know anything you have covered in an optional
module). Any further material needed should be summarised
and suitable references
| Title page
||Title, name, supervisor, module code,
date, and the following
"This report is submitted in partial fulfilment of
the requirement for the degree of [Degree Title] by
The title the dissertation ends up with need not be
the one it started with in the project choice stage
more than a year earlier but it should be
meaningful. "My Design Project" is not
||The second page should be the following declaration:
"All sentences or passages quoted in this report from other people's work have been specifically acknowledged by clear cross-referencing to author, work and page(s). Any illustrations that are not the work of the author of this report have been used with the explicit permission of the originator and are specifically acknowledged. I understand that failure to do this amounts to plagiarism and will be considered grounds for failure in this project and the degree examination as a whole.
** Note that you should type your name here but you are not required to physically sign this page. By submitting your project through MOLE, you agree to the declaration above.
This should be two or three short paragraphs
(100-150 words total), summarising the
dissertation. It is important that this is not
just a restatement of the original project
outline. A suggested flow is background, project
aims and main achievements. A bad abstract would
have a final paragraph that just said "the
achievements will be described" - this is useless,
as it says nothing. From the abstract a reader
should be able to ascertain if the project is of
interest to them and presents results of which
they would like to know more details.
||Thanks to whoever may have helped you in any way -
both serious and a bit of fun.
||Includes titles and page numbers of all sections
and subsections. Chapter 1 begins on page 1. Use
Roman numerals for all previous pages, e.g.. title
page (i), signed declaration (ii) abstract (iii),
acknowledgements (iv) and contents (v-?).
It is often best include a separate list of
all the figures in the dissertation (figure number,
label, page number), and a separate list of all
tables in the dissertation (table number, label,
| Chapter 1: Introduction
The introduction has several purposes. Clearly
one is to set the scene for the project by giving
a little relevant background information - try to
grab the reader's interest early. Another is to
clearly elucidate the aims and objectives of the
project and the constraints that might affect the
way in which the project is carried out. If the
project involves the solution of a specific
problem or the production of a specific system
this should be clearly specified in an informal
way. Finally, the introduction should summarise
the remaining chapters of the dissertation, in
effect giving the reader an overview of what is to
The type of project will dictate the content and
structure of the following chapters and you should
discuss this with your supervisor. For example,
for a theoretical project it is likely that
several chapters will be devoted to constructing
the theoretical foundations for the project and
will consist of your own interpretation and
synthesis of existing work with suitable examples
discussed throughout. A sequence of chapters that
cover theoretical framework, conditions and
assumptions and theory application and comparisons
may be appropriate. For an experimental project,
the experimental goals, design, execution and
evaluation might be covered. What now follows is a
typical structure for a 'design and build'
At the end of chapter 1, you should include a brief discussion of your view of the relationship between your project, and your degree programme. In your discussion, you should mention any advantages or challenges created by this relationship.
Chapter 2: Literature Review
The title of this chapter is open to discussion.
Literature review is a bit simplistic and it may
be that you can title the chapter better, based on
the particular type of project that you are doing.
It is often useful to start this chapter with an
overview of its contents, giving the reasoning
behind why you have structured it in a particular
way. The main thrust of the chapter is a review of
relevant work by other authors and the
relationship between this and your own work. If
several other people have done closely related
work in a different way then the reasons for your
approach should be summarised here.
A good literature review is synthetic: general
trends and positions in your research area should
be identified, and the papers you cite should be
compared and contrasted. A literature review is
not simply an annotated list of papers you may
have read. It should cover a range of relevant
material to your project. Everything you use
should be cited by reference to the bibliography
at the end of your dissertation. See the page on using references for
how to do this.
Everything that you write must be your own words
and you must cite other people using references.
You may also quote sentences from the work of
others. These must be included in quotation marks
and again the relevant work must be cited. Your
signed declaration means that you will fail your
dissertation if you do not acknowledge the work of
| Chapter 3: Requirements and analysis
||This should state, in a more detailed
way, the objectives of the project by requirement
and the analysis should break the problem down into
manageable steps. There may be more than one
suitable approach; the analysis may cover more of
the area than is finally implemented. Testing and
evaluation should be given due consideration. It is
important that you state how you will evaluate your
work. For a design project it is appropriate to
consider testing at the same time as specification.
| Chapter 4: Design
||This should explain the design
technique chosen (and justify why it is appropriate)
from the various ones available; it should select a
suitable subset of the things described in the
analysis chapter and develop a design. Where
trade-offs exist between different designs, the
chosen approach should be justified. Suitable
diagram-techniques (e.g. UML, other drawings) should
be used where appropriate. If a method is applied
selectively, explain which parts were used and why.
Experimental projects should pay careful attention
to control conditions, samples selected, etc. to
ensure a valid result.
| Chapter 5: Implementation and testing
||In addition to illustrating "coding
traps", this should highlight particular novel
aspects to algorithms. Testing should be according
to the scheme presented in the Analysis chapter and
should follow some suitable model - e.g. category
partition, state machine-based. Both functional
testing and user-acceptance testing are appropriate.
For experimental/investigative projects, techniques
developed should be evaluated against a standard
result set for calibration, as well as the "live"
data set. For theoretical projects, the relative
power/expressiveness of the theory should be
evaluated with respect to competing approaches.
| Chapter 6: Results and discussion
||The main results of your work should
be presented, together with critical discussion. The
chapter should cover three things (although these
would not be used as section headings):
- Findings - present all the results
(products, experimental findings, theories,
etc.) generated during the project. This may
also include some off-topic findings that were
not expected, or which were side-effects of
- Goals achieved - describes the degree
to which the findings support the original
objectives laid out for the project. The goals
may be partially or fully achieved, or exceeded.
An experimental project may prove, or disprove
the original thesis. A theoretical project may
cover some or all of the example cases. Note
that reporting of failures to achieve goals is
important since a fundamental feature of the
assessment procedures is that the processes (how
you went about your project) are often as
important as the products of the project.
- Further work - describes two things:
firstly, new areas of investigation prompted by
developments in this project, and secondly parts
of the current work which were not completed due
to time constraints and/or problems encountered.
| Chapter 7 Conclusions
||The conclusions can be summarised in
a fairly short chapter (2 or 3 pages). This chapter
brings together many of the points that you will
have made in other chapters, especially in the
previous results and discussion chapter. Do not be
afraid of repeating some of your earlier statements
here, albeit using different wording.
These may be provided to include further details
of results, mathematical derivations, certain
illustrative parts of program code (e.g. class
interfaces), user documentation, log of project
milestones. In particular, if there are technical
details of the work done that might be useful to
others who wish to build on this work, but that
are not sufficiently important to the project as a
whole to justify being discussed in the main body
of the dissertation, then they should be included
Any appendices do not count towards the page
limit, but equally they are not treated as part of
the dissertation for the purposes of assessing it.
In other words, there is no expectation that the
examiners should read the appendices as part of
the assessment process. Hence, it is important
that any material which will be significant to
judging the quality of the dissertation or of the
project as a whole should be in the main body of
the dissertation, and not in appendices. Do not
include an appendix containing all your source
code listings - instead this material will be
collected electronically. What may be worth doing,
perhaps, is that if there are any code fragments
of particular novelty, then you could include
these in an appendix, so that they could be
referenced in any descriptions in the main text of
the chapters. This would make such an appendix
very similar to the idea of appendices for
You are required to submit the report electronically through MOLE by the deadline. BY SUBMITTING YOU AGREE TO THE FOLLOWING DECLARATION:
All sentences or passages quoted in this report from other people's work have been specifically acknowledged by clear cross-referencing to author, work and page(s).
Any illustrations which are not the work of the author of this report have been used with the explicit permission of the originator and are specifically acknowledged.
I understand that failure to do this amounts to plagiarism and will be considered grounds for failure in this project and the degree examination as a whole.