Business Analysis: Business Requirements Document LMP006

[Version: 0.2]

______

Stage: Business Analysis

Business Requirements Document

Feeding Visitor data into Alma

LMP006

Library Management Platform

[AP56-037]

Document Version: 0.2

Date: 27/01/2016

Contents

1 Document Management 3

1.1 Contributors 3

1.2 Version Control 3

2 OVERVIEW 4

2.1 Project Description 4

2.2 Objectives 4

2.3 Business Dependencies and Constraints 4

2.4 Legislative Impact 4

3 CURRENT PROCESSES 5

3.1 Business Process Description 5

4 PROPOSED PROCESSES 5

4.1 Business Process Description 5

5 BUSINESS REQUIREMENTS 6

5.1 Functional Requirements 6

5.2 Non-Functional Requirements 13

6 DATA REQUIREMENTS 15

7 USER ACCEPTANCE TESTING 16

7.1 Acceptance Test Strategy 16

8 TRAINING 16

1 Document Management

When completing this document, please mark any section that is not required as ‘N/A’. A brief description of why the section is not required should also be included.

1.1 Contributors

Please provide details of all contributors to this document.

Role / Unit / Name
Business Analyst (Owner) / IS Project Services / Elaine Wighton
Project Manager / IS Project Services / Karen Stirling
Project Sponsor / IS User Services Division / Bryan Macgregor
Programme Owner / Business Area Manager / IS User Services Division / Barry Croucher
Systems Analyst Designer / IS ISG Dev Team / Michael Sun / Richard Good
Service Owner / IS Service Management / Chris McKay / Lorraine Brown
Business Areas / IS User Services Division
IS Library and University Collections
IS ITI / Paul Gorman, Marjorie Laurensen, Paul MacLachlan, Andrew Kirk,
Alex Forrest, Sheila Fiskin, Greg Christie
Lyndsey Archibald

1.2 Version Control

Please document all changes made to this document since initial distribution.

Date / Version / Author / Section / Amendment
14/01/16 / 0.1 / Karen Stirling / All / First draft
27/01/16 / 0.2 / Karen Stirling/ Elaine Wighton / 3, 4 / Updated following ‘to be’ process workshop 22/01/16

2 OVERVIEW

2.1 Project Description

The LMP002 project implemented the new Library Management Platform during July 2015 and together with the LMP004 project delivered a Library feed for patron data from golden sources (IDM, EUGEX and HR) of staff and student data into the new library application. This allowed the integration of University of Edinburgh’s Identity Management System (IDM) with the new Library Management system (Alma) provided by 3rd party supplier.

This new project LMP006 Feeding Visitor data into Almahas been initiated to further enhance the Library IDMfeed to incorporate Visitor patron data captured via Visitors Registration System and passed to IDM. This visitor information will then be imported, and the management of data automatically, from the IDM system for forward transmission via the Library feed to Alma.

Due to time constraints the Library IDM feed to Alma was developed originally as a bulk feed, as a change based feed on demand couldnot be delivered in the LMP002 timeframe, therefore it was agreed thatthis could be requested by the library teamfor inclusion withinthe Year 2 project during 15/16.

This projectfits with University Strategy under Infrastructure by 'adapting our infrastructure to meet the changing needs, approaches and working patterns of our diverse population of staff and students and the wider community we serve to best support our world-class academic activity’.

Also fits with Strategic enablers: pursue consistency and continuity in quality and experience across all elements of our physical, information technology (IT) and library infrastructures and ensure that we have the information we need to support learning, teaching, research and effective decision-making.

2.2 Objectives

· To include new Visitor types to VRS to allow further user groupsto be captured via a web interface into this system and streamline / replace existing manual processes and workflows (Colleges, IS USD, IS L&UC and Corporate areas)

· To update the import and management of Visitor user data automatically byenhancing

o the existing VRS feed to IDM;

o the existing Libraryfeedfrom the University's Identity Management System (IDM) to the new Library Management Services application Alma

o and the acceptance of feeds of patrons on a regular basis

2.3 Business Dependencies and Constraints

There are other projects which are being delivered in 15/16 whichhave the potential tomake change to VRS:

· COM023Enhancements to Visitor Registration System (including CF Upgrade) which will upgrade the version of ColdFusion used byVRS, currently the application uses CF6 however the latest version available is now CF11 and also looking to complete some VRS enhancements.

· SMI012 Digital Images Submission for Staff and Visitors- The project teams will be liaising closely with the work being undertaken particularly for Visitor element to ensure there are no overlaps or changes conflicting developments. It has been suggested that the Business Analyst aligned to LMP006 is also assigned to this project for the Visitor Analysis to ensure continuity and consistency of knowledge.

