How to Write a Technical Paper: Structure and Style of the Epitome of your Research

Georgios Varsamopoulos Department of Computer Science and Engineering Arizona State University Tempe, Arizona, USA georgios.varsamopoulos@asu.edu

Abstract
A major problem that young researchers face is their inability to write good research papers. This document serves as a guideline on how to write a good technical paper. It contains ideas that have been gained through experience; skilled authors will nd themselves familiar with these ideas. The document is formated and structured like a typical journal publication. Each section describes what you should discuss in it. The abstract is what a person always reads rst in a technical paper. Based on the content of the abstract, the reader will decide whether the paper is worthy enough to merit further study. The abstract should classify your research and contribution in the research areas. It should contain the following four parts: a brief introduction describing the discipline that the paper belongs to; a clear and concise statement of your problem; a brief explanation of your solution and its key ideas; a brief description of the results obtained and their impacts. Lastly, provide a short list of index keyword terms. Keywords: writing guides, writing technical papers, format guides

Introduction

The introduction serves a twofold purpose. Firstly, it gives the background on and motivation for your research, establishing its importance. Secondly, it gives a summary and outline of your paper, telling readers what they
The title states the contribution of a paper in one sentence. Though the very rst words of a paper, often it is the last to be decided in the authoring process. The most usual format of title is A [adjective] [approach] for [problem] in [environment], although there is no standard to write a title. This document was produced on September 14, 2004

should expect to nd in it. When you write the background review, you should consider including technological trends of the area, open problems and recent promising developments. At this point, you can introduce more specic terminology which is not widely known. Provide good motivation for your work, such as explaining its technological, research or economic importance. The motivation should not be elaborate; simply two or three good reasons are enough to make your research important. The summary should include a problem description, which is slightly more detailed than in the abstract. The summary should also include a description of your solution and some arguments on its impacts. In the description of your solution, include its key concepts and categorize its approach. Close your introduction with a description of your paper outline, what sections it contains and what the reader will nd in each. After completing the introduction, readers will decide if they want to continue. Your paper should ow smoothly. Readers should never feel as if they are missing informationa technical paper is not a novel. A proper ow is to rst set the context, then present your proposal, then provide the verication, and lastly wrap up with conclusions. Figure 1 gives the main sections of a paper. Introduction, related work, system model and problem description set the context, followed by the presentation of your solution. Analysis, simulation and experimentation make up the verication part. Lastly, conclusions and future work make an evaluation of your solution according to the verication results.

Related Work

The purpose of the related work section is the most misunderstood by young authors. Therefore, it is important to pay extra attention in writing this section. Similar to the introduction, the purpose of the related work is twofold. First, it gives a list of research works that are

Introduction

3
Problem Statement

System Model

Related Work

System Model

Your solution

Analysis

Simulation

Experimentation

In the system model section, you explicitly describe all the hypotheses and assumptions of the environment on which the problem will be stated. Put good eort in realizing all explicit and implicit assumptions that you make, and clearly state them. It is important to provide support for your assumption choices. The more valid and acceptable your assumptions are, the more valid and acceptable your work will be. The system model section should always have a gure. The gure should demonstrate the parameters of your system model. Prepare the gure so that it can later be reused or enhanced to demonstrate your solution.

Conclusions

Problem Statement

Future Work

Figure 1: The structure of a typical technical paper

related to your papernecessary to show what has happened in this eld. Secondly, it provides a critique of the approaches in the literaturenecessary to establish the contribution and importance of your paper. Providing a related work section shows that you have done your homework. In this aspect, it is important that your related work section be as complete as possible. By complete, it is not meant that you should list all the existing publications on the subjectthis would be somewhat hard but mostly meaningless; on the contrary, you should distinguish and describe all the dierent approaches to the problem. Ideally, a person who chooses to focus on the area of your paper should only read your paper to catch up with the background work in the eld. Moreover, a good background work survey will deter the possibility that your solution has already been proposed by others. In time, you will realize that the most important works are found only in journals or in proceedings of major conferences. Although you have probably studied publications from other sources, you will end up citing only the important ones. Critiquing the major approaches of the background work will enable you to identify the limitations of the other works and show that your research picks up where the others left o. This is a great opportunity to demonstrate how your work is dierent from the rest; for example, show whether you make dierent assumptions and hypotheses, or whether your approach to solving the problem diers.

