Business Requirements
Functional Requirements
The following lists the fields and data to be included in the nightly feed taken from RMAS into PURE.
Note that the 'views' in PURE will be updated during this project to the new project model.
Requirements have been labelled using the MOSCOW system: Must Have, Should Have, Could Have, Won’t Have.
ID | What | Description | Business Need | Priority |
1 | Frequency | Nightly feed, same as current process | Maximum frequency to have up to date information in PURE | M |
2 | Syncing historic data | RMAS will hold data from 01/08/2008. The sync from RMAS to PUREINT will be a 'clear and refresh' which will rewrite the data each night. The data in PURE for projects completed prior to 01/08/2008 will be archived prior to the RMAS feed going live. | RMAS will be storing project information from 01/08/2008 onwards. PURE requires information back to 2001 for RCUK reporting. The pre 2008 archived data will be merged with the current data on a nightly basis. | M |
3 | Financial data to be imported from RMAS into PURE | Fields: -Budget data, all info that is currently taken from Finance (including breakdowns of costs e.g. directly incurred etc.) - DO NOT take the actual spend (as is currently taken). -Grants awarded and any associated internal funding allocations | Must have to be able to produce PURE reports for REF | M |
4 | Project data to be imported from RMAS into PURE | *Same fields as currently taken from the CFACS tables held in eFIN.* All project metada is required, for example (the following is not the definitive list of fields): -Project code -Project Title -R code(s) linked to the project code -Employee numbers of PI/Co-I's linked to the project code -Percentage split of each employee -Project start and end date -funder details -sponsor id's -Award date of the grant (related to Jira RES051-1) | Must have accurate project data to be able to match with the finance data and to produce accurate reports | M |
5 | Classifications | E.g. Research award types, org hierarchy, funder type classifications. The classifications used in RMAS should match those in PURE. If it is not possible to have the same classifications, it must be possible to map from RMAS to the equivalent field in PURE. | To avoid data mismatches | M |
6 | Academic Percentage | Split across each R code for academic staff | Required for reporting | S |
7 | Non R coded research projects | Will be given an 'R' code and will be administered through RMAS. PURE will no longer see other codes (e.g. 'D'). | To ensure all research-related projects are stored in the same location | S |
8 | Project Description | Field to be included in the project data taken from RMAS | Would be good to populate if available from RMAS | C |
9 | Collaborators | Field to be included in the project data taken from RMAS | Would be good to populate to save double entry | C |
10 | Award Affiliations Date | Field to be included in the project data taken from RMAS | Would be good to populate if available from RMAS | C |
11 | External funding allocations | Field to be included in the financial data taken from RMAS | Would be good to populate if available from RMAS. | C |
12 | Feed load failures | To remain as they are in PUREINT, i.e. create an exception file. | To deal with records that fail in the feed | M |