dissertation marking criteria edinburgh

This main page relates to the course for 2022/23. For information regarding the 2023/24 MSc Dissertation, please see Open Course - DISS .

MSc Project Guide, 2022/23

Introduction.

The project is an essential component of the Masters courses. It is a substantial piece of full-time independent work starting in June. A dissertation describing the work must be submitted by a deadline in mid-August.

Students are expected to stay in Edinburgh for the duration of their degree programme. This includes during the writing of the MSc dissertation until the submission deadline. If you are on a Tier 4 visa and leave the country for an extended period of time, the School is obligated to contact Student Immigration Service who will notify UK Visa and Immigration (UKVI).) See MSc handbook .

The project involves both the application of skills learned in the past and the acquisition of new skills. It allows students to demonstrate their ability to organise and carry out a major piece of work according to sound scientific and engineering principles. The types of activity involved in each project will vary but all will typically share the following features:

• Research the literature and gather background information
• Analyse requirements, compare alternatives and specify a solution
• Design and implement the solution
• Experiment and evaluate the solution
• Develop written and oral presentation skills

Supervision

Supervisors enable students to complete the taught module Informatics Project Proposal (IPP) during Semester 2, and to carry out MSc projects over the summer.

Over the summer, the supervisor gives appropriate technical advice and also assists the student in planning the project and working towards various targets during the period of work. Students should expect approximately weekly meetings with their supervisor at the start of the project but the frequency of these meetings will normally drop as the project progresses and as students become more self-sufficient. Backup supervisors may be allocated to cover periods of absence of the supervisor, if necessary.

Choosing a Project

There are several steps

• Staff and (optionally) students propose MSc projects.
• Students then express interest in projects and potential supervisors mark interested students as suitable/unsuitable for the projects in question. At the end, every student needs to be marked suitable for 5 projects .
• Students rank their project choices in order of preference.
• Students are assigned a project and MSc supervisor.

Details on how to propose a project and select your project preferences are given below.

Student-proposed projects

Students can submit their own project proposal via the DPMT system . However, they need to find an interested supervisor, typically well in advance of the project selection deadline .

Self-proposed project supervisors should be a member of Academic staff or Research staff . The School’s Institutes pages are useful for finding staff in particular research areas, and to browse the broad research areas represented in the School.

This procedure of self-proposal is intended for students who know at the beginning of semester 2 (or earlier) what specific project they wish to do. The student must discuss their idea with a member of academic staff and get them agree to act as supervisor for the project. The MSc project coordinator will take self-proposed projects into account when making the allocation between students and MSc supervisors, and allocate a self-proposed project whenever feasible.

Students are not expected to propose a project; the default is that students will be assigned a staff-proposed project which they will flesh out into a fuller MSc project as an outcome of the taught module Informatics Project Proposal (henceforth IPP).

If you do wish to propose a project however, you must discuss your ideas with a member of staff and get them to commit to supervising your project before submitting a proposal. This will cover aspects such as the suitability of its topic, the methods to be used, any facilities or systems required, the form the results would take, any difficulties that might arise (i.e., risks), the likelihood that it can be completed and written up by the August deadline, etc. It is up to you to find a supervisor who is willing to supervise your project. Having done this, submit the proposal as instructed in the DPMT system with all the relevant details filled in. The deadline for completing the whole process (discussion with staff and filling in the proposal webform) is in the timetable . This staff member will then register as potential supervisor for your project in the DPMT system. (Green button “Register…” at the bottom of the page.)

If you want to do your self-proposed project with an external industrial partner as supervisor, you’ll still need an internal co-supervisor (i.e., an Informatics staff member) in addition to your external supervisor. (If your supervisor is a staff member at a different School at the University of Edinburgh, then no co-supervisor is required.)

See the guide for external supervisors

As always, your project proposal must be filed before the deadline Both the internal and external supervisor need to register for it.

Even if you self-propose a project, you still need to register interest in other projects, until you are marked suitable for 5 projects (including your self-proposed one). You might not get your self-proposed project if the named supervisor ends up with too many projects to supervise. Thus you need fall-backs.

There is no guarantee that all proposed projects will be allocated. However, any pairings between staff and students that happen as a result of student self-proposed project development during these first 2 weeks of the semester will be taken into account when assigning staff their MSc students.

Projects with Industrial Collaborators

Students who are sponsored by, or have close contact with an industrial company may wish to undertake a project which relates to that company’s activities. This is encouraged. Such collaborations can take two different forms:

• If the project is specific to a particular student, then the student should file a self-proposed project in DPMT and get both an internal supervisor (i.e., Informatics staff member) and an external supervisor (i.e., the industrial partner). These supervisors will need to register as supervisors for this particular project in DPMT. See the guide for external co-supervisors here .
• External people (i.e., not staff at UoE) can also propose topics for MSc thesis. (provided that they have a staff member as co-supervisor). However, in this case the topic is open to all students , and not reserved for one particular student. Students can then bid for these topics during the normal project selection phase.
• UoE staff from other departments (i.e., not Informatics) can also propose/supervise MSc projects. Unlike externals from industry, they do not necessarily need an internal Informatics co-supervisor. See the guide here .

