CS 497 - Senior Design Project II
Final Report Guidelines
The final report is a formal communication that both fulfills a
contract obligation and tells a story. Since the final report is, in
some cases, the ``product'' of the project effort, and in all cases
the official record of that effort, it should be prepared carefully.
It must be complete enough to account for all of the essential
information pertaining to your project, so that you or anyone else
could reconstruct and understand what has been done. It must also be
accurate; reality must not be warped either by inflation or by
depreciation. Mistakes or failures should be explained, but not
covered up. Tell it like it was.
Report content will vary as widely as do types of project
activities; some will be mostly data or code, others will be mostly
words. You may have tables and graphs, or you may have none. Do
whatever you need to do to tell a story that is understandable,
complete, and accurate. The sections of a common report format is
presented below.
Title page should be in a format suitable for the type of binding to
be used. E.g., if a report cover with a ``window'' is used, the title
of the project should appear there. The title page should indicate
the name of the project, the project engineer(s), the sponsor, the
project advisor, the University, and the date.
Give credit for any help you received in this section. This includes
significant advice, data, equipment, labor, and so forth. This is not
a book or a dissertation, so do not thank your spouse or special friend
for their great patience, tolerance, and understanding. Dedications
are similarly out of place.
List the title and the starting page number of the major sections of
the main body, appendices, and whatever else follows the table of
contents. It should be obvious that this index (and the next two
sections) must be done after the rest of the report has been completed.
Each figure (anything drawn or reproduced from photographs or screen
images) should be numbered. Give the number and title of each figure
together with its page number. The same title should be used on the
figure itself as a caption written under the figure. A
figure should be inserted into the text at the first available space
occurring after it is mentioned.
Each table should be numbered, separately from figures. (A table is
usually composed of words and/or numbers in a table format.) Give the
title and number of each table together with its page number. The
same title should be used on the table itself as a caption written
above the table. A table should be inserted into the
text at the first available space occurring after it is
mentioned.
Present a quick rundown of the entire design process: the motivation,
problem definition, approach, and results. By giving the reader a
good, overall ``big picture,'' you will vastly simplify their task of
reading and understanding all that follows.
Give a more detailed statement of the problem as it was presented and
as it has evolved to the state to be considered in the design process.
Include any technical discussions that help bring the problem into
focus.
Tell how you decided to attack the problem. Include the methods,
algorithms, etc. used in the various components of the overall task.
Relevant technical discussions should be inserted as needed, but if
they are too bulky or do not continue the flow of discussion, put them
into appendices and cite accordingly.
Tell what came of it all. Give the punchline first, then the details.
It is a good idea to present the results of component tasks in the
same order used to discuss those tasks in the design. Use visual aids
wherever appropriate to add clarity to an otherwise obscure
discussion. Small code samples are appropriate here, but code
listings should be put in appendices.
The reader may wonder ``so what?''; this section should tell them. If
you have recommendations to make, you can add another section with
that title, or you can include them here. Implications for future
work can also be presented here or in a separate ``Future Work''
section. Note that any ideas you have for how to do the
follow-on work are ordinarily reserved for another proposal. If
additional work seems appropriate, suggest it to the sponsor.
Provide a complete list of all references cited in the report in a
suitable format.
Extensive side discussions, lists of data, code listings, etc. are
packaged by topics in separate appendices. The order of presentation
should follow the order in which they were mentioned in the main body
of the report. Note that it is not necessary to provide the entire
code listing for a project.
The prose in a technical report should follow standard English usage
for this type of document. In particular, it should not be ``folksy''
in tone except in rare cases where such language would enhance the
reader's understanding. Likewise, use of contractions is generally
discouraged. The report should use technical vocabulary as
appropriate, but also define them on first use.
Each page of your report should be numbered though the page
number is not printed on the title page of the report. It is common
for the pages up to the introduction to be numbered using lower case
Roman numerals with the rest of the document numbered in Arabic
numerals starting again with page 1. Other formats number all pages
using Arabic numerals with the title page as page 1. Page numbers
should be printed in the top or bottom center, or the top or bottom
outside corner.
A good outline is indispensable in turning out a coherent
report; it will keep you from omitting things or repeating yourself.
A detailed outline is especially valuable if you parcel out sections
in a team project. A team report report written in this manner will
need to have one person do a rewrite to make the style and vocabulary
consistent.
When you have ``completed'' the report, it is helpful to put it aside
for a few days and then read it in its entirety. Not only will you
catch errors that were overlooked in proofing, but you may also become
aware of omissions, redundancies, and obscurities. An ``outside''
reader--someone unfamiliar with the project--can provide another
good check on clarity.
Converted using latex2html on Tue Jan 11 16:29:12 CST 2005