Considerations Writing and structuring reports

188 Chapter 8 n Presenting your project in written form

10. Proofread, check and correct. It is vitally important to proofread your report after

it is completed. Quite often, because you have been so close to your report for so long, reading through your report straight away might mean that you miss glaring errors or omissions. You know what you meant to write so this is what you read, whether it is written or not. With this in mind, it is a good idea to leave your report for a day or two before proofreading it or, preferably, get someone else to do it for you. Bear in mind that if you do this, you will need to complete your report a few days before its deadline to allow time for proofreading and correcting or changing any points that emerge.

8.2.5 Structure

Your report should be structured into the following sections: n Title page or cover sheet – follow any guidelines provided your supervisor should advise you on this issue. If there are no guidelines, as a minimum you should include: title, author, date and degree award perhaps look at some past projects to see how they presented their title pages in your institution. n Abstract. n Acknowledgements – to people and organisationscompanies you wish to thank for helping you with your project. Avoid acknowledging friends, relatives, people, gods, organisations and others that have had only indirect influence on you or your project for example, ‘Uncle Arthur, who taught me the importance of managing my time when I was 8’. n Contents listing. n List of figures and tables – this is not compulsory and you should include these lists only if you feel they will add value to your report and will be useful for the reader. Otherwise, leave these out as they take time to compile and maintain. n The report itself three main sections:

1. Introductionliterature review – the first chapter of your report should always be

an introduction. Quite often, introductory chapters serve to present the literature review. Alternatively, the introduction serves as a brief overview of the project and the report, and the literature review is presented as a chapter in its own right later. Your introduction should set the scene for the project report, include your pro- ject’s aims and objectives, introduce the project’s stakeholders and the topic area, and provide an overview of your report. Berndtsson et al. 2008:129 also suggest that the introduction should include the ‘purpose and situation – indicating why the report was written and what the purpose was.’ They go on to suggest that you should also target the reader – i.e., you should state clearly at whom the report is aimed – who will be interested in the report.

2. Main body – the content of which depends on the type of project you are un-

dertaking. Some examples are provided below.

3. Conclusionsrecommendations – summarises the contribution of the work and

identifies future work, etc. This is discussed in more detail below. n References – presented in an appropriate format. Referencing material is discussed in more detail later in this chapter. 8.2 Writing and structuring reports 189 n Appendices – labelled as Appendix A, Appendix B, Appendix C, etc. These may include program listings, test results, questionnaire results, interviews you have tran- scribed, extracts from manuals, letterscorrespondence you have received and project details such as your initial proposal, your project plan and other project management documentation and meeting reports. You may also include a user manual and instal- lation guide and perhaps extracts or examples of data or data sets used. Consult with your supervisor over what should and what should not be included in the appendices of your report. n Glossary of terms – if required. n Index – if required – but avoid if possible. Following is a typical structure that many of my undergraduate students use for projects that have involved the development of a software system: n Abstract n Acknowledgements n Contents listing n Chapter 1 – Introduction n Chapter 2 – Literature review n Chapter 3 – Requirements n Chapter 4 – Design n Chapter 5 – Implementation and test n Chapter 6 – Evaluation n Chapter 7 – Conclusions n References n Appendices Figure 8.2 provides an indication of how the chapters in this kind of report struc- ture relate to one another those of you familiar with software engineering may recognise this as an adaptation of the v-process model. For example, the Conclusions chapter evaluates the project overall – how well it achieves its aims and objectives outlined in the Introduction and how it fits in and supports existing work in the Figure 8.2 The relationships between chapters