Report Structure

This section covers suggested report structure. This is distinct from the format requirements which must be strictly adhered to by everyone. The advice given here should apply to the majority of projects. However each project is different, and you should get advice from your supervisor about how to structure your report.

Where the advice given here and that of your supervisor differ, you should follow your supervisor's advice as they will be taking into account the individual nature of your project.

Introduction

First and foremost, you should write about the most interesting or important parts of your project. Devote most space and time to this. For example:
• What design choices did you have along the way, and why did you make the choices you made?
• What was the most difficult part of the project?
• Why was it difficult?
• How did you overcome the difficulties?
• Did you discover anything novel?
• What did you learn?

Set the scene and problem statement/specification. Provide the motivation for reading this report. Introduce the structure of report (what you will cover in which chapters).

Background

You should provide enough background to the reader for them to understand what the project is all about. For example:

• What the reader needs to know in order to understand the rest of the report. Examiners like to know that you have done some background research and that you know what else has been done in the field (where relevant). Try to include some references.
• Related work (if you know of any)
• What problem are you solving?
• Why are you solving it?
• How does this relate to other work in this area?
• What work does it build on?

For 'research-style' projects - ones in which a computational technique (for example neural networks, genetic algorithms, finite element analysis, ray tracing) is used to explore or extend the properties of a mathematical model, or to make predictions of some kind - it may be a good idea to split this chapter into two shorter ones, one covering the computational technique itself and one the area of application.

The Examiners are just as interested in the process you went through in performing your project work as the results you finally produced. So, make sure your reports concentrate on why you made the particular choices and decisions that you did. We are looking for reasoned arguments and for critical assessment. This is especially so where design, implementation and engineering decisions have been made not just on technical merit but under pressure of non-functional requirements and external influences.

Analysis and Design

If your project involves designing a system, give a good high-level overview of your design.

In many projects, the initial design and the final design differ somewhat. If the differences are interesting, write about them, and why the changes were made.

If your design was not implemented fully, describe which parts you did implement, and which you didn't. If the reason you didn't implement everything is interesting (eg it turned out to be difficult for unexpected reasons), write about it.

 

Implementation

Give code details (not a complete listing, but descriptions of key parts). Discuss the most important/interesting aspects. It probably won't be possible to discuss everything - give a rationale for what you do discuss.

Testing

Test plan - how the program/system was verified. Put the actual test results in the Appendix.

Results

This covers different areas to the 'Testing' chapter, and is appropriate for 'research style' projects. For such projects this chapter should detail the types of experiments/simulations that were carried out with the code written. Why were certain experiments carried out but not others? What were the important parameters in the simulation and how did they affect the results? If there are very many graphs and tables associated with this chapter they may be put in the Appendix, but it is generally better to keep these close to the text they illustrate, as this is easier for the reader.

Conclusions, Evaluation and Further Work

What have you achieved? Give a critical appraisal (evaluation) of your own work - how could the work be taken further (perhaps by another student next year)?

Appendices

Please use appendices as nessary the listing of computer souce code should be placed in the appendix
If your project is an application the following maybe useful

System manual

This should include all the technical details (where is the code? what do you type to compile it? etc) that would enable a student to continue your project next year, to be able to amend your code and extend it.

User manual

This should give enough information for someone to use what you have designed and implemented.

Test results

If you have test results that add to the value of the report, but which would not fit within the page limit of the main report, you can include then as an appendix. Don't add them just to pad the report though.

Code listing

Your code should be well commented. In order not to use up too many pages of your maximum 120 on code, you may like to use the 'a2ps' Unix facility, which allows you to put two pages of code onto one side of paper - see the Unix 'man' pages for details. If you have a great deal of code, and including all of it would take you over the page limit, you can make the rest available on a floppy disk or CD-ROM. You will need to bring in two copies of any disks or CDs you include when you hand in your project report, one to go with each copy of your project.

Bibliography