Attachment_A-2016-09-2_NGLS_Statement_of_Work.docx

STATEMENT OF WORK

For the Next Generation Library System

i. Introduction The Ralph J. Bunche (RJB) Library of the US Department of State (DOS) is the oldest federal library. It provides open-source information products, print and electronic, to DOS researchers and analysts around the world. The RJB Library has a requirement for a commercial, off-the-shelf, “next-generation” library system and support of that system, and migration of data to that system. The “next generation” package of requirements include what would traditionally be called an integrated library system (ILS) supporting all library functions, along with a “discovery tool” integrating customer searches throughout the library’s resources, an “electronic resources management system” (ERMS), and the hosting and support of those tools by the NGLS Contractor.

ii. Purpose The eventual Next Generation Library System (NGLS) Contractor shall provide reliable access to the Department’s Library resources as described in the next section, to the Library’s worldwide customers (see Attachment A for a list) as recognized by the Department’s IP range.

iii. Background and Operating Environment The following is a profile of the Library’s current resources:

Several other offices within the Department of State use the library’s current system to manage small collections of information resources.

Provided below is the current list of major electronic aggregation resources:

· Proquest Historical Newspapers

· Proquest Newspapers Direct

· Proquest Research Library

· Gale Academic Onefile

· Hein Online

· Jstor

· Project Muse

· LexisNexis (librarians only)

· Factiva (librarians only)

· Gale Virtual Reference

· EBSCO Ebooks

· United Nations Documents

A. High Level Requirements As the Department of State libraries migrate from a second generation integrated library system, the next-generation library service environment must meet the following high level criteria:

A.1. The system shall provide unified management of all of the resources that the library owns, licenses, stewards, and makes available to customers for discovery and delivery. This includes acquisition support for both physical and electronic resources, metadata management across all resource types, and fulfillment across all resource types.

A.2 The system shall provide a hosted cloud or SaaS solution with web-based interfaces for all staff functions. The proposed solution shall not require any software to be installed locally.

A.3. The system shall provide, and be interoperable with, one of the major discovery/delivery systems currently on the market. Such interoperability shall ensure that services developed for patrons that require resource management [i.e., patron-driven acquisitions models] are available without additional integration work on the part of the library staff.

A.4. The system shall include in the base package, at the point of purchase, consisting of the following live components:

· Acquisitions

· Fulfillment (Circulation)

· Periodical check-in

· Metadata management

· Administration

· Link resolution

· Knowledgebase

· Analytics (Reports).

A.5. The NGLS Contractor shall provide the resources to replace the existing system, and as such, shall ensure that the library can, upon migration, decommission the following local systems:

· The Integrated Library System [ILS] from ExLibris Voyager

· 360 Core and E-Journal Portal from Serials Solutions

· The Open URL link resolution software and any linked knowledgebase from ExLibris SFX

A.6. The system shall accommodate multi-site institutions with two or more libraries (two libraries initially with the potential to add additional libraries at a future date) by allowing for member libraries within such an organization to maintain separate policies for:

· Patron management

· Vendors

· Funds management

· Licenses

· Metadata management

· Configurations

· Analytics and statistics

· Patron records A.7. The NGLS Contractor shall provide a Voluntary Product Accessibility Template (VPAT) stating how the system software conforms to the Section 508 Access Board Accessibility Standards for Electronic and Information Technology (E&IT).

A.8. Both the integrated library system and the resource discovery layer shall be in full production by four (4) months from the date of the contract signing.

A.9. The NGLS Contractor of the system shall have a strong track record of developing and implementing systems for libraries, as well as a clear strategy for evolving the library services platform in the future.

A.10. The NGLS Contractor of the system shall install software upgrades and/or bug fixes to the customer’s installation of the software on at least a monthly basis.

A.11. The system shall be 99% reliable and available to library customers around the world.

B. Unified Resource Management Specifications The NGLS Contractor-provided system shall:

B.1. Have an integrated workflow from the point of material selection to circulation for both print and electronic resources.

B.2. Support the integration between interlibrary loan and acquisitions to provide support for purchase-on-demand programs.

B.3. Provide access to electronic resources in a shared bibliographic environment where libraries may have different contractual arrangements with the same vendor.

C. System Administration and Management C.1. The system shall come with a set of standard definitions and configurations so that the library need only make minimal changes to the standard settings.

