Ppt Free Templates for Diploma Certificates by bru20228

VIEWS: 71 PAGES: 79

Ppt Free Templates for Diploma Certificates document sample

More Info
									DRAFT Business requirements document (BRD)                       Assessment




EUCLID:
Edinburgh University Complete Lifecycle Integrated Development




DRAFT Business requirements
document (BRD)


Assessment




Document code:         Version 3.1
Author:                JP, LC, JC
DRAFT Business requirements document (BRD)                                       Assessment


DOCUMENT MANAGEMENT

Contributors

 Role              Department                                        Name
 Owner             EUCLID                                            LC
 Contributor       EUCLID                                            JP, JC
 Stakeholders      Schools, Colleges                                 DW, LG, TW, NC,
                                                                     KH, AH

Version Control

 Date             Version     Author              Section   Amendme nt
 2009-04-15       3.1         JP                  2.3.1     Clarif ication added to the
                                                            exam board process table
                                                            regarding release of
                                                            „agreed‟ course results to
                                                            students (highlighted
                                                            turquoise)
 2009-04-15       3.1         JP                  9         Technical clarifications
                                                            added to paragraphs 9.2.4
                                                            and 9.4.4(.1) (highlighted
                                                            turquoise)
 2009-03-26       3.0         JP                  Through   Changes include/comment
                                                  out       on feedback received at
                                                            meeting of 240309 on
                                                            version 2.1 (highlighted
                                                            yellow)
 2009-01-07       2.1.0       JP                  Through   Changes include/comment
                                                  out       on feedback received from
                                                            key stakeholders to version
                                                            2.0

Associated Documentation

 Title                          Author       Notes
 Course assessment              EUCLID       View at:
 pattern set-up, Interim                     http://www.euclid.ed.ac.uk/ed/Key_Docum
 user guide                                  ents/Assessment/CAPSetupWorkshop-
                                             Guide.pdf
 Assessment Milestones as       EUCLID       View at:
 of 1 April 2009                             http://www.euclid.ed.ac.uk/ed/Key_Docum
                                             ents/Assessment/20090218AssessmentMile
                                             stonesForCSCE_V2.4.pdf
 „Handling Special              EUCLID       View at:
 Circumstances‟                              http://www.euclid.ed.ac.uk/ed/Key_Docum
 presentation slides                         ents/SpecCircs-03Feb09-External.ppt
 Assessment Roles               EUCLID       View at:
                                             http://www.euclid.ed.ac.uk/ed/Key_Docum
                                             ents/CollegeRolesTotal.pdf
DRAFT Business requirements document (BRD)                                    Assessment

 Assessment Scope               EUCLID       View at:
 Document                                    http://www.euclid.ed.ac.uk/ed/Key_Docum
                                             ents/AssessmentScope.doc
 Assessment Process             EUCLID       View at:
 Summary                                     http://www.euclid.ed.ac.uk/ed/Key_Docum
                                             ents/Assessment%20Process%20Descriptio
                                             n.doc
 Assessment Frequently          EUCLID       View at:
 Asked Questions                             http://www.euclid.ed.ac.uk/Programme/Su
                                             bProjects/Assessment1.ht m
DRAFT Business requirements document (BRD)                                                             Assessment

CONTENTS

1         INTRODUCTION.................................................................................7
1.1       Background.......................................................................................... 7
1.2       System screens examples ..................................................................... 7
1.3       Tribal developments ............................................................................. 7
1.4       Scope .................................................................................................. 7
1.5       Assessment implementation.................................................................. 7

2         EXAM BOARDS CHANGES: STAGE 1 AND STAGE 2 ...........................8
2.1       Exam board process introduction........................................................... 8
2.2       Exam board process principles .............................................................. 8
2.3       Exam board process academic year table............................................. 10
2.4       Timing of stage 1 and stage 2 exam boards ......................................... 13

3    DEFINITION AND MAINTENANCE OF COURSE ASSESSMENT
PATTERNS .................................................................................................. 15
3.1       Pattern set up .................................................................................... 15
3.2       Timescales for course set up and updates ............................................ 16
3.3       Migration of current course structures ................................................. 17
3.4       The rubric .......................................................................................... 17

4         EXAM REQUIREMENTS DETAILS FOR REGISTRY EXAM SET-UP ... 18

5         COURSEWORK AND EXAMINATION MARKS ENTRY ...................... 20
5.1       Mark entry roles ................................................................................. 20
5.2       Mark entry screens ............................................................................. 20
5.3       Mark entry process ............................................................................. 23
5.4       Mark Scheme Signals.......................................................................... 27
5.5       OPTIONAL use of Barcodes ................................................................. 28
5.6       Checking marks (double entry) ........................................................... 29
5.7       Calculate course results ...................................................................... 30

6         STAGE 1 (COURSE) EXAM BOARDS................................................ 31

7         HANDLING OF SPECIAL CIRCUMSTANCES .................................... 31
7.1       Principles of handling special circumstances cases................................ 31
7.2       Consideration of Special Circumstances reported against an assessment
          component or course .......................................................................... 32
7.3       Storing special circumstances notes at course level .............................. 37
7.4       Undoing AGREED phase 1 course board decisions ................................ 39
7.5       Consideration of Special Circumstances in progression/award decisions 40

8         HANDLING OF ACADEMIC MISCONDUCT....................................... 42
DRAFT Business requirements document (BRD)                                                            Assessment

8.1       Principles of handling academic misconduct ......................................... 42
8.2       Process for recording academic misconduct in EUCLID.......................... 42

9         REASSESSMENT .............................................................................. 43
9.1       Principles ........................................................................................... 43
9.2       Number of re-assessment attempts allowed......................................... 43
9.3       Reassessment type............................................................................. 44
9.4       Reassessment on Honours courses ...................................................... 45

10        SETUP OF PROGRESSION RULES ................................................... 45

11    RUNNING THE EUCLID PROGRESSION /AWARD PROCESS:
INITIAL PROGRESSION/AWARD PROCESSING ....................................... 46
11.1      Principles of the progression process ................................................... 46
11.2      A note on the award process:.............................................................. 47

12   REPORTS, AND PRESENTATION OF REPORTS, FOR STAGE 2
PROGRESSION/AWARD BOARDS .............................................................. 55
12.2      Online interactive presentation ............................................................ 57
12.3      Paper-based presentation ................................................................... 58

13   RECORDING EXAM BOARD DECISIONS AGAINST THE STUDENT
RECORD ...................................................................................................... 58

14    INTERNAL AND EXTERNAL EXAMINERS’ ONLINE CONFIRMATION
OF DECISIONS MADE BY EXAM BOARDS .................................................. 64

15        UNDOING PROGRESSION DECISIONS........................................... 65

16        PROCESSING OF AWARD DECISIONS............................................ 67

17        FAILURE TO PROGRESS/AWARD ................................................... 69

18        COMMUNICATIONS WITH STUDENTS............................................ 69

19        PRODUCTION OF PAPER TRANSCRIPTS FOR GRADUANDS .......... 72

20        ROLES AND RESPONSIBILITIES .................................................... 74
20.1      ASSESSMENT ROLEHOLDER: Assessment Administrator ....................... 74
20.2      ROLE B: Exam board administrator ..................................................... 74
20.3      ROLE B2: Assessment superuser ......................................................... 74
20.4      ROLE C: Registry superuser ................................................................ 74
20.5      ROLE D: Internal (i.e. Board Convenor) and External Examiner ............ 74
20.6      ROLE E: Temporary assessment administrator (Phase 2 Schools) ......... 74
20.7      ROLE F: External examiner input ......................................................... 75
20.8      ROLE G: VS transcript......................................................................... 75
20.9      ROLE H: Input academic misconduct record......................................... 75
DRAFT Business requirements document (BRD)                                                    Assessment

20.10 ROLE I: View/report on academic misconduct ...................................... 75
20.11 Note that a global view only role (excluding restricted data i.e.
      MISCONDUCT records) is being developed across Assessment/Student
      Admin and so is not included here. ...................................................... 75

21       IMPLEMENTATION PLAN ................................................................ 75
21.1     Technical requirements ....................................................................... 75
21.2     Application interdependencies and interfaces ....................................... 75
21.3     Process interdependencies .................................................................. 76
21.4     Security requirements and permissions ............................................... 76
21.5     Backup and Archiving Issues ............................................................... 76

22       REPORTING REQUIREMENTS ......................................................... 77
DRAFT Business requirements document (BRD)                              Assessment


1           INTRODUCTION

1.1         Background
1.1.1       This Assessment BRD covers the business requirements for UG and
            PGT assessment, progression and award processes. Some of the
            information contained in this document has been previously circulated
            and published on the EUCLID website in the Frequently Asked
            Questions, the Assessment Scope Document and the Assessment
            Process Summary document.
1.1.2       This is the third draft of this document, issued following the
            Assessment Business Process Meeting on 24 March 2009. It will be
            discussed again in the April 2009 business process meetings.

1.2         System screens examples
1.2.1       The examples and text on the screens in this document vary. This is
            due to ongoing software changes and developments. The system will
            be subject to further change until the final assessment developments
            are fully implemented in the system.

1.3         Tribal developments
1.3.1       The processing functions expected from Tribal in November 2008 were
            delivered in February 2009. Screen-shots illustrate the screens or
            processing functions associated with the lower levels for course
            assessment set up and calculation are now included in this version

1.4         Scope
1.4.1       The Assessment scope covers the following areas (the full scope
            document is available on the EUCLID website).

       Definition and maintenance of course assessment patterns
       Coursework and examination marks entry

       Calculation of recommended results at course level
       Reports and procedures for boards of examiners
       Recording the outcome of appeals

       Resit assessment
       Annual progression and eligibility to graduate
       Calculate recommendations for awards and classification

       Marks return to students and transcripts
       Recording of registry exam requirements

1.5         Assessment implementation
1.5.1       Schools in the college of science and engineering, plus the School of
            Biomedical Sciences and the Joint Architecture Programme will be
            going into phase 1, which is planned to go live in July 2010.
DRAFT Business requirements document (BRD)                                 Assessment

1.5.2       All other Schools will be in phase 2, for go live June 2011. However
            schools in phase 2 will be required to enter their agreed course marks
            into EUCLID by a specified date (see section 2 below).

2           EXAM BOARDS CHANGES: STAGE 1 AND STAGE 2

2.1         Exam board process introduction
2.1.1       The University‟s academic policy committee (APC 21 May 2008) has
            implemented changes to the exam boards for the next academic year.
            An outcome of these changes is that a common date or dates is
            required to be set by APC for which all final course marks for all UG
            and PGT programmes across the University must be input to EUCLID,
            to allow progression decisions to be made. This is the „Stage 1 results
            publication deadline‟. The mechanism by which this date will be set has
            been raised with Academic Affairs. Schools require this date to be set
            well in advance (by the summer of the year before) to allow Schools to
            agree and publish their exam board dates in programme handbooks
            etc in good time. At each deadline date, all course results for outside
            courses for that period will therefore be accessible by all Schools, who
            can then hold Stage 2 progression/award boards with a full set of
            agreed course results for all their students.

2.1.2       EUCLID will be required to       gather details of the points at which
            progression/award decisions       are made for different programme
            structures (e.g. progression     decisions for PGT may be made at a
            different time of year to UGT)   so that common dates can be set.

2.1.3       In system terms, Stage 1 course results have to be confirmed (i.e.
            „agreed‟) in EUCLID before Stage 2 progression/award calculatio ns can
            be run. Thus students will have access to final (‘agreed’) course
            results before the exam board has confirmed their progression/award
            outcome.
2.1.4       Business users have raised concerns that results have to be released
            to students after Stage 1 course boards, where results may not yet
            been ratified by the full board of examiners. However this does depend
            on the model of external examiner involvement adopted by the
            School/subject area.
2.1.5       The process of releasing results to students is controlled by the
            School/subject area. Only when the Stage 1 exam board has agreed
            the course results as final, and external examiners have signed-off on
            the conduct of the exam board, will the Assessment Roleholder confirm
            („agree‟) the results in EUCLID, thus releasing them to the student.
2.1.6       All marks screens will contain a caveat stating that all marks are
            provisional, subject to decisions of the final exam board meeting.
            University policy and assessment regulations permit (and indeed
            encourage) the release of provisional marks to students as a means of
            providing early feedback on progress.

2.2         Exam board process principles
2.2.1       University policy on assessment administration (board of examiners),
            and College models for boards of examiners, as approved by APC 21
            May 2008, applies:
DRAFT Business requirements document (BRD)                                  Assessment

2.2.1.1     University policy: „Once the EB has agreed individual course marks,
            these cannot be adjusted further at the progression and award stages.‟
2.2.1.2     SCE College model: „Exam boards should only attempt to resolve
            Stage 2 business once all Stage 1 business for a given cohort of
            students is complete.‟ „Exam boards must complete and make
            available course marks from Stage 1 processes by a pre-published
            date.‟
2.2.2       In this context, exam boards have two principle functions:
2.2.2.1     Stage 1: to determine final marks on individual courses under their
            jurisdiction
2.2.2.2     Stage 2: to determine final degree and progression outcomes within
            particular programmes on the basis of the profile of final („agreed‟)
            marks from component courses.
2.2.3       Stage 1 business must be completed and agreed before consideration
            of Stage 2 business can take place.
2.2.4       A Stage 1 outcome should only be recorded as „agreed‟ on the system
            when it has had formal exam board approval.
2.2.5       The role and involvement of External Examiners at Stage 1 and Stage
            2 varies between Schools. Examiners do not have to be physically
            present at all Board meetings: though it would be normal for them to
            be present at meetings in which final Stage 2 ratification takes place.
            There are three approaches for the involvement of External Examiners
            in the ratification of Stage 1 business:
2.2.5.1     The External Examiner attends Board meetings finalising Stage 1
            business and ratifies this then.
2.2.5.2     The External Examiner ratifies Stage 1 outcomes offline once made,
            and might be particularly asked to ratify specific difficult decisions.
2.2.5.3     The External Examiner has a „QA‟ role: commenting on the robustness
            of the processes by which marks are arrived at, but not ratifying
            individual marks.
2.2.6       BOXI reports for Stage 1 and Stage 2 business must include commonly
            used tools for statistical analysis of results so administrators will not
            need to undertake manipulation of results data outside BOXI to
            produce useful exam board reports.
2.2.7       Business users have raised the issue of producing draft
            progression/award reports before Stage 1 course marks have been
            formally „agreed‟ in EUCLID. It will be possible to run a BOXI report on
            „actual‟ course marks. This report will be able to calculate an overall
            raw average mark for the year, on the basis of the actual course
            results presented, and provide standard statistical analysis. However
            the report will not reference the system-held progression and
            classification rules in its calculation. So, averages presented must be
            handled with considerable care and with knowledge of core course
            requirements etc.
