Stage: Business Analysis
Business Requirements Document
Feeding Visitor data into Alma
LMP006
Library Management Platform
[AP56-037]
Document Version: 0.5
Date: 09/03/2016
Contents
Document Management
1.1Contributors
1.2Version Control
2OVERVIEW
2.1Project Description
2.2Objectives
2.3Business Dependencies and Constraints
2.4Legislative Impact
3PROCESSES
3.1Business Process Description
4BUSINESS REQUIREMENTS
4.1Functional Requirements
4.VRS
5Non-Functional Requirements
Data Requirements
6USER ACCEPTANCE TESTING
7TRAINING
8APPENDIX 1 – PATRON GROUPS
9APPENDIX 2 – STATISTICAL CATEGORIES
10APPENDIX 3 – ACCESS RIGHTS
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.1Contributors
Please provide details of all contributors to this document.
Role / Unit / NameBusiness 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 / Alex Carter / 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, Mark Skinner
Alex Forrest, Sheila Fiskin, Greg Christie
Lyndsey Archibald
1.2Version Control
Please document all changes made to this document since initial distribution.
Date / Version / Author / Section / Amendment14/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
09/02/16 / 0.3 / Elaine Wighton / 2.2, 3.1, 4.1 / Updated following walkthrough of ‘to be’ process with Alex Carter
09/03/16 / 0.5 / Elaine Wighton / Various / Updated following comments received from Barry Croucher, Alex Forrest, Marj Laurenson and Michael Sun
2OVERVIEW
2.1Project 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.2Objectives
- To include new Visitor types to VRS to allow further user groupsto be captured via a web interface 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
- the existing feeds to IDM and to VRS;
- the existing Libraryfeedfrom the University's Identity Management System (IDM) to the new Library Management Services application Alma
- and the acceptance of feeds of patrons on a regular basis
2.3Business 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.4Legislative Impact
N/A
3PROCESSES
3.1Business Process Description
This project willdeliver:
- Web Interface to capture external visitor (excludes Visitor Staff and Student) details
- The ability for Library Staff to search for and process applications for the external visitor types:
- NHSLothianInternal Staff
- Self-Registration Reference Users (including SCONUL Reference)
- SCONUL Access (borrowers)
- General Council
- Fee paying external user
- New college subscription
- OLL
- Other external Users (e.g. public, members of the CRC)
- The ability for new external visitors data to be held in IDM and VRS
- Existing VRS feedto be developed to include amendedVisiting Staff and Visiting Student data inVRS for transfer to IDM
- Existing Library IDM feed to be developed to include the new Visitor datain IDM for transfer to Alma
- Existing Library IDM feed to be developed to also produce 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)]
- Alumni process has been captured, it is expected that this will be taken forward as a separate piece of work outwith the remit of the LMP006 project.
4BUSINESS REQUIREMENTS
4.1Functional 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 / Responsibility1.1 / For prospective visitor patrons, a web interface is required that can be accessed via the Library website. / MH / Paul Gorman
1.2 / For prospective visitor patrons, a web interface is required that can be accessed via the self-service kiosk within the Library. / MH / Paul Gorman
1.3 / The web interface must provide access to a Library Registration form for all visitor patrons (with the exception of Visitor Staff and Visitor Students who will be created using existing VRS process). / MH / Paul Gorman
1.4 / The Library Registration form must contain the following Registration Data Items:
- Title – required
- Surname – required
- Forename – required
- Preferred forename – required
- Initials – required
- eMail address – required
- Home address (lines 1-5, Town/City, Country) – required
- Postcode – optional
- Telephone No - optional
Initials field to contain some help text explaining that forename and middle name (if applicable) initials that should be entered. First initial of surname must not be entered. / MH / Paul Gorman
1.5 / Library Registration form once completed is able to be submitted online or via self-service kiosk and is retrievable by Library Staff real time. / MH / Paul Gorman
1.6 / New visitor patrons must receive an email confirming submission of registration form. / MH / Paul Gorman
1.7 / Email confirmation willcontain the following information:
- Link to relevantinformation and proof of ID required for Library Staff to process the application when visiting the library
- Link to Library opening hours
- Who to contact if the email recipient did not submit the registration form
- Confirmation that the application must be approved within 28 days otherwise record will be deleted and new registration form would need to be submitted
1.8 / Email content must be editable in case of future changes to email text is required. / MH / Paul Gorman
2. Processing submitted visitor data
**Aspiration is for this to be a next day process**
ID / Requirement / Category / Responsibility2.1 / When Library Registration form is submitted via Online / Self-Service Kiosk, data is recorded with the following criteria:
- real time
- date/time stamp
- created by specific Originator type to identify application route
2.2 / New visitor patron data must be searchable using:
- Name (First/Preferred Name, Surname)
- Post Code
- Email address
It is recognised that not all users will have entered Post Code. / MH / Barry Croucher
2.3 / There should be a toggle option available when searching for visitors:
- New Visitor Patronscreated with new originator account
- All visitors
2.4 / The system should contain a blacklist of known individuals that may be rejected if they submitted an application. Library staff must be able to add or remove individuals from the list. The blacklist will contain the following information:
- First Name
- Surname
- Address
- Reason
- Date(s) of previous attempt(s) to access the library
2.5 / The system should cross refer the prospective patron with the blacklist and automatically set a warning if a match is identified based on the following criteria:
- First Name
- Surname
- Address
Library staff would need to act on the warning by following a business process. / CH / Barry Croucher
2.6 / There must be the ability to decline application requests and retain the record for future reference. / SH / Barry Croucher
2.7 / There must be the ability to assign a reason for declining an application. This should be selected from a drop down list and retained for future reference.
- Previous borrowing history
- User behaviour
2.8 / Originator Accounts created when new applications are received will be purged if there has been no activity on the application 28days after submission.
Any applications that have been approved or declined must not be purged. / MH / Barry Croucher
2.9 / Library staff should be able to extend the timescales that an application is retained for prior to purge where there has been no activity. / CH / Barry Croucher
2.10 / The system will automatically set the new Visitor Patrons start date as the date of approval of the application. / MH / Barry Croucher
2.11 / The Library Helpdesk should be able to add a new Visitor Patron end date (End Visit Date, on Alma – calculate End Visit date + 4 weeks for all non-staff like Visitors). / MH / Barry Croucher
2.12 / There must be a facility for Library staff tocreate and maintain a master list of Patron Groups and Statistical Categories. Library staff must be able to:
- AddPatron Groups to a master list
- Amend Patron Groups on the master list
- Create a new Statistical category for Official Student and Staff like Visitors (i.e. those created via VRS)
- Add new Statistical Categories to a master list
- Amend Statistical Categories on the master list
2.13 / Library Helpdesk staff must be able to record Patron Group and Statistical Category for new Visitor Patrons. These will be selected from a drop down list:
- Ability to add Patron Groupto a Patron record (Refer to Appendix 1 – Patron Groups)
- Ability to add a Statistical Category to a Patron record (Refer to Appendix 2 – Statistical Categories)
2.14 / For Visitor Patrons identity must be associated with an organisational unit (default to Users Services Division in Organisational Unit field):
Level 4 P5L User Services Division
Level 5 D673 Help Services
Level 6 SU673 Help Services / MH / Barry Croucher
2.15 / All new Visitor patron will be assigned default services, providing access to:
- EASE
- Central Auth
- UNIDESK
- CCD
Reference users will be assigned these default services though they will not actively use them. / MH / Barry Croucher
2.16 / As Library Staff will be approving and declining applications, the system must provide the facility to manage users of the system. The following options will be available:
- Add a new user
- Update an existing user
- Inactivate an existing user
- Delete/remove existing users
2.17 / The system must contain the following authorisation levels:
- Administrator access (includes granting access at individual or team level and also removing or amending access)
- Update only access
- Update and approve access
- No access (user inactivated)
2.18 / On approval of a Library Registration application, visitor data must be passed into IDM real time as each application is approved. The data items are:
- Forename
- Preferred first name
- Surname
- Initials
- Address
- Email address
- Visit start date
- Visit end date
2.19 / The system must set the following default services for all new visitor patrons:
- Ease
- CCD
- Central Auth
- Unidesk
- Library Services
- MyEd*
2.20 / The system must provide the following non default services for selection if required:
- Electronic journals
- Wireless access
2.21 / The system must have a way of identifying the different visitor types for passing to Card Services:
- Reference Users
- All borrowers (including NHS)
This will be used to identify the batch type within Card. / MH / Barry Croucher
2.22 / The system must have a way of identifying the different visitor types for passing to Card Services:
- Alumni
This will be used to identify the batch type within Card. / CH / Barry Croucher
2.23 / The ‘Valid Until’ date that is passed to Card Services to be displayed on cards that are produced will be the end date of the current visit. Alternatively, if end visit date is not entered a default of one year from date of approval will be used.
Notes:
The card will continue to function beyond the Valid Until dateproviding door access and library services have not been suspended. / MH / Barry Croucher
2.24 / On approval of a Library Registration application, visitor data must be passed into Card on a regular basis.
The frequency will be confirmed during system analysis and design. / SH / Barry Croucher
3. Maintaining Visitor Patron Data
ID / Requirement / Category / Responsibility3.1 / The new system will be the golden copy of visitor patron data. In addition to Library Staff searching for newly submitted applications they will also be able to search for approved and declined applications that were submitted through the new route. / MH / Barry Croucher
3.2 / Any amendment to Visitor Patron data will be made in the new system and passed into Alma via IDM in the change based feed.
- Name
- Address
- eMail address
- Statistical category (add and remove)
4.VRS
ID / Requirement / Category / Responsibility4.1 / For allnew Official Student or Staff like Visitors being entered through the existing VRS, the system will:
- enable the ‘mandatory’ input of email address
- automatically set the organisation unit address based on the organisation unit of the approver
4.2 / When adding a subsequent visit for an existing Official Student or Staff like Visitor, email address must be confirmed or populated (if blank). / MH / Barry Croucher
4.3 / When adding a subsequent visit for an existing Official Student or Staff like Visitor, the organisation unit address applicable to the previous visit will be cleared down and reset based on the organisation unit of the staff member approving the subsequent visit (address may or may not be the same as previous record). / MH / Barry Croucher
4.4 / The Library Helpdesk should be able to add a new visitor patron end date (End Visit Date, on Alma – calculate End Visit date + 12 weeks for all staff like Visitors that come through the existing VRS. / MH / Barry Croucher
4.5 / The Library Helpdesk should be able to add a new visitor patron end date (End Visit Date, on Alma – calculate End Visit date + 4 weeks for all student Visitors that come through the existing VRS. / MH / Barry Croucher
4.6 / Any new visit or visitor added to the VRS will be included in the feed only if the administrator has selected Library Services. This will be effective from the date deployment.
Any existing visit/visitor with Library Services selected prior to date of deployment will not be included in the feed. / MH / Barry Croucher
4.7 / Currently Visiting Staff and Student data is fed from VRS to Card, there is a requirement to amend this to move the feed to come from IDM directly to card. / SH / Lorraine Brown/Alex Carter
4.8 / The feed of Visiting Staff and Student data is currently passed to Card in an overnight job. There is a requirement to pass the data to Card on a more frequent basis.
The frequency will be confirmed during system analysis and design. / SH / Lorraine Brown/Alex Carter
5. Card Production