The agreed requirements will be implemented in three tranches, April, May and June 2013.

Transcription

1 1 erecruitment BUSINESS REQUIREMENTS The erecruitment system was launched (Phase 1) on 8 October 2012 and following feedback from Users requirements for Phase1b have been agreed and prioritised with the Project Board and User Group. Project Board and User Group Membership The agreed requirements will be implemented in three tranches, April, and Functional Requirements 1 Recruiter Experience Usability 1.1 There should be no need for the Originator to select the University of Edinburgh from the default company field when creating the staff request. The preference would be for this field to be hidden. 1.2 There should be no need for the Originator to select the Cost Centre for the hierarchy on the Staff Request. The preference would be for this field to be hidden.

2 1.3 The Originator should enter the following data on the staff request; - Advertiser Contact name (free text) - Advertiser Contact number (numeric free text) - Advertiser Contact (free text) - Closing Date in Weeks (drop down 1,2,3,4) These fields would need to be created on the staff request form and feed in to the back office. The new fields will need to be available in the views. 1.4 Validation is required on the advertising details section of the staff request. 1. If a recruiter selects Post is Required to be Advertised then it should not be possible to submit the staff request without also entering advert text AND further particulars. 2. If a recruiter selects Post is not required to be advertised or Post is 6 months or less Ad not required, then there is no need to enter advert text, further particulars or to select an application form. 1.5 When creating the staff request, if an Originator opts for the option Other from the list of Advertising Publications, the text that is entered in to the free text box should feed from the staff request to the Vacancy Details section in the back office. 1.6 The recruitment system should be able to issue a notification to the system administrator that an Originator has used the option other. The notification should include the data entered in to the free text field, so that the system administrator can add this value to the picklist and create the advertisers profile. Page 2 of 9

3 1.7 The recruitment system should calculate the end date of any positions created as fixed term duration. If fixed term duration is selected then when the start date is entered in the back office the Fixed term duration in months should be used to determine the end date. The calculated end date should be viewable in the target end date field of the appointments screen in the Back Office. The assumption is that by populating the target end date that no update is required to the views. If this assumption is not correct then the views will also need updated as this data is required for contracts. Existing validation requiring the recruiter to enter a duration if the post is fixed term is to be retained. Any changes to the way the data is held or input needs to take this in to consideration. 1.8 On the staff request the originator should select the Fixed Term Duration (in Months) from two picklist (years and months). This would remove any issue with originators entering non numeric values in this field resulting in error with the end date calculation. 1.9 The field contract end date should be hidden from all screens in the back office. This field is not used by UoE and has led to confusion due to a similar field which is mandatory When the Recruiter is accepting web applicants to the Back office the select all button should reset between vacancies. Currently the button does not reset and remains as deselect all following the update action. This is a bug already known to Core The Recruiter should be able to view a history of any notifications that have been sent via the back office to an applicant. It is understood that this is possible through the applicant details screen in the back office, but that there is a bug in the current functionality or a configuration setting requires to be updated Any Pdf s generated by the recruitment system should include a divider between applications for ease of reading. April There is a separate requirement (see Section 4.2) that covers the overall need to replace the existing PDF software. Page 3 of 9

4 1.13 Approvers should have the ability to access approved staff requests that have been approved or rejected by another approver in their department. This could be similar to a My Approved list for their department. This would allow approvers who do not approve a staff request to view if the request has been approved or rejected regardless of whether they actioned the approval/rejection. 2 Recruiter Experience Further Particulars and Standard Wording 2.1 The Recruiter should have the option to format the text of the further particulars when creating the Staff Request. This would allow the recruiter to format text with; Immediate using HTML Headers (i.e. larger font) (Desirable) Bold (Mandatory) Italics (Desirable) Standard Bullets (Mandatory) Numbered List (Mandatory) 2.2 The recruitment system should display Urls/links to the Applicant as active where input by the Recruiter in the Further particulars or standard wording. It is understood that the requirement can be met without incurring significant costs by: Training all relevant users in how to obtain the required formatting and active URLs via an HTML editor, or; Reverting to the Core standard functionality of attaching a word document to the advert. The word document would contain all further particulars information and a short description would be displayed as the advert text. (see Oxford for example obspec?p_id=106364) It has been agreed that a trial of the HTML editor option will be undertaken. No system changes are required at this time. Immediate using HTML Page 4 of 9

