The main goal of the MSc thesis is to prove the ability of the candidate to solve engineering problems independently. The candidate has to prove his/her ability to gain an overview of a problem domain and solve the engineering problem specified in his/her thesis statement through a logical, reasoned and succinct treatment.

Delivering an “optimal” solution is generally not a requirement, as previous experience in an engineering role can’t be expected from the candidate. That being said, delivering a correct solution/approach, the application of known/learned methods, an overview of the existing approaches, etc. are requirements.

Literature research and a review of known results are expected, but the context of their evaluation is solving the problem in the thesis statement.

Any expert reviewer will find a significant number of errors and points of disagreement in an MSc thesis. A complete enumeration of these is not required; the reviewer can simply summarize typical errors and emphasize the major specific problems, if any.

At the same time, if the thesis has particular strengths, we kindly request the reviewer to point these out, too.

The reviewer is expected to give questions to the candidate in the written review (usually 2-3), which he/she receives in advance and has to reply to them at the end of his/her MSc thesis defense presentation.

An MSc thesis review is usually 1½ - 2 pages long.

We kindly ask for a signed copy of the review to be sent to the Department (emailing a signed and scanned copy to the topic advisor is sufficient). We also ask for a signed copy of the grade proposed by the reviewer (on a scale of 1-5, 5 being “excellent” and 1 the single failing grade). This should be a separate document/sheet of paper; historically, we asked for the grade proposal to be forwarded to the Department in a closed envelope (opened only by the defense committee). Nowadays, sending a signed and scanned copy is also an option.

Reviewers are always welcome to participate in the MSc thesis defenses; however, it is not a requirement.

Some departments at the faculty have “checklists” for reviewers – coverage of the stated problems, documentation of software artifacts, whether the software/system/… was tested, demarcation of contributions from the contributions of others, etc. These are all valid evaluation aspects, but we leave their application and weighing their contribution towards the proposed grade to the discretion of the reviewer.