C.2. The system shall allow authorized staff to configure various aspects of the system (e.g. fulfillment policies, patron groups, import profiles) without vendor intervention.

C.3. The system shall allow for customizing the acquisition workflows in order to accommodate specific library needs as well as control over when orders and invoices need mediated handling.

C.4. The system shall allow the library to configure when fulfillment processes such as hold request/call slips can be automated or need to be mediated.

C.5. The system shall come with the ability to add notes and file attachments to various resources managed in the system.

C.6. The system shall offer intuitive and easy to use search methods; both basic and advanced searching shall be supported.

C.7. Advanced search shall allow for the option of searching multiple fields simultaneously for words or phrases. Staff shall be able to define their own search conditions – based on standard indexed options.

C.8. The system shall be delivered with a rich out of the box set of indexed fields, including, but not limited to:

· author

· title

· subject

· series

· call number

· ISBN/ISSN

· publisher

· notes

· other system control numbers (such as the OCLC control number).

C.9. Fields in the holdings and item records shall be indexed and searchable C.10. It shall be possible to search across all types – bibliographic, physical, digital, electronic in one search query.

C.11. It shall also be possible to set a pre-search filter – for example by:

· Bibliographic information

· Physical title

· Physical item

· Electronic information.

C.12. The system shall support the ability to search by local call numbers and by shelving location, along with all other standard library search criteria.

C.13. Based on staff queries it shall be possible to save and manage result sets.

C.14. It shall be possible to search for electronic resources by, but not limited to: title (e.g. journal title), package, and by provider.

C.15. Dependent on the search type, it shall be possible – from the results list - to edit a record, create an order, view holdings, items, etc.

C.16. It shall be possible to sort result sets by various parameters – e.g. ranked, title, author. There shall be more than one level of sorting.

C.17. The system shall support searching of local bibliographic and authority fields.

C.18. When logging in to the solution, the staff shall be navigated to a personalized desktop or dashboard.

C.19. It shall be possible to post widgets of report outputs on the desktop or dashboard.

C.20. It shall be possible to add/remove/reorder the widgets on the desktop or dashboard.

C.21. It shall be possible to view the library’s calendar (open hours and days) from the desktop or dashboard.

C.22. It shall be possible to create customized widgets (e.g. a world clock) that can be added to the desktop or dashboard.

C.23. The system shall support a robust and flexible yet straight-forward system for assigning roles and permissions to staff functions.

C.24. The system shall provide granular access control rights for staff accounts and be able to facilitate multiple profiles accessing different combinations of functional areas.

C.25. The system shall support the option of defining role templates which can then be easily assigned to new staff.

D. Discovery Layer Interoperability

D.1. The solution shall support a complete and transparent integration with a next-generation discovery solution.

D.2. The solution shall support seamless patron-driven workflows initiated from discovery and served by the system such as, but not limited to: digitization on demand, patron driven acquisition, and ILL requests.

D.3. The discovery solution shall support discovery and delivery of all resource types: physical, electronic and digital, as well as discovery by collections.

D.4. The discovery layer shall allow for local library resources to be searched both on its own and combined with online aggregated resources.

D.5. The discovery layer shall support the option of integrating a Map App, or similar capabilities to give the patron details about where the requested item is located in the library.

D.6. The system shall have the ability to publish records to discovery with enriched headings information from the shared catalog.

D.7. The system shall publish authentication and public notes for display to the patrons.

D.8. Patrons shall be able to see all of their account information (loans, requests, saved searches, user interface customizations, etc.) in the library’s discovery solution.

D.9 The system shall present to patron (through the discovery interface) options to fulfill patron requests across all relevant resource types. The system shall include a citation linker to request services for a specific article, book, or journal either through the library or as a resource sharing request.

D.10. The system shall provide published APIs or Web Services to facilitate interoperability with external services.

D.11. The discovery solution shall deduplicate search results.

D.12. The discovery solution shall allow the library to tweak the algorithm used for relevancy ranking.

D.13. The solution shall include personalized ranking to tailor search results based upon patron research preferences.

D.14. The solution shall include an article recommender service that suggests articles based on actual researcher activity.

D.15. The solution shall be delivered with a mobile phone interface.

D.16. The solution shall provide browse search for the catalog materials for the following entities:

D.17. The resource discovery layer shall process and reflect new, updated, and deleted bibliographic, holdings, authority, and item data from the next-generation system at least once per day without library staff intervention.