Students doing a project with an industrial partner are still expected to spend a significant portion of their time at the University.

Selecting projects

Students can view the proposed projects from the DPMT system . The list of projects can be sorted by project title, number or supervisor name by clicking on the relevant columns. There is also a search facility (via project tags), so that you can find projects in specific areas.

Students must eventually be marked suitable (by the potential supervisor) for at least 5 MSc projects that they would like to do (this includes supervisors registering interest in any self-proposed projects, where relevant). To this end, students must register interest in projects via the DPMT system and must contact the project proposer. Before doing this, read project descriptions carefully: these often contain information about how to contact the proposer and what information to provide. This is so that the project proposer can provide feedback to the MSc project coordinator about the student's suitability for doing the project. The supervisor will then mark the student as either suitable or unsuitable for the project. Students who are marked unsuitable for some of their chosen projects must register interest in more projects until they are marked suitable for at least 5 projects.

See the timetable for when project selection phase ends. Students who lack five suitable projects by this date risk being assigned to one of the remaining un-allocated projects/supervisors. To be safe, please try to identify and register interest in an initial set of projects a week before this deadline.

Project selection step-by-step

Please follow all of the steps below, even if you proposed a self-proposed project and found a supervisor for it. We try to accommodate all self-proposed projects, but sometimes load-balancing constraints make it impossible. Thus you need fallback options.

Log into the DPMT system and take a detailed look through the list of proposed projects. You must be on campus or the School’s VPN to access DPMT.

Read the details of all projects that seem interesting, paying attention to “Essential Skills” and “Completion Criteria”. We try hard to make sure you get a project of your choice, but this is not always possible. Some projects are extremely popular, but many can only be allocated to one student. We also cannot guarantee that you will be assigned a project in your specialism area.

In the DPMT system you can register interest in projects. Start by registering interest in 5 projects. Try to do this before 3 February , as supervisors will be encouraged to review students for suitability at that point. Do not worry about your preference ranking at this stage. You may need to register interest in a few more projects later (see below).

If you register interest in a project, then you must contact the supervisor (and, ideally, the co-supervisor as well if there is one) and ask to discuss the project. Please see if there is guidance about how to do this in the project description. Just clicking a button in DPMT alone achieves nothing. This will give you a chance to learn more about the project and about the supervisor(s). It will also give the supervisor(s) a chance to assess if you have the right skills to do the project. Some supervisors may not be able to meet with you in person, in which case you will need to discuss the project via video chat or email. Some supervisors also hold pre-tests or group meetings to assess candidates.

The supervisor will then mark you as either “very suitable”, “suitable” or “unsuitable” for the project in the DPMT system. Normally, the only reason for being “unsuitable” is the student does not have the “Essential Skills” to undertake the project.

If you get marked “unsuitable” for some of your first 5 projects of interest, you need to register interest in a few more until you are “suitable” for 5. Please start doing this at least 4-5 days before the final selection deadline. Do not register interest in large numbers of projects, because you’d be wasting everybody’s time.

You can rank your projects in order of preference. We try to take these into account as far as possible, but remember that you might be assigned to any of your “suitable” projects, including your last choice. So choose carefully.

Getting the project you want

To maximise your chances of getting a project you want:

• Look at the project list to see how many other students registered interest in a given project. If that number is high, and the project does not have capacity for several students, then you are unlikely to get it. Choose a different project instead.
• Do not select all your projects from the same supervisor.
• Do not select all your projects in a narrow subject area.
• Consider interesting projects outside your specialism area.

If you do not register interest/attain “suitability” for 5 projects, you will be de-prioritized in the allocation. This means a significantly higher chance that you don’t get assigned to any project, and will have to choose from whatever projects are left over at the end.

See the timetable for the the deadline for the project selection phase. The final project allocation will be made shortly after that (see timetable).

If you have questions, the IPP/MSc project Piazza instance is a good venue for them.

When choosing projects, some issues you should consider are:

• Do you genuinely possess the essential skills listed in the proposal?
• Will you find the project interesting?
• Does it suit your degree?
• Are you up to the intellectual requirements of the project?

Project selection FAQ

Q: Does it help to register interest in a project early? A: There is no first-come first-serve for projects. It does not matter at all who registers interest in a project first; as long as you are marked suitable you will be a potential candidate for that project.

Q: Will I increase my odds of getting my top pick (or top 2 or 3) if I only register interest for that 1 (or 2 or 3) project(s)? A: No. It will decrease the odds. Our matchmaking system allocates students with five suitable projects first, so your preferences count for much less if you don’t have five.

