1

Writing a Scientific/Technical Report

_____________________________________________________

by Enrique Alba

Dpto. Lenguajes y CC.CC. Univ. de Málaga, SPAIN

September 2002

Abstract. Writing a Scientific or technical report is a major problem for most researchers, especially when they are beginning their professional carrier. In this short note I want to offer some of the comments and advices I usually give to my students about scientific writing in order to get a document of an acceptable clarity and structure. The contents of this short paper will highlight the problems in structuring the information, discussing goals and results, and the problems in selecting words, graphs and the media to better transmit information to readers.

1 Introduction Here, we present some comments and advices for students and novel researchers in order to help them to create good-quality documents with scientific information for specialized readers.

When faced to the problem of writing a document most people experience the following problems:

1. How to structure the document

2. Formatting guides

3. Contents

4. Readability

5. Electronic edition and diffusion

Since a full-text explanation is out of question because I want to help in the most efficient manner (this means as fast as possible) I will provide a kind of “check-list” that you should verify before, during and after writing your report. In fact, there will be a set of such lists, each of them suitable for a particular problem.

The organization of this paper is as follows. Next section will discuss structure of the documents. Section 3 will discuss formatting issues. Section 4 will get deeper into the contents you should not forget, and Section 5 into the readability of the paper. Finally, Section 6 will discuss electronic issues. We will end with some conclusions to help summarizing this note in Section 7.

2

2 Structure of the Document When making a document, try to keep in mind that a traditional structure for a document contains the following sections:

A. Introduction, containing:

a. the state-of-the-art in the field,

b. related work,

c. statements of the goals you intend to obtain,

d. expected advantages of your work with respect the rest,

e. an explicit statement of your contributions (“The contributions of this work are …”),

f. an explicit statement of the structure of the document at the end of the introduction (“This paper is structured in six sections. Section 1 …”).

B. Problems , discussing:

a. the actual problems you mean to solve,

b. related papers, articles or books with the problem instances you are using or which are similar to the problems to be solved,

c. the difficulty of the problems and why they are of interest,

d. a review of the state-of-the-art in solving these problems (include parameters used in the references solving the same problems),

e. a formal or mathematical description of the problems.

C. Resolution Methods , stressing:

a. novelty of your method or approach,

b. specific, non-ambiguous, explanation of the method (e.g., pseudo-codes, without variables or objects missing inside!),

c. mathematical or formal issues of your techniques,

d. parameters and most important decisions made to select these methods or techniques,

e. how you plan to solve the problems with your wonderful methods,

f. expected results after having done so.

D. Experiments, presenting:

a. which are the goals and sets of experiments,

b. which parameters, algorithms and problem instances you intend to use (preferably use tables for this issue),

c. measures, statistical analysis, and criteria you are going to use to judge the goodness of the results,

d. steps you are following to get the results (and justify them).

3

E. Results, analyzing:

a. each result by itself; add graphs/tables and discuss each one!,

b. groups of related results, by problem and/or technique,

c. a summary of the results, with numerical, graphical or table info to make readable this section.

F. Conclusions , including:

a. a brief summary of what you have said/made in the whole paper,

b. an informal statements of the achievements and claims,

c. add some references or technical conclusions if needed,

d. at the end of this section, put some future work relating problem, resolution techniques, goals and/or miscellaneous info (software, etc.)

G. References, highlighting:

a. most important concepts in the paper,

b. references to similar work,

c. references for basic techniques and/or results,

d. references to the work you are extending,

e. make sure that all references are used in the text,

f. select the references carefully related to the contents of the paper, not these works generally relating your domain of interest,

g. book and journal papers should be given priority over conference papers if possible; try to avoid personal communications and technical reports, and make sure the full reference is correct.

In addition, add an abstract or summary to the beginning of the document, including goals, the work you intend to make, and a summary of the conclusions you got in the paper or report. Also, provide a meaningful name to the paper, and a complete affiliation of the authors (including address, email and web page if available). Put also some key words that identify the main topics covered in the paper (avoid general words like for instance “system”, “software”, “element”, “algorithm”, etc.).

You can also consider to add an index at the beginning of the document if you are writing a long document; even, you could add an index of tables/figures to help the reader. Besides that, you could consider to add one or more appendixes (appendices) with information not required to understand the document (nomenclature, user manuals, theoretical demonstrations, etc.).

3 Formatting Guides No matter what editor or format are you using, try to be consistent with your own decisions on how to format the document. This is very important.

You may want to consider the following advices:

o If there is some style defined for the kind of document or the target forum where you intend to send the document, then get the instructions and follow them!

4

o Put the name of the sections at least 4 points larger than the text. Try to reduce the size of the words for sub-section headings.

o Do not put periods (“.”) at the end of the name of a section: it is not a sentence.

o Put in uppercase the leading letter of every word in the section heading, except for articles, prepositions, particles and words of equal-or-less than 4 letters. For example: “Results for the Assignment Problem”.

o Use the same point size and font for all the sections residing at the same level.

o Number all the sections, preferably with Arabic numbers.