· Due to the potential impacts on VRS and risks associated with LMP006, SMI012 and COM023 it has been agreed for a Change Manager to be allocated to oversee these project deliverables

· It is important to note that the upgrade of ColdFusion via COM023 requires to be completed ahead of any development changes to code required for any LMP006 and SMI012 visitorrequirements

· Please note this project has not taken into consideration any User Services Division additional costs for any new card production envisioned for new visitor types, should this be required then a change request can be raised and assessed for inclusion inthe project.

2.4 Legislative Impact

3 PROCESSES

3.1 Business Process Description

This project will deliver:

· Web Interface to capture external visitor (excludes Visitor Staff and Student) details

· Visitor Registration System (VRS) to be enhanced to allow new visitors type records to be created and visits to be processed:

o NHSLothianInternal Staff

o Self-Registration Reference Users

o Other Library Users e.g. Special Collections and Rare Books(to be confirmed)

· Existing VRS feedto be developed to include new Visitor data inVRS for transfer to IDM

· Existing Library IDM feed to be developed to include Visitor datain IDM for transfer to Alma

· Existing Library IDM feed to be developed to achange based feed on demand

· Library feed for both Bulk load and change basedto be split into two parts(Student / Staff ) however this requirement will need to be reviewed andreconsidereddue to inclusion of Visitors

· Review and update existing visitor processes used byIS L&UC, IS USD, Colleges and Schoolsfor the following users [NHSLothianInternal Staff, Self-Registration Reference Users, Other Library Users (to be confirmed)]

4 BUSINESS REQUIREMENTS

4.1 Functional Requirements

Specifying technical solutions should be avoided unless these are an agreed constraint on the solution. Technical specifications will be detailed during the Design Stage.

Record the agreed business requirements below:

· Separate requirements into sections e.g. by functional area

· Uniquely identify each requirement

· Describe each requirement in sufficient detail to enable verification by the business user, definition of acceptance criteria and cross-referencing during the Design stage.

· Specify the category for each requirement, using the following abbreviations:

MH = Must Haves – the current system as –is

SH = Should Haves- not in current process but would greatly improve

Library and / or Helpdesk processes

CH = Could Haves

1. Web Interface for registration of new visitor patrons

ID / Requirement / Category / Responsibility
1.1 / For prospective visitor patrons, a web interface is required that can be accessed via the Library website / MH/SH/CH
1.2 / For prospective visitor patrons, a web interface is required that can be accessed via the self-service kiosk within the Library / MH/SH/CH
1.3 / The web interface to provide access to a Library Registration form for all visitor patrons (with the exception of Visitor Staff who will be created using existing VRS process and Alumni?) / MH/SH/CH
1.4 / The Library Registration form to contain the following information
as per Registration Data Items (Registration data items) / MH/SH/CH
1.5 / Library Registration form once completed is able to be submitted online or via self-service kiosk and passed to Visitor Registration System (VRS) real time / MH/SH/CH
1.6 / New visitor patrons should receive an email confirming submission of registration form / MH/SH/CH
1.7 / Email confirmation should hold information advising new visitor patron what information / proof of ID etc. they will require to complete application when visiting the library / MH/SH/CH
1.8 / Email content needs to be editable in case of future changes to email text is required / MH/SH/CH

2. Enhancements / Changes to Visitor Registration System