D.18. The resource discovery layer shall provide a unique view for each library using the system.

E. System Architecture and Security E.1. The system shall be hosted in a cloud or SaaS environment.

E.2. The cloud environment shall assure complete data protection and have high security capabilities in place with certification for ISO 27001 Information Security Management. The NGLS Contractor shall be capable of meeting requirements for Federal Risk Authorization and Management Program (FedRAMP) sufficient for government data considered LOW confidentiality risk, LOW integrity risk, and LOW availability risk. NGLS Contractor shall host the system at a data center within the United States.

E.3. The cloud environment shall be able to integrate with the institution’s local LDAP for authentication. The cloud environment shall also be able to integrate with a library’s EZ-Proxy server for authentication.

E.4. The system shall be scalable to meet the load of many institutions without performance impact.

E.5. The cloud system shall be fully fault-tolerant without single point of failure. Describe.

E.6. The system shall support basic fulfillment capabilities via offline circulation during local institution network outage. Describe the solution.

E.7. The NGLS Contractor shall allow on-site access to the data center where the system is hosted upon request by authorized representatives of the Department of State in order to observe security measures in place at the data center.

F. Support and Maintenance F.1. The NGLS Contractor shall guarantee a high level of support, up time, consistent and reliable and timely customer service, and emergency procedures.

F.2. The NGLS Contractor shall regularly enhance the products based on customer input and industry changes.

F.3. The NGLS Contractor shall provide initial training in all aspects of the system as the system nears full production.

F.4. The NGLS Contractor shall provide a sandbox version of the system that the library can use for testing and training purposes. The sandbox version shall be kept up-to-date with all of the latest releases of the system software.

G. Implementation and Migration Services G.1. The NGLS Contractor shall work with the library staff and the contractor of our current ILS, discovery tool, and remote hosting (Ex Libris) to migrate data.

G.2. Migration shall include ERM data, acquisitions data (including active and completed purchase orders, vendor records, invoices, fund ledgers), along with local bibliographic data in existing records and local authority records.

G.3. The integrity and quality of the data will be maintained in the migration process.

G.5. The target timeline for implementation shall be (4) months from the date of the contract signing.

Appendix 1 contains Detailed Description of System Module Requirements, all of which shall be satisfied through the NGLS contractor’s system.

H.2 Delivery All deliverables shall be submitted to the COR designated in the COR appointment letter as well as the appropriate Government Technical Monitoring official if any.

H.3 Place of Performance Because the system is entirely hosted by the NGLS Contractor, and access to the system by library staff and library customers is browser based, place of performance will be at the NGLS Contractor’s location. The NGLS Contractor shall monitor the system 24 hours per day, seven days per week.

H.4 Period of Performance The period of performance will be one base year plus four optional year of performance from the contract award date.

H.5 Quality Control Plan The Contractor shall develop a Quality Control Plan (QC Plan) for the term of the contract that establishes and maintains well documented control procedures that ensure the production and deliverance of acceptable performance and materials in accordance with this Statement of Work. The QC Plan shall assure adequate quality control throughout all areas of contract performance, and shall be implemented to assure reliability and effective performance. The Government reserves the right to review the quality controls established, and to evaluate its effective use in the performance of the requirements under this contract. The Contractor shall be solely responsible for controlling and assuring quality work, and providing objective evidence that such controls do, in fact, exist. The Contractor shall also be liable for Contractor employee negligence, and any fraud, waste or abuse. It shall be the responsibility of the Contractor to enforce all QC Plan requirements for any and all subcontractor(s).

After award, the contractor must submit updates to ensure the plan is current with contract and his Quality Inspection Program. Updates shall be submitted with one copy to the Contracting Officer and one copy to the Contracting Officer’s Representative H.6 Acceptance The Contracting Officer's Representative (COR) is a Government official who has been delegated specific technical, functional and oversight responsibilities for this work. The COR is designated in the COR appointment letter, issued by the Contracting Officer, and is responsible for inspection and acceptance of all services, incoming shipments, documents, and services.

H.7 Acceptance Criteria Certification by the Government of satisfactory services provided is contingent upon the Contractor performing in accordance with the terms and conditions of the agreement and all amendments.