o Do not let orphan lines (i.e., one line alone) at the end or beginning of a page, or a column, if the paper is in two-column format.

o Try seriously not to break paragraphs between successive pages. Take a look to the full page to locate paragraphs with a final line of one or two words: these are the best to save room in the paper.

o Do not add tabs in the first paragraph of a section.

o Do add tabs to any other paragraph, including paragraphs that appear after equations, tables or figures.

o If you are using abbreviations (“Fig.”, “Eq.”, etc.) use them all the time, not only sometimes.

o Put in uppercase the first letter of “Figure”, “Table”, “Equation” and “Section”, except when they are in plural, in which case you should use lowercase letters. Well, I mean, use uppercase only when using a number, like in “Section 3”.

o Try to minimize boldface and underlines in the document. If you want to highlight words or expressions use italic or cursive fonts.

o Put in courier-like fonts the text that directly appear in the software system, if you are discussing such systems. I mean: filenames, classes of an object oriented design program, object methods, pseudo-codes, etc. For example, data.txt, Buffer.put(a), main.cpp, http://www.net, etc.

o Center figures and tables in the page (when appropriate).

o Add reference numbers to the equations.

o If you have no automatic reference generator, do not use numbers for references (like [1] or [2]), because if you modify a single reference you could need to change all of them! Try to make references by the name of the author and year [Alba02] or by the initials of the authors and year if there is two or more [ACNT02]. When a reference has two authors, choose one of this two rules at will (but consistently) for your document.

4 Contents Try to stick to the following advices relating the contents of your paper:

o Do not forget to explicitly mention every figure/table/equation in the text.

o Avoid constant repetitions of a word within the same paragraph. In computer science, this typically occurs for “system”, “study”, “program”, “problem”, etc.

5

o Check in your document that you are using consistently (always in the same manner) the “-“ between two words, and the case of a given word.

o Avoid using non-scientific words like “good” or “bad”.

o Always put a reference for a new term, and only the first time it appears in the text. Make sure to reference the very initial work in which this term was defined, not just what you have at hands.

o Always define acronyms the first time the terms appears (put the acronym in parenthesis).

o Never talk about a concept not yet previously defined in the paper. Alternatively, put a reference if you need to do such a thing.

o Take care that sections containing information clearly separable include sub-sections for such cases. Do not use a contiguous exposition of different contents that could easily be described into separate sub-sections.

o Read sequentially ONLY the names of sections, from the introduction to the conclusions, in order to detect problems in the contents or reading flow.

o Think in the completeness of the document: is there something you are talking about that is not referenced or explained in the paper?

o Think of the correctness of the contents: is there something not understandable or incorrect that you could point out by reading only this document?

5 Readability Proof-read your document to check each of the following items:

o Sentences are not longer than two or three lines. If you have such kind of sentences it is very likely that you could cut them into two or more chunks to make them more easily readable.

o Check that figures/tables/equations are placed in the correct place of the document, just as near as possible to the part of the text that reference them.

o Avoid placing a figure/table/equation after having closed a section (or after having open the following section).

o Check your graphs for the size of lettering and lines. Also, do not forget to always include the name and numeric labels for every axis in the graph. Finally, ensure the graph has a meaningful, short, and easily readable name describing its contents (do not use sentences for this matter).

o Avoid using too many lines in tables if this makes difficult to read the values inside.

o Whenever possible, include graphs and pictures describing your system, algorithm or solution to the problem. This helps a lot to the reader.

o Alternate between passive and active form for the sentences, do not abuse of any of them (although technical writing is prone to use passive tense).

o Avoid slang, do not merge different grammatical tenses in the same paragraph, and try not to use the construction “I did …”.

6

6 Electronic Edition and Diffusion Think twice before engaging to an editing environment for your document. The report your are writing could (and most probably would) be reused for a later paper in the future. Think also in how easy could be to change things in the document with your editing environment.

At present, most people are using either Microsoft Word or a Latex platform. I don’t intend to compare or recommend any of them, since each one certainly has its own advantages AND drawbacks.

When using Word you better define styles and use document sheets, otherwise you could not be able to maintain the document in the future, specially its format. When using Latex do not abuse of non-standard keywords or style files, and get a good graphics editor to generate correct and high quality eps (encapsulated postscript) figures for your document.

In any case, try to use predefined formats, and avoid advanced characteristics that could tie your document to a given processor or operating system.

Documents in pdf are preferred by most people because of their quality, low size files, and search capabilities of many modern web engines. Usually, postscript files are much larger and should be compressed with Winzip, gzip or similar tools.

Make a try to see how your document looks like when exported to html format. Nowadays, directly dumping the document in Internet pages is a good idea in many situations.

7 Concluding Remarks This short paper is intended to serve as a basic document to guide students and novel researchers in writing and transmitting their work to other persons.

The document is intentionally short and quick to read in order to motivate people to read and use it. This, necessarily, means avoiding long explanations of why these advices should be met.

The most general recommendations are to try to make decisions that you follow through out all the document, and never forget to think about the completeness and correctness of the information you are including in the document after having written it.