Often, this section is merged with the system model. State your problem clearly. Be as exact as possible into stating what the question of the problem is. It reects poorly upon an author if he cannot describe or does not know what problem his solution addresses. But most importantly, it will be easier for successive researchers to classify your work.

Solution

You should begin this section by providing an overview of your solution. Give a good explanation of its rationale, concepts and mechanisms. If your solution relies on a theorem or some other undocumented concept, make sure that you explain them before you carry on to the detailed description. The main part of this section is the thorough description of the solution and its functionality. The description should not contain arguments on correctness or design decision debates; simply, describe the mechanisms of your solution and avoid explanations of the why so type. Dedicate a separate paragraph or two on the latter, if you deem necessary. Disassemble your solution to its functional components and explain them separately. For example, if you describe a distributed algorithm, explain the protocol-specic part (message format, etc.) separately from the semantics and decision-making part of the algorithm. It is both important and useful to provide gures demonstrating the functionality of your solution. Make the gures look similar to the system model gure, if applicable, and exploit the similarities and dierences to point out important aspects of your solution.

Analysis

certain applications. Usually, papers on software product solutions contain usability tests.

Analysis can be of two types: qualitative and quantitative. The former means to show some properties (qualities) of your solution, while the latter means to show some performance aspects of your solution. Qualitative analysis is usually proof of correctness, however it could be proof that the solution possesses some desired property. For algorithms or protocols, a proof of correctness is always welcome. Quantitative analysis is mostly performance analysis. It is important to explain what performance metric you use and why you have selected the specic metric. Choosing a metric that has been widely used will make the comparison to other solutions easier.

Conclusions

The conclusions section, similar to the introduction and related work sections, serves two purposes. The rst is to elaborate on the impacts of using your approach. The second is to state limitations or disadvantages of your solution, thus enabling you to provide directions for future research in the eld.

Bibliography

Simulation and Experimentation

Use a bibliography utility to generate the bibliography. Do not hesitate to include textbooks in your bibliography; mention them in the introduction or in the related work section.

Depending on your budget and available time, you may have performed simulations or even some experiments. In either case, it is important to describe the environment of your experiments or simulations. This includes stating the parameters and conditions of the environment (simulated or real), what measurements were taken and how they were taken. You need to establish the fact that your simulation or experiment results are statistically stable, meaning that they are representative of the space of possible results. Performing experiments and simulations is a subtle matter, always putting the validity of your data at risk in many aspects. Before you perform the simulation or experiment, educate yourself on how to perform simulations, how to interpret the results and how to present them in graphs and gures. Each gure (or graph) should be well explained. Dedicate at least one paragraph for each gure. Describe what the reader sees in each gure and what he should notice. Moreover, reason on the resultsare they the way they were expected to be? Avoid giving tables of numerical data as means of presenting your results. Compare the performance of your solution to the performance of one or two competing solutions. Usually, when you simulate or experiment on your solution, you simulate it in contrast to a competing solution. You have to make sure that the test scenarios are fair and make an argument about the fairness of your comparison in the paper. A special case of experiment is the usability test. Many times, although the performance of a solution can be impressive, the applicability of it can be minimal. Usability test is a type of experimentation, which determines the acceptance of a solution by end-users or its suitability for

References
[1] ACM Digital Library. http://www.acm.org/dl/. [2] GNUplot. http://www.gnuplot.info/. [3] Guide to a scientic writing style. http://voxlibris.claremont.edu/research/lrs /science cit.htm. [4] IEEE Xplore. http://ieeexplore.ieee.org/. [5] Bates College Department of Biology. Introduction to journal-style scientic writing. http://abacus.bates.edu/ ganderso/biology /resources/writing/HTWgeneral.html. [6] S. L. Kleiman. Writing a math phase two paper. http://www-math.mit.edu/phase2/UJM /vol1/KLEIMA 1.PDF, 1999. [7] Ned Kock. A case of academic plagiarism. Communications of the ACM, 42(7):96104, July 1999. A [8] L. Lamport. L TEX: A Document Preparation System: Users Guide and Reference Manual. Addison-Wesley, 2nd edition, 1994. [9] Merriam-Webster. Merriam-Websters Collegiate Dictionary. Merriam-Webster, 11th edition, 2003. [10] University of Chicago Press. The Chicago manual of style. University of Chicago Press, 15th edition, 2003. [11] H. S. Stone. Copyrights and author responsibilities. IEEE Computer, 25(12):4651, December 1992.