Q: What if I do not meet the essential requirements but I am a quick learner and a hard worker? A: Many of our projects assume that you are both of those things in addition to meeting the essential requirements. Trying to bluff your way into a project is unlikely to be to your advantage.

Q: If I select an “Easy” project, does that mean I can’t get a high mark (e.g., 75+) on it? A: Generally, all projects can be expanded or executed in an unusually impressive way. If you worry a project that interests you might be an exception, ask the proposer.

Allocation of Projects and Supervisors to Students

The MSc project coordinator will allocate each student a project and MSc supervisor on the basis of the preferences expressed by students and the supervision load of individual supervisors. There will inevitably be difficulties when more than one student wishes to do the same project. Some supervisors’ proposals are much more popular than others. Students should not necessarily expect to get their first preference of project, or even (in rare cases) any of the preferences that they stated. This process of assigning students to supervisors and projects will be completed by a date given in the timetable .

These initial assignments of students to projects happens this early in the semester, so that the supervisors, together with the IPP tutors, can deliver to their MSc students the compulsory taught module IPP . However, there is flexibility in changing supervisors in at least two ways. First, a member of staff can, if they choose, delegate supervising duties to a member of research staff (with the researcher’s agreement). However, the staff member remains responsible for ensuring that the supervision meets acceptable standards. Secondly, a student can also choose to change supervisors, provided they get agreement from their existing supervisor and the proposed new supervisor. If there are problems between a student and supervisor that they can’t sort out themselves, then the student can consult with their Personal Tutor.

This flexibility for changing supervisor remains, until the deadline for changes to projects and supervisors given in the timetable . It is not possible to change supervisors after this date.

Plagiarism and other Academic Misconduct

Remember the good scholarly practice requirements of the University regarding work for credit. You can find guidance at the School page . This also has links to the relevant University pages.

See also the following general guide on how to avoid plagiarism .

Progress reports

Progress reports on your MSc projects are due in July; see the timetable for specifics.

The progress reports will NOT be graded. They are meant to be

• informational, for your supervisor and second-marker to verify that you are progressing and that you understand what you are doing;
• additional helpful practice with respect to the final report on your MSc projects, due in August.

The report should be 2-3 pages. It should specify:

• The goal of your project
• The methods you are using
• What you have accomplished so far
• What remains to be done to complete the project.

Submitting progress reports : Students submit their progress report on the LEARN page of DISS, menu item Assessment and then Progress Report on the page.

The Dissertation

The project is only assessed on the basis of a final written dissertation. Additional material, such as the code you submit, may be taken into account in case of doubt, but you should make sure that all the work you have done is carefully described in the dissertation document. All 60-credit MSc dissertations must conform to the following format: (The following limits on the length do not apply to EPCC, DSTI Dissertation (Distance Learning), Masters Dissertation (Design Informatics), and CDT thesis.)

The strict upper bound on the length is 40 pages for normal 60-credit MSc dissertations, excluding front matter (title, abstract, declaration) and bibliography. Theses should not be shorter than 20 pages. Where appropriate, the dissertation may additionally contain appendices in which relevant program listings, experimental data, circuit diagrams, formal proofs, etc. may be included. However, students should keep in mind that they are marked on the quality of the dissertation, not its length. The referees are not required to read any appendices.

The dissertation must be word-processed using LaTeX and must use the School of Informatics infthesis.cls style file according to the skeleton template provided. Any style changes to this LaTeX template (e.g., font size, page size, margins, or anything else) are strictly prohibited .

Additional points about building the thesis using LaTeX:

• The required infthesis.cls style file is installed on all DICE machines. If you run LaTeX on your personal computer you will need to install the following two files found on DICE: /usr/share/texmf/tex/latex/informatics/infthesis/infthesis.cls and /usr/share/texmf/tex/latex/common/logos/eushield.sty.
• Template files skeleton.tex, mybibfile.bib, skeleton.pdf can be downloaded here . The first two of these generate the skeleton thesis document with an example bibliography file, and illustrate correct use of the style. If you compile them yourself, you should get a document that looks like skeleton.pdf. Your dissertation must follow the example usage given in skeleton.tex.
• Additional documentation about LaTeX and LaTeX use within the School can be found here .

On submission of their dissertation, students will be required to certify that their dissertation satsifies these requirements on the length and style.

The typical structure of an Informatics MSc thesis is as follows:

• Title page with abstract.
• Introduction : an introduction to the document, clearly stating the hypothesis or objective of the project, motivation for the work and the results achieved. The structure of the remainder of the document should also be outlined.
• Background : background to the project, previous work, exposition of relevant literature, setting of the work in the proper context. This should contain sufficient information to allow the reader to appreciate the contribution you have made.
• Description of the work undertaken : this may be divided into chapters describing the conceptual design work and the actual implementation separately. Any problems or difficulties and the suggested solutions should be mentioned. Alternative solutions and their evaluation should also be included.
• Analysis or Evaluation : results and their critical analysis should be reported, whether the results conform to expectations or otherwise and how they compare with other related work. Where appropriate evaluation of the work against the original objectives should be presented.
• Conclusion : concluding remarks and observations, unsolved problems, suggestions for further work.
• Bibliography .

