Unified+library+resource+management+specification


 * **Specification for a // Library Services Platform // (next generation Unified Resource Management system). You can:-**


 * 1. Scroll down to view (and edit if you wish) the online version**


 * 2. Download a WORD document version of the specification[[file:Unified_library_resource_management_system_specification_v2_Aug2012.doc]]**

If you are developing a requirement for a 'next generation' library services platform you may find the following blog posts from Sharon Penfold & Andrew Praeter helpful:

The development of our LMS specification. Part 1: What, how and why? Posted on January 31, 2013 by Andrew Preater

This is from the Bloomsbury LMS project team about the development of our LMS specification

The development of our LMS specification. Part 2: Why? Posted on January 31, 2013 by Andrew Preater

This is part 2 of an update from the Bloomsbury LMS project team about the development of our LMS specification and is especially relevant if you are planning an Open Source solution for your library management system.


 * NOTES on licensing and content of the LibTechRFP open specification. You are free to use and adapt the specification.**

This is a ‘free cultural work’ and is licensed as follows: //**Creative Commons CC-0**//

The Creative Commons Attribution License is the most permissive of the six main licenses created by the Creative Commons project (Licenses/CC-0 effectively releases a work into the public domain). A work licensed in this way grants all the four freedoms listed in the definition of free cultural works. For more information go the the creative commons website

The content has been adapted by Ken Chad Consulting Limited from a specification kindly made available by a UK university library in 2012 || ====**CONTENTS**====

flat
||  ||   ||
 * =Introduction= || The requirement is for a new system that should be a next generation system with a wider scope than traditional library systems. The landscape of higher education institutions is changing rapidly. The library is becoming a central information hub for its institution and the library services need to be well integrated with the relevant institutional systems. This will add new demands to the functionality of the library system and to its architecture, including the architecture of the surrounding information systems. ||  ||   ||
 * =General requirements = || This document outlines requirements for a 'next generation' library system which will produce a unified resource management approach to the full spectrum of library collections. This will include the integrated management of digital, electronic and printed collections and the services which are associated with academic libraries and their constituencies.
 * =General requirements = || This document outlines requirements for a 'next generation' library system which will produce a unified resource management approach to the full spectrum of library collections. This will include the integrated management of digital, electronic and printed collections and the services which are associated with academic libraries and their constituencies.

The utmost importance is placed on the architecture for any new system being modern, fit for purpose & designed specifically to operate within a cloud environment.

