Business Requirements

RF01a - Initial Clean Up of Data

UoE Development - The Timetabling Unit will prepare a "clean" SPF image for loading into the new SDB for the upcoming academic year, however, an initial clean up process is required, where the interfaces into Timetabling will be run in a manner that allows for checking of each record to ensure that each record is still valid and if not that it is marked for deletion.  The intention would be that this process would run after the load of the clean SPF into the new SDB.  The reason for running a process like this is to syncronise the data in Timetabling with its source systems, this process must be available to run infrequently (or on demand).

The process would need to check through all data loaded as part of the interfaces for Programmes of Study, Modules, Departments and Staff Members.  Please note that any new developed interfaces will also require a syncronisation process (i.e. Student and Student Course Enrolments).

There are a few potential solutions to this however these will need to be investigated as part of the design stage:

1.Port the reporting database output to Oracle in order to calculate changes against actual data outside of Timetabling and load the results through SPDA

2. Create a plugin to use with the SPDA to calculate changes as part of the SPDA loading process

RF02 - Roll forward of Roles

There is a process in Authorisation Manager (AM) that allows roles to be copied into the new database for the upcoming academic year.  The process for completing this must be documented and tested to ensure that the TImetabling Unit can repeat the roll forward each year. Particular attention will need to be paid to departments and location groups associated with AM Roles, as the roll forward of AM roles has created spurious entries in the Department and Location Group tables where the hostkeys are the same as in the previous database but the underlying objectid has changed.

RF03 - Add forward link to existing Web Applications (separate virtual directory for 1415, configuration to be supplied by Scientia) - new instances of Notifier and SWS/WRB

The existing web applications (Web Room Booking, Book Study Space and Web Timetables) must be updated to include a link that will take users into the upcoming year's version of the same application.  The reason for this is that the launcher channel will only point to one application at a time, therefore the decision has been made to continue to point the launcher at the current year's application with a link forward, until the effective date of the new database is reached in which case the launcher channel will start to direct users to the latest version of the web applications.

The process for adding a forward link must be repeatable as new link will need to added to the current year's Web Applications each time that an upcoming year's set of Web Application are deployed.

For Web Room Booking and Book Study Space the suggestion was to include the link within the text next to the Calendar stating "For bookings after 25 August 2013, please use Web Room Booking for 2013/14" with the link embeded in the text to the new WRB (e.g. www.ted.is.ed.ac.uk/UOE1314_WRB/).

For Web Timetables a note can be added to the front page by the Timetabling Unit by updating the Institution's table User Text 1, this will effect a change to the front page on Web Timetables, however, it would be desirable to make a change that allows a message to be displayed at the top of each page.  The message in both the front page or headers should state "Please note that these timetables only cover up to 25 August 2013 for timetables relating to academic year 2013/14 please refer to 2013/14 Web Timetables" again the text should include a link to the new Web Timetables (e.g. www.ted.is.ed.ac.uk/UOE1314_SWS/).

RF04 - Repointing of MyEd Launcher Channels

The MyEd launcher channels for Book Study Space, Web Timetables and Web Room Booking all point to the UoE1213 instance of their respective Web Applications.  Ideally a solution should be put in place that allows the channels to be pointed at a single link for each of the 3 applications that will redirect the user to a date appropriate instance of that application (for example a student clicking launch Book Study space up to 25 August 2013 will launch the UoE1213 instance, clicking the same link from 26 August onwards will launch the UoE1314 instance).  The main reason for this requirement is to reduce where possible any tasks required to deploy a new year's worth of applications. 

The intermediate step that repoints users to the correct application instance must be documented so that it can be repeated each year by application support, it has been suggested that the maintenance will take place inside the configuration of the IIS.

RF05 - Repoint of OneLan Feeds