In addition, the dissertation must be accompanied by an ethics statement and an own-work declaration, as in the provided template. Your IPP should have planned for the projects ethics requirements, and review the academic conduct section above.

Writing a dissertation is time-consuming. Doing it well can take as long as four weeks of full-time work. You should write up explanations, results, and discussion as you go; this reduces the risk you will run out of time, and often clarifies and improves the research. Do not leave writing up until the last couple of weeks.

Some guidelines on the style of an MSc thesis.

• Focus on your own work . If previous work is provides essential context, cite it and direct the reader to it. Never copy and paste material from elsewhere into your dissertation and edit it.
• Keep the sections on Introduction and Background brief . Mention only background and related work that is necessary to understand and evaluate your work. (E.g., definitions what are used later in your theorems/proofs, or data on the performance of other methods so that you can compare it to your results.)
• Apart from what is necessary (see item above), do not do a lengthy repetition/discussion of background and related work in your dissertation. You already received credit for planning and review in IPP. This material must not be repeated without correctly citing this prior work (see Academic Conduct section). Most students will not want to repeat material from their IPP, as they will have an improved and more focussed view of the subject matter by the time they write their final project.
• Write your dissertation in a brief and concise style. Do not waste words. Do not repeat youself. Say it once, but clearly.
• Pay attention to the bibliography. We recommend that you read the guidelines for bibliography entries - it's easy to get this right, and failure to do so is a sign of sloppiness that the reader may suspect extends to other aspects of your work.

Some links to lectures on writing:

• Informatics Lecture 1. Getting started with writing your dissertation - July 2020 (21.11mins).
• Informatics Lecture 2. Writing your dissertation: IMRaD - July 2020 (19.29mins)
• Informatics Lecture 3. Writing Dissertations - Being Concise - July 2020 (27.33mins)

Computing Resources

The standard computing resource we provide is 24/7 access to communally used DICE machines; we cannot guarantee access to or a specific lab or specific machine, reliable constant remote access, or exclusive use of any machine.

By default, you and the project supervisor are responsible for providing any and all resources required to complete the project. If necessary, the supervisor should discuss any exceptional requirements with support and/or the ITO, and receive their approval before writing the proposal.

Technical problems during project work are only considered for resources we provide; no technical support, compensation for lost data, extensions for time lost due to technical problems with external hard- and software as provided will be given, except where this is explicitly stated as part of a project specification and adequately resourced at the start of the project.

Students must submit their project by the deadline (see the timetable of events ). Students need to submit an electronic copy and archive software as detailed below. Paper copies are not required.

Electronic Copy

Students must submit a PDF version of their thesis. These are included in an electronic archive that is accessible to future students. If there are good reasons why a thesis cannot be archived, ensure your supervisor knows the reasons and tick the appropriate box on the submission page.

Generating your thesis in pdf format should be straightforward, using LaTeX (or similar), or a “save to PDF” feature in most word processors. Take care to ensure that all figures, tables and listings are correctly incorporated into the pdf file you plan to submit.

Submit your PDF using this form .

When you submit the electronic copy of your thesis you will also be asked to provide an archive file (tar or zip) containing all the project materials. Students should use this to preserve any software they have generated, source, object and make files, together with any essential data. This material is not marked directly, but may be used to assess the accuracy of claims in the report. It should contain sufficient material for examiners to assess the completion of the project, the quality of the project, and the amount of work required to complete the project.

You should create a directory, for example named PROJECT , in your file space specifically for the purpose. Please follow the accepted practice of creating a README file which documents your files and their function. This directory should be compressed and then submitted, together with the electronic version of the thesis, via the submission webpage .

Your README should make clear where any data that you used came from, how it was processed, and how any outputs can be generated from the code that you have included. You do not normally need to include large datasets, model outputs, or model checkpoints in your archive. However, sometimes such data might be useful for follow-up projects in future years, or could be important for checking your work. Please discuss with your supervisor what to include.

Project Assessment

Projects are marked independently by the supervisor (1st marker) and the (centrally allocated) 2nd marker. The 1st and 2nd marker are not allowed to discuss marks until after both have filed their marking forms. Once both markers have filed their forms, they discuss the final mark, and one of them (usually the 1st marker) files the Agreed Mark Form. (If you fail to agree, then explain why on this form.) In certain circumstances the project will go to moderation (see below).

Projects are assessed in terms of a number of basic and other criteria. Only the dissertation is used for assessment. See also the common marking scheme . Knowledge of these criteria will help you to plan your project and also when writing up. They include:

