Writing of Reports for CS491/492
Writing of reports/documents in this semester is a serious task that
you should be careful about. Here, in this page, I will try to point
out some common mistakes that students do while writing, and will also
provide some guidelines and suggestions. This page will be an evolving
page. I will make additions to this page without a notice. Therefore,
you should read it from time to time, especially before starting to
write a document related to this course. At the end of the academic
year, it may evolve to a more complete document that can be
distributed.
General Suggestions
- In your analysis report, don't forget to include a section
describing other systems, programs, software, tools that you searched
for and got an idea, while deciding on your project and its
scope. This can be put under the section heading "Relate Work", if
there is no corresponding section in the outline related to the
analysis report posted on the course departmental webpage.
- In your anaysis report, don't forget to have a references section at
the of your document listing all the documents, papers, Internet
resources that you benefitted from so far and mentioned in your report
in some way. At the points where you use some knowledge or idea that
you borrowed from a reference listed in this list, you should cite
that reference.
- Make sure that you read, edit, and improve any of your reports several
times before you submit finally. This is very important. Even
professional writers do this. Therefore, allocate enough time for this
process also. This requires you to finish the first draft not too
late.
- For a good analysis report, you should set aside a good time and have
sevaral discussions and brainstorming sessions among yourself to decide
what kind of functionalites/features(properties) your system will have
and how you will define/specify these functionalities/features. For
this, one type of brainstoring activity can be like the following (but
you are of course not limited to this): some of you can act as the
customer, and the others as the system builders; sit together;
customers tell what they want; system designers question if they
understood the requirements correctly, are they feasible, and so
on. You can come and see me in my office if you need to talk to me as
a requester of the system as well. But if you can not do this always,
you should use your common sense in driving the features and
functions that can be desired by a customer in order to achieve a good
quality system/product/tool/software at the end.
- You should always bind your reports. The binding can be a "spiral
cilt" or a "telli dosya", or something else that is more
appropriate. I saw many reports submitted without proper binding, just
as the output from the printer.
Other Suggestions
- Use the same font style for headings and normal text. The usage
of fonts and styles should be consistent throughout the document.
- The sizes of the fonts that you are using for various elements of
the document, such as section titles, sub-section titles, paragraphs,
etc. should not deviate too much form each other. Some documents, for
example, contain sections titles that are very large in size compared
to other text in the document. This does not appear nice.
- You should construct and use your own sentences. You should explain
something with your own words and sentences.
- The document should be structured both logically and
physically. With logical structure I mean the document should be
divided into sections and paragraphs where each section and paragraph
is about a different topic. The sequence of sections and paragraphs
should have a logical order. The flow of text should be good. There
should not be abrupt jumps in the subjects of the written text. It
should be easy to read and follow.
- You should always have a good dictionary at your disposal while
performing a serious writing activity. It should be ready on your desk.
- Always read and improve document several times before submitting
it to your supervisor. This is very important. Like debugging of
programs, debugging of writing/drafts is also an essential task which
should never be neglected. Otherwise, it will be an embarrasing
document.
- Always spell check.
- Be consistent in your style of writing.
- Try to avoid repetitions and cliches.
- If you are including information or ideas from other sources, you
should provide references (i.e. information about these sources) at
the end of the report. Inside the body of the report, you sould also
cite a reference whenever you include an idea or information from that
reference.
- The point in a report where to list the references is usually the
end of the report.
- Be careful with punctuation in your document. Eliminate the
punctuation errors when you are reading and editing the draft you have
written. Proper punctuation is very important for the reader. It
helps easy and fluent reading.
- Cut-and-paste figures usually do not appear nice. You should have
your own figures. You should draw them yourself. If you have drawn it
using another tool and imported to your document, you should make sure
that it is imported with good resolution and it is in coherence with
the document style.
- Leaving too much empty spave between paragraphs, figures, etc. in
a page does not look nice. You should have enough material in each
page to fill it nicely.
- Introductions are usually poorly written. An introduction should
include paragraphs about the topic of the work, and also about the
work that you have done and that you are presenting in the
report. Some introductions I have seen so far are not talking about
what the report is about.
- If you have a figure, you should have an appropriate caption as
well. You should also explain in text what the figure is about and
what is going on in the figure. Figures should be numbered.
This page is prepared by Ibrahim Korpeoglu.