H.8 Government Acceptance Period The COR or appropriate technical official will have thirty (30) workdays after full implementation to review functionality of the system and completeness of data migration and request corrections. The Contractor shall have ten (10) workdays to make corrections. Upon receipt of the final deliverables, the COR or appropriate technical official will have ten (10) workdays for final review prior to acceptance or providing documented reasons for non-acceptance.

The COR in consultation with the appropriate technical official will have the right to reject or require correction of any deficiencies found in the deliverables that are contrary to the information contained in the Contractor's accepted quote. In the event of a rejected deliverable, the Contractor will be notified in writing by the COR of the specific reasons for rejection. The Contractor shall have ten (10) workdays to correct the rejected deliverable.

H.9 Non-Disclosure Agreement & Protection of Information The Contractor shall sign one copy of the attached Non-disclosure Statement on behalf of the company, only if applicable, and shall also ensure that all staff assigned to, including all subcontractors and consultants, or performing on this order execute and adhere to the terms of the following non-disclosure statement, protecting the procurement sensitive information of the Government and the proprietary information of other Contractors. Assignment of staff who has not executed this statement or failure to adhere to this statement shall constitute default on the part of the Contractor.

H.10 Progress and Status Reporting Requirements Once implementation begins, the Contractor will provide weekly reports for the following milestones:

For the Integrated Library system: Migration of data: bibliographic, acquisitions-related, circulation-related, serial check-in-related.

For the Remote Hosting: Confirmation of access by library staff.

For the Discovery Tool: Implementation, testing, requested modification.

H.11 Status Meetings Contractor personnel will be required communicate with Government and/or other contract representatives to meet the requirements of this order. Contractor personnel shall make their contractor status known during introductions.

APPENDIX 1

DETAILED DESCRIPTION OF SYSTEM MODULE REQUIREMENTS

Appendix 1 expands on the high level requirements outlined in A.1 through A.6. Appendix 1 lists the functional requirements for each module of the NGLS.

I. Acquisitions System provides a functional, integrated acquisitions process that manages fund allocations, commitments, and expenditures for the library for selecting, ordering, receiving, claiming, invoicing, cancelling, payment, and reporting.

1. The system shall support the following purchasing workflows:

· Print firm order

· Print continuation or subscription

· Electronic firm order (package or single-title)

· Electronic subscription (package or single-title)

· Patron-driven acquisitions

2. The system shall support workflows for ordering and invoicing.

3. System shall include:

· the ability for purchase order number and invoice number fields to be variable length;

· the ability to edit purchase order number and suffix to comply with Department of State standards; and

· the ability to edit invoice number and suffix until the invoice is paid.

4. The system shall allow:

· an authorized staff member to cancel line items and reverse fund encumbrances.

· an authorized staff member to edit amounts and funds and adjust encumbrances at payment.

· an operator to receive and invoice in one step.

· multiple funds per order record.

· receipt and payment for incomplete orders.

· Suppression of some on-order items and on-order bibliographic records from display in patron interface.

5. System shall have the ability to use any indexed field as a basis for duplication and to change the duplicate field preferences for different material types and situations.

6. System shall have the ability to create and activate new vendor accounts in real time.

7. System shall have the ability to provide an acquisition status report that includes appropriations, encumbrances, expenditures, and funds available.

8. The system shall manage the acquisition lifecycle such that:

· 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

9. The system shall provide links from a purchase order to other related information such as invoice, vendor, and linked descriptive record.

10. The Acquisitions workflow shall support a full EDI interface with major library vendors for ordering and invoicing.

11. The system shall support workflows for patron-driven acquisition of electronic books, including:

· Loading and deleting candidate records for patron discovery

· Loading EOD MARC records to create purchase orders for purchased items

· Loading invoices for purchased items

· Creating local inventory for purchased items

12. The system shall allow staff to select and purchase print and electronic resources through major library vendors, with the completed transactions being automatically reflected in the system.

12.1. The system shall allow staff to check availability of resources before placing orders via a major library vendor’s selection platform.

13. The system shall support adding interested patrons associated with a purchase, including:

· The placement of holds against titles on order and in process.

· The option to automatically notify the patron (s) when the resource is available (received or activated).

· The option to automatically place a hold on a physical item on behalf of the interested patron once the item becomes available.

14. The system shall support setting up trials to evaluate e-resources before purchasing, which will include managing participant feedback and groups of participants.

15. The system shall support the ability to evaluate existing e-resource subscriptions and make a decision to renew or cancel based on parameters such as usage and cost.

