Some tips on writing a final year project report

A final year project in electrical engineering usually involves a substantial amount of practical work, whether it be design, analysis, programming, prototype development, testing or something else. Undertaking this aspect of the project in a professional manner and delivering something impressive at the end are naturally important steps towards a good grade for your project. However, producing a good report is just as important and a critical factor in securing a high mark. The project report is an aspect of the project in which many students fall dramatically short of their potential. It is tempting to focus for too long on the practical work and neglect the report until it’s too late to write anything that does complete justice to your practical achievements.

The purpose of this post is to summarise some of the attributes that I see as desirable in a final year project report in electrical engineering. I’ll focus primarily on structure, giving a short description of what boxes each chapter should be ticking.

There is no single correct structure for a final year project report, but good ones almost always follow a format similar to the following:

• Title page
• A standard declaration that the report is entirely your own work, apart from where otherwise clearly stated (i.e. it’s not plagiarised – more on this below).
• Abstract
• Table of contents
• Chapter 1: Introduction
• Chapter 2: Literature review / Background research
• Chapter 3: Design / Implementation / Method
• Chapter 4: Testing and results
• Chapter 5: Conclusions
• References
• Appendices

In the following sections, I will describe each of the items above in greater detail.

Title page

This should follow the standard school format. You will probably receive some specific instructions regarding information that should appear here. The following are usually included: your name, your project title, your supervisor(s) name(s), the name of the Institute, the name of the school or department, the year.

Plagiarism declaration

Most institutions now require that students include a signed declaration that the entire document is their own work (other than where clearly indicated). Do not just include this thoughtlessly! You really need to take the opportunity to reflect on whether every part of your document that has originated elsewhere (whether it be text, images, diagrams or anything else) has been clearly marked as such, and whether the original author or authors of any such content have been properly credited.

Remember that your final year project report is likely to be available for others to read for the rest of your life. You should be very careful not to expose yourself to a potential accusation of plagiarism now or at any point in the future. If you are uncertain what does and doesn’t count as plagiarism, now is the time to find out once and for all.

The abstract

An abstract is a short synopsis that appears at the beginning of a document and summarises its entire content in (usually about) a couple of hundred words. Unfortunately, it is not unusual for an undergraduate student to hastily tack a terrible abstract onto their report at the very last minute, without giving it very much thought at all. This is a huge mistake.

In academic writing (project report, thesis, research publication, whatever) the abstract is the most important part of a document and will generally be read many more times than the rest of the document. Your abstract should be painstakingly crafted to be the perfect synopsis of your work and to make crystal clear to the reader whether or not he or she will find the rest of the document worth reading.

The time per word you spend writing
the abstract should be a multiple of the
average for the rest of the document.

Speaking of which, the time per word you spend reading the above statement should be a multiple of the average for the rest of this article! With that in mind, I suggest that you go back and read it one more time. Slowly.

Here are some characteristics of a good abstract:

• Begin by very briefly descibring the problem you set out to solve. If possible, state some facts and figures which demonstrate that it’s an important problem and one worth solving. For example, if your project concerned the design of an electronic device to assist diabetics in managing their condition, you might state some statistics about the incidence of diabetes in Ireland and elsewhere, and perhaps identify the health benefits associated with better management of it.
• Clearly state the specific objective of the project, ideally in a single sentence.
• Describe the actual work carried out, i.e. how you went about trying to solve the problem you have just described. How did you set about achieving the stated objectives?
• If you designed and implemented something, describe the testing you performed to assess its performance. Explain clearly how you tested it. If you did user testing, how many subjects did you recruit and what did you ask each of them to do? If you designed a wind turbine, under what conditions did you measure its power output?
• Summarise your results. Be specific. State the actual numbers you measured. If you designed an electric vehicle, how fast did it go? What was its rate of acceleration? What distance did it cover for each battery charge?

Do a quick search on Google Scholar for any subject you’re interested in. Notice that each result leads to a short abstract summarising a publication of some kind. These abstracts are the way researchers know whether or not to read a particular paper. For every paper a researcher actually reads, he or she has probably skimmed the abstracts of many many other papers. Think of it a bit like the blurb on the back of a novel – if it isn’t interesting, nobody will read the book.

An abstract usually does not include references, although any facts you state will usually be discussed subsequently (with appropriate references) in the main body of the document. Also, the abstract is just text – no images, no equations, no circuit diagrams.

Chapter 1: Introduction

