20240607_ArmyU_Library_Definition_of_Requirement_V5.pdf

Army University Library System Platform

Ft. Leavenworth, KS

7‐June‐2024

1. Introduction and Overview

The Army University Library System (AULS) is a consortium with 1 central administrative office called the

Library Enterprise Division (LED) and 16 U.S. Army academic libraries located at TRADOC Centers of

Excellence and Schools, supporting Officer, Warrant Officer, and Non‐Commissioned Officer education.

AULS requires a commercial off‐the‐shelf (COTS), fully cloud hosted Library System Platform (LSP).

AULS includes approximately 99 library staff serving an FTE of 45,802. All AULS libraries have been migrated and merged into a single integrated library system (ILS). As of August 2023, the ILS includes approximately 836,758 bibliographic records and 903,239 copies. There are currently 3 digital asset manager instances with a combined file size of 231.71 GB and a total of approximately 64,120 records, the majority of which have been added to the catalog and are included with the bibliographic record total.

2. Scope

The contract shall provide an LSP to support operations of the LED central administrative office and 16 libraries located across the United States, as well as the technical, management, and support services for training, migration, application implementation, and continued regular maintenance. Up to three (3), for a total of 20 libraries may be added in the future through contract modification.

3. Objectives

At a minimum, the LSP must include the following staff functions: Acquisitions, Cataloging, Circulation, Digital Asset Manager, Discovery, Inventory, Reports, Staff Search, and User Accounts. The LSP must also include a customizable public search interface, or online public access catalog, for each AULS site.

4. Technical Requirements

4.1 System‐wide Requirements

4.1.1 The system must provide fully cloud‐based architecture and hosting that does not require use of any locally installed vendor‐client software on customer equipment.

4.1.2 The system must meet the Federal government section 508 compliance requirements based on Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d), with updates from the

Information and Communication Technology Standards and Guidelines (36 CFR Part 1194).

4.1.3 The system and data shall be physically located and operated in the Continental United

States.

4.1.4 The system and data shall be managed and operated by U.S. Citizens or approved qualifying contractors and subcontractors.

4.1.5 The system architecture should be configurable, customizable, and expandable for a variety of resources and for further AULS development in response to future needs.

4.1.6 The system must support operations for the 16 libraries and LED, providing administrative controls for LED to manage AULS‐wide settings.

4.1.7 The system must allow authorized staff to configure various aspects of the LSP, such as loan periods and library hours, without vendor intervention.

4.1.8 The system must provide a Responsive Web Design (RWD) to accommodate various device platforms and support for various web browsers across multiple platforms (e.g., Windows, iOS, Android, others) for both staff and end‐users, specifically Edge, Mozilla Firefox, Chrome, and Safari and provide support for two earlier versions of listed browsers.

4.1.9 If the system includes a mobile app, the app must be compatible with Android and IOS devices.

4.1.10 The system default shall be English.

4.1.11 The system shall provide help screens, user guides, and informational resources for both staff and end‐users.

4.1.12 The system shall provide a library staff portal, including an online help desk, trouble ticket reporting, release notes, and a “Frequently Asked Questions (FAQ’s)” section.

4.1.13 The system shall allow authorized users to make batch updates and global changes to all types of records.

4.1.14 The system shall report on the outcome of batch processes, including failures.

4.1.15 When logging into the system, the staff user shall be navigated to a personalized dashboard.

4.1.16 All staff and patron interfaces shall be graphical user interfaces (GUI).

4.1.17 All edits and updates by staff users shall be logged by the system.

4.1.18 The system shall support a multi‐tasking environment, allowing a single staff user to be in multiple modules at the same time.

4.1.19 For streamlining labor‐intensive or repetitive tasks, the system shall offer options including, but not limited to, native keyboard shortcuts.

4.1.20 The system must support the ability to import and export various file types, including but not limited to, TXT, CSV, XML, DAT, MRC, MARCXML, PDF, WAV, MP4, JPG, DOCX, PPTX, TIF.

4.1.21 The system shall include robust and extensive APIs and provide capability for bi‐directional

APIs (including documentation and support).

4.1.22 The system shall allow external systems to search and retrieve records from the system via

Z39.50 with various access points, including local data fields/subfields.

4.1.23 The system must be compatible with RFID and the latest NISO SIP2 standard. AULS currently utilizes Envisionware and 3M Bibliotheca RFID systems. Vendor must identify compatible

RFID systems and provide information on how to integrate with tag formats, gates, self‐ check systems, mobile DLAs, RFID antenna, and software, as well as ILS inventory routines.

4.1.24 AULS currently utilizes these peripherals: Honeywell Voyager MS9520/MS9540; Honeywell

Voyager 1400g; Honeywell Hyperon 1300G; Honeywell 3800g; PSC QuickScan 6000/6500;