16. The system must support the process for obtaining and recording pricing, product descriptions and reviews for electronic resource products.

17. The system shall allow for the activation of approved purchases for electronic packages and titles.

18. The system shall support evaluation and renewal of e-resource items.

19. When an electronic package or title is activated, descriptive records to describe the title(s) shall be added to the catalog automatically.

20. The system shall support the subscription tracking process including the subscription period, cost, payment, renewal, and cancellation.

21. The system shall support electronic resource management, including the recording and tracking of:

· Contact information for technical support billing/payment, licensing and other contacts

· URLs and login information for resource administration

· Access parameters

· Type of purchase

· Library-defined notes

22. The system shall allow print items to be received as part of the invoicing process, or as a separate process.

23. The system shall allow for the receipt of the following item types:

· Single-title monographs

· Monographs issued in sets

· Issues of journals and serials

· Subscriptions

· Standing orders

24. The system shall be able to automatically create new item records when an item is received.

24.1. If the library chooses to create item records at the time of acquisitions, the system shall allow for updating item information.

25. The system shall notify staff when a volume or issue of a series has not arrived after a predefined interval, and allow for claiming of missed items.

26. The system shall identify where to route received items based on the completeness of their metadata and item information (i.e., to cataloguing, physical processing, or shelves).

27. The system shall provide the ability to maintain multiple accounts for a single vendor.

28. The system shall provide the ability to maintain multiple physical and email addresses for a single vendor, with the potential to tie these addresses to individual accounts.

29. The system shall offer the ability to maintain discount and delivery and claim information in the vendor record.

30. Invoices linked to a vendor shall be linked to the vendor record. It shall be possible to navigate from the vendor record to an invoice with a minimum number of key strokes.

31. It shall be possible to include vendor-specific EDI information.

32. The vendor record shall support copies of all communications between the vendor and the library. These shall include both communications generated automatically by the system (e.g. claims), and communications created manually by library staff.

33. The system shall support the recording of EDI information specific to each library using the system.

34. Vendor records shall have links to all vendor related invoices

35. The vendor record shall include links to all purchase orders made against the vendor.

36. The system shall provide real-time access to fund balances (including encumbrances and expenditures).

37. The system shall support a hierarchical fund structure that provides the ability to group and report on funds.

38. Library staff shall be able to define and activate rules related to specific funds (e.g., related to over- encumbrance, over-expenditure). These rules shall be inherited by funds on a lower level of the hierarchy. It shall also be possible to override rules defined at a higher level.

39. The system shall support fiscal year close processing.

40. For each fund, the system shall provide links to invoices and purchase orders encumbered against that fund.

41. The system shall support the reporting of fund balance, allocation, expenditure, encumbrances

42.System shall produce fund summary reports that include fund allocations, amount encumbered and expended, remaining available, and percentage encumbered and expended for a given fiscal year.

43.System shall allow staff to adjust the amount encumbered and expended in a fund.

44.System shall provide a complete audit trail for fund allocations and adjustments by staff members.

45. The system shall support updated encumbrance estimations for foreign currencies based on daily conversion rates for foreign currencies stored as a central service.

46. The system shall support multiple ledgers and funds so that purchases of resources for non-library Offices and Bureaus can be tracked and maintained separately from purchases for the library collections.

47. The system shall support the ability to automatically create an invoice from the purchase order.

48. The system shall provide the option to manually create an invoice, or to load invoices from an Excel file.

49. The system shall support the export of payment requests to ERP systems, as well as the import of payment confirmation files.

1. The system shall have the capacity to manage all types of library material, e.g. books, serials, electronic resources, digital materials, e-book readers, etc.

2. The system shall provide integration with third-party ILL systems using standard protocols, including ISO 10160/10161 and ANSI/NISO Z39.83 (NCIP).

3. The system shall be cable of circulating e-book readers that have multiple e-books loaded on them.

4. The system shall allow the library to define the policies by which their physical inventory is circulated to library patrons, for example – due date policy, maximum renewals policy, etc.

5. The system shall provide the ability to set parameters including for loans, limits and calendar, globally or at the individual library level.

6. The system shall manage automated and manual generation of overdue and courtesy notices with customized messages available as an option to the librarian.

7. The system shall provide the ability to create different patron types and set circulation parameters for each type of patron.

8. The system shall allow authorized staff to create, modify, and delete patron records.

