[ CIS Seminar Homepage ] [ Dept. of Engineering & Science ] [ Rensselaer at Hartford ]

Writing the Final Draft

[ Top? ] [ Bottom? ]


Remember, this is the manuscript, not the camera-ready copy. To make it easier for your advisor to review and comment on your paper, the manuscript should be one column, double-spaced, with one-inch margins, in a type size that won't cause eye-strain (12 point is OK).

[ Top? ] [ Bottom? ]

Audience Analysis

Primary Audience:
Fellow graduate students in Computer Science. May not have completed the MS degree yet, but have taken at least the basic courses. For example, if your paper is about software, you can assume your readers have taken Software Engineering I. They probably know a bit about your general topic, but probably don't know much about the specific problem you're investigating.
Secondary Audience:
The conference is open to the public, and anyone who wants to can buy the proceedings, so there could be several different groups here. One is obviously Rensselaer at Hartford's Computer Science faculty. Others might include managers, engineers, or others who work in MIS or in the computer industry.
Both these audiences are "well-educated." BUT!!! That does not give you license to use every highfalutin' word you know. Impress your readers with content, not verbiage!

Helpful Questions to Ask Yourself:

  1. What are the audiences' reason(s) for reading your paper? Curiosity? Solving a problem at work? Ideas for their own research? Something else?
  2. What Computer Science courses have they probably taken?
  3. What do they probably know about your specific topic? Consider jotting down a two-column list -- in column 1, write down the concepts, terms, and issues the audience knows about; in column 2 write down the things they don't know about. What does your list suggest to you about what you do and don't need to explain?
Now, use your answers to these questions as a guide for making your paper meet their needs.

[ Top? ] [ Bottom? ]

Style and Readability

The Most Important Point: Write to express, not to impress! In other words, write to tell your readers about your ideas. As it says in the "Audiences" section, impress your readers with interesting, original, well-reasoned content, not pretentious, unnecessary verbiage!

"Good scientific writing is logical, clear, precise, direct, and concise....The language used should be as simple as is compatible with the subject and as concise as is compatible with ready understanding. An extremely terse style, which can be cryptic, is as much a barrier to communication as is verbosity." (ANSI Standard on Technical Reports and Presentations, No, Z39.16-1979, Section 6, "Principles of Style")

See also some of the books and on-line references on the "References & Resources" page.

[ Top? ] [ Bottom? ]

Tips on Organizing the Paper

A very useful guide to organizing a technical paper can be found in an article by Clifford B. Fedler and James M. Gregory. The article is "The Information Matrix: Taking the Trouble Out of Technical Writing," published in Engineering Education, December 1988, pages 183 - 185. What follows is a brief overview of their advice, adapted for the Seminar paper. For more detail, see the original article, in the Rensselaer at Hartford Library.
  1. Summary of Fedler and Gregory's article
  2. Adapting their advice to your Seminar paper

1. Summary of Fedler and Gregory's article

NOTE: The article is summarized here with permission of the authors.

Fedler and Gregory break up technical papers into nine blocks of information: title, abstract, introduction, purpose, development, results, conclusions, summary, and references. They then arrange these blocks in a 3 X 3 matrix (shown here). The arrangement helps you see two key things:

Do conclusions reveal that the purpose was achieved? Did you tell the story three times, three different ways? How do your results fit in with other references or the overall problem?
Capture the reader's attention.

Use a few key words and a key thought.


Present an overview of the work.


Tell the reader the subject. What will be learned from the paper? How does it relate to other work in the field?

Present the foundation ­ the body of the paper.

Tell why you did the work. Were you answering a question? Solving a problem?


Discuss the procedure, experimental plan, or theoretical development.


Explain what you did and how it affects present conditions.

Summarize material readers may cite and works you used.

Explain what the reader should learn from the work. Did you answer the question, or solve the problem?


Enhance the reader's memory by reviewing the work


Cite only references used in the text. Use consistent, standard format.

2. Adapting their advice to your Seminar paper

You may find that your paper doesn't fit neatly into the nine blocks specified by Fedler and Gregory. That's OK. Your paper doesn't have to have nine sections, labeled to match the matrix. Many students have found it helpful to combine some of the related sections. Some of the common ways students have adapted the matrix to suit their papers include: A typical structure might then be:

Introduction, which includes an explanation of the purpose
Development (or Discussion)
Conclusions, which summarizes the work as well as states the conclusions
Results and Conclusions, which combines the results, conclusions and summary of the work
Notice that although the paper doesn't have nine sections, the nine things identified in the matrix are still included, so that the paper still does all the things it should do.

[ Top? ]

Where to next?

[ CIS Seminar Homepage ] [ Call for Papers ] [ Proposal ] [ Extended Outline ]
[ Camera-Ready Copy ] [ Conference Day ] [ Student Responsibilities ] [ References & Resources ]
[ Seminar Listserv ] [Rensselaer at Hartford ] [ Dept. of Engineering & Science ]

Copyright © 1997, Kathleen L. Farrell
First Release: March 20, 1997

Updated: 2005-09-07, 16:28