2.2.8       Once the Exam Board has agreed individual course marks, these
            cannot be adjusted further at the progression and award stages.
            College guidance allows credit for a fail mark under CAA criteria to be
    DRAFT Business requirements document (BRD)                                                                           Assessment

                    applied at Stage 2, but not at Stage 1. Assessment Regulation 9
                    covers handling of borderline cases i.e:
    2.2.8.1         UG Reg 9.7: The Board of Examiners, in determining final
                    classifications and awards, may exercise discretion by taking into
                    account additional relevant information.
    2.2.8.2         UG Reg 9.13: The Board of Examiners should take account of any
                    personal circumstances and of the student's general academic record,
                    when determining the classification of a Final Honours degree.
    2.2.9           The system allows concessions (e.g. awarding credit where the
                    minimum course pass mark has not been achieved). EUCLID will have
                    to build new EVision screens to facilitate that process.
    2.2.10          In exceptional cases, it is possible to „undo‟ agreed marks, reconsider
                    these and recalculate the course outcome (see section 8.3) but users
                    should be aware that students will already have had access to the
                    original agreed mark.

    2.3             Exam board process academic year table
    2.3.1           The following table represents the detailed Exam Board process over a
                    full academic year, resulting from discussions at the meeting on
                    240309, with notes where appropriate.

TIMELINE      NEW BUSINESS PROCESS STEPS                              NOTES


SEPTEMBER     Semester 1 ICA ‘actual’ marks entered into EUCLID       ‘Actual’ marks CANNOT be viewed by students via
              from September onwards                                  their EUCLID portal


DECEMBER      Semester 1 exam ‘actual’ marks into EUCLID              ‘Actual’ marks CANNOT be viewed by students via
              December/January                                        their EUCLID portal


JANUARY       The administrator runs ‘actual’ marks course board      The BOXI reports can be for a single course, or can
              reports from BOXI, which can be distributed to          bring together all the Sem1 courses for that Year
              course organisers etc in advance of the exam board      group/programme       in   one   report,    with   common
              meeting.                                                statistical analy sis tools at the bottom of each column.
                                                                      This report can include a ‘calculate average’ column at
                                                                      the end of each row, to work out the current average
                                                                      mark for each student. BUT note that this is a raw
                                                                      mark:    it   is   NOT     underpinned     by   programme
                                                                      progression rules, and so should be treated only as a
                                                                      guide.


              Course Exam Board (Stage 1, Sem1) considers             The decision on whether an External Examiner is
              actual course results (including course related SCs).   present depends       on which model of examiner
              Whether with or without External Examiner present,      involvement (see 3.5 above) the School/subject area is
              the Exam Board formally ‘agrees’ the marks as           using.
              ‘final’.


              On instruction of the Exam Board convenor, the          The administrator is NOT making the decision to agree
              administrator runs the ‘agree marks’ process in         the marks in EUCLID. Rather, the administrator is
              EUCLID, making changes to agreed marks as               acting on the instruction of the Board, and undertaking
              decided by the Exam Board where required.               the administrative tasks required to make the changes
                                                                      the board wants.
              Note that the ‘agree marks’ process could be done
      DRAFT Business requirements document (BRD)                                                                         Assessment


TIMELINE       NEW BUSINESS PROCESS STEPS                             NOTES

               live in the Exam Board meeting on screen, so
               ensuring that no input errors are made. Thus the
               Exam Board is in full agreement with the changes
               made on the system before these are released to
               students.


               As soon as the ‘agree marks’ process in complete in    Students will be able to see the overall course mark
               EUCLID, results are released to students through       and top level assessment component marks for each
               their EUCLID portal.                                   course (see the screenshots in BRD, section 19
                                                                      ‘Communicating with students’ for examples.)
               (Alternatively, the student’s role group could be
               defined such that so that only students with an        All results screens will contain a prominent caveat
               ‘agreed’ progression/award status for the current      stating that all results are provisional until ratified by
               year would be able to view their (course) results      the end of year Exam Board (wording to be defined
               through their EUCLID portal. This means the Stage      with business process group), and advisory that
               1 course results can be agreed but cannot be seen      students      should     not   extrapolate      progression
               till after the Stage 2 Board has ‘agreed’ their        decisions/classifications from these results.
               progression/award outcome.)


               If required, the administrator can rerun the full      If any input errors are identified when the report is
               course board BOXI report using the ‘agreed’ marks,     confirmed, the administrator can ‘undo’ the agreed
               to allow them/the Exam Board to confirm the            mark process for that student and then run the ‘agree’
               changes made. Or they can run an ‘exception report’    process again.
               from BOXI which will show only those results where
               the students’ agreed mark is different to the actual
               mark for them/ the Board to confirm.


               Semester 2 ICA ‘actual’ marks entered into EUCLID      ‘Actual’ marks CANNOT be viewed by students via
               from January onwards                                   their EUCLID portal


MAY            Semester 2 exam ‘actual’ marks into EUCLID             ‘Actual’ marks CANNOT be viewed by students via
               May/June                                               their EUCLID portal


MAY/JUNE       The administrator runs ‘actual’ marks course board     The BOXI reports can be for a single course, or can
               reports from BOXI, which can be distributed to         bring together all the courses for that academic year for
               course organisers etc in advance of the Stage 1        that cohort/programme in one report, with common
               course exam board meeting.                             statistical analy sis tools at the bottom of each column.
                                                                      This report can include a ‘calculate average’ column at
               Dependent on local practic e, the administrator can
                                                                      the end of each row, to work out the current average
               also send samples of work with course board reports
                                                                      mark for each student. BUT note that this is a raw
               to the external examiner in advance of the meeting
                                                                      mark:    it   is   NOT    underpinned   by      programme
                                                                      progression rules, and so should be treated only as a
                                                                      guide.


               Stage 1 Course Exam Board considers actual             The decision on whether an External Examiner is
               course results (including course related SCs).         present depends        on which model of examiner
               Whether with or without External Examiner present,     involvement (see 3.5 above) the School/subject area is
               the Exam Board formally ‘agrees’ the marks as          using.
               ‘final’.


               On instruction of the Exam Board convenor, the         The administrator is NOT making the decision to agree
    DRAFT Business requirements document (BRD)                                                                               Assessment


TIMELINE     NEW BUSINESS PROCESS STEPS                                   NOTES

             administrator runs the ‘agree marks’ process in              the marks in EUCLID. Rather, the administrator is
             EUCLID, making changes to agreed marks as                    acting on the instruction of the Board, and undertaking
             decided by the Exam Board where required.                    the administrative tasks required to make the changes
                                                                          the board wants.
             Note that the ‘agree marks’ process could be done
             live in the Exam Board meeting on screen, so
             ensuring that no input errors are made. Thus the
             Exam Board is in full agreement with the changes
             made on the system before these are released to
             students.


             As soon as the ‘agree marks’ process in complete in          Students will be able to see the overall course mark
             EUCLID, results are released to students through             and top level assessment component marks for each
             their EUCLID portal.                                         course (see the screenshots in BRD, section 19
                                                                          ‘Communicating with students’ for examples.)
             (Alternatively, the student’s role group could be
             defined such that so that only students with an              All results screens will contain a prominent caveat
             ‘agreed’ progression/award status for the current            stating that all results are provisional until ratified by
             year would be able to view their (course) results            the end of year Exam Board (wording to be defined
             through their EUCLID portal. This means the Stage            with business process group), and advisory that
             1 course results can be agreed but cannot be seen            students    should     not    extrapolate       progression
             till after the Stage 2 Board has ‘agreed’ their              decisions/classifications from these results.
             progression/award outcome.)


             If required, the administrator can then rerun the full       If any input errors are identified when the report is
             course board BOXI report showing the ‘agreed’                confirmed, the administrator can ‘undo’ the agreed
             marks, to allow them/the Exam Board to confir m the          mark process for that student and then run the ‘agree’
             changes made. Or they can run an ‘exception report’          process again.
             from BOXI which will show only those results where
             the agreed mark is different to the actual mark for
             them/ the Board to confirm.


             STAGE 1 RESULTS PUBLICATION DEADLINE – all course results must be ‘agreed’ in EUCLID

EARLY        by this date
JUNE?, TBC
             Where no outside courses are taken, Schools/subject areas can hold their Stage 2 progression/award exam
             board meetings before this date as well if they wish to. Where a School/subject area‘s programmes include
             outside courses from elsewhere, or has joint programmes, it will not be possible to run their Stage 2 board until
             all those outside course results have been agreed in EUCLID by the owning School/subject area. So the
             deadline needs to be set to facilitate this.


             The administrator runs the ‘c alculate progression           Noted that business process group has asked to see
             outcome’ process in EUCLID, resulting in a system            the exam board processing demo’d so it is easier to
             recommendation for the ‘actual’ progression/award            ascertain how much time is required to prepare for the
             outcome        calculated        from          programme     Stage 2 board if held directly after the Stage 1 board.
             progression/award rules set within EUCLID.                   EUCLID team considering how/when this can be done.

                                                                          BOXI progression/award reports will include the
             The       administrator       runs      the       ‘actual’
                                                                          detailed statistical analysis that exam boards require,
             progression/award BOXI reports in preparation for
                                                                          so that administrators are NOT required to spend any
             the Stage 2 exam board meeting.
                                                                          time manipulating these through excel etc between
    DRAFT Business requirements document (BRD)                                                                                   Assessment


TIMELINE     NEW BUSINESS PROCESS STEPS                                        NOTES

                                                                               board meetings.


             Stage 2 Progression/Award Board (usually with the
             External    Examiner      present)      considers    ‘actual’
             system-generated recommendations. The Exam
             Board      formally    considers        and   ‘agrees’   the
             recommendations as ‘final’ making any changes it
             requires.


             On instruction of the Exam Board convenor, the                    The administrator is NOT making the decision to agree
             administrator runs the ‘agree progression/award                   the outcomes in EUCLID. Rather, the administrator is
             outcome’ process in EUCLID, making changes to                     acting on the instruction of the Board, and undertaking
             agreed outcomes as decided by the Exam Board                      the administrative tasks required to make the changes
             where required.                                                   the board wants.

             Note that this process could be done live in the
             Exam Board meeting on screen, so ensuring that no
             input errors are made, where changes are required.
             Thus the Exam Board is in full agreement with the
             changes made on the system before these are
             released to students.


             The ‘agree progression/award outcome’ process will                It is intended that the progression/award outcome will
             store the student’s final progression outcome/award               not be released on the student results page (where
             and classification in outcome. This outcome will not              course marks are released). The EUCLID team is
             be released to students through their EUCLID portal               investigating   ways   of   enabling     formal   external
             at this point.                                                    examiner ratification of board outcomes to be recorded
                                                                               before progression/award outcomes can be released to
                                                                               students via the EUCLID portal. The business process
                                                                               group will be kept updated on progress.




    2.4           Timing of stage 1 and stage 2 exam boards
    2.4.1         The timing of Stage 1 course exam boards and Stage 2
                  progression/award boards depends on the structure of the
                  programmes for which a particular exam board is responsible, as
                  illustrated in the diagram below.
                                                                               ‘Stage 1 results

                              Actual results available                       publication deadline’                    Progression/award

                                   for local input                           (final course results                    decision publication

                                    to EUCLID                                as agreed by EBs)                             deadline




                                              STAGE 1 Exam Board Meeting
DRAFT Business requirements document (BRD)                                                       Assessment

EB wholly    responsible for    all
courses on their programme(s)


                                                          STAGE 2   Exam Board Meeting




EB requiring results from ‘outside    STAGE 1 Exam Board Meeting
courses’ owned by other subject
areas



                                                                    STAGE 2 Exam Board Meeting




Diagram: Timing of Summer Stage 1 and Stage 2 Exam Board meetings
2.4.2          This diagram refers to „actual‟ and „agreed‟ marks. „Actual‟ marks are
               the raw marks input directly from the student exam script for example.
               The „agreed‟ mark is the post course exam board mark.

2.4.3          Where a programme‟s Examination Board has ownership of all the
               included courses in that programme, the Stage 1 and Stage 2 exam
               boards can be held together as soon as all the required „actual‟ course
               results have been input to EUCLID. Joint Stage 1 and 2 boards can
               take place provided that this happens in advance of the „Stage 1
               results publication deadline‟, to ensure that all final course marks are
               ratified in EUCLID, and thus available to other subject areas through
               EUCLID, by that date.
2.4.4          Where a programme includes outside courses for which its Examination
               Board is not responsible, the Stage 1 course Exam Board must take
               place before the „Stage 1 results publication deadline‟, and the Stage 2
               Progression/Award Board after that date, so that the Stage 2 Board
               has access to all the appropriate course results from other subject
               areas.