• Understanding of the problem
• Completion of the work
• Quality of the work
• Quality of the dissertation
• Knowledge of the literature
• Critical evaluation of previous work
• Critical evaluation of own work
• Justification of design decisions
• Solution of conceptual problems
• Amount of work
• Evidence of outstanding merit e.g. originality
• Inclusion of material worthy of publication

Marks in the range of 45-49 allow a re-submission of the thesis by the student within 3 months, which will need to be re-marked (Taught Assessment Regulation 58). The marking guidelines can be found here and the policy on moderation can be found here .

Markers can find electronic copies of reports here . (Access problems? Contact Computing support to give you access.)

Marking is done via the webmark system . (Access problems? If you are UoE staff without an Informatics co-supervisor: Contact Computing support to give you access. If you are external and have an Informatics co-supervisor: Consult with your co-supervisor. It is his/her responsibility to file the marking form.)

Extensions are permitted and Extra Time Adjustments (ETA) for extensions are permitted. Please refer to Rule 3 here for further details. Please see Learn for the number of extension days that are permitted.

Important Dates

All the deadlines for the various tasks, including the deadline for submitting the thesis, can be found in the Timetable of Events .

While a demonstration is not a compulsory component of your MSc summer project, there are many circumstances in which providing your supervisor and your second marker with a demo will enable them to assess your achievements more accurately.

If you do decide to give them a demo, then your examiners will need to be convinced that:

• you actually did something,
• what you did was significant and
• you understand what you did.

You should also try to educate the examiners by clearly presenting:

• what was the problem you were trying to solve,
• how you tried to solve it, and
• what the results were.

As a guide to pitching the level of your explanations, assume that your examiners are ignorant of the particular problem you are investigating, but have a general background in the subject area. Often the second examiner is from outside your project area. So, be sure to introduce your project properly, don't just dive into the middle. What were the aims of the project, how did you go about achieving them, what results did you obtain, what difficulties did you have?

In a typical demo, you might:

• lay down rules about when the audience can ask questions
• explain what the project was about
• explain what you're going to show
• show it, but don't spend lots of time describing low-level implementation detail; stick at the `knowledge level' for the most part
• try to cover as much of the functionality as you reasonably can, so in general don't dwell too long on just one or two aspects
• say what else you might have done if you'd had a bit more time

Not all projects will follow this outline; modify it to suit your own particular project.

A demo should take about 20 minutes. You will probably find that this is quite a short time, but it is good practice to do it in this time because this is typically the time you will have to demo a system in other scenarios; e.g., at conferences. Given that 20 minutes is not long, you should:

• Plan your demo carefully to cover the relevant details in the allotted time.
• Make an outline of the demo including time to explain the problem, the solution and results.
• Skip minor details if there isn't enough time.
• Practise the demo beforehand, perhaps with another student.
• Consult with your supervisor over your outline.
• Make drawings, charts and tables to clarify the whole context and simplify presentation.
• Pre-store results displays on the computer if it takes a long time to generate them. How long it takes the computer to go through a demo varies by the load; hence, it might be better to avoid too much on-line demonstration if possible.

• Schools & departments

• Important dates

Project dissertations

• Choosing your project
• Your supervisor's roles
• Project Skills
• School of Mathematics Teaching
• Postgraduate taught
• MSc Programmes
• Operational Research
• Assessment structure

Information about planning and writing a dissertation including the assessment criteria, dissertation format and examples from previous years.

Dissertation

During the period from June to August, candidates for the MSc work on a project on an approved topic and write a dissertation based on this work.

Before the final assessment of the taught component of the MSc programme, all students are considered as MSc candidates. Following the Board of Examiners meeting in June, students who complete the taught component at MSc level proceed to the dissertation stage of the MSc programme. After this time the award of the MSc degree depends only on the achievement of a dissertation mark of at least 50%.

You can either define your own project, in agreement with a member of staff who is willing to act as an Academic Supervisor, or wait until you are being allocated to a project defined by the School. Dissertation topics will be agreed by the end of April. Detailed work will be carried out during the months of June, July, and August, with enough time being allocated to writing up the dissertation. In many cases, the research for the dissertation will involve working with an outside organisation for part of the summer months.

The dissertation will be submitted electronically.

Time management

University regulations require full-time postgraduate students to be in Edinburgh for the duration of the Programme unless specifically granted a leave of absence. This will not be given to enable you to submit a dissertation early in order to return home before the end of the programme. Completing a dissertation in less than the time available is also extremely unwise as early completion may lower the standard of work and presentation.

Backups of dissertations

You are strongly advised to keep a backup draft of your dissertation and not to use a USB flash drive for this purpose since they are easily lost or damaged. No compensation or extension will be given for work or data lost by students. 

Confidential projects

If commercial confidentiality requires that a dissertation be treated as confidential, this can be arranged by informing the office at the time of submission. Confidential dissertations will be read by the Academic Supervisor and examiners, and will not be available for reference. You can collect a copy of the dissertation after the final Board of Examiners meeting in September.  Dissertations are read by two internal examiners before being reviewed by the External Examiner.  

