1. Final Report Structure

2. Title Meaningful and brief, in 14 point bold.
“A Small-Vocabulary Speaker Independent Speech Recognition System” is better than “The Design, Implementation and Testing of a System for Recognising Ten Words Spoken by any Speaker”, even though it is less specific.

3. Abstract 1
The Abstract is a skeleton summary of the project, typically ½ to 1 page in length.
Try for one sentence each on motive, method, key results, conclusions.
As a guide, don’t exceed 3 sentences on any one.

4. Ref: How to Write A Paper, Mike Ashby
Abstract 2
Imagine that the reader of the Abstract has been interested by the title of your project. He or she now wants to know whether to read more of it. Tell them, in as few sentences as possible, what they will find.
No waffle, no spurious details.
See the Appendix in the paper below for an example.
Ref: How to Write A Paper, Mike Ashby

5. Acknowledgements
Thank people who have helped you with ideas, technical assistance, materials or finance.
Keep it simple, give full names and affiliation, and don’t get sentimental.

6. Introduction
Give the background to the engineering problem that you have tackled.
Outline the problem and the reasons for tackling it.

7. Aims & Objectives / Intended Outcomes
What were your specific aims and objectives?
State clearly what you set out to achieve.
Remember that this section is written in the past tense at the time of writing the final report. In the Project Specification and in the Interim Report it is written in the present /future tense.

8. Literature Review / Previous Work
Who worked on your topic before?
What did they do?
Review the background literature, recording briefly the main contributors and summarising the status of the area when you started the project.
Summarise and Reference all articles that you have read that support your understanding of the topic.

9. Design / Project Planning
Describe how you approached the problem and planned the solution, describing any preliminary experimental investigations and possible design approaches.
Justify clearly the final design selection.

10. Theory
Give a brief summary of the main analytic theory underpinning your project, giving references as appropriate.
Do not include simple theory, eg Ohm’s Law, that your target reader would be expected to know.
Provide any specialised information that the reader might need to understand what follows in your report.
Define all symbols and units.

11. Implementation Platform / Tools
Describe briefly any equipment, hardware, tools, or software used to carry out your project.
Give a brief description only, and use, references, diagrams and pictures as appropriate.

12. Implementation
Describe exactly what you did, ie hardware constructed, software written, experiments carried out etc.
Use past tense and the passive voice { Eg, “A voltmeter was used to measure ……..”
Give sufficient detail that the reader could reproduce what you did.
Don’t mix Implementation with Results / Validation or Discussion—they come later.

13. Results / Validation 1
Present the results of the experiments, computer simulation, etc.
Provide evidence that any hardware constructed or software written functioned as expected.
Don’t mix Results / Validation with Discussion. It belongs—all of it— later.
Report your results / validation simply, without opinion or interpretation at this stage.

14. Results / Validation 2 Present data in a form other people can use.
Give emphasis in the text to the most important aspects of the tables, graphs or figures.
Define all symbols and units.
Make each figure as self-contained as possible, and give it both a title (on the figure itself) and an informative caption (below it).
Make sure that the figure axes are properly labelled, that units are defined and that the figure is legible.

15. Discussion
This is where you demonstrate that you understand the subject area, understand what you did, and why you did it.
Extract the main principles, relationships, generalisations, outcomes.
Discuss relationship between the results / outcome that you obtained, compared with what you expected or what the theory indicates. Account for any differences.

16. Conclusions 1
Draw together the most important results and their consequences.
List any reservations or limitations.
Reflect on the outcome of the project in relation to the Aims & Objectives.
Be self-critical, and do not be afraid to state how, with hindsight, things might have been done differently. Doing this is a strength not a weakness! Writing in the first person (I) is acceptable for this section.

17. Conclusions 2
Readers scanning a report often read the Abstract and the Conclusions, and glance at the Figures.
Do not duplicate the Abstract as the Conclusions or vice versa. The Abstract is an overview of the entire project. The Conclusions are a summing up of the outcomes that have emerged from it.
It is acceptable to present conclusions as a bullet-pointed list.

18. Future Work
Describe what could be done to improve your project outcome.
Include work that you planned to do, but were unable to, through lack of time, available resources etc, as well as future ideas that emerged from doing the project. Distinguish clearly between the two.

19. References 1
Cite significant previous work and sources of theories, data, or anything else that you have taken and used in your project.
Use the Harvard referencing system and stick to it, i.e. be consistent. See:
References must be complete: name, initials, year, title, journal, volume, start-page and finish-page.

20. References 2
References tell the reader where an idea, prior results and data have come from. It is important that you reference all such sources. It is a conventional courtesy to reference the originators of key ideas or theories or models, even if you modify them.
A Bibliography is a list of materials not cited but which you found generally useful. Keep this separate.

21. Appendices
Appendices contain essential material that would interrupt the flow of the main text.
An appendix must have purpose; it is not a bottom drawer for the stuff that you cannot bear to throw away. It is the place for tedious but essential derivations, or for data tables or descriptions of procedures, that would disrupt the flow of ideas in the main text.
It should be well structured and stand by itself. Give it a title: “Appendix A1: Procedure for Calibrating The Temperature Sensor ”