The Introduction should be like a considerably fleshed out version of the abstract. After the abstract, the introductory chapter is probably the most frequently read section of most project reports. For a final-year project, it should be several pages in length. Like the abstract, it should summarise the problem you tackled in the project and clearly state one or two specific project objectives (ideally as bullet points). It should describe the methodology you used and summarise the results. Don’t keep anything back for a surprise ending!

By the end of the introduction, the reader should have a very clear idea exactly what it was you were trying to achieve, why you were trying to achieve it, how you went about it, and how successful you were.

Unlike the abstract, the introduction should include a reference for any fact that is not self-evident. For example, if you state that the incidence of diabetes is increasing in Ireland, you need to back that up with a reference to a specific reputable source, such as a report from the CSO. If you state that cycling is more energy efficient than walking, you need to provide a reference to a reputable source that supports that statement.

The introduction chapter should also make extensive use of images, diagrams, etc to help the reader get a good grasp on the problem as quickly as possible. It can sometimes be appropriate to use images from other sources (appropriately acknowledged, of course), but a lot of the images should be your own original work too.

Chapter 2: Literature review (aka “lit review”)

Here, the word literature refers to all existing publications on the subject of your project (or related subjects). Hopefully, at the start of you project, you spent a lot of time researching to find out what work had already been done in the area of your project, so that you could be sure you weren’t reinventing the wheel. The literature review chapter serves two main purposes:

• The ostensible purpose of the literature review is to bring the reader up to speed on background information they will need to know to appreciate the relevance of the original work described later in the report. At the conclusion of the literature review, the reader should know what the state of the art is in the area you’re working in.
• A second, frequently unspoken, purpose of the literature review is to establish the author’s credentials in the mind of the reader (especially if the reader is a project examiner). By demonstrating that he or she carried out sufficient research in the area, the author reassures the reader that they are knowledgable about the area and were in a position to make sensible choices about the direction of the project. If the literature review is inadequate, the reader will be left wondering whether the author’s work has simply gone over old ground, reinventing the wheel. The reader may also be uncertain what benchmark the author’s original work can be measured against.

In a final year project, the literature review should be at least several pages in length. It should contain lots of references to reputable publications. The number of references per page will probably be considerably higher in chapter 2 than in any other part of the document (other than maybe parts of chapter 1).

In particular, this chapter should describe (and reference) existing work that is as close as you can find to what you undertook in your project, so that the reader can see where your original work fits into the landscape of existing knowledge in the area. For example, if you’re designing a solar powered refridgeration system for developing countries, you need to find and describe several existing devices that are as close as possible to what you’re doing so that the reader can see what’s new and different about your design (e.g. cheaper, more efficient, safer, etc).

When reviewing other people’s work, it can be useful to reproduce images from other sources. Setting aside for one moment the potential copyright issues associated with this, it is very important that any images created by someone else need to be properly acknowledged as such. A good way to do this is to give credit the original author or source document in the caption you include with the image.

The literature review chapter should focus only on reviewing existing knowledge in the area and work done by other people. Don’t begin describing the details of your own work yet. Of course, it’s fine to mention aspects of your own project by way of explanation when you review a particular topic. However, there must be a clear dividing line between the end of chapter 2 and the beginning of chapter 3 which separates your description of other people’s work from your description of the work that you yourself have done. That way, the reader (and most importantly project examiner) will be in no doubt as to what work you carried out yourself.

Chapter 3: Method / Implementation / Design

This is where you begin describing the work you carried out in detail. However, it definitely should not be a chronological account of the work you did day-to-day, including dead-ends and red herrings encoutered along the way. Rather, it should be a detailed description of what turned out to be right way of going about the project. Treat the reader’s time as valuable. It’s fine to describe things (probably briefly) that actually needed to be investigated to be eliminated. This type of information is useful to the reader since it provides a context in which your design decisions can be better understood. However, something which in hindsight was nothing but a waste of your time will almost certainly be a waste of the reader’s time too, so he or she should be spared the ordeal of ploughing through your bitter account of it.

Things that should probably be included in chapter 3:

• Maths – What mathematical analysis did you need to carry out in the course of your project? Be sure to include it in the report. This is something examiners will be on the lookout for – did you take an appropriately analytical approach to the project? Do you understand how to bring mathematical analysis to bear on real-world problems? If an electrical engineering project does not contain a substantial amount of maths somewhere in the report, that is likely to set off alarm bells in the minds of most examiners. Equations should be typeset neatly using a proper equation editor.
• Include a clear description of the methodology you used.
• If you designed or implemented something in your project, a clear and complete account of the finished design should always be included. This can include circuit diagrams, sections of code, flow charts of algorithms, schematics of manufactured components, graphs, etc. Diagrams should be professional looking, so use the right sort of drawing tool. If you’re still struggling along with MS Paint or something similar, now is the time to take a leap of faith and get to grips with something more appropriate. I recommend Inkscape for drawings and diagrams because it’s free and very powerful, but of course there are lots of other options too.
• Make use of photos and screenshots. These provide some of the best value of all in terms of benefit to the reader versus effort by the author. It only takes a second to snap a picture of something while you’re working on it, but often it can communicate something complex to the reader much more effectively than a written description. In case you don’t know how to take a screenshot, you just need to use the Print Screen key on the keyboard (often labelled “Pr Scr” ot “Prnt Scrn”) – that copies a snapshot of the screen to the clipboard, so that you can paste it into e.g. MS Paint. To take a snapshot of a single window, hold down the “Alt” key while pressing “Print Screen”. Windows 7 and later also include the incredibly useful Snipping Tool – if you’re not already familiar with it, please take a few minutes to find out how to use it.

Chapter 4: Testing and results

I mentioned at the beginning of this post that people often fall into the trap of neglecting their report in order to focus on the practical work, which results in a disastrous loss of marks. Similarly, many people focus on unrealistic grand plans for something they’re building, and end up leaving almost no time at all to rigorously test its performance. In an engineering project, it is not enough to implement – you need to test thoroughly as well.

By testing, I mean you need to measure some hard and fast numbers that capture useful information about the performance of whatever you’ve built. If the results of your tests include tables of measurements and graphs, that’s all the better. As I mentioned above with respect to maths in the report, if no tables or graphs of “results” appear anywhere in the report, that will sound alarm bells in the minds of most examiners.

When presenting results, it is critical that you provide detailed information about the circumstances under which they were obtained. Also,

• Every single graph should have a clear self-explanatory title.
• The axes of every graph should be clearly labelled, including the units.
• Every graph should be legible. If you’re printing in black and white, keep this in mind when choosing a colour scheme for your graphs.

Chapter 5: Conclusions

This chapter should in many ways echo the structure of chapter 1, but now with the advantage that you can assume that the reader has read the intervening chapters (although it’s possible that they have skipped straight to the conclusions).

• You should remind the reader what the original problem to be solved was. Restate the specific objectives of the project and undertake a critical analysis of how well these objectives have been met.
• You should offer suggestions for further work. If you had ideas that you didn’t have time to explore or implement, this is your chance to tell the examiners. If you didn’t achieve your original objectives, this is you chance to describe how you might do things differently if you were starting over.

A lot of people just tack on the conclusion chapter as an afterthought and offer only the most superficial analysis of how the project worked out. This is a big mistake. If you think there are weaknesses in the project, this is your chance to face them head on and reassure the reader (and the examiners) that you see the flaws and have useful ideas how they could be addressed.

Most examiners have read a ton of projects where the conclusion states that everything worked out great, when it’s actually obvious that that was not the case. Really, it looks much better to give a realistic critical appraisal of your project. Just make sure that if certain aspects of the project have not worked out the way you hoped, you have some decent suggestions for what you could try doing differently.

References

Good final year project reports almost always have a long list of references. Of course, it’s not just about the numbers, but a lack of references is a sure sign that something is not right. Conversely, a long list of reputable looking references reassures the reader that you researched adequately and that you are able to back up what you have written with credible sources.

The type of sources you reference is important. Good references are things like: publications in reputable journals, reports from governement agencies, textbooks, datasheets. Less reliable references include most web pages. Sometimes, of course, you need to reference web sites, but they should not make up your entire list of references.

References should be formatted neatly and consistently. The preferred style of referencing in electrical engineering is usually the IEEE style. Whatever style of references you are using in a document (IEEE, APA, Harvard, etc), you should look up the style guidelines to make sure you’re formatting them correctly. For IEEE style references, complete details are provided in the IEEE Editorial Style Manual (the description of references begins on page 5). Note that the full IEEE Editorial Style Manual is available here, but be warned: it’s a hefty tome!

The appendix

The appendix (or appendices) of your report provides a place where you can provide additional reference material for the reader without disturbing the narrative flow of the main text. Examples of things that people often include in an appendix are:

• A complete code listing for any software you wrote in the course of the project.
• A complete circuit diagram (if the full circuit is too complex to include in the main text).
• Additional graphs of data or results.
• Additional details of a mathematical proof or technique that you have used.