Final Year Project Report Chapter Guide

the software used to run simulations is intended to be

Front Matter ................................................................ 1 of use to others. That is often but not always the case.

Acknowledgments........................................................ 1 Where linked material is distributed throughout the

report it is very important to make explicit forward or
Abstract ........................................................................ 1
backward references to the relevant sections. This
Introduction ................................................................. 1 enables a reader to understand your argument
Background .................................................................. 2 without the burden of repeated material.

Requirements Capture ................................................. 2

Analysis and Design...................................................... 2 Front Matter
The first page of your report should be a standard
Implementation ........................................................... 3
format Cover Page. The second page should be the
Testing .......................................................................... 3 mandatory Plagiarism Statement. Signature is not
Results .......................................................................... 3 required – its presence will imply signature.
Evaluation .................................................................... 4 Between the Abstract and the Introduction there will
Conclusions and Further Work .................................... 4 normally be a Contents page (or more than one if
required).
User Guide ................................................................... 4
Bibliography ................................................................. 5
Acknowledgments
Appendices ................................................................... 5
This section is optional, but customary.
This note covers in detail the normal report structure.
You must also comply with previously taught
guidelines on clear labelling of figures, graphs, use of Abstract
tables instead of lists in text, plagiarism, etc. The abstract should (very concisely) summarise the
topic, content and conclusions of the project.
The advice given here will apply to many projects.
Abstracts can vary in length from 50 words up to at
However each project is unique, and you should
most 200 words. They are more concise than
without fail get advice from your supervisor about
executive summaries. They do not need to be
how to structure your report, and its content, well
identical to any previously submitted abstract. Note
before writing starts.
that abstracts have no explicit marking in the final
Where the advice given here and that of your report scheme, so keep them short and clear.
supervisor differ, you should follow your supervisor's
advice as they will be taking into account the
individual nature of your project. Introduction
The introduction should set the scene and give a high-
Your report should, without fail, contain the sections
level problem statement/specification, so that after
specified in the Project Guide. In addition, the
reading the introduction the reader understands
structure and content of the internal chapters is
roughly what the problem is and what you intend to
typically as below.
do about it. Is the idea to write software, or develop
Some variation in structure is possible for the internal an algorithm, or produce hardware, or something
Chapters, however omitting relevant content is not. else?
For example, the project Evaluation Chapter could be
You should then highlight and summarise the most
a subsection of the Conclusions, or the Results. An
interesting or important questions or problems that
analytical project would not have a User Guide unless
your project addresses, and the broader context in
which those questions or problems are situated.
TJWC Final Year Projects 1
Finally, you must briefly introduce the structure of use is investigated and a brief more detailed than the
report (what you will cover in which chapters and how specification is constructed. This would include what
these relate to each other). You don’t need to go into is necessary, what is desirable, etc in the final
any detail, the aim is to make sure the reader has an deliverable. The results of requirements capture
idea about what will be discussed and in what order. determine project objectives and are used to inform
project evaluation.

Background Requirements capture is important in all projects with

real-world deliverables, and is often a significant
You should provide enough background to the reader
amount of work in software projects. Where
for them to understand what the project is all about,
requirements capture is less relevant (for example in
and what is the relevant prior work.
an analytical ‘research-style’ project) this may be
Examiners like to know that you have done the replaced by a detailed description of the project aims
appropriate background research and it is important and objectives in the Introduction or the Background
that you review either what has been done previously sections.
to tackle related problems, or perhaps what other
products exist related to your deliverable. Clear
references are important here, and much of this Analysis and Design
section will typically already have been written in your If your project involves designing a system, give a
Interim Report. You may use feedback from that good high-level overview of your design.
report to improve what you write in your Final Report,
In many projects, the final design is different from
and should note that self-plagiarism between the two
that originally envisaged. If the differences are
reports is not possible, so no citation is needed of
interesting, write about them, and why the changes
your own earlier writing.
were made. Discoveries during the project may have
 What does the reader need to know in order changed the direction of work, or invalidated prior
to understand the rest of the report? What work, in which case you get credit for the design
problem are you solving? process, if it is principled, as well as the end product.
 Why is this problem interesting or worthwhile If your design was not implemented fully, describe
to solve? which parts you did implement, and which you didn't.
 Who cares if you solve it? If the reason you didn't implement everything is
 How does this relate to other work in this interesting (eg it turned out to be difficult for
area? unexpected reasons), write about it.
 What work does it build on?
