Guidelines for the Project Report

This web page gives some comments concerning the writing of the project report. These comments do not correspond directly to categories of the marking form - they are mainly based on previous experience in marking projects.

Writing the report

Here are a few comments by Mary Cryan, former UG4 project supervisor, with some additions by Helen Pain and Don Sannella.
  1. The project is marked on your report, backed up by your code. If you have done a superb job of system-building, and submit a bad report, you risk getting a low score. So please make sure you put sufficient effort into delivering a good report.
  2. If you absolutely cannot decide how to structure your report, then having the following five chapters will usually work out okay: Introduction, Background, Design, Implementation, Evaluation and Conclusions. Your report does not have to have this structure, not at all, but it is a reasonable place to start for most projects.
  3. The Introduction chapter should always provide a 'roadmap' to the report. Of course it should provide an introduction to the problem being considered, but it should also give some details of what you did - do not leave this to the conclusion. You should give forward references into the rest of the report - e.g., "In Chapter 2 how algorithms and heuristics are used to deal with approximate counting are discussed", "The design of the system is presented in Chapter 4", "In Chapter 3 the reasons for choosing to focus on the bounded-degree case of this problem are explained".
  4. Structure: Please use the environments available in LaTeX (or whatever word processing tool you are using) to structure your report. Use "subsection" and "subsubsection" to separate out the topics of each chapter. Important points should also be displayed so that they are more visible than ordinary text (e.g., using the "itemize" or the "quote" environment). The reader should not have to read deep into a page of text to pick out a key fact.
  5. Through the report, spell out what was done (past tense). Make clear what was your contribution to the task. If you are building on an existing system, or using libraries that already exist, make clear the division between your work and existing work.
  6. Your report will be read by markers throughout the School of Informatics. Do not assume that your marker is an expert in your subfield. Give some basics as well as the details. Also, make sure you point out what was involved in solving certain problems; this can help a non-expert judge the work involved. For instance: "The interpolation algorithm was implemented in C directly, rather than using the routines in Matlab". "In order to develop a user interface appropriate for the educational system, 4 prototypes were tested on 50 students".
  7. Tenses.
    • I know that many of you use your interim report as part of your final report. If you do this, please change the tenses - from "will .. " to "did ...". It is important to be careful with this as not all tasks proposed before Christmas always get completed.
    • Also, try not to use the "generic tense", e.g. "CoolApp Systems use hatterbash technologies for preprocessing of rino-data", if you are talking about your own project: be clear what was done in the particular case of your work. Instead write, "As is common in CoolApp systems, hatterbash technologies were used to preprocess the rino-data" (and continue giving details ...). Generic tense is fine for the background chapter.
    It is often recommended that reports (and research papers in general) are written in the passive voice, as opposed to active voice, e.g., the above, rather than: "As is common in CoolApp systems, I used hatterbash technologies to preprocess my rino-data". The reason for this is that less experienced writers can sometimes find it be harder to be objective when writing in the active voice. However, it is up to you (and the recommendations of your supervisor) whether you prefer to write in the active or passive voice. Personally I prefer the latter - but others may disagree....
  8. Your source code. It is helpful for the marker to be able to look at your source, or other type of documentation, as a back-up to the report. You are required to maintain a subdirectory of your DICE account where you store source code, or processed data, or any supporting evidence which is appropriate to your project. You will be required to submit this entire directory along with your report.
  9. If there was some technical challenge that you could not resolve during the period of the project, it will still be useful to devote space in your report to discussing a design (for example) that did not get implemented, or an implementation that was not completed.
  10. It is okay to get your classmates to read over your work for grammar, punctuation, feedback on clarity, etc. But they should not contribute in any way to the technical content of the report.

Home : Teaching : Courses : Proj 

Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail:
Please contact our webadmin with any comments or corrections. Logging and Cookies
Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh