Guidelines for Research Student Review Talks and Review Reports

The aim in both cases is to indicate what you've been doing since you started your degree, or maybe since your previous review.

Headlines: make sure you describe past work, the gap, and your evaluation plans. Further details are below.

What you should have been doing is a mixture of reading, design-type work (which might include what a software engineer would call requirements analysis), implementation, testing, evaluation (by you, of what you have done), and writing-up. How much of each depends on how long you've been going.

When you give a talk, or write a report, for review purposes, some of the things that you need to convince the review panel of are:

• that you have read plenty of relevant papers and books and now understand the field. You should refer to papers in which the concepts that you are describing are first described: "QR-networks (Smith & Wang, 1994) solve the problem of ...". This allows the audience to ask, during question time, "have you seen the work of Chan & Jones (1996) on QR+ networks" - this may put you onto some valuable new material. In a talk, it is not necessary to have a detailed reference list to specify all these papers in detail. In a report, you should have a bibliography.
• that you have found something which has not previously been "done" - this is sometimes referred to as "the gap" - your talk/report should make clear what the gap is;
  The gap may be something that has never been done at all, or a new (better!) way of doing something that has already been done. In the first case evaluation may consist of showing how useful your new thing is. In the second case, evaluation may consist of showing how much better your new way is. In this case, especially, you may find yourself using statistical methods. Make sure you know and show in advance that your planned statistical evaluation is mathematically valid.
• that you have developed a fairly detailed plan for filling this gap;
• that you have developed a plan for testing your system when it is complete. It is important to work this out in advance: if you finish your implementation only to find that your "advance" cannot be evaluated, you will be in a mess.

This much would be about right for a first review. Subsequently you would proceed to implement your plan:

• design, coding, verification/testing in the software engineering sense;
• difficulties overcome.
• evaluation of your system by you, to show how great it is, and compare it to other relevant systems or approaches;
• writing up (allow at least six months for this, and bear in mind that in some cases during writing up, you suddenly discover a much better way of doing things. This is often because the discipline involved in describing your work for others makes something clear to you that you had never previously seen or fully understood. You might then need to modify your system and re-evaluate it. So start writing up early.