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:
- 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
- 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.
- 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.
- 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.)
- 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
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:
Does your solution actually address the stated problem?
Do you explain your decisions and the trade-offs?
How complex is your solution? Simple is better, yet sometimes simple won't
do the job. But unnecessary complexity is bad.
Does your solution fit well with the rest of the system? If your solution
requires modifying every piece of hardware, software, and data in sight,
it won't be credible, unless you can come up with a very good story why
everything needs to be changed.
How extensible is your design? Are there opportunities for later addition
of desirable features that you decided to omit?
Is your analysis clear?
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.
Is the report easy to comprehend?
Is it well organised and coherent?
Does it use diagrams where appropriate? (A frequent problem when people
use word processors is that they try to express everything in words, either
because the word processor doesn't make it easy to include diagrams, or
they haven't ever learned how to use the drawing features. Pictures can
communicate some ideas far better.)
Does it address the intended audience?
Is there a good abstract and bibliography?
Last modified: Tue Oct 16 03:48:09 BST 2001