2.4.5          Where an Exam Board is responsible for all the courses on a particular
               programme, but some of these courses are taken as outside subjects
               by students from other subject areas, the Stage 1 Course Exam Board
               must take place before the „Stage 1 results publication deadline‟ (so
               that other Stage 2 progression/award boards have access to these
               course results in time for their Stage 2 board meeting.
2.4.6          Even in areas where the Stage 1 and Stage 2 Boards can be held
               consecutively, time will be required between the two stages to allow
               Assessment Roleholder (see Section 20 for role descriptions) time to
               undertake necessary preparation for the Stage 2 Board i.e:

                   Update EUCLID with agreed course results,
DRAFT Business requirements document (BRD)                                 Assessment

               Run the EUCLID progression/award process, and

               Produce BOXI reports for the Stage 2 Board meeting.
2.4.7       The length of time-gap between the Stage 1 and Stage 2 meetings will
            be considerably reduced if updating EUCLID with „agreed‟ course
            results is done live online (by Assessment Roleholder) as decisions are
            agreed in the Stage 1 Course Exam Board meeting.
2.4.8       Note that ALL courses, whether from Schools in phase 1 or phase 2,
            need to have their final agreed course marks in the system by this
            deadline.



3           DEFINITION AND MAINTENANCE OF COURSE ASSESSMENT
            PATTERNS

3.1         Pattern set up
3.1.1       Schools will be able to set up and maintain their course assessment
            patterns in the system (Assessment Roleholder). Tribal, the system
            supplier, has delivered a web-based mechanism for Schools to use.
3.1.2       Full details of how to set up the course assessment patterns are
            available online in the document: „Course assessment pattern set-up,
            Interim user guide‟, and so is not repeated here. You can access the
            user guide online at:
            http://www.euclid.ed.ac.uk/ed/Key_Documents/Assessment/CAPSetup
            Workshop-Guide.pdf
3.1.3       The pattern set-up requires the Assessment Roleholder to input the
            following data:
3.1.3.1     Assessment type (e.g. essay, exam, fieldwork)
3.1.3.2     Course and assessment component mark scheme (e.g. UG common
            marking scheme)
3.1.3.3     Score mark scheme: Score mark schemes will be available to take
            marks out of 1, 5, 10, 20, 25, 100 (i.e. it will not be possible to have
            an assessment that is marked out of 43 for example.)
3.1.3.4     Weighting per assessment component (e.g. Essay 50%, Exam 50%)
3.1.3.5     Course name and code are already in the system.
3.1.4       The setup will be hierarchical as follows; each level can hold a mark,
            either input by the Assessment Roleholder, or system-calculated as
            defined below:
3.1.4.1     Overall course: system-calculated from assessment components
3.1.4.2     Assessment component: input by Assessment Roleholder or system-
            calculated from assessment sections
3.1.4.3     Assessment section: system-calculated from assessment questions
3.1.4.4     Assessment question: input by Assessment Roleholder.
            DRAFT Business requirements document (BRD)                                                                                     Assessment

            3.1.4.5               A fifth level can be formed by grouping component levels as
                                  „Calculation Groups‟, as illustrated by „Exam Group‟ and „ICA Group‟ in
                                  the diagram below:




                                                                                             Course level

                                                                                             Actual course
                                                                                                 mark




                                                          Compon ent level   Compon ent level           Compon ent level            Compon ent level

Assessment Roleh older can i nput marks at                     Exam              Essay 1                      Essay 2               Practical/labwork
these two levels.
                                                            Exam Group          ICA Group                    ICA Group                    ICA Group




                                        Section level                          Section level                             Section level                Section level

                                      Section A: answer                      Section B: answer                      Write-up of practical         Labwork report
                                      1 question from 3                        all 20 MCQs                               demons tration




                Qu estion level        Qu estion level    Qu estion level     Qu estion level                            Qu estion level              Qu estion level

                    Question 1           Question 2         Question 3        1 record to hold                          1 record to hold          1 record to hold
                                                                                  total/20                               mark achieved            mark achieved




            Diagram: Assessment levels in EUCLID

            3.1.5                 The structure allows for weighting of sections, and questions within
                                  each section.
            3.1.6                 Where there are multiple markers of one assignment, BOXI reports can
                                  then be used to draw out the data required for local analysis, i.e. to
                                  compare outcomes for different markers, including statistical analysis
                                  of Max, Min, Ave, SD etc. Details of how this can be done are given in
                                  the final FAQ on the „Recording Marks‟ FAQ page, which you can access
                                  online at:
                                    http://www.euclid.ed.ac.uk/programme/SubProjects/FAQ/Assessme
                                    ntRecordingmarks.htm

            3.2                   Timescales for course set up and updates
            3.2.1                 In alignment with University regulations (Regulation 3), course
                                  assessment patterns should be confirmed prior to student enrolment
                                  on a course. The regulations advise that in exceptional circumstances
                                  where changes are unavoidable after students have entered a course,
                                  College approval must be obtained.
DRAFT Business requirements document (BRD)                                 Assessment

3.2.2       In the new system, courses will be available online (via CCAM) for
            students to view by the April prior to the academic year the students‟
            enrol. Schools are encouraged to have their patterns are finalised prior
            to publication.
3.2.3       Feedback from Schools suggests that changes to components and
            weightings of assessment are often discussed and decided over the
            summer prior to the next academic year.
3.2.4       Prior to students entering a course, the assessment patterns may be
            changed using the standard assessment set up process.
3.2.5       On the rare occasion where an assessment pattern needs to be
            changed after marks have been input, this may result in the marks
            being re-input to the changed assessment structure. Certain
            circumstances can be accommodated without re-entering marks, such
            as where a component of assessment must be discounted and
            weightings of the remaining components adjusted to compensate (and
            future calculations will exclude the discounted component). Such
            changes require College approval and should happen extremely rarely.
3.2.6       It will be possible to extract a copy of the marks from the system using
            a BOXI report before these are deleted from EUCLID, but the
            processes for deleting marks and re-inputting after the course
            assessment pattern has been changed will have to be undertaken
            manually by the Assessment Roleholder.
3.2.7       The risks associated with changing assessment patterns once marks
            have been in put is significant and Schools are strongly advised to
            ensure their assessment patterns are confirmed prior to mark input.

3.3         Migration of current course structures
3.3.1       The EUCLID team has migrated the current course structures held in
            DACS (i.e. the top-level course and assessment component structure)
            into the EUCLID „DEV‟ (development) environment. Key users have
            (March 2009) been given access to the DEV environment to add the
            detailed layers to their course assessment patterns in DEV. This
            information must be thoroughly tested before migrating into the live
            EUCLID environment prior to go live in July 2010.
3.3.2       Key users in Schools currently have online access to EUCLID DEV to
            complete, check and test their assessment patterns using the pattern
            set-up pattern tool.
3.3.3       The project milestone requires that all schools/subject areas to be
            included in Phase 1 will need to have their full course assessment
            patterns input to EUCLID by end of August 2009.

3.4         The rubric
3.4.1       Rules describing a student‟s choice of questions on an examination
            paper (the rubric) will be set up by the Schools (Assessment
            Roleholder) as part of the assessment pattern set up.
3.4.2       The rubric can be described in terms of:
3.4.3       For the whole paper:
3.4.3.1     *total number of questions that may be answered across all sections
DRAFT Business requirements document (BRD)                                   Assessment

3.4.3.2     *minimum number of sections that must be attempted
3.4.3.3     *maximum number of sections that may be attempted
3.4.4       A flag may be set for cases where a student has marks for more than
            the required number of questions from a section or in total, or has
            attempted too many sections. The situation may be handled as an
            error or the best marks up to the allowed total will be counted
3.4.5       For each section of a paper:
3.4.5.1     the minimum number of questions to be answered
3.4.5.2     the maximum number of questions to be answered
3.4.5.3     A flag can be used to note if the section is mandatory

4           EXAM REQUIREMENTS DETAILS FOR REGISTRY EXAM SET-UP
4.1.1       School staff must be able to input the detail of exam requirements
            against each course instance. This might include stationery
            requirements, calculators, whether the exam is common with that of
            other courses, lab requirements etc. In NESI this information is held in
            the EXAM COMPONENT table, and is displayed to users through
            WISARD as in the following examples:




4.1.2       It is anticipated that this data will be input by the appropriate business
            user as part of the course details input and maintenance process.
4.1.3       It is anticipated that EUCLID will build a new EVision screen „Exam
            Component Requirements‟, to allow the user to input this data against
            each course.
4.1.4       The user will access the „Exam Component Requirements‟ screen from
            the appropriate Course Details Summary screen. The mock-up below
            shows how the Exam Component Requirements link might be
            presented (in red box), but the final look of and access to this screen is
            yet to be confirmed:
DRAFT Business requirements document (BRD)   Assessment
DRAFT Business requirements document (BRD)                                 Assessment

4.1.5       The user will click on the appropriate option to add, amend or delete
            exam component requirements and be taken to a new vista where
            they can input the details required.

4.1.6       Deadline dates will be set by Registry by which exam requirements are
            input.

4.1.7       As per existing processes, Registry will send a bulk email message to
            all appropriate users reminding them of the need to input
            requirements to EUCLID by that deadline.
4.1.8       A new BOXI report is required to allow Registry to analyse exam
            requirements for exam set-up. Registry will run this report as per their
            own requirements.

5           COURSEWORK AND EXAMINATION MARKS ENTRY

5.1         Mark entry roles
5.1.1       The mark entry role (Assessment Roleholder A) can be performed by
            any member of staff given permission in the system to enter marks.
            Permission is given by the School.
5.1.2       A mark entry role can be assigned to enter marks for all items of
            assessment for all instances of that course or they can be assigned to
            enter marks for only one item in one instance, or variation of. A mark
            entry role may have permission to enter marks for one question, or all
            components of assessment. Assessment Roleholder is likely to be an
            administrator as current practice. Permission to enter marks can be
            changed by the School as required.

5.2         Mark entry screens
5.2.1       The screen below shows the Assessment link on the left hand
            navigation bar. This will take the user to the assessment processes
            they have permission to access.
DRAFT Business requirements document (BRD)                               Assessment




5.2.2       The screen below highlights the list of assessment processes this user
            has permission to access (note as mentioned earlier that the precise
            phrasing and terminology of these process buttons are subject to
            change).
DRAFT Business requirements document (BRD)                                 Assessment




5.2.3       The screen below highlights the list of courses the user has permission
            to access to enter marks.
DRAFT Business requirements document (BRD)                                  Assessment




5.3         Mark entry process
5.3.1       The screens shown in this draft BRD illustrate the higher level
            components of assessment for mark entry.
5.3.2       The screen above should list all the courses the mark entry role
            (Assessment Roleholder A) has been assigned. Access to the list of
            courses to enter marks for is given by the School.
5.3.3       Where a user has access to a long list of courses, it will be possible to
            search for one particular course to enter marks for, or just to look
            down the list.
5.3.4       Selecting the >>> button(s) will display the required mark entry
            course screen
5.3.5       The components of the selected course are displayed on the screen
            below:
DRAFT Business requirements document (BRD)                                  Assessment




5.3.6       The user can „sort records by‟ using the drop down list of options to
            sort by student name, student number, ascending mark, ascending
            grade, descending grade. The user can also display „unmarked
            students‟ or „all students‟ (i.e. marked and unmarked on that course
            instance) or enter the student number (ID) to select one student only.
5.3.7       Marks can be modified prior to formally being „agreed‟ by selecting „All
            students‟ and returning to the „Enter Assessments‟ option, and re-
            entering and storing the new mark.
5.3.8       Late penalties are outside the agreed scope of the Assessment project
            and will not be handled within EUCLID. Local mechanisms to record the
            outcomes of any late submission will need to be retained. The „actual‟
            mark entered into EUCLID should be the mark after any late penalty
            has been applied i.e. should be the mark the course exam board is to
            consider. Therefore, if local areas have a need to store the mark before
            the late penalty was applied this will have to be recorded locally.
5.3.9       The system can be set to sort by either examination (candidate)
            number or UUN.
DRAFT Business requirements document (BRD)                                Assessment




5.3.10      Marks may be entered for a proportion of students at a time as scripts
            are returned to the office. The user can store („Store Page‟) these
            marks and input more marks later.
5.3.11      The system will automatically calculate the grade at the next stage but
            it may also be input manually. Should an incorrect grade be entered
            the system will produce an error message.
5.3.12      The screen below presents the user with „?‟ to confirm and accept and
            store the grades the system has calculated. („Module‟ here should read
            course).
DRAFT Business requirements document (BRD)   Assessment
DRAFT Business requirements document (BRD)                                  Assessment




5.3.13      The above screen shows an option where marks for two components of
            assessment have been input. These grades are a recommendation,
            defined according to the underlying system mark schemes and this is
            indicated by the ???? marks.
5.3.14      The mark entry screens will allow a much larger volume of students
            and course components to view and enter marks for than is illustrated
            here. An on screen scroll bar will be available for larger lists.
5.3.15      At this stage, „stored‟ (saved) marks may be re-entered and re-saved.

5.4         Mark Scheme Signals
5.4.1       As well as entering numerical marks within a course there needs to be
            some functionality to record other entries. As well as SC , SP and SR
            for special circumstances and AM for actual misconduct, ABS should
            also be recorded against an element of course assessment (not
            necessarily exam questions but is necessary for the total exam mark)
            as well as course assessment components such as essays/mid course
            tests/class exams etc. It is incorrect (and misleading for the Board) to
            leave result fields as blank or to enter in 0 but there does need to be a
DRAFT Business requirements document (BRD)                                  Assessment

            way to indicate where a student has not completed a piece of assessed
            work (not attached to special circumstances).
5.4.2       Flags that need to be recorded against a course result are:
             Pass
             Fail
             Fail (CAA) were credits are awarded on aggregate
             Fail (coursework)
             Fail (exam)
             ABS
             ABS (CAA) indicates Absent credits awarded on aggregate
             Withdrawn
             Not assessed (from the new Exam Board regulations)

5.5         OPTIONAL use of Barcodes
5.5.1       The information here is for those Schools that currently use or wish to
            start using barcodes to support their mark entry processes. The use of
            barcodes is optional.
5.5.2       Anonymous marking (where the marker is not aware of the identity of
            the student) is normal at UoE and is required wherever practicable by
            the Assessment Regulations.
5.5.3       Since anonymous marking involves the use of an identification code
            (normally the examination number), handling of this is often made
            easier and more reliable by the use of barcode stickers attached to
            assessed work.
5.5.4       An assumed prerequisite is that the students are enrolled on the
            course.
5.5.5       Barcode label production will be handled by teaching office secretarial
            staff (Assessment Roleholder A) and can be produced at any time, for
            either a whole class or for an individual student if they enrol after the
            class barcodes have been generated. It is intended that barcodes will
            be generated from the system [via SRLs].
5.5.6       The system will produce a page of barcode labels and these may be
            handed to each student who uses them for work handed in on set of
            courses in a particular subject area.
5.5.7       A page of bar codes may be produced for each student, with a barcode
            label for each item of assessed work.
5.5.8       Barcodes for examinations
5.5.9       A set of barcodes will be produced according to the requirements of
            the exam; there will be variations of the requirements but it will
            typically be one named label and a number of individual barcode labels
            based on the number of script books that are issued in the exam.
            Barcodes will need to be set up to incorporate the “tabtab”
            requirement of data entry.
5.5.10      Timescales
DRAFT Business requirements document (BRD)                                Assessment

5.5.11      Barcodes should be produced early in the teaching period so that they
            are available to students in a timely manner. Some Schools produce
            these in the week prior to Freshers‟ week so that they can be given out
            in Freshers‟ week. Clearly this can only apply to courses which
            currently are compulsory rather than options, unless the barcodes are
            not related to the courses.
5.5.12      Mark entry using barcodes
5.5.13      The use of a barcode scanner (wand) may be used to select students
            (anonymously) for which marks are next to be entered. The user can
            scan the relevant student examination number and the system will
            automatically go to that student. Users may also enter the student
            examination number using the keyboard.

5.6         Checking marks (double entry)
5.6.1       The system holds only an „actual‟ mark (given by the academic
            marker) and an „agreed‟ mark (when confirmed by the Board). Some
            Schools use their current systems to enter marks twice for mark
            checking purposes but the system cannot hold two „actual‟ marks.
5.6.2       Users may view, or print off a report showing all the marks input
            against a particular assessment component. The report can be sorted
            on a range of fields e.g. candidate number, matriculation number,
            surname to compare these against script books, essays or mark
            sheets.
5.6.3       There is no functionality within the SITS software to allow for double
            mark entry for checking purposes. However, the EUCLID team has
            developed a prototype web-based mechanism to facilitate this (outside
            EUCLID), which will be demonstrated at a future assessment
            workshop.
DRAFT Business requirements document (BRD)                                  Assessment

5.7         Calculate course results




5.7.1       Once marks are entered, the course results can be calculated. Course
            results can be calculated for a proportion of students only, if marks are
            not yet available to enter for all students.
5.7.2       Where course marks are „actual‟ i.e. have not been through a course
            exam board, they are not released to the student via their EUCLID
            portal. The Assessment Roleholder will be able to run a BOXI report to
            extract sets of „actual‟ student marks from EUCLID, which can then be
            provided to students outside EUCLID e.g. by posting onto webCT, as
            per current practice.
5.7.3       Once the required assessment marks are entered into the system and
            the course results are calculated, the information is available to
            present to the Stage 1 course exam boards (see section 2 fo r details of
            stage 1 and stage 2 exam boards).
5.7.4       If, for example, a student has a pass in % terms but has not
            demonstrated a particular learning outcome, hence e.g. 45% fail, then
            the student would achieve what is called a „Qualified Fail‟: where a
            particular component or components of the course must be passed
            (e.g. at 40%) for the student to pass the course. This does require
            that the learning outcome is assessed i.e. one assessment requires the
            student to demonstrate that learning outcome in order to pass the
            course.
DRAFT Business requirements document (BRD)                                Assessment

6           STAGE 1 (COURSE) EXAM BOARDS
6.1.1       BOXI reports will be available to produce the required paper copies of
            course exam board reports (see Reporting Requirements). These
            reports will present the „actual‟ marks. The reports will also present
            any special circumstances (flags) for the board to consider.
6.1.2       The „actual‟ marks may be updated to „agreed‟ course marks during
            the meeting; the Assessment Roleholder can access EUCLID online
            during the meeting and agree the marks directly.
6.1.3       When agreeing marks, users must consider that the system‟s current
            default is that „agreed‟ marks are immediately made available to the
            student via their portal.
6.1.4       APC policy of May 2008 states that course marks agreed by the EB
            should not be altered by the progression/award board.
6.1.5       Assessment Roleholder may also update the „actual‟ marks to „agreed‟
            marks on the system after the meeting.
6.1.6       The Board will be required to ratify decisions either on line or on a
            paper copy.

7           HANDLING OF SPECIAL CIRCUMSTANCES

7.1         Principles of handling special circumstances cases
7.1.1       The process for handling of Special Circumstances described below
            follows the requirements of the revised University Special
            Circumstances policy for undergraduate studies as approved by APC on
            21 May 2008. Whilst the policy as there stated applies to UG studies
            only, its general principles were considered by APC as being applicable
            good practice also relevant to the taught postgraduate area.
7.1.2       Colleges have produced guidance on the outcome options for special
            circumstances cases which clarify what actions exam boards can take
            in such cases. The process described below enables Schools to follow
            this guidance. College guidance for the College of Science and
            Engineering can be accessed at:
http://www.scieng.ed.ac.uk/AA/Staff/Taught%20Student%20Admin/Assess.htm
7.1.3       The principles of handling special circumstances cases in EUCLID were
            discussed at the assessment business process group meeting of
            24/03/09, and are as follows:
7.1.3.1     Special circumstances „flags‟ within EUCLID are purely for internal
            processing (supported by note fields), and will not be available to the
            student (who would find out about the outcome from the DoS, as
            currently).
7.1.3.2     There will not be variants of each academic grade (A, B, C, D, E, F)
            indicating where special circumstances have been considered.

            [Explanatory note: the idea of assigning a variant of each grade to
            identify special circumstances (i.e. an ‘A’ grade where special
            circumstances had been considered was recorded as an ‘AS’, a ‘B’ as a
            ‘BS’ etc) was considered but rejected by the group.]
DRAFT Business requirements document (BRD)                                 Assessment

7.1.3.3     There will be no indication of special circumstances consideration in
            either the student‟s EUCLID portal or on their transcript. [Business
            process group required to confirm if this is correct as there was some
            difference in the views expressed in the meeting, with no unanimous
            conclusion.]
7.1.4       EUCLID will allow special circumstances decisions by Stage 1 course
            examination boards and Stage 2 progression/award boards to be
            recorded on the student record.
7.1.5       In most cases special circumstances are considered at course level by
            Special C ircumstances committees (SCC) (for honours level courses)
            or, for pre-honours courses, either before or within the Stage 1 course
            examination boards. Decisions on special circumstances cases are
            made by the exam board. Schools/Colleges will continue to
            operate their special circumstances processes as laid out in the
            appropriate     University    Regulations      and     College-specific
            guidance.
7.1.6       EUCLID will allow users to record the outcomes of special
            circumstances consideration against the student record in advance of
            the SCC/exam board meetings for consideration at those meetings. It
            will also allow special circumstances notes to be added as a „minute‟
            from the SCC/exam board meeting against the student‟s record (i.e.
            during or after the SCC/exam board meeting).
7.1.7       Users will be provided with BOXI reports to show details of special
            circumstances at SCC/exam board meetings, as appropriate.

7.2         Consideration of Special Circumstances reported against an
            assessment component or course
7.2.1       Three special circumstances flags will be implemented at course level:
7.2.1.1     SC: special circumstances to be considered by the Stage 1 EB
7.2.1.2     SP: special circumstances have been considered by the Stage 1 EB and
            action has been taken on marks at course level. This flag can be
            reported to the Stage 2 EB if required.
7.2.1.3     SR: special circumstances have been considered by the Stage 1 EB. No
            The Stage 1 EB has Referred the special circumstances consideration
            to the Stage 2 EB. The Stage 1 EB has not changed marks related to
            these special circumstances.
7.2.2       Example: DoS notifies Assessment Roleholder A that Student „John‟
            was ill and missed the three weeks of a course impacting on his
            coverage of the learning outcomes for the exam assessment
            component. Supporting documentation (medical certificate) provided
            to Assessment Roleholder A and filed securely locally.
7.2.3       Assessment Roleholder A stores the flag „SC‟ in the „Actual Grade‟ field
            against this assessment component for John, indicating that special
            circumstances should be considered by the SCC/Stage 1 Board. Note
            that as John has not yet sat the exam, the SC flag is stored without a
DRAFT Business requirements document (BRD)                                          Assessment

            mark.




7.2.4       When      the   mark     for     the   examination   is   received,   Assessment
            Roleholder A inputs the actual score achieved and                      stores the
            record.




7.2.5       In due course, John‟s scores for the other two assessment components
            are received and Assessment Roleholder A inputs these to EUCLID and
            stores them:




7.2.6       When all the students‟ marks are received and stored in EUCLID, the
            Assessment Roleholder calculates the „actual‟ course mark. The system
            will carry the SC flag from the component to the „actual‟ Course Grade
            as shown below. (Note also that the „Course Result‟ = „D‟, i.e. Deferred
            – a decision on the grade is required for the course to be recorded as
            either a Pass or Fail):




7.2.7       The Assessment Roleholder can then prepare the BOXI reports for the
            SCC/Stage 1 exam board, showing where special circumstances have
            been submitted for consideration, supported by paper documentation
            e.g. medical certificates etc. Note that it is possible to produce this
            BOXI report showing the „SC‟ flag or with that flag hidden, depending
            on the requirements of the Stage 1 exam board.
7.2.8       The BOXI report might contain the elements in the mock-up below
            (Note that the following example has been mocked-up in excel, until
            there is access to BOXI DEV to produce reports in BOXI from this
            data). In this example, the mark to which special circumstances
            consideration needs to be applied is highlighted yellow:
DRAFT Business requirements document (BRD)                              Assessment




7.2.9       If the Stage 1 Exam Board accepts that the special circumstances have
            impacted on the student‟s performance, the board can decide to:
7.2.9.1     Change the course mark (within the limits laid down by College policy
            and University Assessment Regs).
7.2.9.2     Refer the matter to the Stage 2 Board for consideration. (The Stage 1
            Board accepts there are special circumstances but chooses not to
            change the mark because, for example, the special circumstances
            affect more than one course.)
7.2.10      Changing the course mark
7.2.11      In this example, the Stage 1 Exam Board decides to alter the overall
            course mark by 5 points (the maximum allowed) and needs to ensure
            that the Stage 2 exam board is aware that this change has been made.
7.2.12      The Assessment Roleholder confirms the agreed marks in EUCLID, and
            makes the change to the mark overall course mark as agreed by the
            exam board. The Assessment Roleholder:
7.2.12.1 Changes the „actual‟ grade from „SC‟ to „SP‟ (special circumstances
         aPproved) on whichever assessment components it applies to , so that
         there is an internal flag to show what action has been taken. This will
         carry through to the „actual‟ overall course mark. (The student cannot
         view the „actual‟ mark through EUCLID.)
7.2.12.2 Confirms the „agreed‟ grade for the assessment component to reflect
         the mark achieved, rather than „SP‟ (otherwise the „SP‟ would be seen
         by the student in their portal).
7.2.12.3 Updates the Agreed mark in the „Course Result‟ by adding 5 points as
         agreed by the exam board, and manually updates the grade to D.
7.2.12.4 Adds an SCC note to confirm the action taken.
7.2.12.5 The result of these actions is shown on the screen below:
DRAFT Business requirements document (BRD)                                 Assessment




7.2.13      One outstanding issue to be considered by the business process group
            (but in line with College SC policy) is that the results achieved by the
            student do not arithmetically add up to the overall course mark
            achieved, and there will be nothing on the student‟s view of their
            record to say why. (At its last meeting, the Assessment BP group
            decided that special circumstances flags should not be viewable via the
            student portal view.)
7.2.14      The Assessment Roleholder can then prepare the BOXI reports for the
            Stage 2 exam board, showing what action has been taken in regard to
            special circumstances.
7.2.15      The BOXI report might contain the elements in the mock-up below
            (Note that the following example has been mocked-up in excel – it is
            not intended that this is how an EB report would look, it is just to
            provide a view of the main elements that relate to SCs – until there is
            access to BOXI DEV to produce reports in BOXI from this data).
7.2.16      In this example, the signal to show that special circumstances
            consideration was given by the Stage 1 EB is highlighted yellow:




7.2.17      Referring the special circumstances consideration to the Stage
            2 EB
DRAFT Business requirements document (BRD)                                Assessment

7.2.18      In this example, the Stage 1 Exam Board refers the matter to the
            Stage 2 Board for consideration. The Assessment Roleholder needs to
            ensure that the Stage 2 Board is alerted to this referral.
7.2.19      The Assessment Roleholder confirms the agreed marks in EUCLID.
            These are unchanged from the „actual‟ marks as agreed by the exam
            board. The Assessment Roleholder:
7.2.19.1 Changes the „actual‟ grade from „SC‟ to „SR‟ (special circumstances –
         mark unchanged, Refer to Stage 2 EB) on whichever assessment
         components it applies to, so that there is an internal flag to show what
         action has been taken. This will carry through to the „actual‟ overall
         course mark. (The student cannot view the „actual‟ mark through
         EUCLID.)
7.2.19.2 Confirms the „agreed‟ grade for the assessment component to reflect
         the mark achieved, rather than „SR‟ (otherwise the „SR‟ would be seen
         by the student in their portal).
7.2.19.3 Updates the „agreed‟ grade in the „Course Result‟ to D.
7.2.19.4 Adds an SCC note to confirm the referral.
7.2.19.5 The result of these actions is shown on the screen below:




7.2.20      The Assessment Roleholder can then prepare the BOXI reports for the
            Stage 2 exam board, showing what action has been taken in regard to
            special circumstances.
7.2.21      The BOXI report might contain the elements in the mock-up below
            (Note that the following example has been mocked-up in excel – it is
            not intended that this is how an EB report would look, it is just to
            provide a view of the main elements that relate to SCs – until there is
            access to BOXI DEV to produce reports in BOXI from this data).
7.2.22      In this example, the signal to show that special circumstances
            consideration has been referred to the Stage 2 EB is highlighted
            yellow:
DRAFT Business requirements document (BRD)                                Assessment




7.3         Storing special circumstances notes at course level
7.3.1       Storing special circumstances notes at course level can be done at any
            point after students‟ assessment records have been generated.
7.3.2       The recommendations from Special Circ consideration can be made by
            the SCC before the exam board meeting, or considered formally as
            part of the board meeting, dependent on University policy, College
            guidance and local practice. So, any notes (or, where appropriate,
            recommendations made by the SCC) may need to be recorded in
            EUCLID before the Stage 1 exam board. These can then be reported to
            the Stage 1 exam board.
7.3.3       The Assessment Roleholder therefore requires access to an e:Vision
            version of the Student Course Minutes screen to be able to input notes
            at any stage in the process prior to the Stage 1 exam board. EUCLID
            will build an e:Vision version of the Student Course Minutes (SMM)
            table for creation of special circumstances etc records at any point
            after the students‟ assessment records have been generated.
7.3.4       The user can access the Student Course Minutes screen through the
            EUCLID „Assessment‟ container, as illustrated below:




7.3.5       The user will then be able to choose which cohort of students (or which
            individual student) records they want to update from the retrieval
            screen, by inputting the appropriate retrieval criteria. The student‟s
            „sortname‟ (e.g „Pass JD‟) can be added to this screen as a retrieval
            criteria field as an alternative to using the student‟s UUN:
DRAFT Business requirements document (BRD)                                 Assessment




7.3.6       And can then view and update any existing records, or add new notes
            against the appropriate student course record:




7.3.7       The „Notes type‟ [ANT table] is „SC‟: Special circumstances.
7.3.8       A BOXI report will be provided to display any existing notes for
            consideration of the special circumstances committee meeting, and/or
            for the exam board: by student or by course as appropriate to fit with
            the local committee‟s process.
7.3.9       The Assessment Roleholder can also [current EVision functionality]
            input the outcome of consideration of Special C ircumstances by the
            Stage 1 course examination board, when processing the course marks
            (i.e. as agreed by the exam board)‟, by adding notes to the „Course
            Minutes‟ box in the „Course Mark Entry‟ screen (see screenshot below):
DRAFT Business requirements document (BRD)                              Assessment




7.3.10      Note that the „Course Minutes‟ section on this screen is simply a
            different representation of the Student Course Minutes records, as
            shown in above. Any notes stored here will be stored as a Student
            Course Minutes record and so can also be viewed by directly accessing
            the student‟s records through the „Add or update Student Course
            Minutes (SMM)‟ option described above.

7.4         Undoing AGREED phase 1 course board decisions
7.4.1       Exceptionally, AGREED course marks may be undone. But note that
            having been „agreed‟, these marks will have been made available
            to the student.
7.4.2       „Undo course results‟ enables the original AGREED, post-exam board
            mark, to be removed from the student‟s record and then reprocessed.
            The system logs the number of times that a student‟s marks are
            undone and by whom.
DRAFT Business requirements document (BRD)                                  Assessment




7.4.3       This will not alter the ACTUAL (i.e raw) mark as achieved by the
            student, only the mark AGREED by the exam board.
7.4.4       The student‟s view of their agreed mark will then be updated to the
            new agreed mark. It is important therefore that the notes field is used
            to store the rationale for any change to previously agreed mark, so
            that this rationale is available should the student ask why this was
            done.

7.5         Consideration of Special Circumstances in progression/award
            decisions
7.5.1       The University‟s policy on Special Circumstances, as approved by APC
            21 May 2008, states that: „Once the exam board has agreed individual
            course marks, these cannot be adjusted further at the progression and
            award stages… However, the coding of the nature and the treatment of
            the SC for each course should be brought to the Board considering the
            relevant Programme outcomes [as, for example] the board may
            consider the fact that some SCs have occurred in part consideration of
            borderline degree classification.‟
7.5.2       So, the Stage 2 board may still have to consider how to proceed in any
            particular case and requires access to all relevant information to do so.
            The BOXI reports prepared for the Stage 2 EB as described earlier in
            this section will allow that consideration.
7.5.3       The Assessment Roleholder will also be able to store notes from Stage
            2 EBs against the student‟s record in EUCLID, providing explanation of
DRAFT Business requirements document (BRD)                                 Assessment

            changes to the progression/award decision made on the basis of
            specific concessions/special circs awarded earlier, as required.
7.5.4       The note field provides the location for the remaining special
            circumstances recording flags requested by the business process group
            i.e:
7.5.4.1     „SY‟: to show that the progression decision/degree classification has
            been adjusted for Special Circumstances. (To provide a rationale for
            the course results not adding up to the final mark/ classification.)
7.5.4.2     „SN‟: to show that the progression decision/degree classification has
            NOT been adjusted for Special Circumstances. (To provide
            confirmation that the Board had been informed of, and considered, any
            special circumstances but decided not to alter the mark/classification.)
7.5.4.3     Note that the flag code can be supplemented by a further free-text
            note in that field if required.
7.5.5       To enable this, two free-text fields will be added to the Evision
            progression screen, „More details‟ by Tribal as they are not currently
            accessible there. As this is a program screen, Tribal build will be
            required to facilitate this. The mock up shown below demonstrates how
            this might be done.
DRAFT Business requirements document (BRD)                                  Assessment




7.5.6       Assessment Roleholder will thus be able to record the rationale for
            Stage 2 Board decisions against the student record and could, for
            example, report on this information later by running BOXI reports as
            per their own subject area‟s requirements.



8           HANDLING OF ACADEMIC MISCONDUCT

8.1         Principles of handling academic misconduct
8.1.1       Current University policy, University regulation and College guidance
            for handling cases of alleged/actual academic misconduct remain in
            force.
8.1.2       The process of dealing with cases of alleged academic misconduct is
            not part of a student record system. Therefore, the current processes
            for handling cases of academic misconduct at School, College and
            University level will remain outside the EUCLID system. Only proven
            cases of academic misconduct should be stored on the student record.
8.1.3       The record of actual academic misconduct is held on the student
            record for two reasons:
8.1.3.1     To allow those administering the misconduct procedures for a
            particular student to know of any previous occasions on which the
            student has been found guilty of academic misconduct. (This is
            because it affects whether the subsequent stage can be considered at
            School or College level.)
8.1.3.2     To allow Schools/Colleges to report on cases of academic misconduct.
8.1.4       The Assessment Business Process meeting on 240309:
8.1.4.1     Agreed on the need for a common mechanism for recording proven
            academic misconduct in EUCLID that would be used across the
            University
8.1.4.2     Agreed that only actual academic misconduct should be recorded on
            EUCLID, there will NOT be any flag for „alleged offence‟.
8.1.5       Access to view/input/report on academic misconduct should be limited:
            it should not be part of the core Assessment Administrator roles:
            separate role groups are required (added to „Roles‟ section).

8.2         Process for recording academic misconduct in EUCLID
8.2.1       There has been considerable offline discussion about whether the flag
            should be attached to the student‟s assessment record to which the
            offence applies, or whether the record should be held outside the
            assessment component (i.e. against the student record).
8.2.2       The following process proposal is based on the outcome of those
            discussions and that at the BP meeting on 240309.
8.2.3       Where academic misconduct is being investigated, a flag of „RD‟ (result
            deferred‟) can be stored in the „actual‟ grade field (in a similar way to
            the special circumstances are applied) against the component/course
DRAFT Business requirements document (BRD)                                  Assessment

            record to which it applies. This ensures that exam boards are aware
            that there is an investigation underway.
8.2.4       The RD flag can be replaced by the appropriate grade when the
            investigation is completed.
8.2.5       The remainder of the process will be undertaken outside the EUCLID
            system, following current University policy and College guidance.
8.2.6       The result of the process will be recorded against the student record,
            only if academic misconduct is proven.
8.2.7       EUCLID to define where this flag will be held. [One option is to add a
            new SPD record: with new PDT type of „MISCONDUCT‟. This can be
            PDT password protected, and role group limited?]
8.2.8       Four flags are required to be used to record proven academic
            misconduct against the student record for reporting purposes. [In this
            scenario, the flags would be manually input by the user into the note
            field on the SPD record. Or a drop-down list showing only the four
            flags could be applied to a UDF field?] The flags that have been
            suggested are:
8.2.8.1     „SW‟ School warning: „Poor Scholarship‟ which for the first occasion can
            be handled at School level by the School Academic Misconduct Officer
            (SAMO) without reduction of marks
8.2.8.2     „CW‟ College warning: Plagiarism confirmed but not sufficiently serious
            to merit a penalty reduction of marks
8.2.8.3     „CR‟ College reduction of marks
8.2.8.4     „CD‟ College refer to Discipline Committee.



9           REASSESSMENT

9.1         Principles
9.1.1       Where re-assessment is permitted, a prerequisite is that the exam
            board has made its decisions on the first assessment attempt.
9.1.2       Reassessment mark schemes, for honours and pre-honours, will be set
            up by EUCLID in the system prior to go live.
9.1.3       Reassessment mark schemes for those PGT programmes which permit
            resits of courses (usually collaborative or distance learning
            programmes e.g. MSc in System Level Integration), will be set up by
            EUCLID in the system prior to go live. EUCLID will be required to
            gather details of all such instances, early detail from business users is
            welcomed.
9.1.4       The system will also manage re-assessment for students taking
            honours courses towards the award of ordinary or general degrees.

9.2         Number of re-assessment attempts allowed
9.2.1       At present there is no University standard on this, though for UG pre-
            honours 4 attempts over 2 diets is widely used.
9.2.2       Within EUCLID, Markschemes are used to determine the number o f
            reassessment attempts allowed, depending on the level of study (e.g.
DRAFT Business requirements document (BRD)                                  Assessment

            UG pre-honours, UG honours, PGT) and type of programme the
            student is on.
9.2.3       EUCLID proposes that, where reassessment attempts are allowed
            (primarily pre-honours courses), the second attempt (i.e. first
            reassessment) record will be automatically created by the system, at
            the point where the first attempt fail is confirmed („agreed‟) by the
            exam board in EUCLID.
9.2.4       For attempt three the student will need to be re-enrolled on the course
            (or onto an agreed alternative course, as per the programme DPT) in
            the next academic year. The fourth attempt would be generated
            automatically if attempt three is failed. Re-enrolment is a manual
            process that will be undertaken by the SSO/DoS as appropriate. This
            ensures that, where a student is carrying additional course(s) whether
            as full attendance or exam only, their subject area/School can easily
            see from their record the total actual study-load the student is carrying
            in any one academic year.
9.2.5       Where a student does not sit the reassessment at the first attempt
            within the same academic year this can be marked as „absent‟, and the
            student will need to be re-enrolled on the course (or on an alternative
            course) in the next academic year. Re-enrolment is a manual process
            that will be undertaken by the SSO/DoS as appropriate.

9.3         Reassessment type
9.3.1       The reassessment is set at assessment component level (i.e. one level
            below the overall course mark). Thus a student is only required, by
            default, to resit those components of the course they have failed .
9.3.2       The reassessment should contribute the same weighting to the course
            outcome as the original assessment component did, though the name
            of the reassessment can be changed (e.g. practical lab report failed at
            attempt 1 could be reassessed as an essay for attempt 2, due to the
            difficulty of rerunning labs over the summer period).
9.3.3       Example: the course assessment pattern is made up of 3 pieces of
            coursework (A, B and C), 1 design portfolio and 2 exams. Each
            assessment component has a qualifying mark of 40%. Student X
            achieves 10% in coursework B. This mark is agreed by the exam
            board. A reassessment record is generated for Student X for
            coursework B. All other marks are stored until the f inal mark can be
            recalculated after the reassessment has been submitted.
9.3.4       Assessment components can be joined together as a „Qualifying Set‟.
            This allows the School/subject area to record the component marks
            making up part of a course assessment pattern (e.g. 30% coursework)
            without having to apply a minimum pass/qualifying mark to each
            assessment component within the set. Here, the student does not
            need to achieve the Qualifying Mark for the individual components, but
            must gain it as an overall mark for the Set. If the student fails the
            Qualifying Set, reassessment records are only created for the
            assessment component(s) that have been failed within the Qualifying
            Set, not for the full Set.
9.3.5       Example: the course assessment pattern is made up of 3 pieces of
            coursework (A, B and C), 1 design portfolio and 2 exams. The 3 pieces
DRAFT Business requirements document (BRD)                                  Assessment

            of coursework are recorded as a Qualifying Set with an overall
            qualifying mark of 40%. Student X achieves 20% in coursework B, but
            gains good passes in the other 2 courseworks and passes the
            Qualifying Set. No reassessment record is generated.

9.4         Reassessment on Honours courses
9.4.1       University Assessment Regulations permit reassessment of Honours
            courses for some professional/vocational programmes (e.g. nursing,
            education, social work) where students must pass core courses to gain
            the required professional accreditation. (Though it is the first attempt
            mark that is used in the classification calculation, not the resit mark.)
9.4.2       A separate markscheme is required to support these programmes,
            based on the standard Honours markscheme but allowing an
            incremental reassessment.
9.4.3       Under exceptional circumstances Honours students on other
            programmes may be allowed a resit for Honours courses. The Honours
            markscheme accommodates this by allowing a non-incremental resit
            (i.e. a repeat of the first attempt) where special circumstances merit it.
9.4.4       Where a student fails Honours courses without special circumstances,
            and is required to transfer to an Ordinary degree, they can resit
            Honours courses as part of the Ordinary degree.
9.4.4.1     To facilitate resit of an Honours course, the Honours markscheme will
            hold a grade of (working title) „FR‟ for „Fail - Resit permitted‟. This
            would be ranked lower in the mark scheme than the standard „Fail‟
            grade and would never therefore be the default outcome. The FR grade
            would have the increment attempt flag set to „Y‟. The corresponding
            „Attempt 2‟ elements of the mark scheme would also be required. Any
            student moved to non-honours and permitted a resit would need to
            have their F grade replaced with FR which would then trigger the resit
            generation. If the decision to move to the non-honours programme is
            made at Stage 2 this would most likely require that the „agreed‟ F
            grade be undone and then „agreed‟ again as FR.
9.4.5       The markschemes in EUCLID can facilitate capping of reassessment
            marks, though it is understood that at least one College has introduced
            a policy to prohibit capping of reassessment marks.
9.4.6       The rest of the reassessment process follows the same procedures for
            standard marks entry and exam board processes.
9.4.7       Registry will be able to download data from EUCLID using BOXI to
            upload into the exam timetabling system. EUCLID will be required to
            develop a BOXI report to support this activity.

10          SETUP OF PROGRESSION RULES
10.1        School/subject area Stage 2 Progression/Award Boards take a decision
            on the progression or final assessment outcome of all UG and PGT
            students. For UG students this decision is made at the end of the
            academic year. For PGT students there is a progression decision during
            the year (usually Diploma/MSc) and a final award outcome at the end
            of the (12 month) academic year.
DRAFT Business requirements document (BRD)                                 Assessment

10.2        University Regulations and individual degree programme regulations
            govern progression and final award outcomes. The Progressions
            Working Group of APC set up in October 2008 is working towards
            streamlining the variation in current progression rules and is now
            expected to report by May 2009.
10.3        As part of its work, the Progressions Working Group of APC is
            considering „elevated hurdles‟ (e.g. where a student must obtain 55%
            average in the JH year to progress to MPhys). The outcome of the
            report will confirm whether or not elevated hurdles may continue to be
            used.
10.4        The progression rules will be set up in EUCLID. EUCLID will make
            progression recommendations for consideration by the School/subject
            area Stage 2 Progression/Award Board. The Progression/Award Board
            then makes decisions which are recorded as the „agreed‟
            progression/award outcome.
10.5        It will not be possible for the system to produce recommendations in
            all cases, for example, where students have undertaken a year abroad.
            In such cases the recommendation will remain blank and users will
            have to input the agreed decision from the progression/award exam
            board meeting.
10.6        All PGT and UG programmes will follow one of the progression rules
            structures to be considered by APC by May 2009.
10.7        The detail of which courses are „Core‟ (Core can be Compulsory or
            Elective) and which are „Options‟ are stored in the programme DPTs
            which have been submitted to EUCLID by Schools as part of the
            EUCLID Curriculum Management Project.
10.8        These mechanisms for flagging courses as core or options, to reflect
            the DPT, effectively allow rules to be established to meet the specific
            progression needs of each programme (as defined by its Board of
            Studies) without the need for individual progression rule profiles to be
            built and maintained for every programme.
10.9        The progression rule profiles will be input to EUCLID in advance of
            golive. Any future changes to the overarching progression rule profiles
            will be approved by APC. For changes to go live in EUCLID, the
            secretary to APC will be required to provide details of these to EUCLID
            support directly following the final APC meeting of the year (i.e. May)
            preceding the start of the academic year to which they apply.
10.10       EUCLID will prescribe the format in which these changes must be
            provided to EUCLID support.

11          RUNNING THE EUCLID PROGRESSION /AWARD PROCESS:
            INITIAL PROGRESSION/AWARD PROCESSING

11.1        Principles of the progression process
11.1.1      „Progression‟, in system terms, will take place between all years of
            any programme including, for example, in Years 1 and 2 of a standard
            UG programme to allow the student‟s enrolment records for the next
            year of their programme to be generated (Note that between the pre-
DRAFT Business requirements document (BRD)                                Assessment

            honours years a progression code of „CONTINUE‟ rather than
            „PROGRESS‟ will be used for clarity.)
11.1.2      EUCLID will calculate automatically where students have failed to make
            adequate academic progress. User intervention will be required to
            enable confirmation of the outcome of progression.
11.1.3      Online calculation and processing of progression/award decisions using
            EUCLID replaces the current system of manual completion of „Registry
            Examiners List‟ (results list), to be signed by internal and external
            examiner, and returned to Registry.
11.1.4      EUCLID will use predefined rules to calculate progression/award
            recommendations which Schools can then take direct to their exam
            boards for approval.
11.1.5      The progression/award calculation will work on the basis of „agreed‟
            marks. It will not calculate on „actual‟ marks. The system generated
            recommendation can be over-ridden manually.

11.2        A note on the award process:
11.2.1      The screenshots below generally refer only to „progression‟, and not to
            „award‟.
11.2.2      The two processes for managing progression and award decisions use
            the same Evision screens in EUCLID.
11.2.3      From the user‟s perspective, the process for recording a progression
            and award decision are the same. The details of the award decisions
            are held in different tables in the background database, but this does
            not impact on how the user will use EUCLID for awarding and agreeing
            award decisions.
11.2.4      Those aspects of the award process that differ from progression
            processing are covered later.
11.2        Pre-requisite: All course level results relevant to the programme
            must be input to EUCLID and „agreed‟ in EUCLID by the Stage 1 course
            exam board by the Stage 1 results publication deadline, so that any
            boards with Stage 2 business (progression/awards decisions) that
            require Stage 1 results from elsewhere, can arrange to meet after that
            date to complete their Stage 2 business.
11.3        Where a student‟s assessment mark is not input, the system will not
            calculate an „actual‟ course outcome. Rather it highlights the lack of
            mark as shown on the screenshot below:
DRAFT Business requirements document (BRD)                               Assessment




11.4        If the mark is missing due to special circumstances, a mark of „0‟ can
            be entered and an „SC‟ flag (see section 8) can be input to the grade
            field. The Phase 1 Business Process Group may wish to consider
            whether a further flag (or flags) of (for example) „Absent‟ („ABS‟) is
            required to identify students who have failed to submit, or failed to
            attend an exam, but where the reason is not known. Thus this could be
            flagged in the course result (see SC example in screenshot below):




11.5        Progression and award functions are run through the standard
            „Progression‟ screens shown below. (Throughout all these screens text
            changes are required to amend „Progression‟ to „Progression/Award‟.)
DRAFT Business requirements document (BRD)                                      Assessment




11.5.1      Initial Progression/Award Processing: Calculate system generated
            progression/award recommendations prior to        the Stage 2
            progression/award board reports being produced
11.5.2      Confirm Progression/Award Processing: „Agrees‟ decisions that
            are made by the Stage 2 progression/award Board, and stores these
            final decisions.
11.5.3      Undo Progression/Award Processing: to correct errors, update
            agreed decisions.
11.6        To commence the progression process, Assessment Roleholder will
            click on the „Initial Progression Processing‟ screen and input the
            required selection criteria to retrieve the appropriate student cohort.
            Not all fields need to be completed on this screen. Standard retrieval
            criteria might usually be:
11.6.1      Year: academic year e.g. 2009/0
11.6.2      (Perhaps) Mode of attendance: e.g. full-time full-year: FTFY
11.6.3      Programme: degree programme code from a list
11.6.4      Block: two-digit numerical value to define the point at which the
            student is in their programme of study. For example for a FTFY UG
            student a Block of „21‟ would indicate they are in their second year of
            study, following the standard route.
11.6.5      A full list of Block codes with definition will be provided in training.
11.7        Each School should be provided with a BOXI report/list which names
            all the degree programmes (with codes) held within a „Subject‟ on
            EUCLID. Sometimes Assessment Roleholder will want to retrieve
            information one programme at a time, but sometimes (e.g. for speedy
            initial progression processing between Stage 1 and 2 exam board
            meetings) they may require to retrieve and process all of the students
            on any programme within a subject area in one process.
DRAFT Business requirements document (BRD)                                                                  Assessment




11.8            EUCLID will implement the following text changes to the „out of the
                box‟ screens shown on these screenshots, to match UoE terminology:
11.9            Text changes under first section „Selection Criteria - Enrolment Details‟

Current label                                           New label

Text: ‘Enter the criteria to select the SCE records…’   Enter the criteria to select the student records…

Student Course Join                                     UUN

SPI Status                                              Progression status




11.10           Text changes under second section „Selection Criteria - Course Details‟

Current label                                           New label

Text header: ‘Selection Criteria - Course Details’      Selection Criteria - Programme Details

Text: ‘Enter the criteria to select the SCE records…’   Enter the criteria to select the student records…

Course                                                  n/a: remove/hide this field

Programme                                               Subject

Course group                                            n/a: remove/hide this field

Faculty                                                 College

Occurrence                                              Start month
DRAFT Business requirements document (BRD)                                                     Assessment


Route                                            Programme

Course Type                                      n/a: remove/hide this field

Department                                       School


11.11           Text changes under third section „Progression Processing‟

Current label                                    New label

Text : ‘… view the list of selected SCEs and…’   ‘… view the list of selected students and…’

Button: ‘Process SCEs’                           Button: ‘Process students’

Button: ‘View SCEs’                              Button: ‘View students’

11.12           Assessment Roleholder can choose to „Test Process‟ first before
                actually processing the records, bringing up the following screen. This
                screen is purely a confirmation screen for users i.e. the green box at
                the top confirms what has happened.
11.13           The remainder of the screen is a blank template of the progression
                screen. Users may find this confusing but, as „out of the box‟ software,
                this cannot be changed. (This is therefore a training issue.)




11.14           Assessment Roleholder can then click on „View students‟ button which
                provides a view of the tested scenario:
DRAFT Business requirements document (BRD)                                                             Assessment




11.15           It has been requested that full names of the students be brought
                forward – not initials. However, this is a Tribal process screen and so
                we may not be able to add/change columns. This will be investigated
                and will be done if it is possible.
11.16           It is possible that two students might even have the same forename
                and surname, so using the UUN (listed on this screen as the „Student
                Course Join code‟) is the best way to ensure the unique identity of any
                student.
11.17           The following text changes to the „Progression Calculation - View SCEs‟
                screen are required:

Current label                                          New label

Text: ‘…SCEs…’, used throughout the screen in header   ‘…student…
area and body sections

Column header: ‘Student Course Join Code’              UUN

Column: ‘SCE sequence’                                 n/a: delete/hide this column

Column: ‘Course’                                       Replace this column with one headed ‘Programme’ giving
                                                       the ROU

Column header: ‘Occurrence’                            Start month
DRAFT Business requirements document (BRD)                                Assessment

11.18       Assessment Roleholder then selects which students they wish to
            process (can be a one, a selection, or all of those on list), moving
            those records into the „Selected‟ list:




11.19       The resultant screen requires the same text changes as listed above.
11.20       Assessment Roleholder can then run „Calculate Progression‟ in „Trial‟
            (to test the process without altering the status of the records) or
            „Calculate‟ (which will run the full process against the records) mode.
            Either mode will bring forward the following process screen. User notes
            at the top of the screen are self-explanatory.
DRAFT Business requirements document (BRD)                                                                Assessment




11.21           The following text changes to the „Progression Calculation - Results‟
                screen are required:

Current label                                             New label

Text: ‘…SCEs…’, used throughout the screen in header      ‘…student…
area and body sections

Column header: ‘Student Course Join Code’ or ‘SCJ code’   UUN

Column: ‘SCE sequence’                                    n/a: delete/hide this column

Column: ‘Course’                                          Replace this column with one headed ‘Programme’ giving
                                                          the ROU

Column header: ‘Occurrence’                               Start month

Column header: ‘PIT code’                                 Recommendation


11.22           The „Messages‟ section at the end of the screen provides the detail of
                the system calculation used to reach the „Outcome‟.
11.23           Where a recommendation cannot be made for any student, the student
                details remain in the first container „Selected students‟. Assessment
                Roleholder can then go back to the individual student assessment
                records to review what information is missing for this student (e.g. a
                missing course mark) and update the record if required to allow
                processing to take place.
DRAFT Business requirements document (BRD)                                  Assessment

11.24       The signal of ABS would allow a calculation, that flag would be
            highlighted and the user could allow it or override it manually as
            appropriate.
11.25       When all students have been successfully processed, Assessment
            Roleholder will use BOXI to run the required reports in preparation for
            the Stage 2 progression/award board meetings.
11.26       To assess the time required between the stage 1 and stage 2 parts of
            a EB meeting, and whether this is manageable, it is agreed that
            running a mock EB will be the best way to test this. The EUCLID team
            have to consider when this can be done (given current problems with
            DEV BOXI reporting).

12          REPORTS, AND PRESENTATION OF REPORTS, FOR STAGE 2
            PROGRESSION/AWARD BOARDS
12.1.1      Stage 2 progression/award boards determine final degree and
            progression outcomes for particular programmes (APC 21 May 2008).
12.1.2      Stage 2 boards need to see the overall profile of results for courses,
            not the components within courses: it is assumed that the course (and
            component) results have already been signed-off by the Stage 1
            course exam board.
12.1.3      Final undergraduate classification boards need to see the overall profile
            covering two years (and even three years, for taught undergraduate
            Masters programmes in CSCE and for the MA Fine Art).
12.1.4      Assessment Roleholder will use BOXI to run the required reports in
            preparation for the Stage 2 progression/award board meetings.
            EUCLID will provide standard BOXI report templates for each stage of
            the examination board process. A School requiring a non-standard
            report will be able to copy the standard BOXI report and adapt this by
            (for example) adding further field columns from the EUCLID
            assessment universe to meet any specific local requirements.
12.1.5      The detail of content, structure, data fields etc for these reports is
            given in BRD Appendix 3 – „Reporting requirements‟. For the Stage 2
            progression/award board meetings, two groups of standard reports will
            be produced. Both will be available in anonymised and non-
            anonymised formats:
12.1.6      „Programme spreadsheet‟: A spreadsheet-style report with students in
            the left-hand column and courses across the page. Retrieval might
            usually be by programme, by year, but can encompass some/all
            programmes in one subject area, as per local requirements. A sample
            (course) report is given below:
DRAFT Business requirements document (BRD)                                  Assessment




12.1.7      The letters in the third column of the above example are the first name
            initial. It would be possible to show full forename instead. Users will be
            able to adapt the generic reports to meet their own requirements.
            Whilst it would be technically possible to include the full course name
            field in this report, it would present the user with significant
            presentation problems. It would be easier to show the full course name
            in the „Programme summary by student‟ report illustrated below.
12.1.8      „Programme summary by student‟: A student-by-student report
            summarising the assessment and progression/award outcome for each
            student. A sample report is given below:
DRAFT Business requirements document (BRD)                                  Assessment

12.1.9      These reports will be printable, but can also be viewed live through the
            MyEd portal using BOXI. So there are two options for reporting student
            assessment data to the exam board:
12.1.10     The BOXI reports can be set up so that any marks that fall within the
            borderlines as stated in the University‟s Assessment Regulations are
            highlighted (e.g. with a colour) to the exam board
12.1.11     Online interactive presentation
12.1.12     Paper-based presentation

12.2        Online interactive presentation
12.2.1      Where School has access to data projector: Assessment Roleholder will
            use BOXI to set-up the required reports in advance of the Stage 2
            progression/award board meetings.
12.2.2      Examination board meetings will have online access to EUCLID and
            BOXI reporting as internet tabs on one PC/laptop in the exam board
            meeting.
12.2.3      The user can display the appropriate BOXI report on-screen,
            presenting the „agreed‟ course results (as ratified by the Stage 1
            course board); the „actual‟ progression/award recommendation (i.e.
            the    system   generated     recommendation);    and    any special
            circumstances etc flags to be viewed by the Stage 2 board. It would be
            usual for members of the board to also be provided with paper copies
            of these reports for reference while Assessment Roleholder is able to
            flick between updating EUCLID and refreshing BOXI reports as
            required.
12.2.4      The user will follow the decisions as made by the board, flicking to
            EUCLID to update student records from „actual‟ to „agreed‟ with any
            changes as required by the board directly onto the LIVE EUCLID
            system. (See section 13 for the detail on how this process is
            undertaken.)
12.2.5      Note that as for „agreed‟ course marks, once marks are „agreed‟ in the
            system, these marks will be immediately available to the student.
            Where required, it would be possible to limit students‟ access to the
            results pages in their portal until. This was discussed in the meeting on
            03/02/09 and will be worked up and presented separately. It is
            anticipated that the maintenance of any such functionality would sit
            with the Schools in question. However this will require additional build
            work to produce the vistas (screens) for Schools to maintain this
            information, which would have to be added to the resource for the
            EUCLID Assessment area.
12.2.6      Assessment Roleholder will „refresh‟ the BOXI reports periodically as
            required on screen. As BOXI represents information from the live
            EUCLID system, the Stage 2 Board will be able to see the agreed
            outcome on each record confirmed, in real time.
12.2.7      The Board will be required to ratify the decisions recorded (see section
            13) below.
DRAFT Business requirements document (BRD)                                          Assessment

12.3        Paper-based presentation
12.3.1      Assessment Roleholder will use BOXI to set-up the required reports in
            advance of the Stage 2 progression/award board meetings, and will
            print out paper copies of these reports for all exam board members.
            The reports will present the „agreed‟ course results (as ratified by the
            Stage    1     course   board);     the    „actual‟  progression/award
            recommendation (i.e. the system generated recommendation); and
            any special circumstances etc flags to be viewed by the Stage 2 board.
12.3.2      As described above, Assessment Roleholder could also access EUCLID
            via laptop, and follow the decisions as made by the board, updating
            student records from „actual‟ to „agreed‟ with any changes as required
            by the board directly onto the LIVE EUCLID system. (See section 13
            below for the detail on how this process is undertaken.)
12.3.3      Alternatively, Assessment Roleholder could take paper notes of
            decisions made by the board for updating to EUCLID immediately
            following the meeting.
12.3.4      The Board will be required to ratify the decisions recorded (see section
            13 below). Following the meeting, Assessment Roleholder would be
            required to update EUCLID with the board‟s decisions, then „refresh‟
            the BOXI reports. These reports can then be reprinted, if required, for
            the Convenor and External Examiner to check. This obviously entails
            some delay before the external examiner can confirm the outcomes
            are as presented in the meeting.

13          RECORDING EXAM BOARD DECISIONS AGAINST THE STUDENT
            RECORD
13.1.1      Stage 2 progression/award boards take decisions about students‟
            progression or classification of award, which may involve changes to
            the system-generated recommendation for individual students.
13.1.2      Stage 2 progression/award boards will be able to confirm or change
            the outcome recommended for progression or classification or final
            result on a student-by-student basis. Reasons for making any such
            changes can be recorded as a general note against the student record
            (see also section 8 above, special circs), as academic appeals often
            relate to clarification of why a board took the decision it did.
            Classifications can also be altered for students who are sitting within
            the borderline as defined in the appropriate UG and PGT Assessment
            Regulations.
13.1.3      EUCLID will be used to confirm the boards‟ decisions by recording the
            „agreed‟ progression outcome or award on the system.
13.1.4      Assessment Roleholder            will   click   on   the   „Confirm   Progression
            Processing‟ option:
DRAFT Business requirements document (BRD)                                                      Assessment




13.1.5          Assessment Roleholder is presented with the „Progression Selection
                Criteria‟ screen.
13.1.6          The following text changes to „Progression Selection Criteria‟ screen
                are required:
Current label                                    New label


Student (SPR) Code                               UUN


Programme                                        Subject


Route                                            Programme


Year                                             Academic Year


Period                                           Semester/Period


PIT code                                         Recommendation


Course                                           n/a: remove/hide this field


Occurrence                                       Start month


13.1.7          Programme (Route) lists should be limited by to College or preferably
                School.
13.1.8          Assessment Roleholder will input the required selection criteria to
                retrieve the appropriate student cohort. Not all fields need to be
                completed on this screen. Standard retrieval criteria might usually be
                (note: revised text terms used here):

               Academic Year’: academic year e.g. 2009/0

               ‘Programme’ (currently Route): degree programme code from a list; or ‘Subject’
                (currently Programme) to access all programmes in one subject.

               ‘Block’: two-digit numerical value to define the point at which the student is in their
                programme of study. For example for a FTFY PGT student a Block of ‘11’ would
                indicate they are in their first year of study, following the standard route.
DRAFT Business requirements document (BRD)                               Assessment




13.1.9      The user may want to use the retrieval screen differently, depending
            on how they are using EUCLID with the Stage 2 Board. For example, if
            using online presentation, they may wish to bring up all students in a
            cohort. If using paper-based presentation and updating the records
            after the board meeting, the user may want to retrieve in groups by
            „Recommendation‟ (PIT code on the screen above) to update the
            record for all students with similar progression outcome together.
13.1.10     Assessment Roleholder clicks on „Retrieve Records‟ and the following
            „Progression Confirmation‟ screen is returned:
DRAFT Business requirements document (BRD)                                                                  Assessment




13.1.11         The following text changes to „Progression Confirmation‟ screen are
                required:

Current label                                              New label


Initial text: ‘If you have changed a PIT code then…’       If you have changed a Recommendation…


Initial text: ‘Use the Confirm button to update the SPI,   Use the Confirm button to update the student’s record
SCE, SPR and SAW records.’                                 with the ‘agreed’ progression/award outcome .


13.1.12         Text changes under sections „Progression Records for Confirmation‟
                and „Global Update‟:

Current label                                              New label


Student                                                    UUN


PIT code                                                   Recommendation


Course                                                     n/a: remove/hide this field
DRAFT Business requirements document (BRD)                                                             Assessment


Occurrence                                            Start month


Prog                                                  Subject


Route                                                 Prog


UDS                                                   Status


13.1.2          Programme („Route‟) lists should be limited by to College or preferably
                School.
13.1.13         Text changes under section „Confirmation‟:
Current label                                         New label


Text: ‘Enter a decis ion date to be held on the SPI   Enter a decis ion date to be held on the progression
records…’                                             records…


13.1.14         Assessment Roleholder can use the „Global Update‟ section to make
                changes to all the records selected, or can do this one record at a time
                using the „>>‟ arrows at the end of the row.
13.1.15         To amend one record at a time, the user clicks on „>>‟ at the end of
                the appropriate row, and the „More details‟ screen is displayed:




13.1.16         The fields displaying the default values for the „Next Programme
                details‟ that would be expected for this student will be hidden, so that
                these cannot be amended by the Assessment roleholder. The user can
DRAFT Business requirements document (BRD)                                                                          Assessment

                 then click on „Update Values‟ to return to the „Progression Records for
                 Confirmation‟ screen and continue to the next student record.
13.1.17          The user can then click on „Update Values‟ to return to the „Pro gression
                 Records for Confirmation‟ screen and continue to the next student
                 record.
13.1.18          The following text changes to „More details‟ screen are required.
13.1.19          Text changes under section „Student‟s Current Details‟:

Current label                                            New label


Student                                                  UUN


Calculated PIT                                           Recommendation


Course                                                   n/a: remove/hide this field


Occurrence                                               Start month


13.1.20          Text changes under section „Next Course/Programme Details‟:
Current label                                            New label


Section header: ‘Next Course/Programme Details’          Next Programme Details


Text: ‘Make your changes. If PIT is changed then the     Text: ‘Make your changes. If you wish to change the
List button should be used to validate the changes and   ‘Agreed Outcome’ the List button must be used to
update the other fields using the information on the     validate the changes and update related fields.’
selected PIT record.’


PIT Code                                                 Agreed Outcome


Course                                                   n/a: remove/hide this field


Occurrence                                               Start month


Prog                                                     Subject


Route                                                    Prog


UDS                                                      Status [or just hide this field? (from users’ perspectiv e)]


13.1.21          The user then clicks on the „Confirm Progression‟ button to store the
                 decisions as agreed by the Stage 2 progression/award board meeting.
                 This will update the background records for the student.
13.1.22          Te process is described here in the order that it happens within the
                 system. In practical terms it is recommended that the internal/external
                 examiner sign-off task (see section 15 below) is undertaken before the
                 „Confirm Processing‟ option is undertaken. Schools will follow local
                 processes to ensure that the approval of the EB and external examiner
                 is secured via the sign-off task before the „Confirm Processing‟ option
                 is undertaken.
DRAFT Business requirements document (BRD)                                 Assessment

13.1.23     The user will receive a confirmation message screen. This screen is
            purely a confirmation screen for users i.e. the green box at the top
            confirms what has happened.
13.1.24     The remainder of the screen is a blank template of the progression
            screen. Users may find this confusing but, as „out of the box‟ software,
            this cannot be changed. (This is therefore a training issue.)
13.1.25     This process can be undertaken either during or after the board
            meeting.
13.1.26     When the „Recommendation‟ has gone through the progression/award
            board and Assessment Roleholder has updated the student‟s record on
            EUCLID with the „agreed‟ outcome, and processed that decision, the
            student will have access to this result through their EUCLID student
            portal (see section „Communication with Students‟).
13.1.27     Completion of the „Confirm Processing‟ option allows students to view
            their agreed results. It is therefore imperative that the „Confirm
            processing‟ option is undertaken with great care and only after the
            Board has reached its final decision, and is happy that the result can
            be released to the student.
13.1.28     So, in EUCLID, the release of information to the student through their
            EUCLID portal is controlled by the exam board, not by Registry. This is
            a change to current practice.
13.1.29     It should also be noted that the online confirmation of results by the
            internal and external examiners (described in section 15 below) is not
            part of the release process: the internal/external examiner sign-off is
            simply confirmation of their attendance at, and agreement with, the
            decisions made by the board to allow later reporting: any disputed
            decisions must be agreed before the „Confirm Progression‟ processing
            option is undertaken.
13.1.30     It would be usual therefore (and this procedure would be enforced by
            Schools as part of their local exam board processes) for the
            internal/examiner sign-off to be undertaken and completed
            successfully before Assessment Roleholder is authorised, by their EB
            Convenor, to undertake the „Confirm Processing‟ option.




14          INTERNAL   AND     EXTERNAL    EXAMINERS’    ONLINE
            CONFIRMATION OF DECISIONS MADE BY EXAM BOARDS
14.1.1      Current University Assessment Regulations require that Internal
            (Convenor of exam board) and External Examiners ratify exam board
            decisions by signing-off paper copies of all exam board decisions
            before these are submitted to Registry for addition to the student
            record.
14.1.2      The following process assumes a change to University regulations to
            allow authorised examiners to sign-off exam board decisions online via
            EUCLID, either on-site (i.e. at UoE) or off-site if required.
14.1.3      The online sign-off of results by the internal and external examiners is
            simply confirmation of their attendance at, and agreement with, the
            decisions made by the board to allow later reporting. It is not part of
DRAFT Business requirements document (BRD)                                  Assessment

            the process for release of results to students: any disputed decisions
            must be agreed before the „Confirm Progression‟ processing option is
            undertaken.
14.1.4      A new task will have to be built to support this process, the details of
            which (i.e. screens etc) will be provided in due course. The process will
            be the same for internal examiners (i.e. Convenors of Exam Boards)
            and External Examiners.
14.1.5      Assessment Roleholder will have the option of uploading docs to the
            task: i.e. to upload the exam board reports that the examiner is
            responsible for, in order that they can satisfy themselves that the
            results are those they approved at the Board meeting.
14.1.6      As required, Assessment Roleholder can run a BOXI report to identify
            which examiners have signed-off which programme instances with the
            date of sign-off.
14.1.7      If any further follow up is required (i.e. if an examiner has not
            responded) this should be done by Assessment Roleholder or the Exam
            Board Convenor phoning the examiner directly to elicit the quickest
            response possible.

15          UNDOING PROGRESSION DECISIONS
15.1.1      It would be unusual to „undo‟ a progression decision. However, in
            exceptional circumstances, it may be that Assessment Roleholder has
            to „Undo‟ and reprocess some progression decisions after they have
            been agreed by the progression/award board. This could be because
            retrospective special circumstances come to light for a particular
            student after the decision has been approved. Or as a result of a
            successful appeal, or under Assessment Regulation 9.19.
15.1.2      When considering the „Undo‟ process, Assessment Roleholder should
            be aware that the „agreed outcome‟ will already have been displayed to
            the student via their student portal.
15.1.3      The „undo‟ process is, therefore only suitable where there are genuine
            reasons for change: if there is any doubt about a decision for a
            student, it should not be confirmed in the first place.
15.1.4      Assessment Roleholder will access the „Progression – Undo Task
            Processing‟ option from the Assessment homepage:




15.1.5      Returning the „Progression Selection Screen‟, where the user can input
            their required selection criteria:
DRAFT Business requirements document (BRD)                                                Assessment




15.1.6          The following text changes to „Progression Selection Screen‟ are
                required.
Current label                                New label


Student (SPR) code                           UUN


Prog                                         Subject


Route                                        Prog


PIT Code                                     Agreed Outcome


Course                                       n/a: remove/hide this field


Occurrence                                   Start month


UDS                                          Status (or may delete – does not aid user)


15.1.7          When the user „Retrieves‟ the „Progression Task/Undo Processing‟
                screen is presented. The following text changes are required:

Current label                                New label


Student code                                 UUN


PIT Code                                     Agreed Outcome


UDS                                          Status (or may delete – does not aid user)


15.1.8          The user can select the appropriate records and „undo‟ the selected
                records, or choose current page, or „All‟. This will remove the „Agreed
                outcome‟ from the student‟s record.
DRAFT Business requirements document (BRD)                               Assessment




15.1.9      On clicking „Undo Records‟ a confirmation message screen is returned.
            This shows the new listing, with any „undone‟ records having been
            removed.
15.1.10     The „agreed outcome‟ (Agreed PIT) field becomes blank, ready for
            Assessment Roleholder to re-process the students‟ records.
15.1.11     The „agreed outcome‟ will also be removed from the student view in
            their EUCLID portal, as the portal only displays agreed outcomes.
            When a new outcome has been agreed and processed, the new value
            will show in the portal.
TW: Does the system maintain an auditable trail where decisions have been
undone?
EUCLID note: Yes.


16          PROCESSING OF AWARD DECISIONS
16.1.1      The processing of award decisions uses the same screens as the
            progression process. From the user‟s perspective, the process for
            recording a progression and award decision are the same. The details
            of the award decisions are held in different tables in the background
            database, but this does not impact on how the user will use EUCLID for
            awarding and agreeing award decisions.
16.1.2      The user will follow the process described earlier to prepare awards
            information for the progression/award board meetings, and to confirm
            „agreed‟ outcomes in EUCLID during/after the board meeting.
16.1.3      The programme set-up held in EUCLID will define the point at which
            the student becomes eligible for an award.
16.1.4      The progression and award rules define the potential outcomes for the
            student.
DRAFT Business requirements document (BRD)                                 Assessment

16.1.5      Eligibility for an award is recorded in the „Recommendation‟ column
            (column currently labelled „PIT code‟) on the screen shot below.
16.1.6      The „messages‟ section on this screen does show the user what award
            calculation has been done, and the award title and classification of
            award have been made for each student. To populate the messages
            section, the user must click on the „>>‟ button at the end of the row
            for the student.




16.1.7      However the messages section is only able to show the details for one
            student at a time. Tribal is currently working on developments to
            include the award name and classification as new columns on each
            student row, so that this information is easily viewable by the user for
            the full group of students together. It is anticipated that this
            development will be released by Tribal by May 2009.
16.1.8      When the „Recommendation‟ has gone through the progression/award
            board and Assessment Roleholder has updated the student‟s record on
            EUCLID with the „agreed‟ outcome, and processed that decision, the
            student will have access to this result through their EUCLID student
            portal (see section Communication with Students). It is therefore
            imperative that the „Confirm progression/award‟ option is undertaken
            with great care and only after the Board has reached its final decision.
16.1.9      So, in EUCLID, the release of information to the student through their
            EUCLID portal is controlled by the exam board, not by Registry. This is
            a change to current practice.
16.1.10     It should also be noted that the online confirmation of results by the
            internal and external examiners (described in section 13) is not part of
            the release process: the internal/external examiner sign-off is simply
            confirmation of their attendance at, and agreement with, the decisions
            made by the board to allow later reporting: any disputed decisions
DRAFT Business requirements document (BRD)                                       Assessment

            must be agreed before the „Confirm Progression‟ processing option is
            undertaken.

17          FAILURE TO PROGRESS/AWARD
17.1.1      A review process is required where a student does not achieve the
            required credits to progress to the next year of their programme, or to
            gain the anticipated award i.e. where the student has failed to make
            satisfactory progress.
17.1.2      The decision-making process in such cases will take place outside the
            EUCLID system. Schools/Colleges already have their own processes for
            handling such students in line with University Regulations, for
            discussing   options  with    such   students    and    for   making
            recommendations on the way forward for such students.
KH: Can EUCLID ensure that a BOXI report is set up which will allow reports to
be created showing all students who fail to achieve the minimum required credits
for progression?
EUCLID note: Yes. Noted.
17.1.3      EUCLID will flag that a student has failed to achieve satisfactory
            progress, enabling this to be drawn to the attention of the exam board,
            and for the review process to start.
17.1.4      EUCLID will also be used to store the outcome of the School/College
            review process on the student record.
17.1.5      The EUCLID team will undertake further analysis with business users
            to identify the full range of review outcomes required.

18          COMMUNICATIONS WITH STUDENTS
18.1.1      Communication with students will be primarily through the student‟s
            EUCLID portal, either by:

          Intray messages to the student’s personal EUCLID portal intray.

          Display of assessment information in the student’s ‘My Programme’ container.

18.1.2      The screen below shows a mock up of (roughly) how this data might
            be displayed from the student‟s EUCLID portal „Home‟ page:
DRAFT Business requirements document (BRD)                             Assessment




18.1.3      When the student clicks on the container option „My course results‟
            they are taken to the „Progress and Course Results‟ screen. The
            student can choose to view this one year at a time (e.g. just their
            current year), or for „all years‟ of their programme. Note that the
            screen now shows course name as well as course code [internal note:
            manual hts change].




18.1.4      Any course results or progression/award decisions will only be shown
            to the student when these have been through the result or
            progression/award „Confirmation‟ process i.e. results must be
            confirmed through EUCLID before they will be viewable by students.
DRAFT Business requirements document (BRD)                               Assessment

            (The confirmation process must be run after the relevant exam board
            meeting has approved all the decisions made.)
TW: If students will get their results online – and (given a specific date for the
completion of stage 1) for the most part will be expecting course results on
approx the same day – the likely result in very high numbers of students logging
on at the same time that many assessment A roleholders and Internal and
External examiners are logged in. Can you provide some reassurance that the
system will have sufficient capacity and resilience to cope with this while
maintaining the speed that exam boards will need?
EUCLID note: part of the reason for the one-year extension to the EUCLID
project is to ensure that the University‟s IS infrastructure cope effectively with
expected traffic at peak times.
18.1.5      The student can access further details from the „Progress and Course
            Results‟ screen.
18.1.6      By clicking on the course code, they will be taken to the published
            course details as submitted to EUCLID by the owning School (part of
            the CCAM process):




18.1.7      By clicking on the „>>>‟ button at the end of a row on the „Progress
            and Course results‟ screen, they will be taken to the „Result
            Information‟ screen. This screen provides the student with a
            breakdown, to course assessment component level, of the
            assessments that form that course and any results achieved.
DRAFT Business requirements document (BRD)                                      Assessment




18.1.8      Though by default the system enables only agreed (post Exam Board
            marks) to be released, a process will be made available to staff to
            make available interim marks to students.
18.1.9      The following paper communications will also be required:
           Formal transcripts on completion of programme: see section 19 below.
           Interim transcripts/student reports: at the end of a Semester or study
            period, and/or at the end of each academic year
           Year end/award results lists: traditional (anonymised) paper list for
            posting on student notice boards in Schools, produced via a BOXI
            report.



19          PRODUCTION OF PAPER TRANSCRIPTS FOR GRADUANDS

Registry is responsible for the production of official transcripts for most UoE graduates.
Guidance on when transcripts are produced for students and the charges that apply can be
found at:

http://www.registry.ed.ac.uk/AwardConfirmation/Transcript_Product_Information.htm
19.1.1      Current practice requires Registry to download graduand data from
            DACS into a locally maintained Graduation Database. This database is
            used to support organisation of graduation ceremonies and to produce
            transcripts.
19.1.2      It is intended that transcripts for all students on UG and PGT
            programmes who will be „current‟ when EUCLID assessment goes live
            in July 2010 will be produced directly from EUCLID, as part of the
            Assessment project.
19.1.3      At present, Registry cannot produce transcripts for some areas as the
            required detailed results information is not held in DACS.
DRAFT Business requirements document (BRD)                                   Assessment

19.1.4      Where historical data for graduates is not being migrated to EUCLID,
            then the current arrangements for production of transcripts will
            continue i.e. if transcripts have had to be produced locally as the
            required level of detail is not in DACS, then any requests from past
            graduates for transcripts will have to be managed as per current
            processes (as described on Registry webpages).
19.1.5      As all current/future student assessment results will now be held in
            EUCLID, transcripts for future graduates for all UG and PGT areas will
            be derived from EUCLID.
19.1.6      Detail of the arrangements for different groups will be discussed with
            Registry staff and the outcomes recorded.
19.1.7      Transcripts for Visiting Students (VS) are produced locally by College
            Offices. It is intended that this arrangement continues and that College
            Offices be given functionality to produce these transcripts as required
            via EUCLID. VS transcripts are required at the end of each semester of
            study. The first transcripts for Visiting Students to be produced from
            EUCLID will be required for January 2011, reflecting study undertaken
            by VSs in Semester 1 of 2010/11 academic year.
19.1.8      Note: Organisation of graduation ceremonies, production of European
            Diploma Supplements (EDS) etc will be considered within the scope for
            the EUCLID Graduation Project.
19.1.9      Users will access transcript production functionality via an option in the
            eVision „Assessment‟ container:




19.1.10     The detailed content of transcripts will be developed in line with
            Registry requirements. Further analysis will be undertaken to identify
            any specific requirements for VSs (UG and PG).
DRAFT Business requirements document (BRD)                                 Assessment

20          ROLES AND RESPONSIBILITIES
NOTE: More than one person could perform each role, and one person could perform
more than one role.
Note for business process group. From the last meeting, it appears we need to
revisit the split of responsibility between roles A and B in particular. These have
not been changed below at this point.

20.1        ASSESSMENT ROLEHOLDER: Assessment Administrator
               Input assessment component/question marks
               Run „calculate course marks‟ process
               Exam board secretary for Stage 1 and/or Stage 2 Boards
               Prepare exam board reports (BOXI)
               Run „progression‟ process
               Input exam (stationery) requirements (so that Registry can set up
                examinations)
               Set up course assessment patterns

20.2        ROLE B: Exam board administrator
               Send sign-off task to external examiners
               Confirm exam board decisions in EUCLID.

20.3        ROLE B2: Assessment superuser
               Set-up assessment roles for other staff within the same School.

20.4        ROLE C: Registry superuser
               Sends reminder emails to Role groups in advance of particular
                deadlines (e.g. graduation deadline
               Accesses and downloads exam requirements data and graduand
                information to local systems
               Prints official transcripts.

20.5        ROLE D: Internal (i.e. Board Convenor) and External Examiner
               Only requires a EUCLID portal intray, to allow them to receive and
                complete examiner „sign-off‟ task after attendance at Board
                meetings (on or off-site)

20.6        ROLE E: Temporary assessment administrator (Phase 2
            Schools)
               Limited assessment administrator for administrative staff in Phase 2
                Schools during 20010/11 academic year to allow them to:
               Input course level mark and progression/award decisions directly
                into EUCLID after these have been agreed by their exam board
                meetings.
               Input exam (stationery) requirements (so that Registry can set up
                examinations). Note that this task may be undertaken by the CCAM
                Proposer Role.
DRAFT Business requirements document (BRD)                                 Assessment

20.7        ROLE F: External examiner input
               Input external examiner details (Approval process via College office
                is outside EUCLID)

20.8        ROLE G: VS transcript
               Run transcripts for VS

20.9        ROLE H: Input academic misconduct record
               Inputs „MISCONDUCT‟ record to student‟s SPD table
               Password protected

20.10       ROLE I: View/report on academic misconduct

20.11       Note that a global view only role (excluding restricted data i.e.
            MISCONDUCT records) is being developed across
            Assessment/Student Admin and so is not included here.



21          IMPLEMENTATION PLAN

21.1        Technical requirements

21.1.1      Process interdependencies Other systems
[Provide an overview of related local systems that will be retained following
implementation, giving detail about why the system is to be retained; w hat data and
processes will be included, and any timelines attached to the life of the system].
21.1.1.1 SMART – College of Science and Engineering Assessment system
21.1.1.2 SMART is used by 4/5 Schools in Science and Engineering. The
         intention is to retain this as a contingency during Phase 1. (Will
         Informatics and Engineering & Electronics also be able to retain their
         systems similarly?)
21.1.1.3 Some EUCLID development will be needed to ensure that a data load
         from EUCLID to SMART can be achieved should the processes in
         EUCLID fail.

21.2        Application interdependencies and interfaces
[Detail inputs from other applications, and any outputs to other applications. Each
interface will require an interface business requirements document.]

21.2.1      Assessment Pattern Migration Interface
21.2.1.1 For phase 1 (College of Science and Engineering, plus Biomedical
         Sciences and Joint Architecture programmes), the Schools involved
         have substantial local systems for assessment.
21.2.1.2 Discussions on the best mechanism for migrating assessment patterns
         held in existing systems is ongoing.
DRAFT Business requirements document (BRD)                                Assessment

21.3        Process interdependencies
[Detail changes to existing processes within the scope of EUCLID, or any impacts on
processes within the scope of EUCLID still to be developed.]

21.3.1      CCAM – Course Creation, Approval and Maintenance
21.3.1.1 Assessment processes cannot run without courses being up to date
         with MOD and MAV correctly set up, since course assessment records
         (MAP, MAB etc) depend on these.

21.3.2      Preparation for PCAM (Programme migration) – Programme details
21.3.2.1 Details of programmes must be correctly set up in the system to allow
         progression rules and award rules in assessment to be set up.

21.3.3      Student Administration – Student records
21.3.3.1 To allow assessment to be used, student records must be set up
         correctly with appropriate SMO records.
21.3.3.2 The student assessment records should (probably) be set up as part of
         the enrolment process, but configuration for this is part of the
         Assessment project.

21.4        Security requirements and permissions

21.4.1      Specify high-level security requirements, including:
               Authorisation levels (plus roles and access required)
               Authentication (e.g. EASE)
               Internal/external access
21.4.1.1 A high level of security is generally required around the assessment
         process.
21.4.1.2 External examiner access via envision (EASE authenticated) will
         (probably) be required for validation of Examination Board decisions.

21.5        Backup and Archiving Issues
21.5.1      Assessment involves the generation of huge numbers of records.
21.5.2      The overall course results should be archived very long term, since
            they will be needed for student transcripts.
21.5.3      Marks for principal components of assessment below the level of
            course results should be retained for a moderate period so that
            Schools can use these for QA, trend monitoring, etc.
21.5.4      Marks at a detailed level (e.g. exam question marks) need only be
            retained for a short period (e.g. the period during which students are
            allowed to appeal results). UG assessment regulation 16.5 states “Only
            in special circumstances may an appeal from a visiting or final year
            student or graduate be considered more than six weeks after the
            results of an examination have been available to the appellant”.
DRAFT Business requirements document (BRD)                                          Assessment


22            REPORTING REQUIREMENTS
A = Anonymised, E= Exam number order, R= rank order, N= Non anonymised
(named), S= Students number order


[Detail reports required, including statutory reporting requirements. For each report
listed here, a report specification should be completed.]

 Re port title         Format         Used for?                   Priority   Data items
 Course reports        [SRL/BOXI]                                            [Item 1]
 Class list                           Course organiser /
                                      secretary for general use
 Assessment mark                      To identify students with
 missing                              a missing mark for a
                                      single assessment




 Exam Board
 reports
 Course,
 anonymous
 Course                               Generic course report,
 spreadsheet (AE)                     anonymised, one line
                                      per student, exam
                                      number order,
                                      assessment elements
                                      across the page
 Course                               Generic course report,
 spreadsheet (AR)                     anonymised, one line
                                      per student, rank order,
                                      assessment elements
                                      across the page
 Course summary                       Generic course report,
 by student (AE)                      anonymised, grouped by
                                      student, exam number
                                      order, assessment
                                      elements down the page
                                      for each student
 Course summary                       Generic course report,
 by student (AR)                      anonymised, grouped by
                                      student, rank order,
                                      assessment elements
                                      down the page for each
                                      student
 Course, named
 students
 Course                               Generic c ourse report,
 spreadsheet (NA)                     non-anonymised, one
                                      line per student,
                                      alphabetical surname
                                      order, assessment
DRAFT Business requirements document (BRD)                                         Assessment

 Re port title         Format         Used for?                   Priority   Data items
                                      elements across the
                                      page
 Course                               Generic course report,
 spreadsheet (NR)                     non-anonymised, one
                                      line per student, rank
                                      order, assessment
                                      elements across the
                                      page
 Course                               Generic course report,
 spreadsheet (NS)                     non-anonymised, one
                                      line per student, student
                                      number order,
                                      assessment elements
                                      across the page
 Course summary                       Generic course report,
 by student (NA)                      non-anonymised,
                                      grouped by student,
                                      alphabetical surna me
                                      order, assessment
                                      elements down the page
                                      for each student
 Course summary                       Generic course report,
 by student (NR)                      non-anonymised,
                                      grouped by student,
                                      rank order, assessment
                                      elements down the page
                                      for each student
 Course summary                       Generic course report,
 by student (NS)                      non-anonymised, one
                                      grouped by student,
                                      student number order,
                                      assessment elements
                                      down the page for each
                                      student
 Programme,
 anonymous
 Programme                            Generic programme
 spreadsheet (AE)                     report, anonymised, one
                                      line per student, exam
                                      number order, course
                                      results across the page
 Programme                            Generic programme
 spreadsheet (AR)                     report, anonymised, one
                                      line per student, rank
                                      order, course results
                                      across the page
 Programme                            Generic programme
 summary by                           report, anonymised,
 student (AE)                         grouped by student,
                                      exam number order,
                                      course results down the
                                      page for each student
DRAFT Business requirements document (BRD)                                         Assessment

 Re port title         Format         Used for?                   Priority   Data items
 Programme                            Generic programme
 summary by                           report, anonymised,
 student (AR)                         grouped by student,
                                      rank order, course
                                      results down the page
                                      for each student
 Programme,
 named students
 Programme                            Generic programme
 spreadsheet (NA)                     report, non-anonymised,
                                      one line per student,
                                      alphabetical surname
                                      order, course results
                                      across the page
 Programme                            Generic programme
 spreadsheet (NR)                     report, non-anonymised,
                                      one line per student,
                                      rank order, course
                                      results across the page
 Programme                            Generic programme
 spreadsheet (NS)                     report, non-anonymised,
                                      one line per student,
                                      student number order,
                                      course results across the
                                      page
 Programme                            Generic programme
 summary by                           report, non-anonymised,
 student (NA)                         grouped by student,
                                      alphabetical surname
                                      order, course results
                                      down the page for each
                                      student
 Programme                            Generic programme
 summary by                           report, non-anonymised,
 student (NR)                         grouped by student,
                                      rank order, course
                                      results down the page
                                      for each student
 Programme                            Generic programme
 summary by                           report, non-anonymised,
 student (NS)                         one grouped by student,
                                      student number order,
                                      course results down the
                                      page for each student

								
To top