Final Report Structure

  1. Title Page
    1. Include the project title and the name of the author of the report. You can also include the name of your supervisor.
  2. Originality avowal
    1. First page of the report after the Title page  should contain the following statement certifying the work as your own: “I verify that I am the sole author of this report, except where explicitly stated to the contrary.” Your signature and the date should follow this statement.
  3. Abstract
    1. IT IS a very brief summary of the report’s contents (half a page long). Somebody unfamiliar with your project should have a good idea of what your work is about by reading the abstract alone.
    2. It is usual to thank those individuals who have provided particularly useful assistance, technical or otherwise, during your project (your supervisor).
  4. Contents page
    1. List the main chapters and (sub)sections of your report (Choose self-explanatory chapter and section titles.)
    2. Should include page numbers indicating where each chapter and section begins.
    3. Avoid too many levels of subheading. In particular, stick to sections and subsections (sub-subsections are usually avoidable).
  5. Introduction
    1. Begin with a clear statement of what the project is about so that the nature and scope of the project can be understood by a lay reader.
    2. Summarise everything that you set out to achieve, provide a clear summary of the project’s background and relevance to other work.
    3. Give pointers to the remaining sections of the report, which will contain the bulk of the technical material.
  6. Background
    1. Set the project into context by motivating the subject matter and relating it to existing published work.
    2. Background will include a critical evaluation of the existing literature in the area in which your project work is based and should lead the reader to understand how your work is motivated by and related to existing work.
  7. Body of Report
    1. Usually consists of three or four chapters detailing the technical work undertaken during the project.
    2. Can reflect the chronological development of the project, e.g. design, implementation, experimentation, optimisation, evaluation, etc (although this is not always the best approach).
    3. However you choose to structure this report, make it clear how you arrived at your chosen approach in preference to other alternatives.
    4. In terms of the software that you produce, you should describe and justify the design of your programs at some high level, e.g. using OMT, Z, VDL, etc. (?), and you should document any interesting problems with, or features of, your implementation.
    5. Integration and testing are also important to discuss in some cases.
    6. May include fragments of your source code in the main body of the report to illustrate points; the full source code is included in an appendix to your written report.
  8. Evaluation
    1. Be aware: many projects fall down through poor evaluation. Simply building a system and documenting its design and functionality is not enough to gain a good mark.
    2. It is extremely important that you evaluate what you have done both in absolute terms and in comparison with existing techniques, software, hardware, etc.
    3. This might involve quantitative evaluation, for example based on performance measures, or something more qualitative, such as functionality or ease-of-use.
    4. ** Usability questionnaire for users? 
    5. May also involve a discussion of the strengths and weaknesses of your work.
    6. You are expected to provide a proper critical appraisal of what you have done. Your assessors are bound to spot the limitations of your work and you are expected to be able to do the same.
  9. Professional issues
    1. Either in a separate section or throughout the report demonstrate that you are aware of the Code of Conduct & Code of Good Practice issued by the British Computer Society and have applied their principles, where appropriate, as you carried out your project.
  10. Conclusions and Future Work
    1. List the key things that have been learnt as a consequence of engaging in your project work. Avoid tedious personal reflections like “I learned a lot about C++ programming…”.
    2. It is common to finish the report by listing ways in which the project can be taken further. This might, for example, be a plan for turning a piece of software or hardware into a marketable product.
  11. Bibliography.
    1. Consists of a list of all the books, articles, manuals, etc. that are referred to in the report. Provide enough information to allow the reader to find the source.
  12. Appendix
    1. The appendices contain information that is peripheral to the main body of the report. Information typically included in the Appendix are things like tables, proofs, graphs, test cases or any other material that would break up the theme of the text if it appeared in the body of the report. It is necessary to include your source code listings in an appendix that is separate from the body of your written report (see the information on Program Listings below).
    2. ** Add to report paper wireframes (low fidelity) and good designs made using software (high fidelity).
  13. User Guide
    1. Provide an adequate user guide for your software. Provide easily understood instructions on how to use your software.
    2. Treat the user guide as a walk-through of a typical session, or set of sessions, which collectively display all of the features of your package.
    3. Keep the guide concise and simple.
    4. Use of diagrams, illustrating the package in action, can often be particularly helpful.
    5. The user guide is sometimes included as a chapter in the main body of the report, but is often better included in an appendix to the main report.
  14. Program Listings
    1. Complete source code listings must be submitted as an appendix to the report.
    2. The project source codes are usually spread out over several files/units.
    3. You should try to help the reader to navigate through your source code by providing a “table of contents’‘ (titles of these files/units and one line descriptions).
    4. The first page of the program listings folder must contain the following statement certifying the work as your own: “I verify that I am the sole author of the programs contained in this folder, except where explicitly stated to the contrary”. Your (typed) signature and the date should follow this statement.
    5. All work on programs must stop once the code is submitted. You are required to keep safely several copies of this version of the program. Your examiners may ask to see the last-modified dates of your program files, and may ask you to demonstrate that the program files you use in the project examination are identical to the program files you have  submitted. Any attempt to demonstrate code that is not included in your submitted source listings is an attempt to cheat.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s