The required systems will exhibit the following characteristics:- ||  ||   || As libraries migrate from first or second generation integrated library systems, it is important that the next generation library service environment meets the following high level criteria: || The system must provide unified management of all of the resources that the library owns (for example but not limited to monographs, serials, datasets, maps, audio and all digital materials), licenses, stewards and make them available to end users for discovery and delivery. This includes support of selection and acquisition of both physical and electronic resources, metadata management across all resource types, submission of digital content, and fulfilment across all resource types. ||  ||   || • The Library management system/Integrated Library System • The Electronic Resource Management (ERM) system(s) • The Open URL link resolution software and any linked knowledgebase ||  ||   || • Print approval • Print firm order • Electronic firm order (package or single-title) • Print continuation • Electronic subscription (package or single-title) • Patron (demand) driven acquisitions (PDA/DDA) ||  ||   || • an order that passes criteria will continue the lifecycle through creation and sending with no staff intervention • library-defined criteria (such as incomplete order lines or prices above a threshold) will flag purchases for staff review ||  ||   || • Loading and deleting candidate records for patron discovery • Loading (MARC) records to create purchase orders for purchased items • Loading invoices for purchased items • Creating local inventory for purchased items. ||  ||   || • Privilege restrictions on what patrons may place requests • Potential for mediation in the approval/rejection of purchase requests • Automated ordering of requested purchases based on library-defined rules (i.e., patron role, price) • Notification and delivery to patron once a requested item has been received. ||  ||   || • Usage • Cost • Changes in license • Changes in titles lists to a package. ||  ||   || • Single-title monographs • Serial monographs • Issues of serials. ||  ||   ||
 * General requirements || * Search and discovery for end users is clearly 'de-coupled' 'back-end' resource management. Successful decoupling means going beyond search. It requires powerful enough APIs to allow a ‘search/discovery service’ user to, for example place holds (requests) for particular titles or items, or to see their personal library account information such as current (and past) transactions (such as loans) overdue items, unsatisfied holds etc ||  ||   ||
 * General requirements || * The management of print and electronic (digital) resources are integrated (or 'unified) ||  ||   ||
 * General requirements || * The library system elements interoperate easily with other systems. This is facilitated where overall architecture of the system is based around a (web based) Service Oriented Architecture (SOA) model to allow easier lower cost integration with 'admin' systems such as student registry and finance. This can be viewed as a move from a library system to what has been called a 'library services platform' approach where various components and sub systems are 'loosely' coupled (SOA) to provide an overall solution ||  ||   ||
 * General requirements || * Related to the above is more attention to improved workflows leading to saving in staff effort and consequently lower cost of ownership ||  ||   ||
 * General requirements || * Systems are typically 'cloud' based. This is a move away from more conventional 'hosting' to a system that is, in effect, a single entity that is shared by many separate and distinct libraries. Such 'multi-tenant' systems offer economies of scale and the opportunity to better share data (bibliographic, data on suppliers, licences etc) across the organisations that share the system ||  ||   ||
 * General requirements || * Related to the above is a move from 'management information' to 'analytics' or 'business intelligence'. This is characterised by not simply providing statistics on transactions recorded by a single library system (number of loans, items catalogued, orders placed etc), to an approach where all activity (including clickstreams) is potentially recorded and might be analysed to deliver new business insights. A cloud environment offer opportunities to collect and analyse data and detect trends across, what is in effect, a global network of systems ||  ||   ||
 * General requirements || The system should be vendor hosted with all necessary migrations and data updates to be carried out on behalf of the Library by the vendor ||  ||   ||
 * General requirements || Clear evidence of cloud resilience will be required along with a robust infrastructure which demonstrates the essentials of business continuity planning in the event of unforeseen events. ||  ||   ||
 * =High Level Requirements=
 * High Level Requirements || The system must be able to integrate with the institution’s systems such as but not limited to: Enterprise Resource Planning (ERP) system, student information systems and the VLE in a robust and transparent manner allowing on going updated from and to the system. ||  ||   ||
 * High Level Requirements || The system must support APIs and/or other interfaces that will allow the library to develop extensions to the core software as well as integrate the software into the local institutional environment. Documentation must be provided by the vendor as well as support for certifying any extensions developed by the library. The vendor should also provide support for sharing of customer-developed extensions. ||  ||   ||
 * High Level Requirements || The system must offer robust interoperability with library’s resource discovery platform. Such interoperability shall ensure that services developed for end-users that require resource management [i.e. user-driven acquisitions models] are available without additional integration work on the part of the library. ||  ||   ||
 * High Level Requirements || In addition, the system must provide support for multiple discovery and delivery services and offer capabilities for the library to publish relevant library resources [both metadata and inventory information] to these discovery environments as well as develop extensions to the core resource management software to interface and interoperate with such environments. ||  ||   ||
 * High Level Requirements || The unified resource management environment should ensure that the library can – upon migration – decommission the following local systems:
 * High Level Requirements || The system should facilitate migration from the various internal digital asset management systems that are managed by the library. The digital objects that are currently managed by these systems could either be migrated and stored within the unified resource management repository, or can continue to reside in their current storage environment but be managed by the unified resource management system. ||  ||   ||
 * =Acquisitions and Digital Deposit= ||  ||   ||   ||
 * ==Selection== || The system must support the ability to load vendor recommendations (notifications) for purchase consideration. Selectors may then purchase, reject, or defer purchase. ||  ||   ||
 * || The system must support the ability to load vendor recommendations (notifications) for purchase consideration. Selectors may then purchase, reject, or defer purchase. ||  ||   ||
 * || Approved selection items must generate orders in acquisitions that have the potential to be automatically ordered if they pass library-defined criteria (e.g. selector role, price and completeness of order line). ||  ||   ||
 * || The system should support the setting up of trials to evaluate e-resources before purchasing, which will include managing participant feedback and groups of participants. ||  ||   ||
 * ==Purchasing Workflows== || The system must support the following purchasing workflows:
 * Purchasing workflows || The system must be able to automatically create purchase orders based on vendor-supplied (MARC) records for resources ordered in the external system. ||  ||   ||
 * Purchasing workflows || The system must manage the acquisition lifecycle such that:
 * Purchasing workflows || The system must provide links from a purchase order to other related information such as invoice, vendor and linked descriptive record. ||  ||   ||
 * Purchasing workflows || The Acquisitions module must have a full EDI interface with major library vendors for ordering and invoicing. ||  ||   ||
 * Purchasing workflows || The system must support workflows for patron-driven acquisition of electronic books, including:
 * Purchasing workflows || The system must support streamlined purchase requests for and from end users, including:
 * Purchasing workflows || The system must support the ability to evaluate existing electronic resource subscriptions and make a decision to renew or cancel based on:
 * Purchasing workflows || The system should support setting up RSS feeds for newly acquired items. ||  ||   ||
 * ==Receiving== || The system must allow print items to be received from both approved purchase orders and invoices. ||  ||   ||
 * Receiving || The system must allow for the receipt of the following item types:
 * Receiving || The system must allow for the receipt of the following item types:
 * Receiving || The system must be able to automatically create new item records when an item is received. ||  ||   ||
 * Receiving || The system must notify staff when a volume or issue of a series has not arrived after a predefined interval, and allow for claiming of missed items. ||  ||   ||
 * Receiving || The system must identify where to route received items based on the completeness of their metadata and item information (i.e. to cataloguing, physical processing, or shelves). ||  ||   ||
 * ==Activation== || The system must allow for the activation of approved purchases for electronic packages and titles. This refers to the Knowledge Base primarily but also to any individual records for example e journal records within a package. ||  ||   ||
 * Activation || The system must notify staff when an electronic package or title is activated. ||  ||   ||
 * Activation || When an electronic package or title is activated, descriptive records to describe the title(s) must be added to the catalogue automatically. ||  ||   ||
 * Activation || Indicate if there is a need to import/export data in order to support the e-resources lifecycle. This refers in some instances to ejournal records or in its broadest sense any data not held within the unified system that would need to be imported to activate an eresource/eresources. It includes for example descriptive records for added for the purposes of Patron Driven Acquisitions (PDA). ||  ||   ||
 * ======Activation====== ||  ||   ||   ||
 * ======Activation====== ||  ||   ||   ||

• By end user • Bulk load • Submission software development kit. ||  ||   || • Automatic loading from pre-defined data sources (ftp) or Manual via wizard (PC) • Define automatic validation/enrichment during load • Optional sampling rates/approval process and dedicated interfaces for handling exceptions ||  ||   || • A discovery interface • A Web input form. ||  ||   || • Add new records, ignoring duplicates • Overlay one record with the other • Merge the two records • Do not load new records when a duplicate is detected. ||  ||   ||
 * ==Licenses Management== || The system must be able to manage licenses and amendments, including attaching digital versions. ||  ||   ||
 * Licenses Management || The system must support the ERMI schema for licenses, including the ability to display only those fields that the library uses and not the rest. ||  ||   ||
 * ==Vendors== || The system must provide the ability to maintain accounts for a single vendor. ||  ||   ||
 * Vendors || The system must provide the ability to maintain multiple physical and email addresses for a single vendor, with the potential to tie these addresses to individual accounts. ||  ||   ||
 * Vendors || The system must offer the ability to maintain discount and delivery information in the vendor record. ||  ||   ||
 * ==Funds Management== || Real-time access to fund balances (including encumbrances and expenditures) must be supported. ||  ||   ||
 * Funds management || The system must support a hierarchical fund structure that provides the ability to group and report on funds. ||  ||   ||
 * Funds management || The system must support optional fiscal year close processing. ||  ||   ||
 * Funds management || For each fund, the system must provide links to invoices committed against that fund. ||  ||   ||
 * Funds management || The system must support updated encumbrance estimations for foreign currencies based on daily conversion rates for foreign currencies stored as a central service. ||  ||   ||
 * ==Invoices and Payments== || The system must support the ability to automatically create a system invoice from a purchase order. ||  ||   ||
 * Invoices and payments || The system must support the export of payment requests to ERP systems, as well as the import of payment confirmation files. ||  ||   ||
 * ==Digital Deposit== || By digital deposit we mean material that we have digitized & can make available within the existing legislative framework. E.g. special collections material, teaching texts that we have digitized on demand. There should be options available for deposit of materials
 * Invoices and payments || The system must support the export of payment requests to ERP systems, as well as the import of payment confirmation files. ||  ||   ||
 * ==Digital Deposit== || By digital deposit we mean material that we have digitized & can make available within the existing legislative framework. E.g. special collections material, teaching texts that we have digitized on demand. There should be options available for deposit of materials
 * || The product should support pre-defined workflows for upload of digitized material and their metadata including:
 * =Fulfilment (Circulation)= ||  ||   ||   ||
 * ==General== || The system must have the capacity to manage all types of library material e.g. books, serials, electronic resources, digital materials, etc. ||  ||   ||
 * General || The system must be able to support variations in library policy from site to site. ||  ||   ||
 * General || The system must be able to support lending policies based on customer demand, for example, a demand driven variable dynamic loan concept. ||  ||   ||
 * General || Common circulation parameters should also be able to be set to work across multiple libraries.(branches/campuses) ||  ||   ||
 * General || The system must support ANSI/NISO z39.83 (NISO Circulation Interchange Protocol) and SIP2. The system must be fully compatible with the self service equipment including self issue/return and book sorter machines. ||  ||   ||
 * General || The system must provide integration with third-party ILL systems using standard protocols, including ISO 10160/10161 and ANSI/NISO z39.83 (NCIP). ||  ||   ||
 * General || Digitized library – the system should support the development of digitisation on demand services. ||  ||   ||
 * || The product should have flexible policies to control access to digital material. ||  ||   ||
 * ==Fulfilment Policy Tables== || Libraries must be able to define the policies by which their physical inventory is circulated to library patrons for example – due date policy, maximum renewals policy, fining policy, etc. ||  ||   ||
 * Fulfilment Policy Tables || The system must provide extensive ability to set parameters including for loans, limits and calendar, globally or at the branch level. ||  ||   ||
 * ==Patron/user/borrower Management== || The system must provide the ability to create different patron types and set circulation parameters for each type of patron. ||  ||   ||
 * Patron/user/borrower Management || Patron information must be updateable (through an API/plug-in) via institutional systems that serve as the initial source of that patron information. ||  ||   ||
 * Patron/user/borrower Management || The system must allow authorised staff to create, modify, and delete patron records. ||  ||   ||
 * Patron/user/borrower Management || It must be possible to update defined areas of the patron record (core information, addresses, and phone numbers) independently. ||  ||   ||
 * Patron/user/borrower Management || The system must integrate with external identify management systems (e.g. LDAP) for authorisation and authentication. ||  ||   ||
 * Patron/user/borrower Management || Individual segments of the patron record must be updatable by disparate sources without affecting information in other segments. ||  ||   ||
 * ==Fines and Fees== || The system must support assessment of fines and fees for an item based on transaction policies defined by the library. This includes both overdue fines and lost item fees, which may be automatically applied after an item is overdue for a library-defined period of time. ||  ||   ||
 * Fines and fees || It must be possible for an authorised operator to manually add or waive a fine or fee ||  ||   ||
 * Fines and fees || The system must offer the ability to set the amount of fines accrued after which the patron account is blocked from further activity. ||  ||   ||
 * Fines and fees || It must be possible for end-users to view their fines and fees in the resource discovery solution, without seeing any element of the University Library’s back-office systems. ||  ||   ||
 * Fines and fees || It must be possible to disable fines and not operate a fining regime at all. ||  ||   ||
 * ==Request/holds Management== || The system must support business rules that automatically manage patrons’ requests and allowing staff user mediation only when necessary ||  ||   ||
 * Request/holds Management || A patron-initiated digitization request must trigger an alert and a pick slip at a specific digitization location ||  ||   ||
 * Request/holds Management || The system must automatically generate a notice to patrons when requested items are available. This notice may be in the form of an email or an SMS. This should be generated in real time. ||  ||   ||
 * Request/holds Management || The system must support the administration of access rights for digital materials, based on patron group and collection. ||  ||   ||
 * Request/holds Management || The system must support the administration of access rights for electronic materials, including the ability to restrict access by IP address and federated access management where appropriate. ||  ||   ||
 * ===Smart Fulfilment=== || The system must provide smart fulfilment, using a combination of patron and item attributes to determine the best fulfilment method. ||  ||   ||
 * Smart Fulfilment || For all request types, patron permissions must be based on transaction policies defined by the library. ||  ||   ||
 * Smart Fulfilment || The system must support fulfilment of purchase requests submitted by borrowers via the discovery interface. ||  ||   ||
 * Smart Fulfilment || The system must support the fulfilment of requests via link resolution to appropriate electronic resources. ||  ||   ||
 * Smart Fulfilment || The product should support digitization-on-demand workflows. ||  ||   ||
 * =Course reading material= ||  ||   ||   ||
 * Course reading material || The system must be able to receive information about course reading materials from external sources. These sources may include:
 * Course reading material || The system must be able to receive information about course reading materials from external sources. These sources may include:
 * Course reading material || The system must support complete list integration for print, digital, and electronic reserve items. ||  ||   ||
 * Course reading material || The reserve system must have a high level of integration with other modules, utilising the same user and bibliographic databases, and discoverable using same search interfaces. ||  ||   ||
 * Course reading material || It must be possible for an authorised operator to request digitisation of a resource from the reserve queue. ||  ||   ||
 * Course reading material || It must be possible to report copyright clearance status. ||  ||   ||
 * Course reading material || The system must provide the ability to easily produce lists of items held on reserve by a variety of fields, including course code and lecturer. ||  ||   ||
 * Course reading material || The system must provide the ability for authorised users to archive information after the withdrawal date and re-activate at a time specified by the Library. ||  ||   ||
 * Course reading material || The system must be able to support the advance bookings of material, including items of varying loan periods (e.g. 24 hour as well as 2 hour loans). ||  ||   ||
 * Course reading material || The system must be able to control access to certain content by some categories of patrons. ||  ||   ||
 * Course reading material || The product should support workflows for digitization of course reserve material. ||  ||   ||
 * =Metadata Management (Cataloguing)= ||  ||   ||   ||
 * ==Format Support== || The system must support multiple metadata formats and be extensible to additional formats. At a minimum, MARC21, Unicode, Dublin Core and MODS must be available out-of-the-box for the library. The metadata management environment must support functions appropriate to these formats. ||  ||   ||
 * Format Support || The system must support import and export (with no loss of data) in all supported formats. ||  ||   ||
 * Format Support || The system must support new fields and subfields added to MARC to support RDA. ||  ||   ||
 * Format Support || The system must support validation of appropriate use of elements, fields, subfields, and values, including validation of controlled vocabularies for fields (e.g. RDA content, carrier, and media terms). ||  ||   ||
 * Format Support || Text in all records must support Unicode for importing, editing, storage and export ||  ||   ||
 * Format Support || The product should support PREMIS data model and data dictionary (for digital objects). ||  ||   ||
 * Format Support || The product should support shelf-ready procurement and metadata provision; this will require full interoperability with established monograph and serials vendors including but not limited to those currently delivering content as part of existing regional and/or national procurement frameworks. ||  ||   ||
 * ==Editing== || The system must support the ability to edit all records through an online editor, including any element, field, subfield, or fixed field value as appropriate for the format. ||  ||   ||
 * Editing || The product should have the same editing capabilities for all metadata types (physical, electronic and digital). ||  ||   ||
 * Editing || The system must notify the cataloguer when a record being edited or saved matches an existing record in the catalogue. ||  ||   ||
 * Editing || The system must support the display of cataloguing policies in the editor. ||  ||   ||
 * Editing || Cataloguers must be able to save drafts of records without committing them to the catalogue. ||  ||   ||
 * Editing || The system must support the creation and storing of record templates for use in creating and editing records, including specifying default elements, fields, subfields, and values stored in these templates. ||  ||   ||
 * Editing || The system must support record versioning, including the ability to view and roll back to past versions of that record. ||  ||   ||
 * Editing || The system must support hotkeys for navigation and actions that allow editing entirely with the keyboard. ||  ||   ||
 * Editing || The system must support the ability to perform changes in bulk against a set of records, including the ability to alter any element, field, subfield, or fixed field value. ||  ||   ||
 * Editing || The system must provide a set of metadata management services that allows the library to easily and quickly define a set of records and perform actions against these records. For example, the library should be able to specify a group of records to be withdrawn from a collection or moved to an off-site storage facility; the library should be able, on import of metadata records from a specified source, to define a set of validation and normalization routines to be applied to the records on import; similarly, the library should be able to define, on export of records, various data transposition routines, etc. ||  ||   ||
 * ==Authority Control== ||  ||   ||   ||
 * Authority Control || The system must provide access to global, shared authority files without the need for individual libraries to synchronize with the authorizing agency. ||  ||   ||
 * Authority Control || The system must allow libraries to create or load local authority files and records for subjects (including genre terms) and names. ||  ||   ||
 * Authority Control || The system must support authorization of bibliographic headings against local or global headings in authority records. ||  ||   ||
 * Authority Control || When a heading changes in a local or global authority record, the system must automatically make the change in bibliographic records that are authorized against that heading without staff intervention. The system must flag changes that request staff decisions, such as heading splits and newly qualified names. ||  ||   ||
 * ==Holdings Management== ||  ||   ||   ||
 * Holdings Management || The system must allow for the creation of holdings and item records for physical resources. ||  ||   ||
 * Holdings Management || The system must support the ability to perform changes in bulk against a set of holdings or items. ||  ||   ||
 * Holdings Management || Institutional repository – describe how your product manages the process of collecting internally digital generated material. ||  ||   ||
 * ==Importing Records== || The system must allow for the loading records singly or in bulk ||  ||   ||
 * Importing Records || The system must allow for searching external databases through the online interface via z39.50 or SRU/W and importing resulting records to the catalogue. ||  ||   ||
 * Importing Records || When loading a record or set of records, staff must have the following options for handling records detected as duplicate:
 * Importing Records || When loading a record or set of records, staff must have the following options for handling records detected as duplicate:
 * Importing Records || The system must allow for validation of incoming records according to library-defined validation rules. ||  ||   ||
 * Importing Records || The system must allow for the enhancement of incoming records according to library-defined bulk record change rules ||  ||   ||
 * Importing Records || System operators should be able to perform mass updates in an efficient, controlled way for all resources types (electronic/digital and print). ||  ||   ||
 * ==Exporting Records== || The system must allow for the export of individual, groups of records, or an entire catalogue to a predefined target with no additional fees. The records to be exported may be based on a selected set, or records that have changed since the last export to that target. ||  ||   ||
 * Exporting Records || The system must allow for the enhancement of exported records according to library-defined bulk record change rules, including the ability to enhance bibliographic records with holdings information. ||  ||   ||
 * ==Shared Bibliographic Records== || The system must provide access to a catalogue of bibliographic records shared by all libraries of that system. Libraries must be able to attach holdings directly to the shared records, edit the records, or copy them from the shared catalogue to the libraries’ local catalogue. ||  ||   ||
 * Shared Bibliographic Records || The system must support a local catalogue in addition to the shared catalogue for storing records that have local descriptive needs or terms of use that prevent their being shared with other libraries. Libraries must be able to use the shared catalogue, the local catalogue, or both simultaneously. ||  ||   ||
 * Shared Bibliographic Records || The system must support the addition of local fields to the shared records that are viewable only to the local library. ||  ||   ||
 * Shared Bibliographic Records || Libraries must retain the right to remove their records from the shared catalogue. The vendor must not take ownership of the records or make any kind of charge for their use. ||  ||   ||

• How many resources are managed in your Knowledge Base (per type)? • How frequently is the Knowledge Base updated? • Give details about how the following types of electronic resources are described in the Knowledge Base: • electronic journals (Individual electronic journals, newspapers, and other serials; journal packages; selective packages) • eBooks • Databases. • Does the system allow for the addition of titles not currently in the Knowledge Base? ||  ||   || • author • title, • subject • series • call number • ISBN/ISSN • publisher • notes. ||  ||   || • Bibliographic information • Physical title • Physical item • Digital title • Digital files • Electronic information. ||  ||   || • Type of support plans (i.e. 24x7x365) • Can plans be adjusted? • Do you provide the support or is it provided by a third party? ||  ||   || • A knowledge base that includes extensive information to assist customers in troubleshooting issues and FAQs. • Access to product information such as release notes, user group presentations, etc. • Access to all software documentation. • Information regarding upgrades and patches. ||  ||   ||
 * =Central Knowledge Base= || It is expected that the new system will support and be supplied with a Central Knowledge Base of electronic resources. This is important as the Library needs to be able to manage a large and complex digital collection. The vendors should answer the following
 * ==Link Resolution== || The system must be able to accept OpenURL and context sensitive services as well as resolving the services. ||  ||   ||
 * Link Resolution || It is highly desirable that the system be able to augment the OpenURL metadata content where necessary. ||  ||   ||
 * Link Resolution || The system should be able to support cases where the OpenURL resolves to multiple records. ||  ||   ||
 * =Collection Management= ||  ||   ||   ||
 * Collection Management || A selector must be able to review recommendations and make decisions about whether or not to acquire a recommended resource. ||  ||   ||
 * Collection Management || The system should support automated acquisition workflows for recommended items. Describe how rules to support this can be defined and managed in your system. ||  ||   ||
 * =Reporting and Analytics= ||  ||   ||   ||
 * Reporting and Analytics || The solution should provide not only operational and usage report but analytics and Business Intelligence (BI) capabilities. ||  ||   ||
 * Reporting and Analytics || The solution must support reporting and analytics capabilities. Describe the reporting and BI solution of the proposed product and specifically indicate its ability to run in a cloud environment. ||  ||   ||
 * Reporting and Analytics || The reporting & BI tool must support a variety of output options including, but not limited to viewable online, send to printer, email and export to a spreadsheet. ||  ||   ||
 * Reporting and Analytics || The reporting and BI system must be able to provide business intelligence capabilities and the analysis of different data gathered by the system to serve as a support for decision making process. Benchmarking is strategically important to the University Library and any system must be able to generate the relevant metrics. ||  ||   ||
 * Reporting and Analytics || The reporting & BI system should support the ability to collaborate and share reports made by other parties. ||  ||   ||
 * Reporting and Analytics || The reporting system must support the customization of reports by librarians; this includes but not limited to: changing of reports parameters, views, time range etc ||  ||   ||
 * Reporting and Analytics || The reporting solution must be able to provide usage statistics reports and comply with industry usage reporting standards such as SUSHI, COUNTER. ||  ||   ||
 * Reporting and Analytics || The solution must support flexible reporting with a range of standard expenditure reports. ||  ||   ||
 * Reporting and Analytics || The solution must support role-based report generation and view such that user will only be able to view reports and data according to his/her role. ||  ||   ||
 * Reporting and Analytics || The solution must include a dashboard in which it is possible to monitor performance, tasks and detect trends. It is also required that the dashboard will be based on roles, allow customization and support the embedding of widgets. ||  ||   ||
 * Reporting and Analytics || The BI & Analytics tool must be able to analyze history data and provide trends analysis (such as usage, expenditure ||  ||   ||
 * Reporting and Analytics || The reporting and BI solution should allow layered reporting with drill down capabilities – for example: expenditure over year with drill down to quarters/items etc. ). ||  ||   ||
 * Reporting and Analytics || The Reporting application must allow for the automatic scheduling of reports at defined intervals. ||  ||   ||
 * =System Architecture and Security= ||  ||   ||   ||
 * System Architecture and Security || The system must be vendor hosted in a cloud or Software-As-A-Service (SaaS) environment and be cloud born. ||  ||   ||
 * System Architecture and Security || The solution must maintain personal information securely and conform to EU legislation ||  ||   ||
 * System Architecture and Security || The cloud environment must assure complete data protection and have high security capabilities in place. ||  ||   ||
 * System Architecture and Security || The cloud environment must be able to integrate with the institution’s local LDAP for authentication.. ||  ||   ||
 * System Architecture and Security || The system must be scalable to meet the load of many institutions without performance impact. ||  ||   ||
 * System Architecture and Security || The system must be able to integrate with 3rd party solutions, specifically but not limited to ERP and human resources systems. ||  ||   ||
 * System Architecture and Security || The system must provide a means for the institution to monitor basic parameters on its cloud environment. ||  ||   ||
 * System Architecture and Security || The product should have the ability to store digital collections in cloud storage or in customer-managed storage. ||  ||   ||
 * System Architecture and Security || The cloud system must be fully fault tolerant without a single point of failure. ||  ||   ||
 * System Architecture and Security || The system must support basic fulfilment capabilities during local institution network outage. ||  ||   ||
 * System Architecture and Security || The data managed in the product must be preservation-ready and allow the library, at a later date, to apply preservation procedures to digital objects that are stored in the repository. ||  ||   ||
 * System Architecture and Security || Describe the data model for management of digital resources. Describe how resources with multiple representations/files are managed. Are physical, electronic and digital resources managed in the same repository? ||  ||   ||
 * System Architecture and Security || The product should support linking of digital resources to the relevant physical/electronic resources. ||  ||   ||
 * =System Administration and Management= ||  ||   ||   ||
 * ==Customization== || The system should come with a set of “Out of the Box” definitions and configurations so that the library need only make minimal changes to the standard settings. ||  ||   ||
 * Customization || The system should allow customization of the acquisition workflows in order to accommodate specific library needs as well as control over when orders and invoices need mediated handling. ||  ||   ||
 * Customization || The system should allow the library to configure when fulfilment processes such as hold request/call slips can be automated or need to be mediated. ||  ||   ||
 * Customization || The system should come with the ability to add notes and file attachments to various resources managed in the system. ||  ||   ||
 * Customization || The interface must be easily customizable to the extent that it can be branded with the library identity. This includes control of style, images and graphical elements. ||  ||   ||
 * Customization || The system must permit changes to vocabulary to reflect local practices/preferences ||  ||   ||
 * =User Management= ||  ||   ||   ||
 * User Management || The system should support a robust and flexible yet straight-forward system for assigning roles and permissions to staff functions. ||  ||   ||
 * User Management || The system should support automatic assignment of roles to staff users. ||  ||   ||
 * User Management || The system should support Authorization/authentication which is role/attribute based (i.e. a single user can have multiple roles without needing multiple IDs). ||  ||   ||
 * User Management || The system must provide granular access control rights for staff accounts and be able to facilitate multiple profiles accessing different combinations of functional modules. ||  ||   ||
 * =Unified Staff Search= ||  ||   ||   ||
 * Unified Staff Search || The system must offer intuitive and easy to use search methods; both basic and advanced searching must be supported. ||  ||   ||
 * Unified Staff Search || Advanced search must allow for the option of searching multiple fields simultaneously for words or phrases. Staff should be able to define their own search conditions – based on standard indexed options. ||  ||   ||
 * Unified Staff Search || The system must be delivered with an out of the box set of standard indexed fields, including, but not limited to:
 * =Unified Staff Search= ||  ||   ||   ||
 * Unified Staff Search || The system must offer intuitive and easy to use search methods; both basic and advanced searching must be supported. ||  ||   ||
 * Unified Staff Search || Advanced search must allow for the option of searching multiple fields simultaneously for words or phrases. Staff should be able to define their own search conditions – based on standard indexed options. ||  ||   ||
 * Unified Staff Search || The system must be delivered with an out of the box set of standard indexed fields, including, but not limited to:
 * Unified Staff Search || It must be possible to filter large result sets – e.g. by facets. ||  ||   ||
 * Unified Staff Search || It must be possible to search across all types – bibliographic physical, digital, electronic in one search query. ||  ||   ||
 * Unified Staff Search || It must also be possible to set a pre-search filter – for example by:
 * Unified Staff Search || Based on staff queries it must be possible to save and manage sets. ||  ||   ||
 * Unified Staff Search || Sets should be the result of a query – i.e. all the items resulting from the search will be included in the set. ||  ||   ||
 * Unified Staff Search || It should also be possible to choose items from a query, and to form a set from the chosen items. ||  ||   ||
 * Unified Staff Search || It must be possible to search for electronic resources by – but not limited to - title (e.g. journal title), package and by provider ||  ||   ||
 * Unified Staff Search || Dependent on the search type, it should be possible – from the results list - to edit a record, create an order, view holdings, items etc. ||  ||   ||
 * Unified Staff Search || It would be desirable if the software had a persistent search box so that staff could search the database regardless of where they are in the system. ||  ||   ||
 * =Resource Discovery Layer Interoperability= ||  ||   ||   ||
 * Resource Discovery Layer Interoperability || Integration with the Library’s discovery layer must be complete – i.e. no elements of the Next Generation Library System’s own interface should be visible to the Library’s end-users. ||  ||   ||
 * Resource Discovery Layer Interoperability || The solution must be compliant with the DLF standard for the integration of resource discovery systems with library management systems ||  ||   ||
 * Resource Discovery Layer Interoperability || Describe any unique capabilities available by using your Resource Discovery solution in conjunction with your proposed library resource management system. ||  ||   ||
 * Resource Discovery Layer Interoperability || The solution must support seamless patron driven workflows initiated from discovery served by the system such as but not limited to: digitization on demand, patron driven acquisition, ILL requests, and course reserve requests. ||  ||   ||
 * Resource Discovery Layer Interoperability || End-users should be able to see all their account information (fines, loans, stored searches etc) seamlessly in the library’s discovery solution. ||  ||   ||
 * =Support and Maintenance= ||  ||   ||   ||
 * || Describe the hosting capabilities – please include: up-time, data centre details, maintenance periods and level of support. Provide examples of Service Level Agreements (SLA) you offer. Supply evidence of human resource dedicated to support and maintenance. ||  ||   ||
 * || Describe overall support options:
 * || Describe the hosting capabilities – please include: up-time, data centre details, maintenance periods and level of support. Provide examples of Service Level Agreements (SLA) you offer. Supply evidence of human resource dedicated to support and maintenance. ||  ||   ||
 * || Describe overall support options:
 * || Describe your proposed incident response procedures, addressing specifically how you will manage unscheduled outages, interrupted services, or a customer's report of degradation in service. Include specifics as to how you will investigate and resolve service level interruptions. ||  ||   ||
 * || Describe how emergency support is available 24x7. List any web sites used for support purposes. ||  ||   ||
 * || Describe what steps you have taken to secure the cloud environment including information about specialist staff dedicated to this. ||  ||   ||
 * || Please describe the way in which feature enhancements are released to your product (e.g. separate beta testing vs. en-masse beta testing with the entire population). How will the users be notified of upcoming or released product features? ||  ||   ||
 * || Please describe your change control procedures and how the users receive prior notification of scheduled downtime for maintenance or upgrades. ||  ||   ||
 * || Describe how you provide access to customer resource web site that includes:
 * || Describe how requests for enhancements are handled. How are priorities set for enhancements? What role, in any, does a user group have in this proces ||  ||   ||

Approved selection items must generate orders in acquisitions that have the potential to be automatically ordered if they pass library-defined criteria (e.g. selector role, price and completeness of order line).

Describe how you provide access to customer resource web site that includes: Information regarding upgrades and patches.
 * A knowledge base that includes extensive information to assist customers in troubleshooting issues and FAQs.
 * Access to product information such as release notes, user group presentations, etc.
 * Access to all software documentation.