Writing Style

Your paper should be as long as is necessary to explain the problem, your solution, the alternatives you considered, and the reasons for your choices. It should be no longer than that.

A good paper begins with an abstract. The abstract is a very short summary of the entire paper. It is not an outline of the organisation of the paper! It states the problem to be addressed (in one sentence). It states the essential points of your solution, without any detailed justification. And it announces any conclusions you have drawn. Good abstracts can fit in 100-150 words, at most.

The body of your paper should expand the points made in the abstract. Here you should:

  1. Explain the problem and the externally imposed constraints. You should explain to your intended audience the background of the problem in terms that the audience can understand.
  2. Explain and elaborate your solution. Be sure to explain the approach or architecture conceptually before delving into details, components, and mechanics. (Remember, you aren't writing a mystery novel!) Present any analysis clearly and concisely.
  3. Show how your solution satisfies the constraints and solves the problem (or how it fails to do so); explain how the properties of your solution that result from choices you have made in your design are reasonable or desirable in the context of the problem statement.
  4. Briefly describe the alternative approaches that you considered and rejected, and why you rejected them. Your paper will be more convincing if you say not just why your idea is good, but why it is better than the alternatives. (For example, if another approach would meet all of the objectives perfectly, but the cost would be 100 times higher, then you should mention that as a reason for choosing your less general but cheaper approach.)
  5. Document your sources, giving a list of all references (including personal communications). In particular, a bibliography at the end and no citations in the text of your paper is insufficient; we'd like to see what specific pieces of information you learned from where as we read your paper.

Your report should give details of each of the deliverables and contain the actual deliverables as annexes. Each deliverable should be explained in enough detail that you could hand the report over to a programmer (e.g. you in the next phase of the project) for implementation with some confidence that you won't surprised by the result.

2. How do we evaluate your report and deliverables?

We will give you a detailed pro-forma outlining the grading scheme we will use in evaluating the project. As part of the submission we will expect you to submit a self-assessment of your work following the guidance in the pro-forma. We will supply the pro-forma well in advance of the submission date to heklp you direct your work toward the assessment. Meantime here is some general advice on report writing and what content we are looking for.

Some content considerations:

Some writing considerations: A very good book on writing style is: "The Elements of Style," by William Strunk Jr. and E. B. White, Third Ed., MacMillan Publishing Co., New York, NY, 1979.
Stuart Anderson
Last modified: Tue Oct 16 03:48:09 BST 2001