Note that the Project Report is written at the end of
 For 'research-style' projects involving the
project work and must describe the project work, but
design and analysis of specific algorithms
need not do this chronologically. Often the best
there is a large amount of relevant
description of design, in retrospect, is far from the
background both of general theory, and very
way in which you developed it. Where the evolution
specific to the algorithm you investigate.
of ideas is interesting or relevant it can be described,
Supervisors will help you to see what is most
as above, but otherwise the order in which things
important here, but the general rule is that
were done need not be documented.
you must both provide overall context and
note work close to what you do that The Examiners are just as interested in the
influences your work or is in some way engineering process you went through in performing
comparable to your work. your project work as the results you finally produced.
So make sure your report identifies when design
choices have to be made, what were the possibilities,
Requirements Capture and why you made the particular choices and
Projects with a deliverable that serves a specific decisions that you did. They are looking for principled
function often have an initial phase in which expected rational arguments and for critical assessment.
TJWC Final Year Projects 2
Engineering involves trade-offs and the reasons for a conveying your design than source code, whether that
design decision may be various, and may in some is a data-structure, a client-server interaction, a
cases be out of your control. Explicit understanding of design-flow, or a circuit hierarchy. For example, a
this, and the ability to communicate it, is important. diagram of a block-diagram of digital circuit can be
used to communicate to the reader most of the
important high-level decisions you have made, then
Implementation VHDL fragments (or another diagram) could be used
In projects with a software element give code details to focus on specific parts and demonstrate any
(not a complete listing, but descriptions of key parts). interesting local details.
Discuss the most important or interesting aspects, and
Complete listings may be included as appendices of
anything that was surprising or difficult. It probably
your report but this is not normally appropriate,
won't be possible or relevant to discuss everything –
unless the appendix is documentation, or describes an
state clearly what you leave out.
API. Software may be provided on a CD-ROM given to
Pasting verbatim code from your project into the your supervisor or in a cloud repositories such as
report is rarely a good idea; usually it should be edited Github. No marks are awarded for the mass or page-
down to remove extraneous details and often count of a report, and reports which contain 50 pages
annotated to help the reader understand what they of printed code are more likely to be seen as showing
are looking at. Good reasons for including code could poor judgement.
be to illustrate algorithmic flow, or highlight an
interesting optimisation, demonstrate interactions
with a data-structure, or give an example of input for Testing
a tool that has been designed. If you cannot explain Describe your Test Plan -- how the program or system
what message or point a code fragment is conveying, was verified. Put the actual test results in an Appendix
it probably should not be in the report, and if you if they are repetitive but relevant. Detailed test data
cannot justify why a line of code in the fragment helps may be omitted from the report if not relevant,
convey that point, it maybe it shouldn’t be in the code however an accurate summary of tests should be
fragment. included in the Report itself. Sometimes non-working
designs are described in project reports as though
For similar reasons, pasting screen-shots is unlikely to
they work, when in reality they don’t, or only partially
be a good use of space, unless it serves a particular
work. Therefore a precise description of what works
purpose. Screen-shots are sometimes used instead of
and how this has been established is important.
drawing a picture (for example as a “cheap” way of
Examiners may try to compile, use, or test
showing wave-forms or state machines), or in order to
deliverables themselves (even after your report is
capture the results of running a tool (which will often
submitted), and your report should accurately reflect
be text anyway), and tend to look unprofessional and
the state of the project.
lazy. They are also sometimes used as page filler, or as
“proof” that a tool was launched and something This section is normally useful for software or
compiled, which is not necessary: your marker’s hardware deliverables and less relevant in analytical
default position will be to believe your claims. Use a projects.
screen-shot if it is demonstrating a particular point,
such as a failure mode in a tool, or a particular
interaction that is difficult/impossible to highlight, but Results
make sure you edit and annotate the figure to show This covers an area different from the 'Testing'
and highlight the important parts. chapter, and relates to the understanding and analysis
of the algorithm, program, or hardware behaviour.
When discussing the implementation, it is generally
Where the deliverable is a product with easily
best to focus on the conceptual and logical design,
quantified performance then the previous Chapter
and only then dive into details for interesting parts or
shows how functional correctness is established,
to highlight important decisions. Well thought-out
while this Chapter shows qualitatively or
figures and diagrams are often much more effective at
TJWC Final Year Projects 3
quantitatively how well the product works. The list between final and initial objectives should be
below shows typical content, not all of this will be explained in a self-contained manner.
applicable to all projects.
Note that here you will reference and summarise,
 An empirical relationship between rather than repeat, your description of Requirements