5 3 Equality and Diversity 3.1 The Applicant enters their initials when establishing their applicant profile in the personal details section of the applicant portal. The value entered by the applicants should be the value populated in the views, back office or recruiter portal. Although the Applicant is specifically asked to enter initials for their forename and middle name only, these values do not currently feed into the views. At present, the system determines the initials from the applicant s first name and surname and this is fed into the views. As a result the notifications are set up with surname only, while the preference is for Initials and Surname. 3.2 If a Recruiter uses the applicant search functionality in the Back Office they should only be returned a list of applicants for vacancies attached to their area. 4 Recruitment Training Flag There is a requirement to display whether a member of staff has completed recruitment training and, as a result, is suitable as an interview panel member. The Recruitment Training flag needs to be reportable and therefore available in the views. 4.1 A system administrator should be able to confirm whether an Interview Panel user has completed Recruiter training on the personal profile details in the back office. This data should be available in the views for reporting purposes. 4.2 A system administrator should be able to confirm whether an Interview Panel user has completed Equality and Diversity training on the personal profile details in the back office. This data should be available in the views for reporting purposes. Page 5 of 9

6 5 Applicant Experience 5.1 Formatting of Application History Screens to better align statements and responses. 5.2 An Applicant should have the ability to clear the response to an Additional Question should they select the incorrect response. Alternatively, there should be an option for N/A should the applicant need to remove the selection. For example, where a previous questions response has indicated that no response is required to a following question if selected by mistake there should be the option to clear this error. Successful Applicant interface should be updated to not ignore N/A if selected. 5.3 Applicant s should have the option to select a Daily Update notification of all vacancies that match their selected criteria. Currently, notifications are sent when any new vacancy is created and feedback from applicants is that a daily update is the expected functionality. 5.4 When an applicant sets up notifications the rule should be and rather than or for the options selected, for example, when a user selects to be notified of vacancies for Grade 7 and also HR then they should be sent vacancies that are ONLY for Grade 7 vacancies in the department HR rather than all Grade 7 and all HR vacancies. 5.5 When an applicant selects an interview slot they should be provided with an acknowledgement (either on screen or via ) that the action has been successful. Page 6 of 9

7 6 Interface Updates (inc View Updates) 6.1 The Student Matriculation Number input in response to Additional Question on the application form should be made available in the applicant master view 6.2 The Successful Applicant Interface should be updated to pull the Student Matriculation Number from the applicant master view and update in the additional personal details screen. 6.3 The BOXI Universe should be updated to include any new fields added to the views. Additional erecruitment Fields added for collection of HESA data should be added to the BOXI universe. These have been created as Additional Questions in erecruitment. 6.4 A System Administrator should be provided access to a view to resolve Internal Applicant registration issues. This view should provide confirmation on whether the staff member exists in the erecruitment IDM views and if so what UUN and address is attached to that user. 6.5 The notification that is displayed to the applicant after attempting to register as an internal applicant validation should include a reference to contact HR Systems Team should there be any issues. If attempt successful the notification should include the address This would make the applicant aware should the incorrect address be held in the universities ID Management system. 6.6 The successful applicant interface should be updated to correctly handle superannuation for successful applicants appointed to SDS Grades with a Job Segment of 1. Page 7 of 9

8 7 System Administrator 7.1 A system administrator should be able to create an notification that links direct to a vacancy. 7.2 A system administrator should be able to include the following data in appointment approval notifications; - Hours entered (on appointment details screen) 7.3 A system administrator should be able to add the ID of the staff request that was approved to create the vacancy to notifications. 1.2 Non-Functional Requirements 1 Environments 1.1 DEV and TEST URLS should be reviewed and updated to bring in line with LIVE Urls. 2 PDF Generation and Document Storage 2.1 Implement Core s revised PDF Generation software April 2.2 Confirm document (including pdf) storage requirements on server are sufficient, if not, recommend and implement an alternative storage solution. March 3 Notifications 3.1 Review and agree timing for notifications and s. Core recommendation in 10 minutes but currently set to 1 minute. 3.2 Notifications to be sent with correct time stamp for either BST or GMT. This will not be an issue until the change to BST Page 8 of 9

9 4 MyEd Channel 4.1 The nonce or secure key should be generated at the time the user selects to launch the erecruitment system. Currently the key is generated when the user logs in to MyEd which results in a high level of timeout failures. Users need to refresh MyEd to refresh the key. Page 9 of 9