The following is a general template for a project report under my supervision (and software-based). It is not necessarily the structure other staff members would recommend, but it works for me!
First, don’t bother with the abstract, introduction, and conclusions - they are the last things you write. Next, if you have a lot of code (being supervised by me probably means “yes”) then put it on GitHub (or equivalent) as a private repository and include a link to that. Don’t fill appendices with many code listings—think of the trees. Your code must be available via a GitHub repository under the Birkbeck Organisation and not publicly visible.
So, here is the outline:
- Title
- Disclaimer (stating your work, etc. - usual plagiarism requirements)
- Abstract
- Acknowledgements (optional)
- Contents
Chapter 1 - Introduction
- State the problem you are trying to solve
- Why is it worth tackling?
- What approaches are available (briefly)?
- What approach have you chosen?
- Any special knowledge you presume of the reader
- Any special typography or terms
- A “road map” of the report….. “In Chapter Two, we describe xxxx. In Chapter Three, we describe yyyy…”
Chapter 2 - Background
- Any information the reader requires regarding techniques/technology that isn’t part of your study programme. You can include a reference to the proposal if necessary or, if required to provide context, include materials from the proposal. You should not do a cut-and-paste function but reword, enhance, and restructure the reused material and include a statement that this material is based upon your proposal.
Chapter 3 - Analysis, Requirements, and Design
- What it says on the title
- Should include appropriate formal design diagrams/notation as necessary
Chapter 4 - Implementation
- Describe how the implementation maps onto the design you have already discussed.
- You should use “code snippets” to illustrate particular features of your work or tricky (awkward) bits of coding. Don’t make these snippets longer than half a page (and include line numbers if possible). Break the code fragment into smaller bits if it is over half a page.
- Describe the code in terms of the overall architecture and the snippets. Make sure the reader understands what you have done and why!
Chapter 5 - Experimentation & Evaluation
- Again, what it says on the tin!
- If you haven’t done too much testing (for instance, it is GUI-based), include a “walk-through” of the application with screenshots showing the scenarios in which it can be used. After all, the examiners may not be near a computer to actually “run” your code.
- You must also clearly show how you evaluated your work and how it meets the original aims and objectives.
Chapter 6 - Conclusions
- Restate the problem.
- Say how successful (or not) you have been in solving/tackling the problem.
- What would you have done differently?
- What have you learnt?
- Basically, “reflect” on the work you have done.
- What additional features/extensions can be done to the work, and what would you have done if you had more time?
Appendices
- Include design diagrams, data formats, etc.
- Basically, don’t overfill the report.
- Link to the GitHub repository (if appropriate).
Now, “one size does not fit all” - this structure is meant to be a starting point; you may have more or fewer chapters. You may need a background chapter, you might not, etc. Be flexible and check with me about what you are writing.
I prefer to read the report chapter by chapter (or even just a few pages at the start). A whole report sent to me to read at the end, with no chapters submitted before that, is a recipe for problems. It doesn’t give me any time to say, “No, change the style”, or “No, I suggest you do it this way”.