parameters and results may be investigated, Capture earlier in the Final Report.
typically through the use of appropriate
graphs.
 Where theory predicts aspects of Conclusions and Further Work
performance the results can be compared How successful have you been? What have you
with expectation and differences noted and (if achieved? How could the work be taken further given
possible) explained. more time (perhaps by another student next year)? It
 Semi-empirical models of behaviour may be is important here to identify positively what is
developed, justified, and tested. worthwhile in your work. At the same time, honesty,
and a clear description of the limits of your work, is
 The types of experiments/simulations that
equally important. It is often most appropriate to
were carried out should be described. Why
describe work you did not have time to complete as
were certain experiments carried out but not
further work.
others? What were the important parameters
in the simulation and how did they affect the Your readers will not be clear where, in your long
results? If there are very many graphs and report, are your most significant achievements. In the
tables associated with this chapter they may conclusions you must summarise this, referring as
be put in the Appendix, but it is generally necessary to other sections for more detail.
better to keep these close to the text they
 What design choices did you have along the
illustrate, as this is easier for the reader.
way, and why did you make the choices you
made?
Evaluation  What was the most difficult and/or clever part
This Chapter (or possibly section of the conclusions) is of the project?
distinct from your results. It must contain your critical  Why was it difficult?
evaluation of your work as compared to previous  How did you overcome the difficulties?
analysis, algorithms, products, and when related to  Did you discover or invent anything novel?
your original objectives. To what extent have your  What did you learn?
original objectives been fulfilled? If they have Note that “difficult” does not necessarily mean the
changed, what is your rationale for this? What are the thing that took you the longest amount of time. Note
advantages, disadvantages of your approach also that the conclusions must concisely summarise
compared with related work? How does the scope of this material, and refer to other sections for the
your work differ from related work? Examiners expect details.
your project report to show evidence of your ability to
think as an engineer, and that includes the ability to
critically reflect on your own work and evaluate its
significance.
User Guide
Material here will compare project outcomes with When the deliverable is software or hardware
initial objectives and requirements captured. Usually intended to be useful to others, this Chapter provides
your Interim Report will contain these. Where these details on how to install/configure/use it. Otherwise it
have changed significantly over the course of the can be omitted.
project this should be explained and reasons given.
This section should not require examiners to read
your Interim Report, and will not reference it. Changes

TJWC Final Year Projects 4

Bibliography concise summaries of the test data in a
Give publication details for all the citations you have human readable form.
made in the report. Internet URLs are allowed and in  Raw results. Tables of results in unreadable
many cases necessary, however published material form should not be put in the main report, but
should if possible be given in standard form with if needed may be put in an Appendix.
publishing body, date, and author(s). Open URLs to  Related material possibly but not directly
published material, where these exist, may also be relevant to the project work. E.g. manuals of
given for a reader's convenience. test equipment used. (There is no
requirement to include such, but in some
Bibliographic format: the recommended format for
cases, where they have some tangential
simplicity (using latex and bibtex) is numeric, with
relevance, it might be appropriate).
hyperref allowing hyperlink references (which you will
almost certainly need).
For example:
\usepackage[backend=biber,style=numeric,
sortcites,sorting=nty,backref,natbib,
hyperref]{biblatex}
Exact blibliographic format is not mandated but
uniformity across the cohort is helpful: let me know if
you think the above does not work for you.

Appendices
Please use appendices as necessary for material that
is tangentially relevant, or necessary to preserve
project value, but that you do not expect Examiners to
read. Note that software projects with significant code
should normally provide electronic versions of the
code on USB stick, CDROM, or cloud repository. In
that case the Appendix should state where the code
may be found. The Appendix should normally
include, or refer to, all the technical details needed
for another user to continue code development.
Typical items that should not be in the main report,
but should (possibly - since Appendices are not
normally read this is a matter of judgement) be in
appendices:

 Source code. Note that code (if long) should

also be available in some electronic form, e.g.
a github repository, CD, or USB stick. Software
projects must provide access to the source
code in some form. The Appendix will then
reference this.
 Test data sets (again, for large volumes of
data an electronic form would be more
appropriate). The report itself will contain

TJWC Final Year Projects 5