Claypool

Index

html | docx | pdf | txt | md

v 1.4 diff: [prev | all], License

Writing the Conclusion

The Conclusion chapter typically opens with a brief reminder of the domain (about one paragraph) and the problem that was addressed (another paragraph). This may sometimes include a paragraph summarizing what was done to address the problem (another paragraph).

Then, the chapter should actually conclude (i.e., not just summarize) in light of the original problem that was addressed by the project.

Usually, this involves concretely describing the main findings from the results and evaluation that addressed the problem. While the Results chapter usually has low-level details, here they are coalesced and brought to a summation at a higher-level. Typically, there are 2-4 paragraphs with such conclusions.

Tip: avoid unmeasureable outcomes (opinions) and superlatives (e.g., "our work was the best" or "our system was super necessary"). Instead, speak to the facts of what the project designed, built and evaluated.

The Conclusion chapter does not need a post-mortem type of discussion (e.g., "what went wrong" or "what we could have done better"). If such material is needed for the report, it should be in a "Discussion" chapter (although most reports will not have this).