Appendix A What goes to an appendix

Moving text to the appendix is a good way to reduce the pages of the main portion of your paper, and to preserve the pace of reading. Appendices usually contain

long program codes, rigorous and tedious proofs, mathematical background of a key concept which is not well documented, and detailed instructions of reproducing an experiment. Generally, an appendix takes anything that is necessary to be included in the paper, but it is not completely within the main scope of the paper.

Appendix B Some useful tips

This is not the only guide to scientic writing. There are numerous, possibly better, guides on the web [3, 5, 6] on how to write technical papers. Just use a web search B.4 Learn from others engine and you will nd many. There are many well-written papers that you can use to learn how to write in a technical manner. Good paB.1 Language and clarity pers can be found in all journals. IEEEs Xplore [4] and Check the language and styleit is the authors greatest ACMs Digital Library [1] have all their journals and conchallenge. Use a writing style guide. IEEE Computer ference proceedings available in PDF format over the web. Society recommends The Chicago Manual of Style [10] You could also look for papers which received Best Paper for papers submitted to IEEE; it is not a bad idea to awards. Give your paper to one-or-two trusted persons for restudy the book prior to publishing papers. Also, have view. Ideally, give one copy to a person who is very faa dictionary within reach; Merriam-Websters Collegiate miliar with the papers focus, and one copy to a person Dictionary [9] is recommended by IEEE Computer Sociwho is generally familiar with the discipline of the paper. ety. Use a spell checker program on your document. Evaluate the clarity and purpose of each paragraph; does it meet its objectives? Evaluate the clarity of each section; are its objectives well stated at its beginning? Is there a paragraph at the end of each section that concludes whether the objectives and purposes have been met? Always ask yourself whether a concept that you detail will be clearly understood. Never assume that the reader will know how you think and never expect that he can guess what was in your mind when you wrote the text. Use consistent and conventional notation: x, y, z are reals, i, j, k are integers, , are parameters, etc. Avoid recycling of identiers, and do not introduce an identier unless you will use it later in the paper. B.5 What you should avoid

in the gure. The example in the gure should be minimal yet complex enough to demonstrate the non-trivial aspects of the idea you are trying to illustrate. Reuse the gures. Draw simple gures on which you can build upon and demonstrate more concepts as you progress in your paper. Similarity and reuse of gures increase the consistency, coherency and comprehensibility of your presentation. By maintaining the basic style and layout in the gures, you allow the reader to relate and understand the new ideas based on the dierences and similarities among the gures in the paper.

Do not cite references in the abstract. Many times, the abstract will appear by itself and any citations in it will be pointless. Do not use custom terminology in the abstract; use terms and concepts that are widely accepted. Unless a formula is the epitome of your results, do not write formulas in the abstract. Doing so would require explaining the terms in the formulas, which is basically impossible if you want a short and clear abstract. Avoid repeating in the introduction sentences which are in the abstract. You can mention a publication with minor contribution, but avoid describing or critiquing it. Acknowledge your sources. Do not plagiarize and do not fabricate reB.2 Use the right software tools for preparation sults. The consequences of such acts can burden you for a lifetime. Read the article by Ned Kock [7] for a real story Nearly all papers submitted to reputed journals are pre- of academic plagiarism. Harold S. Stone, in [11], explains A pared using L TEX [8]. It is a good idea to get acquainted the importance of acknowledging your sources. with this powerful document preparation software. Make good and readable graphs in the results section. Avoid three-dimensional graphs. An excellent tool for generating graphs is gnuplot [2], which is free. B.3 Figures, gures, gures Introduce gures to demonstrate key ideas or to explain anything which is hard to describe in writing. Make every gure simple and clear. Do not draw redundant objects