Department of Information Technology

Required deliverables

To pass the course, you must hand in two reports - a product report and a course report - and zip archive file. Both reports should refer to each other, so that they complement each other. The zip file should be an archive of everything you produced during the course, including review presentations etc.

Product report

In the product report the intended reader is the customer, and/or a future development team but not necessarily the end users of the system. The focus is on the end product and it should be described with sufficient detail for your customer organization be able to:

  • install it
  • run/operate it
  • continue developing it

This is what you "hand over" to your customer.

See below for more detailed guidelines for this report

Course report

In the course report, the focus is not on the product you ended up with, but on how you got there:

  • What decisions did you make?
  • What ideas did you discard and why?
  • What ideas turned out to work well, which did not, etc

This is also the place to talk about your non-technical experience, for example with the:

  • project methodology used
  • project organization
  • difficulties faced and overcome, etc

It is OK to be more subjective in this report. The intended audience is us teachers and (not least) future students on this course, but of course the company will be interested in this report as well.

The course report must include a section where each group member describe their own contributions to the project! Make sure that all group members agree on these descriptions!

See below for more detailed guidelines for this report

Zip archive

We want zip archive of everything:

  • The above reports
  • Presentations/Slides (presentation for the bachelors, the review and final presentation ...)
  • Press releases (if any)
  • Documentation
  • Source code
  • Executables

In other words: essentially everything you have produced.

Suggested contents of the product report


Very short summary, 100 words maybe. For example, one sentence on background (a summary of the original idea), two sentences on what you've done and one last sentence of conclusions.

Think of the abstract as a sales talk for your paper, not for the actual product, to make the reader interested enough to read on.


An explanation of the original product idea you were approached with. Explain why it is interesting, important and useful. This is where you sell the idea to marketing people for example, who are less likely to read the rest of the report.


Describe important concepts, acronyms, tools you used in the process, target platforms, etc. Don't forget your references! This is probably the section which will contain the most reference tags, essentially for every concept/product you introduce.

<Your product name>

Describe the product from a user perspective, what you can do / what it looks like.

System description

System architecture, how it works.
This is the core of your report, and is therefore most likely the largest section.

Evaluation and testing

Describe what experiments you have done to test your product.

Related work

Similarities with existing products/systems. How is yours similar or different? What do you do better? What can you learn from what's already out there?

It is possible that you want to have this section earlier, before the system description, perhaps as a part of (the end of) the product description, so that you can refer to it later.

Conclusions and future work


Avoid web references. Published white papers, journal papers, conference papers, or books are solid. Imagine a reader picking up your report 10 years from now. Is the web site you want to refer to still there then? Even if it is, does it contain the same information? Web references are nice as a complement, though. ("see also http://...")

Appendix A: Installation instructions

How to install and setup a working system.

Appendix B: Maintenance instructions

When the system is running.

Appendix C: Suggested future work

For developers, more technical details than in the conclusions above

Suggested contents of the course report


(See above)


Background. To a large part, probably, the same as in the other report, though that is only a background to the application. Here you may also want to introduce other things which are, perhaps, not relevant in the product report. Scrum, for example.


Describe your resources - hardware, computers, etc.

This includes you, the people involved. You had different backgrounds when you came to this course. Has that been useful? In what way did you complement each other? Or didn't it matter?

Project methodology and organization

(possibly several sections)

More detail on Scrum, in general, and how you implemented it why you did it that way and advantages/disadvantages you discovered.

Try to justify the choices you made along the way. Explain the reasoning behind a decision, even if you know now that it was a bad choice.

Describe your relation with the "customer". What worked well and what did not.


Advice to the teaching staff and future students taking this course: what went well, what did not, what could be improved upon.


(See above)

Appendix A


Each group member explains his/her own contributions to the project, maybe half a page each. Make sure that all members agree on these descriptions.

Updated  2013-12-18 15:55:28 by Olle Gällmo.