ID / Requirement / Category / Responsibility
2.1 / When Library Registration form is submitted via Online / Self-Service Kiosk, this is passed to Visitor Registration System (VRS) with the following criteria:
· real time
· visitor record
· pending status
· date /time stamp
· dummy pending status (14 calendar days which is used to complete data clean up should new visitor patron not complete registration within Library)
· created by specific Originator to identify application route / MH/SH/CH
2.2 / Dummy visit must be created in the VRS with a default duration of one day, start date is equal to the creation date of the VRS record / MH/SH/CH
2.3 / New visitor patrons should receive an email confirming submission of registration form / MH/SH/CH
2.4 / Email confirmation should hold information advising new visitor patron what information / proof of ID etc. they will require to complete application when visiting the library
· Library opening hours
· Who to contact if the email recipient did not submit the form
· That the application must be approved within 14 calendar days otherwise record will be deleted and new registration form would need to be submitted / MH/SH/CH
2.5 / Email content needs to be editable in case of future changes to email text is required / MH/SH/CH
2.6 / New visitor patron data needs to be searchable within VRS using:
· Name (First / Preferred, Surname)
· Post Code
· Email address / MH/SH/CH
2.7 / Toggle option is required when searching for visitors within the VRS
· New Visitor Patrons created with new originator account
· All visitors / MH/SH/CH
2.8 / Email address field in VRS requires to be modified to be a mandatory field for both Official visitors created via VRS and Visitor patron via web interface / MH/SH/CH
2.9 / Ability to update VRS to decline application requests and retain the record for future reference / MH/SH/CH
2.10 / Originator Accounts created when new applications are received will be purged if the status remains set to pending 14 days after submission. Any applications that have been approved or declined must not be purged. / MH/SH/CH
2.11 / The Library Helpdesk should be able to add a new start date for Visitor Patron / MH/SH/CH
2.12 / The Library Helpdesk should be able to add a new Visitor Patron end date (on VRS – End Visit Date, on Alma – calculate End Visit date + 4 weeks for all non-staff like Visitors) / MH/SH/CH
2.13 / The Library Helpdesk should be able to add a new visitor patron end date (on VRS – End Visit Date, on Alma – calculate End Visit date + 12 weeks for all staff like Visitors / MH/SH/CH
2.14 / Library Helpdesk staff must be able to record Patron Group and Statistical Category in the VRS. These will be selected from a drop down list.
· Ability to add user group to VRS patron record as per list
· Ability to update and add new user groups to master list by Library/Helpdesk staff
· Create a new Statistical category for Official Visitor (i.e. those created via VRS)
· Ability to add a statistical category to VRS patron record as per list
· Ability to update and add new statistical category to master list by Library/Helpdesk staff / MH/SH/CH
2.15 / For Visitor Patrons automatic organisational unit defaults to Library Code or Users Services Division in Organisational Unit field
Level 4 P5F Library & University Collections – Level 5 D (tbc) Level 6 Su (tbc)
Or
Level 4 P5L User Services Division – Level 5 D673 Help Services Level 6 SU673 Help Services / MH/SH/CH
2.16 / For Visitor Patrons automatic Library Organisational Unit Code defaults to Library or User Services Division address in Address Field / MH/SH/CH
2.17 / For Official Visitors when organisation code is selected, the address of the business unit should be auto-populated / MH/SH/CH
2.18 / New Visitor patron - default services (access to EASE, Cent Auth, UNIDESK, CCD) / MH/SH/CH
2.19 / New Visitor patrons – specific services (include list) / MH/SH/CH

3. Card Production

ID / Requirement / Category / Responsibility
3.1 / Update CARD overnight CRON job to capture new batch types to allocate visitor defaults for relevant IDs
· Reference
· Lothian Health Staff
· All others e.g. SCONUL, General Council, External
IDs To be confirmed / MH/SH/CH
3.2 / New batch types to aid identification of new cards (colours) to be produced
· Reference
· Lothian Health Staff
· All others e.g. SCONUL, General Council, External
Colours to be agreed and confirmed / MH/SH/CH / Paul MacLachlan

4. Door Access to Library Areas

ID / Requirement / Category / Responsibility
4.1 / Update Door Access database to accept new Visitor ID defaults as provided via CRON job from CARD
· Reference
· Lothian Health Staff
· All others e.g. SCONUL, General Council, External
IDs To be confirmed / MH/SH/CH / Lyndsey Archibald
4.2 / Clearance set on IDs to have access to x (as per Access Matrix)
Clearance set on IDs to have access to y (as per Access Matrix)
Clearance set on IDs to have access to z (as per Access Matrix) / MH/SH/CH
4.3 / Clearance set on IDs to have access to x but with restricted time periods (as per Access Matrix) / MH/SH/CH

5. Enhancements to existing Library IDM feed

ID / Requirement / Category / Responsibility
5.1 / The library system should allow updates from IDM patron data as per existing feed
Note: ExLibris expect zip files containing XML user files to be placed at their defined S/FTP location where they will be fetched and uploaded by Alma / MH / Alex Forrest
5.2 / As existing feed, Library should receive changes to individual patron ID data from IDM and include all details for individual, not just those field where data has changed, (frequency to be confirmed) / MH / Alex Forrest
5.3 / For changes only, periodically synchronise the data between both systems to avoid any support issues with failed changes / MH / Alex Forrest
5.4 / For change based file this should be split into separate files for a) Student, b) Staff and c ) Visitor / MH / Alex Forrest
5.5 / Library should receive the Full file of patron data from IDM less regularly – currently once a day? / MH / Alex Forrest
5.6 / For full file this should be split into separate files for a) Student, b) Staff and c) Visitor / MH / Alex Forrest

6. Patron data