Attachment J3 - Mandatory Requirements for Task Order.xlsx
XLSX spreadsheet 158 KB Posted
- Solicitation number
- 030ADV22R0036
- Issued by
-
Library of Congress
View the file
Other files
Show all 21
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Overview
| Project Name: Library Collections Access Platform |
| Document: Attachment J3 - Mandatory Requirements for Task Order |
| The requirements listed in this workbook are mandatory and must be implemented in the core system. |
| Instructions: If the offeror’s solution already does or will meet the stated requirement, they will respond “Yes” on the right-most column; if the offeror does not already or does not anticipate meeting a specific requirement they must indicate “No.” If an offeror responds with a “No,” then they must attach an explanation of why they cannot meet that requirement or how they will provide an equivalent solution. The distinction between this document and Attachment J4 - Requirements Traceability Matrix (RTM) for Analysis is that the requirements listed in this matrix will be both analyzed and implemented in the first task order, while the requirements in Attachment J4 will be analyzed for execution in future task orders to be ordered off the awardee's IDIQ. |
&14Respondent: Library of Congress Product Name: Next Gen Library Services Platform &14RTM REQUIREMENTS TRACEABILITY MATRIX Printed on &D
1.0 Cross-functional
| Functional Area: | Cross-functional | ||||
| Description: | The requirements below apply to all functional areas of LCAP. | ||||
| Unique | |||||
| ID | Category | Requirement | Description | Priority | Is this/will this be provided? Y/N |
| 1.1.0 | Reporting & Analysis | ||||
| Summary: | The Library must have the ability to generate a variety of reports and queries on workflow processes, collection usage and availability, collection content, preservation condition and status and acquisitions and fiscal data to support operational and planning needs. Such reports may be “canned” and delivered as part of the LSP or may be custom prepared by Library staff using standard reporting tools to meet specific management information needs. They may be run on a scheduled or on an ad hoc basis. The general business needs for reporting and analysis are described below. | ||||
| 1.1.2 | Reporting & Analysis | Staff need to compile statistics related to the discovery layer and usage statistics. | Typical reports might include search statistics, number of suggested searches, number of displays invoked (how many clicks it took a user to get to a particular resource/title), indexes used and search results within a given period, searches performed over a given time period, cost per use (for e-resources), and successful requests (by holdings record number, keyword index, subject index, and resource index). | Mandatory | |
| 1.1.3 | Reporting & Analysis | The Library needs the ability to generate reports that count and capture searches made by target (inside and outside LC), e-resource usage, services selected, and key searcher behaviors. | Including statistics on searches refined by target (bibliographic, authority, subscription e-resources, web scale discovery); by usage (including Z39.50/SRU); by service (faceting, search enhancement, personalization choices, links to Ask A Librarian and to resources such as reference guides, output options selected, etc.). | Mandatory | |
| 1.1.4 | Reporting & Analysis | The Library needs the ability to access metadata indexes in reports | Mandatory | ||
| 1.1.5 | Reporting & Analysis | The Library needs the ability to report on selected backend processes in real-time while also maintaining a batch updated copy or data store for regular querying | Staff need to be able to report on real time data – this is particularly important for acquisitions and inventory / circulation reports where data changes significantly from day to day. For other reports, data can be updated at regular intervals. | Mandatory | |
| 1.1.6 | Reporting & Analysis | The Library needs the ability to create and/or use pre-existing standard (“canned”) reports run as scheduled, ad-hoc, or event-triggered situations | Staff need the ability to utilize pre-existing or to create new standard or “canned” reports that can be triggered to run in certain situations, scheduled to run at specific times, or run on demand. Please describe the canned reporting functionality offered by the solution. | Mandatory | |
| 1.1.7 | Reporting & Analysis | The Library needs the ability to create ad-hoc reports to fulfill specialized information requests | Mandatory | ||
| 1.1.9 | Reporting & Analysis | The Library needs advanced reporting interfaces to support complex query needs of full access report creators | Authorized advanced users need a more advanced interface in which they can construct more complicated queries. | Mandatory | |
| 1.1.11 | Reporting & Analysis | The Library needs the ability to restrict reporting access to PII and/or sensitive metadata to full access report creators while allowing reporting on bibliographic data for bibliographic access report creators. | Full access report creators need read-only access to patron, circulation and financial data as well as the full range of system bibliographic and inventory data. Bibliographic access report creators need read-only access to biblographic, holdings and item data for collection management and reporting to external stakeholders and senior management. | Mandatory | |
| 1.1.12 | Reporting & Analysis | Library business needs require statistical reporting on loans at the item level. | Functionality must have the ability to aggregate request and charge statistics by division, format type, fulfillment status, location and other data points as determined by the Library. | Mandatory | |
| 1.1.13 | Reporting & Analysis | The Library needs reports on additions, deletions, and changes made to knowledgebase metadata during specified update sessions. | LC staff need reports associated with each knowledgebase update that identify global and LC-specific additions, deletions, and changes to sources, targets, econtent, and services. | Mandatory | |
| Reporting & Analysis | The system must support reporting acrosss multiple data types (Acquisitions, Bibs, Circulation, etc.) throughout the implemetnation process. | If the implementation plan calls for a a phased implementation, Library staff must retain the abilityt to run standard reports that may include a mix of data coming from the old system and new system. | Mandatory | ||
| 5.11.1 | Reporting | Library business needs require the ability to report on item status and location as it moves through workflows. | Library staff must monitor progress and report on items in a given status to expose bottlenecks, identify completions, etc. | Mandatory | |
| 5.11.4 | Reporting | Library business needs require regular statistical reports at the item level with predetermined data elements and aggregation. The data should be populated automatically on a recurring basis (ex: daily, weekly, monthly, quarterly, annual). | Functionality must have the ability to aggregate request and charge statistics by division, format type, fulfillment status and rates, location, patron category and other data points as determined by the Library. | Mandatory | |
| 5.11.5 | Reporting | Library business needs require ad hoc statistical reports at the item level with customizable data elements and aggregation, specific time frames, and export formats. Staff and management should be able to add/remove fields to query and aggregate both within and across administrative units according to user-specified criteria. | The Library has various administrative levels that have different statistical needs and must sometimes be aggregated by criteria not adhering to those units, particularly for long-term planning and monitoring. | Mandatory | |
| 1.2.0 | Application Integrations | ||||
| 1.2.1 | Application Integrations | The system must to be able to exchange data with other systems across the institution. The interfaces should support common APIs and exchange protocols where appropriate. | Mandatory | ||
| 1.2.2 | Application Integrations | The system must interface with the Library's Interlibrary Loan systems | The Library currently manually integrates ILL into its workflows. | Mandatory | |
| 1.2.4 | Application Integrations | The system must integrate with the Library's authentication services including Shibboleth, LDAP Active Directory, and Single Sign On (SSO) services. | Name, department, email, phone, active/inactive fields shall all be synchronized with Active Directory no less than daily. | Mandatory | |
| 1.2.5 | Application Integrations | The system must exchange data with third party dashboard software, such as Tableau or Kibana, via common APIs and exchange protocols. | The Library is moving toward wider use of dashboards as a management aid and requires appropriate data to support Key Performance Indicators (KPIs), workflow efficiencies and future planning. | Mandatory | |
| 1.2.6 | Application Integrations | The system must exchange data with the Library's acquisition and fiscal systems to support operational and planning needs. | At present the Library uses Momentum Enterprise Resource Planning (ERP) system from CGI. | Mandatory | |
| 1.2.8 | Application Integrations | The system must interface with the Library's digital content access and presentation systems. | Mandatory | ||
| 1.2.9 | Application Integrations | The system must interface with the Library's audiovisual collection management system. | Mandatory | ||
| 1.2.10 | Application Integrations | The system must interface with the Library's cooperative acquisition system for overseas offices. | Mandatory | ||
| 1.2.11 | Application Integrations | The system must interface with the Library's Cataloging In Publication (CIP) program metadata service for publishers. | Mandatory | ||
| 1.2.12 | Application Integrations | The system must interface with the Library's Binding & label-making applications. | Mandatory | ||
| 1.2.13 | Application Integrations | The system must interface with the Library's linked data service. | Mandatory | ||
| 1.2.14 | Application Integrations | The system must interface with the Library's book sorter and self-check out kiosks via SIP2. | Mandatory | ||
| 1.3.0 | Data Migration | ||||
| 1.3.1 | Data Migration | The Contractor must migrate the following Acquisitions data to the new system in a manner that preserves hierarchies, linkages between the records, and audit trail: |
- Active purchase orders
- Open invoices
- Serials check-ins, patterns, and history
- Active ledgers for current fiscal period (past 5 years)
| - Active vendor records (includes vendors, exchange partners, overseas offices) | In order to maintain audit trails and other continuity of business needs, certain types of acquisition data must migrate: all check-in history; payment history on active subscriptions; open orders and invoices; fund and ledger balances for open fiscal years with outstanding receipts/invoicing. Additionally, the Library is working under the assumption that all Acquisitions records must be migrated around the beginning of the financial year (October 1st). | Mandatory | |
| 1.3.2 | Data Migration | The Contractor must migrate the following Bibiographic data from LCDB, CDSDB, CRSDB, NLSDB, HLASDB to the new system in a manner that preserves hierarchies and linkages between the records: |
All bibliographic records (suppresed and unsupressed) All holdings records (suppressed and unsuppressed) All items records All authorities records All deleted records
| Mandatory | ||
| 1.3.6 | Data Migration | The Contractor must migrate the following RDF formatted bibliographic data to the new system in a manner that preserves hierarchies, structures, semantics and linkages between the resources and to external sites such as ID.loc.gov and other linked data providers: |
- BIBFRAME Works and Hubs
- BIBFRAME Instances
- BIBFRAME Items
| Mandatory | ||
| 1.3.7 | Data Migration | The Contractor must migrate the following Electronic Resource Management System data to the new system in a manner that preserves hierarchies and linkages between the records: |
Bibliographic records created or modified by Library of Congress staff Resource records created or modified by Library of Congress staff
| License and terms of use data for display in discovery layer | The Library currently gets bib and coverage data from Serials Solutions. This data would need to replicated in the new system if it cannot support Serials Solutions. | Mandatory | |
| 1.3.8 | Data Migration | The Contractor must migrate the following Patron data to the new system in a manner that preserves hierarchies and linkages between the records: |
Patrons (including proxies)
| Circulation Histories (including charges that are active at the time of migration) | Mandatory | ||
| 1.3.9 | Data Migration | The Contractor must migrate or replicate the following Administrative data to the new system in a manner that preserves hierarchies and linkages between the records: |
locations statistical categories item types patron groups cataloger groups
| thesauri displays | Mandatory | ||
| 1.3.10 | Data Migration | All data must be migrated in a manner that protects personally identifiable information (PII) and all environments must be FedRAMP certified or equivalent and have Authortity to Operate (ATO) granted by the Library prior to data migration. |
| Mandatory | ||||
| 1.4.0 | Workflow Support | |||
| 1.4.1 | Workflow Support | Library ability to create and edit customizable, role-based workflows within the system's modules | Workflows should include role-based routing, approval steps, customizable triggers, alerts, scheduled delays, messaging, and exception processing, as well as options to create, edit, save, and share checklists and other workflow tools . | Mandatory |
| 1.4.2 | Workflow Support | Ability for Library staff to track an item's status and location as it moves through workflow | Library staff must be able to track an item's status and location as it moves through workflows so that they can monitor progress and report on items in a given status to expose bottlenecks, identify completions, etc. | Mandatory |
| 1.4.5 | Workflow Support | Ability to trigger a specific action or routine or action at a given point in a workflow | For example, library staff need to be able to automatically update the location when an item is scanned in by staff associated with that location, or trigger a validation routine that checks the bib and holdings items when an item is scanned in at a given location. | Mandatory |
| 1.4.11 | Workflow | Library business needs require configurable workflows for inventory processes that can record milestones, events and locations for items or collections of items. This should cover the item/collection lifecycle and be customizable to adapt to changing library needs. | Milestones include: precise dates that each item reaches a process milestone (received in a processing area, selected for the Library's collection (or not), made accessible to Library users). | Mandatory |
| 1.4.14 | Workflow | The Library needs an automated and configurable way (similar to a macro) to change data in holdings and item records. This information is managed by staff and contractors as part of their processing workflow. | Examples of workflows requiring this type of functionality include processing materials for off-site storage, deacidification, and binding. | Mandatory |
| 1.5.0 | UX | |||
| UX | Library ability to apply customized branding and responsive design in conformance with Library web design principles | Mandatory |
Product Name: Next Gen Library Services Platform &14RTM REQUIREMENTS TRACEABILITY MATRIX Printed on &D
2.0 Acquisitions
| Functional Area: | Acquisitions | ||||
| Unique | |||||
| ID | Category | Requirement | Description | Priority | Is this/will this be provided? Y/N |
| 2.1.0 | Acquisitions Workflows | Acquisitions Workflows | |||
| 2.1.1 | Acquisitions Workflows | The Library needs customizable workflows that can be configured to support a wide variety of acquisition types and approval plans. | The Library handles a wide variety of acquisition types including but not limited to: |
- Purchase
- Non-Purchase: exchange
- Non Purchase: transfer
- Non-Purchase: gifts
- Non-Purchase: Cataloging in Publication
- Non-purchase: Copyright Deposit
- Hybrid Purchase / Non-Purchase
- Duplicate Materials Exchange Program - Revolving Funds (OvOp) - Cooperative Acquisition Program (CAP)
- One-time
- Continuation These categories are associated with different business rules and must be distinguishable for both staff users and reporting purposes.
| and reporting purposes. | Mandatory | ||||
| 2.1.2 | Acquisitions Workflows | The Library needs the ability to support unique Library workflows and data elements for different acquisition types | Each Acquisition type has a unique workflow and may have unique needs for associated documentation or specific data elements. Some of this is elaborated in other requirements below. | Mandatory | |
| 2.1.3 | Acquisitions Workflows | The Library needs the ability to create specialized generic POs that can be used on multiple invoices throughout each fiscal year. | The Library receives thousands of items via Approval Plan that need to be received and paid for before bib records can be created. Generic POs called Expedited Processing Records (EPR POs - "Bag of Books", "Sack of Serials") citing specific vendors or regions and format of material are created and reused throughout the fiscal year to use in receiving and invoicing these items. These PO line items need to remain available for invoicing on a continuing basis and may need to be used with multiple vendors. | Mandatory | |
| 2.1.4 | Acquisitions Workflows | The Library needs the ability to track and maintain audit trails | For audit purposes it is necessary to keep granular logs of financial transactions, retain attachments to acquisitions-related documents, keep role-based permissions, and incorporate the use of digital signatures in acquisitions workflows. Additionally, full audit trail documentation on legal approvals/agreements throughout the workflow from Material Acquisition Request System (MARS) request through invoicing is required. | Mandatory | |
| 2.1.5 | Acquisitions Workflows | The Library needs the ability to lock fields and attachments | Because acquisitions documents are considered business records, the Library needs the ability to lock certain note fields and attachments so that they can only be modified by authorized users. | Mandatory | |
| 2.1.6 | Acquisitions Workflows | The Library needs the ability to comply with required separation of duties | All necessary internal controls and separation of duties need to be supported, e.g. no one person can be able to create vendor records (banking info) + approve orders + approve expenditures. | Mandatory | |
| 2.1.8 | Acquisitions Workflows | The Library needs the ability to exchange data between LCAP and systems used by the Overseas Operations Offices | The Library maintains six Overseas Operations (OvOp) offices in Rio de Janeiro, Cairo, Nairobi, Islamabad, Jakarta, and New Delhi. OvOp offices use a separate system called OFORS to facilitate cooperative acquisition and the purchase of rare international materials on behalf of other libraries. The Library would like the ability to exchange data between LCAP and OFORS. | Mandatory | |
| 2.1.10 | Acquisitions Workflows | The system must provide offline support for Acquisitions | OvOp staff often work in environments with unstable WiFi connections and need the ability to acquire and catalog materials offline when connectivity is not available. | Mandatory | |
| 2.1.12 | Acquisitions Workflows | The Library needs the ability to update purchase orders at a very flexible and granular level | Staff need the ability to update purchase orders globally or individually if data changes or was entered incorrectly. For instance, if currency information was incorrectly entered or an organizational change triggers location changes (e.g. to order site, bill-to site, or intended custodial location), staff need to be able to update the PO without disturbing other workflows or losing associated data such as check-in or payment history. Additionally staff need a way to easily asses the status of purchase orders so they can identify problems, such as lack of receipt or payment. | Mandatory | |
| 2.1.14 | Acquisitions Workflows | The Library needs the ability to assign / reassign POs to specific Acquisition units | POs should be associated with specific acquisition units - order site location and bill-to location. If the Library reorganizes, it should be possible to reassign existing POs from an old unit to the new. | Mandatory | |
| 2.2.0 | Vendors/Donors | Vendor and Donor Information | |||
| 2.2.1 | Vendors/Donors | The Library needs the ability to efficiently import, create and update vendor data | In order to improve accuracy, LC Staff would like to be able to create and update vendor data though a standardized form import or some other automated process. Important for system to detect possible duplicates and warn/ prohibit, or merge/unmerge vendor records if kept a highly controlled permission. | Mandatory | |
| 2.2.2 | Vendors/Donors | The Library needs unique, system-generated vendor codes | The Library needs a single code shared by both LCAP and Momentum. Not all LCAP system vendors would be shared with Momentum - we have many non-purchase vendors and FRO vendors. | Mandatory | |
| 2.2.3 | Vendors/Donors | The Library needs the ability to search vendors by all forms of name and code | Vendors should be able to be searched via expanded, boolean searches by country, type of payment, date of payment, etc. The system should accommodate longer descriptive strings for vendors names with multiple indexed, searchable alternative forms of vendor names and codes. Alternative names include use of abbreviations and acronyms, and could also include the offical authorized access point (410) if it exists. Indexing desired to help eliminate duplicate vendor record creation. | Mandatory | |
| 2.2.4 | Vendors/Donors | The Library needs the ability to deactivate/activate vendors and flag their status | This is particularly important for vendors who are exchange partners. The Library needs the ability to flag Duplicate Materials Exchange Program (DMEP) as well as non-DMEP exchange partners who send, but don't receive materials from LC | Mandatory | |
| 2.2.5 | Vendors/Donors | The Library needs the ability to associate related documents with vendor records | Related documents to include licenses, legal agreements, incomplete actions, tracking notes, etc. Complance with upcoming NARA standards will make this more important. These records could be managed by the system itself or link out to an external repository. | Mandatory | |
| 2.2.10 | Vendors/Donors | The Library needs the ability to manage Donor information | The Library needs a secure and reliable way to manage information about donors such as name, point of contact, contact information . While PII such as donor contact information should be restricted to authorized users, all staff should be able to view information about where a collection came from. | Mandatory | |
| 2.3.0 | Acquisition Planning/Material Acquisition Request Service (MARS) | ||||
| Summary: | The Library supports a variety of types of acquisitions, including Proactive (LC seeks to acquire materials, e.g., gift, exchange, purchase, etc.), Reactive (An individual or an organization offers materials to LC, e.g., gift, exchange, purchase, etc.), Passive (Automatic submissions such as Copyright materials). Each of these methods requires planning and approvals which include the participation of multiple offices or divisions prior to the actual acquisition, all of which need to be tracked and retained for auditing and collection management purposes, even if the acquisition is not ultimately approved. | ||||
| 2.3.2 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to assess the impact of acquisitions | Staff need a way to identify all divisions impacted by a potential acquisition and assess the impact of a given acquisition on those divisions so that they all can be involved in both negotiation and approval. Areas of impact include preservation costs, processing requirements, storage requirements (both physical and digital), and access restrictions. | Mandatory | |
| 2.3.4 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to incorporate acquisition requests into the full acquisition workflow. | All general collections acquisitions at the Library of Congress go through a pre-approval process called Material Acquisition Request Service (MARS) in which a recommending officer requests an item for purchase, the request is reviewed at multiple levels, accepted or rejected, and routed to the appropriate acquisitions stream (e.g. purchase vs. demand via copyright, etc.). Different acquisitions streams may be associated with different workflows and milestones. Often requestors need to associate additional documentation or link to other records in order to contextualize the request. Being able to reference this information is crucial for record keeping and collection development decisions and much of the data collected during this process can be reused in the creation of acquisitions and bibliographic records. | Mandatory | |
| 2.3.5 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to track MARS status & coordinate requests across multiple areas | Recommending officers and other authorized staff need to share MARS information and improve coordination on acquisitions of materials of mutual interest in order to streamline acquisitions and reduce duplication. This could mean viewing a queue of existing MARS requests, searching by topic, title, or data element to see all pending MARS requests in a given category, or endorsing existing MARS requests to demonstrate shared need. There is a need for system dashboards or other ad-hoc reporting tools to allow staff to create a global picture of the status of MARS requests across the institution. | Mandatory | |
| 2.3.6 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to comply with federal records requirements | LCAP will be the official and legal system of record for acquisitions. The system needs to provide functionality to retain or dispose of data (records or attached/associated documents) according to Federal recordkeeping guidelines. This retention/disposal action should have the option to be automated in certain cases. | Mandatory | |
| 2.3.9 | Acquisition Planning/Material Acquisition Request Service (MARS) | The Library needs the ability to process unsolicited donations and integrate them into established workflows | In many cases, donations are unsolicited, so staff will not have an opportunity to go through the process of planning and assessing impact prior to acquisition. In these cases, staff need a separate workflow that allows them to follow up on acquisition paperwork after a donation has been accepted. This functionality crosses over into many/all other areas of LC; no one structure/workflow possible at this time. | Mandatory | |
| 2.4.0 | Financial Transactions | ||||
| Summary: | Order and invoice data needs to be stored in relationship to bibliographic and item data, including, but not limited to, linking an order record to multiple bibliographic records and to supporting documentation. | ||||
| 2.4.1 | Financial Transactions | The Library needs the ability to interface LCAP financial transactions with the Library’s central accounting system (Momentum) | Staff needs a two-way interface between LCAP acquisitions and the Library’s central accounting system (Momentum) to support fund loading (by dollar amount and percentage), disbursements (debits/credits), allocation updates, vendor banking and address data, open obligations after vouchering, status updates on closed POs, data validation of banking and account info. Additionally multiple data elements such as voucher number & invoice number, ledger & fund IDs, vendor codes, etc. should be indexed and searchable in both systems without need for crosswalks. Data integrity and consistency between the two systems also needs to be maintained. | Mandatory | |
| 2.4.2 | Financial Transactions | The Library needs the ability to process foreign currency transactions accurately, and efficiently | The Library buys a significant amount of material from international vendors using non-USD currencies. To accommodate this, the system needs to be able to record the currency exchange rate that was in effect at the time of transaction to ensure accuracy and integrity of the audit trail. | Mandatory | |
| 2.4.4 | Financial Transactions | The Library needs the ability to automate invoicing and related transactions | The system should have full EDI functionality to enable electronic receipt, validation and archiving of invoices to maximize accuracy, efficiency, and transparency. | Mandatory | |
| 2.4.6 | Financial Transactions | The Library needs the ability to enforce controls on data elements on systems used downstream (MOM to LCAP) | Need to consider allowable situations when changes to an approved PO can interface to MOM. Role based, flexible. Example to correct errors noticed after LCAP approval and sent to Momentum. | Mandatory | |
| 2.4.7 | Financial Transactions | The Library needs the ability to maintain transaction notations | The system should support flexible notation abilities regarding fund transfers including sufficient field length, alerts, specificity to fiscal year/fund/PO. | Mandatory | |
| 2.4.8 | Financial Transactions | The Library needs to have a flexible ledger/fund structure | The system should support an extensive and flexible ledger/fund structure in order to incorporate meaningful budget plan/project designations, including subsidiary ledger-fund level controls. Ledgers and fiscal periods should support no-year money, and single-year money authorizations/allocations. Additionally the system should have an efficient, granular fund-cloning process and be able to import allocations from an Excel file. For example, LC staff need to the ability to load individual initiating fund balances, ability to load fund increases, such as ability to automatically update specific fields (e.g. fiscal year identifier in accounting strip). Ledgers and Funds should be able to be associated with Library units. | Mandatory | |
| 2.4.9 | Financial Transactions | The Library needs the ability to tightly control and report out fund balances | The system should clearly show actual and percentage used fund balances, taking into account pending amounts. Additionally, the Library needs the ability to prohibit staff from obligating money when it is not available in order to conform to the Anti-deficiency Act. The system must allow recording of estimated funds without recording them as a legal commitment or obligation. Bulk fund orders and obligations should not be able to draw down accounts. | Mandatory | |
| 2.4.12 | Financial Transactions | The Library needs the ability to handle taxes flexibly | The system needs to be capable of paying taxes at different tax rates based on where an item is received/housed/paid. The system also needs to be able to support tax exempt status purchases. | Mandatory | |
| 2.4.13 | Financial Transactions | The Library needs the ability to link multiple financial transactions | Staff often need to associate financial transactions with each other. In some cases this may involve combining items from different acquisitions streams in a single order (for example, during end of year processing it is often necessary to associate a gift with a purchased item in a single order). | Mandatory | |
| 2.4.14 | Financial Transactions | The Library needs the ability to support split funding of acquisitions | In many cases custodial divisions will share the cost of a single acquisition for which there is a shared need. This may involve the purchase being split across two or more funds. | Mandatory | |
| 2.4.15 | Financial Transactions | The Library needs the ability to suppport International Bank Account Numbers (IBANs) | The system must fully support international banking and should comply with international standard specifications, specifically IBAN and SWIFT/BIC. The IBAN structure is defined by the international standard under ISO 13616-1:2007 and check digits are performed using MOD 97 (ISO 7064). |
| Mandatory | ||||
| 2.4.16 | Financial Transactions | The Library needs the ability to incorporate partial budget authorizations | The system should be able to accommodate partial as well as full budgets, e.g. continuing resolutions, sometimes more than one, whereby Library spending authority is restricted to a finite time period and the amount determined by a percentage of a previous year's budget. System needs to accomodate fund increases/decreases. | Mandatory |
| 2.4.18 | Financial Transactions | The Library needs the ability to rollover purchase orders for renewed continuations and serials at the beginning of each fiscal year without losing the associated payment or check-in history associated with the title. Rolled over POs should retain original PO number | The Library is appropriated some no-year money, but most spending is done using one-year money authorizations/allocations. Multi-year money is not currently allocated. Purchase orders for continuing and serial publications using one year money are only legal in the fiscal year in which that money was authorized; these titles must be explicitly renewed each year for the Library to continue receiving ongoing issues. It is necessary to retain the entire payment and check-in history associated with each title, regardless of how many POs may have been issued over the years for a given title. POs should have ability to rollover, should not be closed after initial payment has been invoiced. ** Noncomplance with this requirement would put the Library in violation of the Anti Deficiency Act and with OGC's 2010 directive when the Library switched from multi-year to one-year money allocations. | Mandatory |
| 2.5.0 | End of Year Spending | End of Year Spending | ||
| 2.5.1 | End of Year Spending | The Library needs the ability to perform Fiscal Period Close and Rollover | The system needs to allow for granular rules determining what data rolls over intact from fiscal year to fiscal year, and what data is re-set or completed by year-end workflows. Extensive data integrity reporting is also required. | Mandatory |
| 2.5.2 | End of Year Spending | The Library needs the ability to run multiple Rollover Rules | The Library needs the ability to have multiple Rollover Rules acting against specific ledgers and locations that have different workflows in place | Mandatory |
| 2.5.5 | End of Year Spending | The Library needs the ability to flag acquisitions recommendations, orders, and invoices specific to projects. | Examples include end of year (EOY) acquisitions and the National Book Festival. Project budgets vary from thousands to millions of dollars. | Mandatory |
| 2.6.0 | Continuations/Subscriptions | Continuations and Subscriptions | ||
| Summary: | Subscriptions and other continuations present unique challenges for acquisitions because the Library is restricted in how it can spend money across financial year boundaries | |||
| 2.6.1 | Continuations/Subscriptions | The Library needs the ability to perform Check-in for serial issues and serial elements of monograph titles | Check-in needs to happen for regular serials as wells as for supplements, indexes, fascicles, other sub-parts (especially Law), and many formats, including print, online, microfilm, pdf… | Mandatory |
| 2.6.2 | Continuations/Subscriptions | The Library needs the ability to associate check-in records with Purchase Orders, Bib and Holdings records, and Vendor records | Check in history must be retained year over year and should be associated with the bib or holdings record, as well as the PO and vendor records (important for Duplicate Materials Exchange Program) as appropriate, especially when there are multiple POs for a given title with different acq source workflows (see 2.6.1.4) | Mandatory |
| 2.6.4 | Continuations/Subscriptions | The Library needs the ability to associate check-in records with a specific PO | The Library may receive multiple copies of a serial, via exchange, via subscription, via membership, via Transfer, via CO, or other non-purchase methods, etc.; staff need a way to associate the check in with the correct PO. | Mandatory |
| 2.6.5 | Continuations/Subscriptions | The Library needs the ability to retain check-in history for legal audit purposes up to 7 years | Check-in history necessary for legal audit purposes needs to be associated with the PO and should be able to be reported on. | Mandatory |
| 2.6.6 | Continuations/Subscriptions | The Library needs the ability to impose location controls on check-in authorization | Check in should be limited by role and permissions so that only authorized staff in the division associated with the purchase can check in a given serial (order site location and custodial location staff). | Mandatory |
| 2.6.9 | Continuations/Subscriptions | The Library needs the ability to create and support publication patterns in all vernaculars and complexities | The Library needs full implementation of MARC Holdings Standards to support publication patterns in all vernaculars. One title can have several types of supplemental materials, each with different frequencies. | Mandatory |
| 2.6.10 | Continuations/Subscriptions | The Library needs efficient, robust claiming functionality | Claiming functionality needs to be robust and associated with predicitve publication patterns. This would apply to purchase, and non-purchase workflows (including Transfer, CO - need to be able to turn off considering CO workflow receipt times -, CIP) | Mandatory |
| 2.6.12 | Continuations/Subscriptions | The Library needs the ability to collapse and expand check-in / received serial issues. | Holding records should be fully updatable in regard to issue receipt, ability to collapse / expand. | Mandatory |
| 2.6.13 | Continuations/Subscriptions | The Library needs the ability to produce reports on non-receipt of items | This functionality is needed for claiming. Production of reports is needed for check-in, serial claims, missing/damaged issues, predicitive issues, inactivity. Reports should be customizable to include parameters for types of PO, specific vendors, location, types of material, etc. | Mandatory |
| 2.7.0 | Non-Purchase Acquisitions | Non-Purchase Acquisitions | ||
| Summary: | In FY21, the Library acquired 516,764 items via purchase (25 percent of the total acquired), and 1,586,859 items via non-purchase (75 percent of the total acquired). Of those non-purchase items, 34,552 were acquired from exchange partners, 72,128 were transferred from government agencies (federal, state and local), 864,560 came as gifts, 100,345 were received through the Cataloging-In-Publication Program, and 515,274 came in via copyright deposit. Additionally, some material was not counted on an item by item level, but in the aggregate, such a manuscript collections. The Library needs a system that can support the acquisition of material via non-purchase workflows, hybrid purchase/non-purchase workflows, and for managing the distribution of material to exchange partners. | |||
| 2.7.1 | Non-Purchase Acquisitions | The Library needs the ability to support Cataloging In Publication claiming activities | A claiming functionality will be developed in the replacement to the ECIP Traffic Manager. LCAP will need to allow for push and pull of data between systems to indicate that an item has been claimed, how often it has been claimed, and whether it has been received. LCAP will need to be able to indicate that an item has been received via the CIP and PCN programs, so internal users without access to the stand-alone CIP system will know if an item is available. The LCAP shall expose secure RESTful web service endpoints to allow for interoperability with external systems such as the ECIP Traffic Manager. All capabilities of LCAP should be made available via this API to facilitate searching, creating, updating, and deleting records if allowable. | Mandatory |
| 2.7.6 | Non-Purchase Acquisitions | The Library needs the ability to support the Duplicate Materials Exchange Program (DMEP) | The Library of Congress exchanges library materials with approximately 3500 partners around the world through its Duplicate Materials Exchange Program (DMEP). In exchange for materials sent to the Library, partners receive quota credits that allow them to select from an inventory of available books. A web-based ordering system, called Web DMEP, allows partners to select exchange materials online. DMEP needs to be able to interact with LCAP to pull vendor data, identify partners, identify outgoing subscriptions (currently stored in the vendor record Accounts tab of Voyager) DMEP also interacts with access dbs to pull additional data. | Mandatory |
| 2.7.8 | Non-Purchase Acquisitions | The Library needs the ability to efficiently support government document acquisition workflows for both online and physical items | The Library must be able to identify active and non-active serial titles acquired by transfer. Also, we currently do not count items available through online access, and we claim hard-copy printed versions of government documents. System integration/links to web archiving would enable systematic, accurate reporting | Mandatory |
| 2.8.0 | Licensing/Agreements/Contracts | Licensing, Agreements, and Contracts | ||
| 2.8.1 | Licensing/Agreements/Contracts | The Library needs the ability to attaching and flexibly access acquisitions-related documents | Staff need to be able to easily access documents related to an acquisition such as Material Acquisition Request Service (MARS) requests, license agreements, correspondence, emails, gift agreements, and contracts so that they can effectively manage collections and provide information to auditors, Congress, and patrons. Desirable options for managing acquisitions-related documents in the system and making them easily discoverable to staff could include support for full-text search of attached documents, options to restrict access to attached document by roles and permissions, and support for document versioning so users can reference changes to a license or contract. | Mandatory |
| 2.8.2 | Licensing/Agreements/Contracts | The Library needs the ability to retrieve specific information from licenses, contracts & agreements | In addition to searching the documents themselves, staff often need to search or report on specific data elements related to licenses, contracts, and agreements. LCAP should be able to support access to specific fielded data related to contracts, licenses, and agreements such as collection name, donor name, contact name (attorney), vendor name, access information, and usage restrictions. | Mandatory |
| 2.9.0 | Rights Management Metadata | Rights Management Metadata | ||
| 2.9.1 | Rights Management Metadata | The Library needs the ability to assign and store machine-readable rights metadata | The Library needs a way to consistently assign and store machine-readable rights metadata in a way that it can be exposed to users either through the discovery layer or via API. | Mandatory |
| 2.9.7 | Rights Management Metadata | The Library needs the ability to assign flexible restrictions descriptions | The Library needs flexible restrictions metadata that can support a number of different scenarios including restriction by number of simultaneous users, user type, location (on or off site), and duration (such as embargo period), and corresponding level of access to content (thumbnail only, view only, streaming only, or download). The Library needs local metadata field(s) that allow for specific/unique use limitation descriptions, not limited to restricted vocabularies. Local note field(s) would also be used to record use terms/decisions re collections, etc. organized/documented on paper in file cabinets. | Mandatory |
Product Name: Next Gen Library Services Platform &14RTM REQUIREMENTS TRACEABILITY MATRIX Printed on &D
3.0 Bibliographic Control
| Functional Area: | Bibliographic Control & Cataloging | ||||
| Unique | |||||
| ID | Category | Requirement | Description | Priority | Is this/will this be provided? Y/N |
| 3.1.0 | Standards and Schemas | ||||
| Summary: | The cataloging data prepared by the Library represents several different descriptive standards, and the structural schemas vary as well. For the MARC records in the ILS, bibliographic records represent cataloging standards adopted over a century, from early LC and ALA rules, to the AACR family of standards, and records following Resource Description & Access for books, serials, cartographic materials, and music scores cataloged since 2013. Special collection cataloging areas may follow other descriptive standards, such as the suite of Descriptive Cataloging for Rare Materials (DCRM) standards, the Archival Moving Image Manual (AMIM), Describing Archives, a Content Standard (DACS), etc. We need a system that continues to allow the integration of bibliographic data from such various content standards. Regardless of the standards used for description, the Library attempts to keep access point fields in MARC records synchronized with authority records (NACO records for names and titles, LCSH authority records for LCSH subject access points), although it is understood that there are many bibliographic records with access points that don’t correspond to authority records for various reasons. We also have many records with subject access points representing thesauri and subject systems other than LSCH, some developed and maintained locally at LC and others that come into the catalog from other sources. LC also creates metadata representing finding aids following the Encoded Archival Description standard, MODS records for a significant number of resources (typically e-content), locally defined non-MARC schemas, etc. These non-MARC records are not represented in the current ILS, which allows only MARC records. It is expected that the Library will need the ability to create metadata in the format most appropriate for the collections being described. To that end, the Library is developing and testing the BIBFRAME standard, and it expects that a future solution will include the tools to create, index, maintain, and perform access point control/identity management in a BIBFRAME and MARC environment. | ||||
| 3.1.1 | Standards/Schemas | The system must support the ability to create, manage, import, and export descriptive metadata in the Metadata Object Description Schema (MODS) | Mandatory | ||
| 3.1.4 | Standards/Schemas | The system must provide methods to make timely incremental updates to conform with changes to the metadata standards that are used in the system | The Library knows from experience that metadata standards will change over time, and so it needs as system that can respond to those changes in incremental ways such as being able to update input screens, displays, and indexes to reflect changes such as updates from the MARC Advisory Committee. | Mandatory | |
| 3.1.5 | Standards/Schemas | The system architecture must support the prompt integration of new and emerging metadata standards and schemas | The Library needs to keep its platform and metadata compatible and interoperable with schema such as BIBFRAME | Mandatory | |
| 3.2.0 | Granularity/Relationships | ||||
| Summary: | In order to effectively manage and provide access to its collections, the Library needs the ability to create, manage, and display complex relationships between entities in a way that can be logically represented. | ||||
| 3.3.0 | Linked Open Data | ||||
| Summary: | While the Library is committed to making its data available in the MARC standard, it is also committed exploring ways that creating, distributing, leveraging linked open data could bring new value and efficiencies to its metadata offerings, including support for the BIBFRAME standard. | ||||
| 3.3.3 | Linked Open Data | The system will accommodate BIBFRAME data and its implementation, including storing BIBFRAME data natively and full indexing support, the ability to import and export Bibframe data, and a system capable of converting to/from Bibframe and other formats, principally MARC. | As the leader in the development of the BIBFRAME standard, the Library is particularly interested to learn how your application’s current and future plans for the implementation of BIBFRAME fit into that strategy as it pertains to descriptive metadata. | Mandatory | |
| 3.3.4 | Linked Open Data | The system will include a linked data editor, specifically one that can accommodate Bibframe cataloging. | Mandatory | ||
| 3.4.0 | Cataloging |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .