Back to Home Page Report Writing---a Refresher.

Report Writing-a Refresher.

Alan Robert Clark

Feb 7, 2001


An abstract is the most important part of a report. It must represent the essential GUTS of the ENTIRE report, therefore including important numerical results, costs, conclusions etc. It needs to be relatively short and easy to read. It must be factual, not general!!! ie it generally needs to contain numbers! An abstract must be written after the report so that it accurately reflects the entire report. The abstract needs to written in easy-to-read language, in a single parapgraph; must include a short statement of the problem, with the scope of the investigation defined; important results; important conclusions and recommendations for extension.

1  Introduction

Report writing is a skill that is learned-it does not come naturally to most of us. As engineers, we are constantly writing reports to a very wide range of audiences-funding requests to non-technical financial managers, research papers in technical publications, verbal presentations at technical conferences, tender documents for government contracts, contract research reports, etc. Each type of report will probably demand a different style, but all types will need to contain the essential ingredients of a technical report.

You will be writing reports constantly for the rest of your professional career, you might as well write good ones!

This document does not seek to replace the standard report-writing documentation that you received in first year, it just seems that I am constantly harping on a few points that may need clarification :-)

2  What is a report?

A report is an account of work performed. As such, many people mistake a report for a blow-by-blow reportage of facts as they occurred. This is the most common mistake made. DO NOT be tempted to report on things in the order that they happened!

Writing a report takes planning. Many people do not plan a report-you have spent weeks designing a widget, now design the report-don't ``just write'' it! Set up your section headings, your subsections and subsubsections, and write a 2-3 line description of what you are going to say in each of these divisions. Stew on that design, and optimise the flow of thought. Ask yourself whether it makes sense to introduce the concepts at that point in the report etc. Don't forget to introduce the background to the subject gently-don't barge in with fancy maths!

By the way, the above paragraph is why I say that a hand-written report must be written at least four times!! It is simply not possible to sit down and write the entire report in the correct logical order without messing it up!

The next common mistake is to address the report to an idiot. ie ``My class has been given a project at the Department of Electrical Engineering at the University of the Witwatersrand, Johannesburg, Gauteng, South Africa, and we need to construct a student death warning device.'' I couldn't care HOW you got the project, what I want is a succint and informative PROBLEM STATEMENT. This does NOT mean copying the intentionally vague problem statement that was handed out to you!

You need to define your target audience as a relatively intelligent colleague, but perhaps not quite in your field, and you need to lead her into the topic.

The next common mistake is to bumble along. A report is essentially an argument. It has a premise (the problem statement) and a conclusion. You need to argue in a direct line without meandering about the thousands of design options you considered and rejected. Your report is about your final design, and if you need to refer to earlier designs as they influenced the final design, fine, but keep it to the point.

Quantify. Quantify. Quantify. Always quantify. Quantify the error in your reference voltage as a function of the supply voltage, and hence get it down to how much of a temperature difference its going to make at the end of the chain. ie Find and Define your errors. We do NOT live in an ideal world.

Explain the design at a high level first, ie break it up into logical functional blocks, then explain why a resistor is there, and how you got to its value.

When we say that the report must follow a format of Abstract, Introduction, Body, Conclusion, References; for heaven's sake don't call the ``Body'' section BODY. By the ``Body'', we mean the bulk of the report. Split that up into several sections eg Temperature Sensing; Setting the Reference Voltage; Comparing the Reference to the Temperature; Output Interface...

3  Figs, appendices etc


Figures, such as Figure (1) are: 1) Numbered, 2) Captioned, and 3) Referred to in the text. If they aren't, they are pretty pictures with no place in a technical report-remove them. A ``picture is worth a thousand words''-don't have long-winded descriptions when a well-designed figure will make things clear.

Any material which detracts from the line of argument (like long maths) needs to be placed in an appendix... BUT!!! the ``bottom line'' needs to be referred to in the text, else its a pretty appendix. Note that in general, appendices are NOT read.

Reference any statement, or derive it from first principles, unless it is basic knowledge. Use a PROPER referencing system-either a numerical system similar to the IEEE system, or a name-based Harvard system. Make sure that you use them properly. Pay particular attention to verbal communication and Web-based refs. Remember that the purpose of a reference is to enable the reader to get more information on the topic.

4  Conclusion

Your conclusion should RECAP on all principle findings and summarise the report. Essentially, the Abstract and the Conclusion should make up a concise version of the report!

A conclusion is not:``I really learn't a lot in this project, and the tutor was very nice, and the department is very nice''.

Point Form is often useful in a conclusion:

The online version is ""

Back to Home Page Webalizer Stats

File translated from TEX by TTH, version 2.86.
On 7 Feb 2001, 13:43.