FYP Final Report

Acknowledgments

An an acknowledgement section is not required for FYPs, but it is common for FYTs.
It's where you thank all people or companies that helped you complete the project successfully.
You don’t need to mention every single person who helped you with the research- just those who were most important to your research.
Typical people whom you can acknowledge can include your advisor, academic staff, PG students, other HKUST staff and industry sponsors
It should be placed after your title page and before your Abstract.

Abstract

What's an abstract?

Your abstract is a brief statement of the essential content of your final report.
It is like a movie trailer in text format.
It's purpose is to give the readers a taste of what they will see if they read the whole final report.
It goes after your title page and Acknowledgements (if any) and before your Table of Contents.

It is usually a brief yet interesting summary of:

your project
the extent of your research
selected (important) results

To help you write the abstract, try to think about the following questions:

Why would another student or researcher be interested in this project or research?
What are the most important aspects of the project or research? What should a reader be sure to know after reading your abstract?
What information will the reader have to have in order to understand the most important aspects?
What are the main points from each section of your report? Summarize each section in one sentence, if possible.

In addition:

Incorporate the key facts and conclusions from the body of the report.
Write the abstract using mainly present simple verbs.
Try to keep your abstract to 50-200 words.

1. Introduction

The introduction provides the context for the report and tells the reader the purpose and plan of your project. The introduction does not need to be as broad nor motivational as the abstract. The introduction should be longer than the abstract and include the background of your topic, your objectives and a history of your approach or other similar approaches (i.e., your critical review or literature survey). Also, your introduction should have been 99% complete after you finished your progress report. You do not need to change it unless your communication tutor made revisions on your progress report. For more informaiton, see Introduction.

2. Methodology

The methodology section should serve as an instruction manual with which another FYP or FYT student could completely duplicate your results. It should include facts, procedures, equipment, data, details, tests performed and results (success or failure or what degrees or each.) It should also tell the two professors who give you your grade what was special about your work. Beware of two extremes:

Not explaining clearly what you did or being specific in how you did it.
Telling about almost every tiny detail and boring the readers to death. (You don't need to write a user manual!)

Instead, try to show your readers how you are intelligent, clever, skillful and resourceful and how you utilized your software engineering skills or computer science knowledge. For boring details, put them in appendices or just leave them out. Focus on what's important. Imagine what you would write if you were taking your report to a job interview and letting your prospective employer look at it! Why would he want to hire you? Or if you were to apply to grad school, would your report help or hurt your chances?

For Design, think about WHAT you did:

What does the system look like?
What are the hardware and software components, and how do they relate to each other?
What kinds of functions can different kinds of users perform and in what sequence can or should they perform them?
What does the data look like that is used for input, and do you need to do anything to it before processing it?
What processes are involved in the system, and how do they relate to each other?
What algorithms or formulas were needed, and why did you use them?
What does the output information look (or sound) like? (If you have a lot of screen shots, it might be best to put them in an appendix.)
What elements of the user interface (UI) make it user-friendly and/or facilitate a good user experience (UX)?

For Implementation, think about HOW you did it and HOW you applied your software engineering skills or other computer science knowledge:

What data, coding tools, development kits, IDE, libraries and APIs did you use, and where did you get them?
How did you set up the server (if your system has one)?
How did you build your database, and how is it updated?
What important steps did you follow as you built the system, performed experiments or recorded data?
What cool or creative ideas did you come up with?
What were the most difficult parts of building the system or solving your problem, why were they difficult and what steps did you take to try to overcome them?
What assistance did you seek from your advisor or other knowledgeable people?

For Testing, think about this:

What could possibly go wrong from the user's point of view? (If you have a lot of test cases, you can list them in an appendix.)
What types of tests helped to locate bugs or logic errors?
How did you make the testing environment realistic? Did you need to run any simulation?
What devices or equipment were used in the experiments?

In the Evaluation, think about this:

Did we accomplish each of our objectives? (Explain one-by-one.)
What went well, and what didn't?
What factors might discourage people from actually using the system in real life? (See also Evaluation or FYP final report examples.)
What did our volunteer testers (if any) think about our app or system?
What statistics, charts, or graphs might help me illustrate how good (or bad) the system or approach is?

3. Discussion

Think about this:

WHY did you succeed or fail or only partly succeed in accomplishing each objective?
What does your reader need to know before anything else in order to understand and be persuaded to believe your argument?
What is the most important thing for your reader to understand from your interpretation? Consider placing this first.

For organization, you can either follow the sequence used in your Evaluation, or perhaps you can organize your information starting with what you are most happy or certain about and progressing towards matters that you are less happy or certain about.

For research reports, the sequence might follow this outline:

Discussion or interpretation of the data
Generalization or analysis of the data
The relationship between the data and the research problem or hypothesis
What can be inferred from the data

(See also some FYP final report examples.)

4. Conclusions

Your Conclusions section doesn't need to be long. One page may be enough.

In this section, you communicate two main things:

A summary of your major technical accomplishments

Focus on:

the key things you did and learned
problems not addressed in your paper
questions that were not answered in your paper

Recommendations or ideas for future work

Possible ideas could include:

Different algoritms
Better / newer tools (software, libraries, etc.)
Better data collection
Better user testing with more volunteer testers

(See also some FYP final report examples.)

Q&A about the final report

What's the difference between testing, evaluation and discussion?

Implementation and testing are like playing a basketball game.
Evaluation is like the game statistics
Discussion is like what the players or spectators say about the game afterwards.

In your evaluation you summarize the results from testing and state how well you achieved your objectives. This is very objective (客觀的).
In your discussion, you interpret the results based on your opinions, so it is more subjective (主觀的).
In the discussion you can also mention what you could have done better. Nobody's perfect. Some of the best lessons of life are learned from our mistakes.

What do we do with the Project Planning and Required HW & SW sections?

You can simply move these to appendices, for example, "Appendix B - Project Planning" and "Appendix C - Required Hardware and Software". You can have several appendices, if necessary. In the past, some FYP groups had 5 or 10 different appendices.

What if we changed our project scope and cancelled some objectives?

You can delete all mention of the cancelled objectives in the final report, because they are no longer relevant, but be sure to mention what parts you cancelled and why you cancelled them in your Discussion.

Can we change the title of our project?

Yes! The title should accurately and concisely describe your project in its final state. Many FYPs start with a title that reflects a concept that is quite different from the final concept. Make your final title describe the final concept. If your CT suggested a new name and that name fits, it is probably best to use that title.

How do we label pictures and graphs?

Most writers center the picture or graph or table and put a description underneath which identifies the figure for easy reference and identification, for example: Figure 3 - System flowchart. To be reader-friendly, figures are also usually best placed directly under the paragraph that first references them, not several paragraphs down or on another page.

What verb tense should we use?

There is no fixed rule, because projects differ, and sections of the report differ. However, in general present tense is usually appropriate for concepts and application features, for example, "The frequency is denoted by ..." or "The system calculates ..." Past tense is usually appropriate for work you did, for example, "We developed a system..."