Assessment criteria

All dissertations are expected to conform to the following standards:

• The dissertation must add to the understanding of the dissertation subject.
• The dissertation must show awareness of the relevant literature.
• The dissertation must contain relevant analysis: an informed description of a problem is not sufficient.
• The dissertation must be presented using a satisfactory standard of English.

You should inform your Academic Supervisor and the Programme Director of any factors that will adversely affect your ability to work on your dissertation topic. Special circumstances will be taken into account by the Board of Examiners, but this information must be available before the meeting of the Board. Exceptionally, it is possible for extensions to be granted if justified by illness or other personal problems. This can be done if relevant information is given to the Academic Supervisor or the Programme Director.

Dissertation format

Dissertations are normally expected to be between 10,000 and 14,000 words in length. Reports for the SwDS programme have a limit of 5,000 words for each project.

All should consist of the following:

• Own work declaration
• Abstract (around half a page)

The main text should consist of the following:

• Introduction section
• Final section on conclusions and/or recommendations
• List of all bibliographic references
• Appendices (optional)

Reports should be typeset with single spacing and font size 11 pt . The following minimum margins must be observed: 

The pages in the main text, bibliography, and appendices must be numbered consecutively.

We provide a LaTeX template for dissertations.

We have also additional and more detailed guidelines available as well as the examiner's form .

Good dissertations from previous years 

• Analysing spatiotemporal sensor data on respiration, activity, and air pollution , Meeke Roet (distinction)
• The Firefighter Game , Oleguer Simon Camps (distinction)
• Optimisation of the Outbound Baggage Process at Edinburgh Airport , James Marek (distinction, industry)
• Heuristics for the Multi-Period Sales Districting Problem , Josephine Li (merit)
• Learning the Heterogeneity in Large-Scale Service Systems , Morgan Gallagher (merit)
• A hydrogen refuelling network design - Metaheuristic solution approach , Anqi He (merit)

• Schools & departments

Common Marking Scheme

The University of Edinburgh uses a Common Marking Scheme (CMS) for taught student assessment. The below lays out the interpretation of the general scheme in the context of the School of Informatics, without changing the basic principles.

 Extended Common Marking Scheme – School of Informatics

Information for staff and students.

The University CMS is set out below with brief descriptors clarifying the interpretation within the School of Informatics. The remainder of this document provides guidance on implementation and further interpretation with respect to subjectively assessed work.

Implementation

Within Informatics we use a range of different types of assessment. For some types of assessment (notably, auto-marked assignments where the mark depends only on passing certain tests), it may be difficult to achieve alignment with the above scale. Deviation from the scheme is permitted for individual items of assessment, provided that:

• the assessment in question constitutes a relatively small proportion of the course mark;
• students are advised in advance of the deviation from the CMS, and how marks on this assignment should be interpreted; and
• overall course marks reflect the CMS. That is, as a whole the course assessment appropriately differentiates between students at each level and provides students with the opportunity to demonstrate achievement at the top two levels. At the course level, the ‘work’ referred to in the CMS above indicates the student’s work for the course as a whole, including examinations.

Note that achieving the higher levels of the marking scheme requires work of standard beyond that normally expected for the course. This will usually require the student to demonstrate more advanced attributes, rather than simply an increased volume of work. The assessment must have scope for students to demonstrate such advanced attributes.  This may require a component of the assessment to have a different style, such as more open-ended questions.

Guidance for subjectively assessed work

In addition to the general descriptors above, we include the following more detailed descriptors, which should be used to maintain consistency of marking for subjectively assessed work such as lab and project reports, essays, open-ended questions on assignments and exams, and some larger practical assignments. These are adapted from earlier College guidance (in particular, by adding further guidance regarding software projects) and are indicative of the level of performance expected from students. They are not, however, a checklist of qualities that each student must demonstrate, and not all assessments will cover or consider all of the aspects listed below. The way performance is demonstrated will vary from course to course, and from one mode of assessment to another.

Grade / Mark / Descriptor

A1 / 90-100 / Excellent (Outstanding)

Often faultless. The work is well beyond that expected at the appropriate level of study. See also the guidance above.

A2 / 80-89 / Excellent (High)

A truly scholarly and/or professional piece of work, often with an absence of errors. As ‘A3’ but shows (depending upon the item of assessment): significant personal insight/creativity/originality and/or extra depth and academic maturity in the elements of assessment.

A3 / 70-79 / Excellent