Tech Econwand IDT1230‐U. Vendor must identify if those listed will work with system or provide a list of scanners that are compatible.

4.1.25 The system shall support a sandbox environment that provides a full replication of data and configurations from the production environment for both the staff environment and the

OPAC/discovery layer at least twice a year. The vendor should support a timely off‐cycle refresh upon request from AULS.

4.2 Security

4.2.1 A FedRAMP system is preferred and will receive higher consideration by the evaluation board. If not FedRAMP, refer to 4.2.7 for minimum security standards. The LSP shall meet one of the following conditions as outlined in 4.2.2, 4.2.3, or 4.2.4.

4.2.2 The vendor shall be FedRAMP authorized to provide a cloud‐based LSP and must provide authorization letter with impact level at which the Contractor has been assessed and authorized. If subcontractors are involved, each party shall have the above stated FedRAMP authorization or federal agency‐issued ATO letter stating the authorization.

4.2.3 If the system is not FedRAMP authorized, the LSP provider shall demonstrate that it is actively working toward authorization by the fact that it is listed on the FedRAMP

Marketplace website at https://www.fedramp.gov as either “Ready” or “In Process.”

4.2.4 If the system is not FedRAMP authorized or found listed on the website above, the LSP provider shall demonstrate that the LSP is hosted on a FedRAMP authorized cloud. The cloud’s name and the physical location of the servers shall be identified. The cloud’s name shall be listed under “Authorized” on the website above.

4.2.5 The contractor may be required to undergo an Assessment and Authorization of security and privacy controls and receive an ATO from Army.

4.2.6 In accordance with AR 25‐2, post contract award, the Government will perform a review for a local ATO decision, required for go‐live, and ongoing security and privacy assessments for continuous monitoring thereafter. The Government will determine the risk rating of identified vulnerabilities. The Contractor shall respond to the Government with an action plan and schedule to mitigate security or privacy risks found within 10 business days of notification of security or privacy risks. The Government will notify the Contractor of whether or not the action plan and schedule are acceptable. The Contractor shall implement the action plan according to the agreed‐upon schedule.

4.2.7 The Vendor must provide the following certificates: System and Organization Control SOC 1 Type 2 and SOC 2 Type 2 certifications; ISO 27001 security certification (Information security management systems); NIST 800‐53 SP‐3 certification; ISO 27018:2019, certification (Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors); ISO 27017:2015 certification (Security controls for the cloud); and ISO 22301:2019 certification (Business continuity management systems). Compliance with NIST 800‐171 (Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations) is preferred.

4.2.8 The system must operate in a Family Educational Rights and Privacy Act of 1974 (FERPA)‐ compliant environment or a demonstrated equivalent.

4.2.9 Army data stored on the site (data‐at‐rest) must comply with AR 25‐2.

4.2.10 Some data under this effort may be considered Personally Identifiable Information (PII), and as such is subject to Privacy Act protection measures as prescribed in Chapter 5 of AR‐25‐22.

Other personal information that may not be initially recognized as PII, when combined with other pieces of information, may become PII and therefore all personal data is sensitive and should be protected. PII includes data that identifies, links, relates, or is unique to, or describes an individual, e.g., SSN; age; military rank; civilian grade; marital status; race;

salary; home/office phone numbers; other demographic, biometric, personnel, medical, and financial information, etc. PII shall not be released either formally or informally to anyone without the written consent of the Government. Any data breaches shall be reported to AULS staff within 24 hours of the incident.

4.2.11 The system shall be actively monitored for security and regularly updated with the latest security and stability releases.

4.2.12 The system shall be protected via measures such as firewalls and other security devices.

4.2.13 The vendor shall provide detailed, up‐to‐date, and accessible system documentation, including, but not limited to, documents of software architecture, data dictionary, security technical information guide (STIG), entity relationship diagrams, and a list of ports, protocols, and services, as well as administrator and user manuals.

4.2.14 The vendor must provide their Cybersecurity and Information Assurance Incident Response

Plan. The plan will include details pertaining to the management, mitigation and reporting of all security incidents. The data includes all analytical data such as the initial reporting, remediation, damage assessment and final reports pertaining to the incident. Vendor shall provide the government a point of contact with the emergency cyber incident response plan.

4.2.15 In the event of a cyber incident on the system, the system must generate audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event. The audit records shall be retained for a minimum of 1 year and be available for Army use.

4.2.16 Vendor must provide a protocol to document and rapidly assist customer with expunging from the cloud‐based system any bibliographic record(s) and associated full‐text content that is deemed to be un‐releasable, subsequent to said item(s) having been placed into the cloud‐based system (such restricted spillage may cause significant harm to US national security interests). Vendor shall be able to provide proof of expungement if requested.