The OneLan feed is a customised version of the Web Timetables application and as such it has an academic year reference in the url (https://www.ted.is.ed.ac.uk/UOE1213_OI/web/main.asp) ideally the URL should not be changed but fresh data be fed to the same URL.  If this is not possible then it is suggested that a similar intermediate function is created to re-direct users to the correct URL based on the date.  The OneLan feed can only present today's information so it is cleaner in terms of switchover from year to year.  Where a new URL is required LTSTS (Learning Teaching Space Technology Section) and T@Ed users must be informed of the change over as there are a number of monitors that are pointed at the existing URL.  The solution for the re-direction may be more complex for the OneLan feed as the url contains conditions that define what information is returned (for example https://www.ted.is.ed.ac.uk/UOE1213_OI/web/main.asp?bid=0201&fid=03&rid=3.02&periodstoshow=32&style=textreport will return only bookings in Building 0201 Appleton Tower, for the 3rd Floor and Room 3.02 for the whole day (32 periods) and in the Textreport style).  Any redirection would need to allow these additional parametres to be passed to the relevant instance in order to display the timetable for today with the correct constraints.

A solution suggested was to change the SDB behind the scenes and use a proxie in place of the exisitng url, so that onelan monitors would only have to be redirected once.

During the requirements sign off it was agreed that the repointable URL should not contain an academic year reference (e.g. https://www.ted.is.ed.ac.uk/UOE_OI/web/main.asp) so that it is not confusing to users, this does mean that LTSTS will need to update all of their room monitor links to refer to the new repointable URL.  It was suggested that the repointable URL is launched early so that LTSTS can phase in the changes rather than having to make them all on 26 August 2013.

RF06 - Repoint of PADS XML Feed (single RDB if only wish one ayr or need multiple instances if we want to retain more than one academic year)

The PADS XML feed produces an xml file of bookings for the day in the Business School when the EBIS (Estates and Business Information System) site is hit (https://www-live.ebis.estates.ed.ac.uk/xml/pads_room_info.cfm), a web service and SOA service were introduced during Minimum Change to drive this url and the XML produced.  At present the web service (delivered by Scientia) is linked to a single SDB (i.e. UoE1213).  The preference would be to maintain the existing URL as PADS have monitors coded to use the URL, while underneath the SOA/Web services would be switched to point at the new database (i.e. UoE1314).  This process would have to happen each year on the date that the current database runs out.  There are a few potential solutions to this, as it would be possible to get Scientia to create new web services for each new SDB, but another potential solution is to move to using the reporting database (which is feed regularly with up to date information from the current SDB) - this is a design decision and will be covered in the System Design Specification.

In addition to the roll forward requirements, a live issue with the PADS feed must be addressed.  The issue relates to the calculation of the time of the activity booking, the system was implemented while in British Summer Time (BST) and following a change made via JIRA (https://www.jira.is.ed.ac.uk/jira/browse/STU215-93) during minimum change correctly displayed the time.  Once BST was over and the clocks where moved back to GMT, the times quoted in PADS where ahead by one hour.  A short term fix has been put in place on the cold fusion part of the application to remove the hour deducted, this will suffice until March 2013.  This project must deliver a more robust solution so that the PADS service produces an output with the correct time where in BST or not.

RF07 - Repoint of Incoming Interfaces

Minimum Change implemented 3 incoming interfaces for Timetabling, more will be introduced as part of this project.  The staff and organisational hierarchy feeds do not provide year specific information and as such they can be switched in their entirity when a new SDB is created (or more likely just before the new SDB comes into effect).  The remaining interfaces for Courses (and the new interfaces to be introduced) will feed year specific information into each SDB (for example UoE1213 is only interested in Courses running in the academic year 2012/13).  A process must be introduced to allow the interfaces to swtich from one SDB to another and for the selection of data to change from one SDB to the next.  The ideal position would be that the interfaces can be switched using parametres, although this is limited to the technology used to pull data into the Timetabling system, namely Syllabus Plus Data Adoptor.  At a minimum a procedure must be documented to cover how to change the SPDA instances to feed year specific information into the appropriate SDB.

Please note that for Course, Students and Programme of Study interfaces there is will be a requirement to run the current years and upcoming years interfaces concurrently as the existing year's data must be maintained while feeding the upcoming year's data for course planning.

A potential re-use of the virtual desktops has been proposed that rather than decommision the desktop each year, it should be retained to be used to feed an upcoming's year's database - which would involve changing the connections each academic year.

Non-Functional Requirements