• Knowledge: Comprehensive range of up-to-date material handled in a scholarly and/or professional way.
• Understanding and handling of key concepts: Shows a good command of the subject and current theory.
• Focus on the subject or task: Clear and analytical; fully explores the subject or task.
• Critical analysis and discussion: Shows evidence of deep thinking and/or an appropriately logical and rigorous approach in critically evaluating and integrating the evidence and ideas. Deals confidently with the complexities and subtleties of issues. Shows elements of personal insight/creativity/ originality.
• Literature synthesised, analysed and referenced: Comprehensive grasp of the up-to-date literature which is used in a scholarly way.
• Structure: Clear and coherent showing logical, ordered thought. Additionally for code: likely to support re-use. No unused variables or dead code.
• Presentation: Clear and well presented with few, relatively minor flaws. For writing: Accurate referencing; using the correct referencing system. Figures and tables well-constructed and accurate. Good standard of spelling and grammar. Alternatively for code: well-documented, readable code.
• Design of software or experiments: sensible, with appropriate justification.
• Correctness and robustness: Compiles and executes without errors or warnings. Strong evidence of testing and (if appropriate) optimisation. Correct functionality and robust to unexpected input.

B / 60-69 / Very Good

• Knowledge: Very good range of up-to-date material, perhaps with some gaps, handled in a competent way.
• Understanding and handling of key concepts: Shows a firm grasp of the subject and current theory but there may be gaps.
• Focus on the subject: Clear focus on the subject with no or only trivial deviation.
• Critical analysis and discussion: Shows initiative, the ability to think clearly, critically evaluate ideas, to bring different ideas together, and to draw sound conclusions.
• Literature synthesised, analysed and referenced: Evidence of further reading. Shows a firm grasp of the literature, using good, up-to-date references to support the arguments.
• Structure: Clear and coherent showing logical, ordered thought. Additionally for code: re-usability may be somewhat limited. No unused variables or dead code.
• Design of software or experiments: sensible and usually well-justified, though may have some minor weaknesses or omissions in the justification.
• Correctness and robustness: Compiles and executes without errors or warnings. Some evidence of testing and (if appropriate) optimisation. Robust to unexpected input and largely correct behaviour, perhaps with a few minor bugs.

C / 50-59 / Good

• Knowledge: Sound but limited. Inaccuracies, if any, are minor.
• Understanding and handling of key concepts: Understands the subject but does not have a firm grasp and depth of understanding of all the key concepts.
• Focus on the subject: Addresses the subject with relatively little irrelevant material.
• Critical analysis and discussion: Limited critical analysis and evaluation of sources of evidence.
• Literature synthesised, analysed and referenced: References are used appropriately to support the argument but they may be limited in number or reflect restricted independent reading.
• Structure: Reasonably clear and coherent, generally structuring ideas and information or code in a logical way. Additionally for code: Few or no unused variables or dead code.
• Presentation: Generally well presented but there may be some flaws, for example in figures, tables, referencing technique and standard of English. Alternatively for code: generally well-documented, readable code, but with some weaknesses.
• Design of software or experiments: sensible for the most part but justification may be weak or absent in places.
• Correctness and robustness: Compiles and executes without errors or warnings. Code is somewhat robust to unexpected input and generally shows correct behaviour, but may have a few bugs or be inefficient.

D / 40-49 / Pass (for UG or Diploma)

• Knowledge: Basic; may have factual inaccuracies and omissions.
• Understanding and handling of key concepts: Superficial; there may be some gaps in understanding. Lacks detail, elaboration or explanation of the key concepts and ideas; some may have been omitted.
• Focus on the subject: Addresses the subject but may deviate from the core issues.
• Critical analysis and discussion: Limited or lacking. The arguments and conclusions may be weak or lack clarity with unsubstantiated statements. The emphasis is likely to be more on description than analysis.
• Literature synthesised, analysed and referenced: Basic and limited. May lack appropriate citations and evidence of independent reading.
• Structure: Lacks clarity of structure. Shows poor logical development of arguments or structure of code.
• Presentation: Inadequate; may show flaws in the overall standard of presentation or in specific areas such as figures, referencing technique and standard of English. Alternatively for code: documentation is limited or unclear. Code difficult to read in places.
• Design of software or experiments: shows weaknesses in the design. Justification may be weak or largely absent.
• Correctness and robustness: Compiles and executes without errors or warnings. Code is not robust to unexpected input and generally shows correct behaviour, but may have a few bugs or missing components, or be very inefficient.

E / 30-39 / Marginal Fail

• Knowledge: Poor and inadequate. Content too limited, there may be inaccuracies.
• Understanding and handling of key concepts: Poor and inadequate; does not show sufficient understanding. Concepts omitted or poorly expressed.
• Focus on the subject: Does not adequately address the subject.
• Critical analysis and discussion: Poor and inadequate. May be no real attempt to critically evaluate the work.
• Literature synthesised, analysed and referenced: Poor and inadequate; appropriate literature citations lacking or trivial.
• Structure: A lack of coherence or poor structure.
• Presentation: Overall standard of presentation may be poor. May be problems in specific areas such as writing style and expression (making it hard to follow the content), errors in referencing technique, and poor standard of English (spelling, punctuation and grammar). Alternatively for code: documentation is very limited, code difficult to read.
• Design of software or experiments: flawed design, with little or no justification provided.
• Correctness and robustness: Compiles and executes without errors or warnings, but supports only a limited subset of the functionality required.

