V – 4 Project
Report
Purpose
of a report: writing to be read
A
key thing to keep in mind right through your report writing process is that a
report is written to be read, by someone else.
This
is the central goal of report-writing. A report which is written for the sake
of being written has very little value.
Before
you start writing your report, you need to have in mind the intended
audience.
In
the narrowest of possibilities, your report is meant for reading by yourselves,
and by your advisor/instructor, and perhaps by your evaluation committee. This
has value, but only short-term. The next broader possibility is that your
report is readable by your peers or your juniors down the line. This has
greater value since someone else can continue on your work and improve it, or
learn from your work. In the best case possibility, your report is of
publishable quality. That is, readable and useful for the technical community
in general.
Overall
approach: top-down
Take
a top-down approach to writing the report (also applies to problem solving in
general). This can proceed in roughly three stages of continual refinement of
details.
- First write the section-level outline,
- Then the subsection-level outline,
and
- Then a paragraph-level outline. The
paragraph-level outline would more-or-less be like a presentation with
bulleted points. It incorporates the flow of ideas.
Once
you have the paragraph-level flow of ideas, you can easily convert that into a
full report, by writing out the flow of ideas in full sentences.
While
doing the paragraph-level outline, think also about (a) figures, (b) tables,
and (c) graphs you will include
as part of the report at various stages. You will find that many things can be
better explained by using simple figures at appropriate places.
Another
thing to nail-down while doing the paragraph-level outline is the terminology
you will be using. For instance, names of various protocols/algorithms/steps in
your solution. Or names/symbols for mathematical notation.
The
overall approach also includes multiple stages of refinement, and taking
feedback from others (peers/advisor/instructor). I will talk about these in
more detail after talking about the overall report structure.
The
following should roughly be the structure of a report. Note that these are just
guidelines, not rules. You have to use your intelligence in
working out the details of your specific writing.
Title and
abstract: These are the
most-read parts of a report. This is how you attract attention to your writing.
The title should reflect what you have done and should bring out any
eye-catching factor of your work, for good impact.
The
abstract should be short, generally within about 2 paragraphs (250 words or so
total). The abstract should contain the essence of the report, based on which
the reader decides whether to go ahead with reading the report or not. It can
contain the following in varying amounts of detail as is appropriate: main
motivation, main design point, essential difference from previous work,
methodology, and some eye-catching results if any.
Introduction: Most reports start with an introduction
section. This section should answer the following questions (not necessarily in
that order, but what is given below is a logical order). After title/abstract
introduction and conclusions are the two mainly read parts of a report.
What is the setting of the
problem?
This is, in other words, the background.
In some cases, this may be implicit, and in some cases, merged with the
motivation below.
What exactly is the problem
you are trying to solve?
This is the problem statement.
Why is the problem
important to solve?
This is the motivation. In some
cases, it may be implicit in the background, or the problem statement itself.
Is the problem still
unsolved?
The constitutes the statement of past/related
work crisply.
Why is the problem
difficult to solve?
This is the statement of challenges.
In some cases, it may be implicit in the problem statement. In others, you may
have to say explicitly as to why the problem is worthy of a BTech/MTech/PhD, or
a semester project, as the case may be.
How have you solved the
problem?
Here you state the essence of your approach.
This is of course expanded upon later, but it must be stated explicitly here.
What are the conditions
under which your solution is applicable?
This is a statement of assumptions.
What are the main results?
You have to present the main summary
of the results here.
What is the summary of your
contributions?
This in some cases may be implicit in the
rest of the introduction. Sometimes it helps to state contributions explicitly.
How is the rest of the
report organized?
Here you include a paragraph on the flow
of ideas in the rest of the report. For any report beyond 4-5 pages, this
is a must.
The
introduction is nothing but a shorter version of the rest of the report, and in
many cases the rest of the report can also have the same flow. Think of the
rest of the report as an expansion of some of the points in the introduction.
Which of the
above bullets are expanded into separate sections (perhaps even multiple
sections) depends very much on the problem.
Background: This is expanded upon into a separate
section if there is sufficient background which the general reader must
understand before knowing the details of your work. It is usual to state that
"the reader who knows this background can skip this section" while
writing this section.
Past/related
work: It is common to
have this as a separate section, explaining why what you have done is something
novel. Here, you must try to think of dimensions of comparison of your
work with other work. For instance, you may compare in terms of functionality,
in terms of performance, and/or in terms of approach. Even within these, you
may have multiple lines of comparison -- functionality-1, functionality-2,
metric-1, metric-2, etc.
Technical
sections: The main body
of the report may be divided into multiple sections as the case may be. You may
have different sections which delve into different aspects of the problem. The
organization of the report here is problem specific. You may also have a
separate section for statement of design methodology, or experimental
methodology, or proving some lemmas in a theoretical paper.
The
technical section is the most work-specific, and hence is the least described
here. However, it makes sense to mention the following main points:
Outlines/flow: For sections which may be huge, with
many subsections, it is appropriate to have a rough outline of the section at
the beginning of that section. Make sure that the flow is maintained as the
reader goes from one section to another. There should be no abrupt jumps in
ideas.
Use of figures: The cliche "a picture is worth a
thousand words" is appropriate here. Spend time thinking about pictures.
Wherever necessary, explain all aspects of a figure (ideally, this should be
easy), and do not leave the reader wondering as to what the connection between
the figure and the text is.
Terminology: Define each term/symbol before you use
it, or right after its first use. Stick to a common terminology throughout the
report.
Results: This is part of the set of technical
sections, and is usually a separate section for experimental/design papers. You
have to answer the following questions in this section:
Future
work: This section in
some cases is combined along with the "conclusions" section. Here you
state aspects of the problem you have not considered and possibilities for
further extensions.
Conclusions: Readers usually read the title,
abstract, introduction, and conclusions. In that sense, this section is quite
important. You have to crisply state the main take-away points from your work.
How has the reader become smarter, or how has the world become a better place
because of your work?