4.2.17 The hosted solution shall provide protection at all security levels 1‐4 Perimeter (see link below); (Operating systems and servers; Host Protection; Information Protection) including intrusion detection, reference DoD Cloud Computing Security Requirements Guide

(https://public.cyber.mil/dccs/).

4.2.18 The system must operate on machines running current Microsoft Windows (64bit)

Operating Systems or higher in an encrypted environment and provide support for one previous version of the OS.

4.2.19 Third party access to the environment must be vetted and monitored per company policy and access is immediately disabled once no longer needed or when access is determined to be inappropriately provisioned in accordance with third party or service provider agreements.

4.2.20 The system shall prevent the staff and patron users from signing on after invalid login attempts. The system must provide an option for reset of password for both staff and patron access.

4.2.21 The system shall be able to accept authentication passwords for users that conform to US Army requirements (at least 14 characters, upper and lowercase, numbers, and special characters) and provide support for secure/encrypted staff connections via VPN to the hosted server.

4.3 Acquisitions

4.3.1 The system shall retain acquisition records until deleted by staff.

4.3.2 The system shall allow purchase orders to be deleted under certain conditions.

4.3.3 The system shall generate alerts and reminders for acquisitions staff.

4.3.4 The system shall allow the library to configure if items being acquired are displayed (or not) in the OPAC/discovery tool.

4.3.5 The system shall support the ability to perform an overlap analysis report by library for resources, including the ability to upload/paste a list of titles or standard numbers (ISBNs, UPCs) that the library is considering acquiring to determine whether the titles are part of the library collection.

4.3.6 The system shall have the ability to automatically create a purchase order (PO) via MARC import and via text or excel file import.

4.3.7 The system shall link specific fields, such as order notes, from purchase orders and line items to other related information such as, but not limited to, invoice, vendor, and linked bibliographic records and copies.

4.3.8 The system shall allow a purchase order to be relinked from one bibliographic record to another.

4.3.9 The system shall retain canceled items on the PO and differentiate canceled items from remaining lines.

4.3.10 Upon cancelation of an item, the associated on‐order copy will be deleted.

4.3.11 The system shall allow the cost of an order to be split between funds.

4.3.12 The acquisitions workflow shall support a full EDI interface, using the EDIFACT standard.

4.3.13 The system shall create an audit trail on orders.

4.3.14 The system shall allow for distinct levels of authorization for ordering workflows to be set.

4.3.15 The system shall allow a variety of order templates to be created/used.

4.3.16 The system shall support adding and managing user requests to bibliographic and copy records, including, but not limited to, placing a hold on a physical item on behalf of the interested user(s) and to automatically notify the user(s) when the resource is available.

4.3.17 The system shall allow the operator to update and add new PO lines after an order is created and receiving has started.

4.3.18 The system shall allow individual or multiple items to be received.

4.3.19 Real‐time access to fund balances (including encumbrances and expenditures) shall be supported.

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

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

4.3.22 The system shall support the ability to continually recalculate encumbrances based on the current date.

4.3.23 The system shall support the option of transferring money from one fund to another.

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

4.3.25 The system shall support different types of vendors – e.g. licensor, licensing agent, content owner, subscription agent, access provider, vendor/payee. The system should allow staff to customize vendor types.

4.3.26 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.

4.3.27 It shall be possible to include vendor‐specific EDI information.

4.3.28 Vendor records shall have links to all vendor related invoices, purchase orders, and order lines.

4.4 Cataloging

4.4.1 The system shall support and differentiate the holdings of the LED centralized office and 16

AULS libraries.

4.4.2 The system shall support MARC21 and BIBFRAME, with future support for other formats.

4.4.3 The system shall allow staff to create, edit, and delete records in any supported format.

4.4.4 The system shall support import and export in file formats, including but not limited to, DAT, MRC, TXT.

4.4.5 The system shall have embedded support for Resource Description and Access (RDA) including the indexing of RDA specific elements.

4.4.6 The system shall support customizable validation of appropriate use of elements, fields, subfields, and values, including, but not limited to, validation of controlled vocabularies and allowable values for fields.

4.4.7 The system shall support the creation of multiple validation tables that can be selected and applied at metadata import.

4.4.8 The system shall update the MARC tag tables when updated by Library of Congress. The system shall allow local changes to the tag tables.

4.4.9 Text in all records shall support Unicode encoding for indexing, search, importing, editing, storage, and export.

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

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

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

4.4.13 The system shall support relevant online help for elements cataloged.

4.4.14 The system shall support drop down lists for value vocabularies including, but not limited to, country codes, language codes, content types, media types, and carrier types.

4.4.15 The system shall support controlled vocabulary for defined fields.

4.4.16 The system shall support the option to suppress records from the OPAC/discovery tool.

4.4.17 The system shall support input and display of the full Unicode character set including, but not limited to, diacritics and non‐Roman characters.

4.4.18 The system shall support the creation and storing of record templates for use in creating and editing records, including, but not limited to, specifying default elements, fields, subfields, and values stored in these templates.

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

4.4.20 The system shall support linking to and access of related records.

4.4.21 The system shall support the ability to perform changes in bulk against a set of bibliographic, holdings, and authority records, including, but not limited to, the ability to alter any element, field, subfield, or fixed field value subfields, as well as specific strings within fields and subfields, at both the local and consortium level according to user authorization.

4.4.22 The system shall be able to support library‐defined rules for manipulating records either on import, export, or in the online editor.

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

4.4.24 The system shall allow the library to define and group 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.

4.4.25 It shall be possible to link an electronic, digital or physical item to one metadata record.

4.4.26 The system shall provide the ability to derive a new bibliographic record from an existing record.

4.4.27 The system shall provide access to global, shared authority files without the need for individual libraries to synchronize with the authorizing agency.

4.4.28 The system shall allow libraries to create or load local authority files and records for subjects

(including genre terms) and names.

4.4.29 The system must support multiple classification schema and subject vocabularies including, but not limited to, Library of Congress Classification and Subject Headings, Dewey Decimal

Classification, SuDoc classification numbers, local classification schema, National Library of

Medicine Subject Headings, and LC Genre Form Terms. The system must enable each library to operate under multiple schema that may differ at each location.

4.4.30 The system shall support authorization of bibliographic headings against local or global headings in authority records.

4.4.31 When a heading changes in a local or global authority record, the system shall automatically make the change in bibliographic records that are authorized against that heading without staff intervention. The system shall flag changes that require staff decisions, such as, but not limited to, heading splits, newly disambiguated names, and newly deleted headings.

4.4.32 It should be possible to search the authority database, and link back to bibliographic records in the local database from headings in the authority database.

4.4.33 The system shall allow linked 880 MARC fields to be used as fully‐fledged access points for purposes of authority control.

4.4.34 The system shall record the history of activities on an item ‐ e.g. loans, item changes.

4.4.35 The system shall support the recording of missing and lost items.

4.4.36 The system shall allow items to be moved from one bibliographic/holdings record to another bibliographic/holdings record.

4.4.37 The system shall support temporary locations for items.

4.4.38 The system shall support customized label formats and printing, without the installation of software on staff computers. Vendor shall provide documentation of steps required to print labels.

4.4.39 The system shall allow authorized users to upload and change cover images associated with bibliographic records, including the ability to override images supplied by Syndetics or similar service.

4.4.40 The system shall support the use of serials prediction patterns, specifically allowing for the ease of creating complex customized patterns.

4.4.41 The system shall provide workflows for receiving serial issues and serials claiming.

4.4.42 The system shall support multiple levels of enumeration and chronology.

4.4.43 The system shall allow for searching external databases, including Library of Congress, National Library of Medicine, and OCLC, through the online interface via z39.50 and importing resulting records to the catalog.

4.4.44 The system shall allow for the importing of records singly or in bulk.

4.4.45 When importing a record or set of records, it shall be possible to set parameters, such as

ISBN, ISSN, title, or a combination of fields, to detect duplicate records across all libraries.

4.4.46 When importing a record or set of records, staff shall have the following options for handling each duplicate record when detected:

• Add new records, ignoring duplicates

Compare imported record to the existing record(s)

• Overlay one record with the other

• Merge the two records

• Not load new records when a duplicate is detected

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

4.4.48 The system shall allow for mapping additional physical item‐level fields from the import records into the system – for example, temporary location information, enumeration and chronology subfields, and notes subfields.

4.4.49 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.

4.4.50 The system shall allow for the enhancement of exported records according to library‐ defined normalization (reformatting) rules, including, but not limited to, the ability to enhance bibliographic records with holdings information.

4.5 CIRCULATION

4.5.1 The system shall have the capacity to circulate all types of library material, including but not limited to, books, serials, electronic resources, digital materials, laptops, and kits.

4.5.2 The system shall allow staff and patrons to reserve rooms and equipment.

4.5.3 Room reservation shall support images and free‐text description.

4.5.4 Authorized users shall be able to set room reservation permissions, including the ability to limit reservations to staff only.

4.5.5 The system shall provide the ability to seamlessly track in‐house use of library materials via the check‐in function.

4.5.6 The system shall include an offline circulation component.

4.5.7 Each library shall be able to define their loan policies, including but not limited to, due date policy, maximum renewals policy.

4.5.8 The system shall provide extensive ability to set parameters, globally or at the branch level, including but not limited to, material type, location, and user group.

4.5.9 Staff shall be able to override loan limits and due dates. This shall be limited to staff with override privileges.

4.5.10 The system shall support blocking options, limiting patron access to physical or electronic materials.

4.5.11 The system shall allow pickup locations for requests to be specified.

4.5.12 The system shall have a native self‐checkout capability that can be accessed via the mobile app, if available, or devices including, but not limited to, laptops and standalone machines.

4.5.13 The system shall provide way to generate a list of a patron's items out on loan and for check‐out/return receipts to be printed.

4.5.14 It shall be possible to create temporary and on‐the‐fly item records.

4.5.15 The system shall support library configurable recall options and must be able to recall items with automatic notices sent to patrons.

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

4.5.17 The system shall support hold queue priority.

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

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

4.5.20 The system shall display the reason for not allowing renewal for the patron, based on the information from the system, and not require staff intervention.

4.5.21 Renewal parameters shall be configurable by each library and support configuration of automatic renewals by, for example, material type, item policy, user group.

4.5.22 Staff shall be able to see the current number of renewals for each item borrowed by the patron.

4.5.23 The system shall provide the ability to define closed dates, opening hours, etc., and each library will be able to add special exceptions to standard opening and closing times.

4.5.24 It shall be possible for each library to customize notices without vendor intervention and to send ad hoc messages to all patrons or specific patron groups.

4.5.25 The system must integrate interlibrary loan borrowing and lending directly into the circulation workflow.

4.6 Digital Asset Manager (DAM)

4.6.1 The system shall provide a DAM capability that allows for the upload and storage of a variety of digital items including images, videos, documents, audio files, etc.

4.6.2 The system shall include a built‐in OCR utility to allow the user to extract the text from image files, generate a text file that can be indexed, and automatically associate that extracted text file with the original image file.

4.6.3 The system shall allow selecting Dublin Core as a target format for digital import.

4.6.4 Metadata for the digital assets shall be compliant with the Dublin Core metadata standards for digital resources and other special items.

4.6.5 The system shall include an implementation of the industry standard OAI‐PMH protocol to allow for harvesting and sharing of the Dublin Core metadata.

4.6.6 The system shall support a hierarchical classification structure to allow end‐user browsing of digital materials by context.

4.6.7 The system shall incorporate access control and authentication management, i.e., the ability to restrict or limit access to protected assets, item‐by‐item, or batch, and define different viewing privileges by individual user, group, or location.

4.6.8 The system shall provide at least 3 terabytes of storage capacity with the option to modify the contract if additional storage is required in the future.

4.6.9 The system shall have the existing capability to interface with a digital preservation system if it is required in the future.

4.7 Discovery

4.7.1 The vendor shall provide a customizable discovery layer that is integrated with the other LSP components for each library and the LED centralized office.

4.7.2 The discovery layer shall have built‐in mechanisms that enable automatic harvesting, normalization, and indexing of bibliographic, holdings, item, and authority data from the system.

4.7.3 The discovery layer shall present real‐time information (e.g., bibliographic, item, acquisitions), including, but not limited to, item availability status and processing requests for physical materials through interoperation with the system while enabling users to remain in the discovery layer.

4.7.4 The discovery layer shall support import of records in formats such as, but not limited to, KBART, Dublin Core, XML, or MARC21, through file upload or OAI from local AULS sources for access through the discovery layer.

4.7.5 The discovery layer shall support seamless patron‐driven workflows initiated from discovery and served by the system such as, but not limited to, placing holds and ILL requests.

4.7.6 The discovery layer shall provide a robust statistical reporting functionality for the library to create reports for monitoring and assessing usage of the discovery layer.

4.7.7 The discovery layer shall provide simple one‐box searching, supporting keyword searches with, but not limited to, the use of Boolean operators, truncation, and wild card.

4.7.8 The discovery layer shall provide a separate advanced search form. The advanced search form shall be expandable with additional search rows and include use of Boolean operators, specifying search fields and collections, truncation, wild card, nesting, phrase, and filtering options.

4.7.9 The discovery layer shall allow users to search individually or across local collections, encompassing all resource types (physical, electronic and digital), and a central index of full text, citations, and metadata from publishers, open‐access collections, aggregators, and subscription databases.

4.7.10 The discovery layer shall allow for standard and locally defined data not included in the out‐ of‐the‐box indexing to be indexed as separate searchable fields and all their subfields to be indexed and searchable.

4.7.11 The search options shall be configurable by each library, including “Did you mean?”, auto complete, alternative spelling, and character normalization.

4.7.12 The discovery layer shall allow the library to adjust the relevancy ranking, including but not limited to boosting by specific collections and exact match for a journal title over a keyword match.

4.7.13 The discovery layer shall allow users to retrieve additional records by clicking on hyperlinked metadata, including but not limited to author, subject, title, and series in a result record.

4.7.14 The discovery layer shall provide short persistent URLs to search result items, bookmarks, and saved search queries.

4.7.15 The discovery layer shall allow users to refine their searches to specific facets and limits.

4.7.16 The discovery layer shall allow users to sort result sets by various parameters – e.g.

relevance ranking, title, author, date (ascending and descending).

4.7.17 The discovery layer shall allow users to manage, select, and save their search queries and results.

4.7.18 The discovery layer shall allow users to format and output search results via email, printing, and citation managers.

4.7.19 The discovery layer shall integrate with a single sign on service for authentication, including but not limited to, OpenAthens.

4.7.20 The discovery layer shall allow users to search and use the layer without signing in. The discovery layer shall allow users who have a patron account in the system to sign in, customize preferences, manage previously saved search queries and search results lists, manage alerts, and submit ILL requests.

4.7.21 When signed in, the discovery layer shall allow users to request ILLs from a selected search result record using a form that is configurable by each library. It shall automatically populate information from the selected record on the request form including bibliographic, item and user information. Users shall be able to add additional notes.

4.7.22 The discovery layer shall provide customizable alerts to inform users of new items in the system or other collections related to their saved search queries.

4.7.23 The discovery layer shall include built‐in views to access digital objects including text, video and audio.

4.7.24 The discovery layer shall be customizable without vendor intervention and meet current web design standards, such as responsive web design.

4.7.25 The discovery layer shall allow multiple views of a record displaying varying levels of information. The information in each view shall be configurable by each library. Search terms shall be accentuated/highlighted.

4.7.26 The discovery layer shall identify and manage the display of duplicate records within search results.

4.7.27 On the search result list, the discovery layer shall provide an indication of online access to applicable resources with availability, sources, authentication information, public notes, and license information.

4.7.28 The discovery layer shall support and display multilingual text, including diacritics and non‐

Roman characters.

4.7.29 The discovery layer shall provide a robust Knowledge Base that shall be updated weekly, no less than monthly.

4.7.30 The discovery layer shall allow for the addition of titles and collections not currently in the

Knowledge Base. As part of the proposal, the vendor shall identify which AULS resources are currently included in the Knowledge Base (Appendix D).

4.7.31 The discovery layer shall provide both individual and global editing of Knowledge Base titles.

4.7.32 The discovery layer shall support the creation of A‐Z lists for ebooks, ejournals, and databases that can be browsed and searched by author, subject heading, and title.

4.7.33 The discovery layer shall support OpenURL link resolution and shall handle cases where the

OpenURL resolves to multiple records.

4.7.34 The discovery layer link resolver shall support integration with Google Scholar so that library holdings display alongside Google Scholar results.

4.7.35 The discovery layer shall allow for the creation of dynamic URLs for local electronic collections and override linking provided by the Knowledge Base if desired.

4.7.36 The discovery layer shall provide users with the ability to link directly to full text content.

4.7.37 The discovery layer shall allow customization of the resolver service by each library.

4.8 Inventory

4.8.1 The system must have the ability for mobile inventory through wireless or offline.

4.8.2 Inventory options include importing TXT or CSV (i.e. ASCII delimited) formats, as well as scanning item barcodes while in inventory mode.

4.8.3 The system will include the inventoried date, either set by staff or automatically set by system during inventory, on item records.

4.8.4 The system shall support the ability to automatically set the item status to missing for items within the staff‐specified criteria that were not scanned during inventory.

4.8.5 The inventory module will integrate with the circulation module to take into account item statuses other than checked in.

4.8.6 The system shall provide inventory reports listing item status after inventory completion and statistics for collection status from inventory.

4.9 OPAC/Public Interface

4.9.1 The application shall support separate web interfaces for each library and provide an enterprise web interface.

4.9.2 The system shall provide the ability for each library to search their local holdings and provide an enterprise search of all holding across the consortium.

4.9.3 The system shall provide ability for AULS library staff to customize web interface at no additional cost and without vendor intervention.

4.9.4 The system shall provide online account solutions, that can be turned on or off by staff, allowing patrons to manage their library account to include the ability to place holds, renew items, view loans, and create lists that can be saved or exported.

4.9.5 The system shall support recommended reading lists or pre‐defined searches.

4.9.6 The system shall allow items to be displayed using thumbnail images of book and journal cover art similar to Syndetics.

4.9.7 The system shall provide both a basic and advanced search with faceted search.

4.9.8 The system shall support wildcards, truncation and have the ability to perform a full Boolean search of the library holdings based on library call number, subject, author, title and other item attributes.

4.9.9 The system shall allow users to view resulting authority headings, view "see" and "see also" references, navigate previous/next result page on browse list, view matching bibliographic and/or authority records when selecting a heading.

4.9.10 The system shall provide spelling suggestions in cases of misspelled or incomplete inquiries.

4.9.11 The system shall allow the library to select order of importance of fields for relevancy searches, such as title over subject.

4.9.12 The system shall allow users to sort result sets by various parameters – e.g. relevance ranking, title, author, date (ascending and descending).

4.9.13 The system shall support and display multilingual text, including diacritics and non‐Roman characters.

4.10 Reports

4.10.1 The system shall include a comprehensive analytics component that covers all of the system’s data, including, but not limited to all MARC fields, LC and Dewey call numbers, acquisitions, circulation, and system administration data, for report creation and is an integral part of the system.

4.10.2 It shall be possible to utilize canned reports provided by the vendor.

4.10.3 It shall be possible to create custom reports without vendor intervention or assistance, including but not limited to: changing of reports parameters, views, date/time range.

4.10.4 It shall be possible for authorized users to generate consortium level reports using data from all libraries, as well as for each library to generate reports using their local data only.

4.10.5 All canned and custom report variables shall be clearly defined with descriptions that include the fields which are used in the reports.

4.10.6 Neither canned nor custom reports should require staff to create or edit using SQL.

4.10.7 The system shall support a variety of output options including, but not limited to, viewable online, send to printer, email, and export to a spreadsheet. The system shall allow for the automatic scheduling of reports at defined intervals (daily, weekly, or monthly).

4.10.8 The system shall support the ability to collaborate and share custom reports to be used by other staff.

4.10.9 The system shall support role‐based report generation and viewing such that a user will only be able to view reports and data according to his/her role.

4.11 Staff Search

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

4.11.2 Advanced search shall allow for the option of searching at least three fields simultaneously for words or phrases. Staff should be able to define their own search conditions – based on standard indexed options.

4.11.3 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, OCLC number, publisher, notes, format, location, publication date, material type, language.

4.11.4 It shall be possible to sort result sets by various parameters – e.g. ranked, title, author, call number, date (ascending and descending). There should be more than one level of sorting.

4.11.5 The system shall allow for local and standard MARC tags that are not included in the out‐of‐ the‐box indexing to be indexed as separate searchable fields and all their subfields to be indexed and searchable.

4.11.6 Fields in the holdings and item records shall be indexed and searchable.

4.11.7 It shall be possible to search across all record types – bibliographic physical, digital, electronic in one search query.

4.11.8 It shall be possible to save and manage sets of records.

4.11.9 Dependent on the search type, it should be possible – from the results list ‐ to edit a record, create an order, view holdings, items.

4.12 User Accounts

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

4.12.2 It shall be possible to define more than one patron identifier linked to a patron record.

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

4.12.4 The system shall provide the ability to bulk load, edit, and delete patron records.

4.12.5 The system shall provide the ability for customers to self‐register online.

4.12.6 The system shall integrate with a single sign on service for authentication, including but not limited to, OpenAthens.

4.12.7 The system shall allow the deactivation of patron check out history.

4.12.8 When deleting or purging user records, the system shall retain statistical data.

4.12.9 The system shall allow the creation and maintenance of staff user accounts within the LSP for authentication into the LSP.

4.12.10 The system shall support generic users/passwords for staff functions.

4.12.11 The system shall provide granular access control rights for staff accounts accessing different combinations of functional areas.

4.12.12 The system shall support the option of defining roles with access permissions and privileges which can then be easily assigned to new staff users.

4.12.13 The system shall provide each staff account the capability to set individual preferences (i.e.

display preferences, etc.…) to be maintained and applied at login.

5. Migration and Implementation

5.1. LSP provider shall provide project management for the implementation of the new system to include a migration and implementation plan with tracking of phases, tasks, and milestones.

5.2. System implementation shall include system setup and configuration, data migration, and website integration.

5.3. The LSP provider shall migrate the data from existing ILS database and DAMs to the new system to support stand up of the new LSP. The migration must support continuous operation during the transition.

5.4. Data migration from the existing ILS database shall include the entirety of the AULS records to include but not limited to the following:

5.4.1. Bibliographic, authority, copy data. The LSP provider shall provide a means to manage and track suppressed records throughout the migration process.

5.4.2. Patron records. The LSP provider shall provide a means to manage current status of individual patron records and notes/comments fields throughout the migration process.

5.4.3. Circulation records. The LSP provider shall provide a means to manage inventory and circulation history of each item throughout the migration process.

5.4.4. The LSP provider shall provide a means to manage acquisition records and notes if the migration process does not support migration of these items.

5.4.5. Serials records and notes.

5.5. The data migration from the existing DAMs shall support the migration of all the digital asset files that have been uploaded and stored in the legacy systems to include the following: image files, audio files, video files, document files, and metadata associated with the asset files

5.6. Data migration from the existing LSP and existing DAMs shall include pre‐production testing to minimize service disruption.

5.7. The LSP provider shall inform the customer of invalid data (data found in the Customer's current system that will need to be cleaned or corrected before migration) and how it is handled by the Vendor.

6. Training

6.1. The LSP provider shall provide comprehensive, online training as needed for LED staff, including administrative controls to manage AULS‐wide system settings.

6.2. The LSP provider shall provide live, online training programs and materials for all library staff during the implementation process.

6.3. The LSP provider shall offer virtual training when new releases or new versions are distributed if functionality changes.

7. Support

7.1. The LSP provider shall provide full technical support for the LSP, during implementation and production, to include self‐managed trouble tickets and telephone and e‐mail support to users during AULS core operating hours of 0600 – 1800 Central Standard Time at a minimum.

7.2. Scheduled maintenance must take place outside of normal library operating hours, not including

Federal Holidays. The LSP provider shall provide notice at least 2 business days before scheduled maintenance.

7.3. The system shall have an uptime of at least 98% annually.

7.4. The LSP provider shall provide system redundancies to protect data in the event of a system failure.

7.5. The LSP provider shall proactively monitor system reliability, proactively mitigate risks in operation disruption, maximize system availability, and timely notify customers of unplanned downtimes. Response time to system outages or incidents which render the system or system components unusable is within 2 hours with updates every 4 hours until resolved. Response time to incidents with lesser impact is within 12 hours with daily updates until resolved.

7.6. The LSP provider shall provide detailed, up‐to‐date, and accessible system documentation, including, but not limited to, documents of software architecture, data dictionary, entity relationship diagrams, as well as administrator and user manuals.

7.7. In the event of a future migration of the data to a new system, the LSP provider shall allow a follow‐on vendor to access and migrate AULS’s data at the expiration of the contract.

7.8. The LSP provider is required to maintain the data until successful migration is confirmed by the

Government, up to a maximum of 180 days from end of contract.

7.9. If FedRAMP authorization is not complete, quarterly status reports shall be submitted to the

Contracting Officer on progress of obtaining FedRAMP authorization.

8. Data Rights

The Government has unlimited rights to all data stored in the AULS LSP instances under this effort. The

Government shall retain custody of all records associated with this system and shall have exclusive control in the distribution of these records. All Government Data shall be stored within the borders of the United States.

9. Anticipated Period of Performance

This requirement consists of a 6‐month Base Period with four (4) successive 12‐month Option periods.

Migration/Implementation will begin 15 March 2024 and be completed within 6 months.

Base/Migration/Implementation Year 15 September 2024 to 15 March 2025

Option Period I 16 March 2025 to 15 March 2026

Option Period II 16 March 2026 to 15 March 2027

Option Period III 16 March 2027 to 15 March 2028

Option Period IIII 16 March 2028 to 15 March 2029

Appendix A – Glossary

API – application programming interface

ATO – authority to operate

AULS – Army University Library system, a consortium with 1 central administrative office and 16 U.S.

Army academic libraries

BIBFRAME – bibliographic description format that supports linked data techniques

COTS – commercial off‐the‐shelf

DAM – digital asset manager

EDI – electronic data interchange

EDIFACT – electronic data interchange for administration, commerce and transport

ILL – interlibrary loan

LED – Library Enterprise Division, the central administrative office of AULS

LSP – library services platform

MARC21 – machine readable cataloging

OAI‐PMH – open archives initiative protocol for metadata harvesting

OCR – optical character recognition

OPAC – online public access catalog

PII – personally identifiable information

RDA – resource description and access

RFID – radio‐frequency identification

RWD – responsive web design

STIG‐ security technical information guide

TRADOC – Training and Doctrine Command

VPN – virtual private network

Z39.50 – procedure and formats to search different bibliographic databases and retrieve records

Appendix B – Standards

36 CFR Parts 1194, Information and Communication Technology Standards and Guidelines, 508 compliance requirements ‐ https://www.ecfr.gov/current/title‐36/chapter‐XI/part‐1194

AR 25‐2, Army Cybersecurity – https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN37506‐AR_25‐2‐003‐WEB‐4.pdf

AR 25‐22, The Army Privacy and Civil Liberties Program ‐ https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN38442‐AR_25‐22‐001‐WEB‐2.pdf

BIBFRAME ‐ https://www.loc.gov/bibframe/docs/index.html

DoD Cloud Computing Security Requirements Guide ‐ https://public.cyber.mil/dccs/

Dublin Core ‐ https://www.dublincore.org/

Electronic Data Interchange for Administration, Commerce and Transport, EDIFACT ‐ https://unece.org/trade/uncefact/introducing‐unedifact

Family Educational Rights and Privacy Act of 1974 (20 U.S.C. § 1232g; 34 CFR Part 99) ‐ https://www.ecfr.gov/current/title‐34/subtitle‐A/part‐99?toc=1

ISO 27001, Information security management system – https://www.iso.org/standard/27001

ISO…