9. The system shall allow library staff to update defined areas of each patron record (core information, addresses, and phone numbers). Patrons shall be able to have multiple addresses and different types of address (office, e-mail, etc.).

10. The patron record shall have a field to record the patron’s official Department of State Bureau or Post affiliation code.

11. The system shall allow EZProxy for authentication.

12. The system shall be able to define more than one patron identifier linked to a patron record

13. The system shall support online patron self-registration including the ability to restrict patron self-registration by IP range. Patrons shall be able update their own patron records as needed.

14. The system shall support business rules that automatically manage patrons’ requests, requiring staff mediation only when necessary.

15. The system shall allow a patron to designate, when placing a request, whether the requested item is digital or print.

16. A patron-initiated digitization request shall trigger an alert and a pick slip at a specific digitization location.

17. The system shall automatically generate a notice to patrons when requested items are available. This notice shall be in the form of an email message or an SMS text message. This message shall be generated in real time.

18. The system shall support the administration of access rights for digital materials, based on patron group and collection.

19. The system shall support the administration of access rights for electronic materials, including the ability to restrict access by IP address.

20. The system shall allow for delivery of items to a particular circulation desk, or a patron’s home or office, depending on permissions.

21. The system shall support hold queue priority.

22. The system shall support library configurable recall options.

23. The system shall support digitization on demand workflows.

26. The system shall support ILL functionality – both for borrowing and lending

27. This functionality shall allow for mediated or unmediated requests III. Metadata Management (Cataloging)

1. The system shall support multiple metadata formats and be extensible to additional formats. At a minimum, MARC21 and Dublin Core shall be available out-of-the-box for the library, with future support for other metadata schema and emerging standards which may serve as a successor to MARC21. The metadata management environment shall support functions appropriate to these formats.

2. The system shall allow staff to create, edit, and delete records in any supported metadata schema.

3. The system shall support import and export (with no loss of data) in all supported metadata schema.

4. The system shall have embedded support for RDA including the indexing of RDA specific elements.

5. The system shall support validation of appropriate use of elements, fields, subfields, and values, including validation of controlled vocabularies such as Library of Congress Subject Headings and locally defined vocabularies, for fields.

6. The system shall support Unicode text for importing, editing, storage, and export.

7. The system shall support the ability to edit all records through an online editor, including any element, field, subfield, and fixed field value as appropriate for the format.

8. The system shall have the same editing capabilities for all material types (physical, electronic and digital).

9. The system shall notify the cataloger when a record being edited or saved matches an existing record in the catalog.

10. The system shall support relevant online help for fields cataloged.

11. The system shall allow catalogers to save drafts of records without committing them to the catalog. The system shall also auto-save drafts of records or changes to existing records to prevent loss of data.

12. The system shall 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.

13. The system shall support record versioning, including the ability to view and roll back to past versions of that record.

14. The system shall support hotkeys for navigation and actions that allow editing entirely with the keyboard.

15. The system shall 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.

16. The system shall be able to support library-defined rules for manipulating records either on import or in the online editor.

17. The system shall support the option of library defined merge routines that can be applied to records imported in bulk and one by one in the catalog editor.

18. The system shall 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 shall be able to specify a group of records to be withdrawn from a collection or moved to an off-site storage facility; the library shall 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 shall be able to define, on export of records, various data transposition routines, etc.

19. The system shall support all linking an electronic, digital or physical item to one metadata record.

20. The system shall allow global changes of item and order records within the system.

21. The system shall support a tool for printing labels.

22. The system shall support the suppression of bibliographic records from the discovery layer.

23. The system shall support a “bound with” solution that allows multiple bibliographic records to be linked to the same holdings or item record.

24. The system shall provide access to global, shared authority files without the need for individual libraries to synchronize with the authorizing agency. The files shall include Library of Congress Subject Headings and Names, and Medical Subject Headings (MeSH).

25. The system shall allow libraries to create or load local authority files and records for subjects (including genre terms) and names.

26. The system shall support authorization of bibliographic headings against local and global headings in authority records.

27. When an authorized access point changes in a local or global authority record, the system shall automatically make the change in bibliographic records that are authorized against that access point without staff intervention. The system shall flag changes that request staff decisions, such as heading splits and newly qualified names.

28. It shall be possible to search the authority database, and link back to bibliographic records in the local catalog from authorized access points in the authority database.

29. The system shall support the MARC21 format for holding records.

30. The system shall allow for the creation of holdings and item records for physical resources.

31. The system shall support the ability to perform changes in bulk against a set of holdings or items.

32. The system shall support the recording of missing/lost items.

33. The system shall support the suppression of holdings records from the discovery layer.

34. The system shall allow for the loading records singly and in bulk.

35. The system shall allow for searching external databases such as OCLC WorldCat through the online interface via Z39.50 or SRU/W and importing resulting records to the catalog. The system shall allow copy cataloging to be done without requiring separate login.

36. When loading a record or set of records, staff shall have the following options for handling records detected as duplicate:

· Add new records, ignoring duplicates

· Overlay one record with the other

· Merge the two records

· Not load new records when a duplicate is detected

37. The system shall allow for validation of incoming records according to library-defined validation rules.

38. The system shall allow for the enhancement of incoming records according to library-defined bulk record change rules.

39. The system shall allow for the export of individual, groups of records, or an entire catalog 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.

40. The system shall 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.

41. The system shall allow for export of new, changed, and deleted bibliographic, authority, holdings and item data to the resource discovery layer at least once per day without requiring any library staff intervention.

42. The system shall provide access to a catalog of bibliographic records shared by all libraries of that system. Libraries shall be able to attach holdings directly to the shared records, edit the records, and copy them from the shared catalog to the libraries’ local catalog.

43. The system shall support a local catalog in addition to the shared catalog for storing records that have local descriptive needs or terms of use that prevent their being shared with other libraries. Libraries shall be able to use the shared catalog, the local catalog, or both simultaneously.

44. The system shall support the addition of local fields to the shared records that are viewable only to the local library.

45. The solution shall allow for sharing bibliographic metadata between two or more libraries, while at the same time allowing individual libraries to record and maintain information of local importance.

46. The system shall allow the option for local bibliographic records that are not contributed to any shared database of bibliographic records.

IV. Central Knowledge Base

1. The accuracy and scope of the Knowledge Base shall be maintained by the vendor and updated to track changes made by information providers, new resources to the library’s collection, as well as other changes.

2. The Knowledge Base shall support accurate indexes that facilitate resource discovery for library customers.

3. The Knowledge base shall allow the library to add and remove local resources in a simple manner.

V. Link Resolution

1. The system shall be able to accept Open URL and context sensitive services as well as resolving the services. Describe the functionality your software supports in this area.

2. The system shall support the ability to augment the Open URL metadata.

3. The system shall be able to compensate for cases where the Open URL resolves to multiple records.

4. The discovery layer shall provide a summary of journals available to patrons and staff (an A-Z list).

5. The link resolver’s services menu shall be customizable by the library.

VI. Licenses Management

1. The system shall be able to manage licenses and amendments, including attaching digital versions. License management shall be included in the system and not require additional setup or fees.

2. The system shall support the ERMI schema for licenses, including the ability to display only those fields that the library uses, excluding the remainder if the library so chooses.

3. The system shall enable license terms to be displayed to the patrons. The terms that are displayed as well as the labels shall be configurable.

4. All the electronic resources linked to a license shall be viewable from the license record

VII. Reporting and Analytics

1. The solution shall include a comprehensive analytics component that covers all of the ILS data and is an integral part of the system.

2. The system shall include functioning standard reports provided by the NGLS Contractor.

3. The reporting system shall support a variety of output options including, but not limited to viewable online, send to printer, email and export to a spreadsheet.

4. The reporting system shall support the customization of reports by librarians; this includes, but is not limited to: changing of reports parameters, views, time range, etc.

5. The reporting system shall support the ability to collaborate and share reports made by other parties.

6. The reporting solution shall be able to provide usage statistics reports and comply with industry usage reporting standards such as SUSHI, COUNTER.

7. The system shall support the ability to subscribe to report outputs.

8. The system shall support role-based report generation and viewing such that staff will only be able to view reports and data according to his role.

9. The system shall be able to analyze historical data and provide trends analysis (such as usage, expenditure).

10. The reporting application shall allow for the automatic scheduling of reports at defined intervals (daily, weekly, or monthly)

11. The reporting application shall provide cost-per-use reports for electronic subscriptions using accurate cost data based on the actual PO lines.

12. The system shall store records, data, and reports from library processes indefinitely at no additional charge.

13. The system shall provide a “new books list.”