F / 20-29 / Clear Fail

• Knowledge: Very poor. Irrelevant or erroneous material may be included. May be very limited in scope consisting, for example, of just a few good lines.
• Understanding and handling of key concepts: Very poor, may be confused.
• Focus on the subject: Does not address the subject.
• Critical analysis and discussion: Extremely limited or omitted. May be confused.
• Literature synthesised, analysed and referenced: Extremely limited or omitted.
• Structure: Confusing or no attempt to order the material in a systematic way.
• Presentation: Writing style and presentation may be unacceptable. Alternatively for code: documentation is very limited or absent, code difficult to read.
• Correctness and robustness: Compiles and executes without errors or warnings, but supports little, if any, meaningful functionality.

G / 10-19 / Bad Fail

• Knowledge: Serious lack of knowledge. Irrelevant or erroneous material may be included.
• Understanding and handling of key concepts: None or trivial evidence of understanding.
• Critical analysis and discussion: May be no coherent discussion.
• Literature synthesised, analysed and referenced: May be omitted.
• Correctness and robustness:  The submitted code is of limited size and cannot be executed.

H / 0-9 / Very Bad Fail

The presented work is of very little relevance, if any, to the subject in question. It is incomplete or inadequate in every respect. A blank answer must be awarded zero.

Schools & departments

Toggle navigation menu Menu

• Student Story (videos)
• Literature Searching This link opens in a new window
• Managing your references
• Subject Guides This link opens in a new window
• Institute For Academic Development - dissertation resources This link opens in a new window
• Cultural Heritage Collections This link opens in a new window
• Digital Primary Sources This link opens in a new window
• The University of Edinburgh
• Subject guides

Dissertations

This guide highlights the help and resources available from the Library to support your dissertation or research project. It also directs you to other support teams that may be useful.

Always check that you are following the requirements provided by your School. 

You can explore the different topics using the left-hand navigation.

Get tips from previous students in Student Story.

Student Story

As you embark on your own dissertation, there is guidance from the Institute for Academic Development (IAD).

Institute for Academic Development

Find out more about literature searching and managing your references. 

Literature Search Managing your references

Explore key resources for your research in Subject Guides.

Subject Guides

Go beyond DiscoverEd and explore collections.

Cultural Heritage Collections Digital Primary Sources

• Dissertation and Thesis Festival

The Library's Dissertation Festival brings together the support that the Library, Digital Skills and IAD provide for students undertaking their dissertations. Dissertation and Thesis Festival Dates for 2023 - 2024 

• Semester 1: Monday 30th October - 10th November 2023 
• Semester 2: Monday 11th - Friday 15th March 2024.

For the programme of events and previous event recordings visit the Dissertation and Thesis Festival webpage.  

For more information please get in touch 

Follow the Library

• Schools & departments

Thesis requirements

The criteria for award.

Award criteria

The criteria for the award of research degrees as set out in the Postgraduate Degree Regulations or otherwise agreed by the Senate Education Committee are that the thesis must:

• Be the student’s own work, except where indicated throughout the thesis and summarised clearly on the declarations page of the thesis, and must not have been presented for any other degree except as specified on the declarations page.
• Present a coherent body of work.
• Make an original and significant contribution to knowledge in the field of study.
• Relate particular research projects to the general body of knowledge in the field and show adequate knowledge of relevant literature.
• Demonstrate critical judgement of the student’s own work and that of other scholars in the field.
• Present the results of the research in a critical and scholarly way.
• Contain material worthy of publication.
• Demonstrate that any publications included in the thesis are the students own work, except where indicated throughout the thesis and summarised clearly on the declarations page.
• Be presented in a clear, consistent and accessible format.

The Institute for Academic Development provides more information and advice on writing up your thesis.

Writing up your PhD

Additional information

More information on thesis submission, including thesis submission forms, is available on the University website.

Doctoral thesis submission

Postgraduate Degree Regulations

School of Social and Political Science

We take considerable care to ensure that our marking is fair and consistent to all students.

Once all coursework submitted for assessment has been marked, all the marks for the whole assignment are moderated by a second member of staff, and a sample is second marked to ensure consistency.

Samples from every course are also sent to an External Examiner, who is an experienced member of staff at another University.

This is to further ensure that our marking is fair, consistent, and equivalent to other UK institutions. The External Examiner also comments on the design and content of the course.

The University has common marking schemes which apply to all programmes at the University: 

Postgraduate Common Marking Scheme

Within the School of Social and Political Science, while applying the University-wide  Postgraduate Common Marking Scheme , we have developed this into more detailed descriptors of the marks/grades, as below: