Yale University Library

DOCUMENT DELIVERY SYSTEM REQUIREMENTS

Introduction

 

The Yale University Library is planning to implement a seamless document delivery program in the summer of 2001 and seeks an integrated software management system that will support this program.

As envisioned, the program will encompass the following elements:

The program will function among the library system's 22 libraries in New Haven, as well as its Library Shelving Facility (LSF) in Hamden, Connecticut. Current intra-campus material delivery numbers 21,751 volumes per year among all library locations, with software support provided by the circulation module of our library management system (Ameritech's NOTIS). Direct patron borrowing among three partner institutions, supported by URSA software developed by CPS and Epixtech, numbers 629 volumes borrowed and 867 volumes loaned by Yale (December 1999-August 2000).

Interlibrary borrowing and lending is currently centered in six Yale libraries, and utilizes RLIN, OCLC, and DOCLINE software, as well as several document supply services (American Society for Testing and Materials, Canadian Institute for Scientific and Technical Information, Chemical Abstracts Service, the John Crerar Library, MicroPatent, MIT, SPIE [International Society for Optical Engineering], UMI's Dissertation Express, and UnCover); activity totals for FY99 are as follows:

 

Borrowed

Loaned

Total

Volumes*

5,232

6,131

11,363

Articles*

4,200

7,771

11,971

Totals

16,931

24,065

40,996

*The Medical and Law libraries' statistics are not reflected in

the individual figures, only in the aggregate totals

Article transmission, both intra-campus and nationally, is accomplished through the use of both fax and Ariel, with Ariel workstations implemented at the six interlibrary loan sites on campus.

 Yale provides access to over 200 bibliographic databases for the identification and verification of citation-level information and to over 2,000 full-text electronic journals. These resources are available over a network through IP-based authentication and are represented in Orbis, Yale's online catalog, with URLs provided in the 856 field. In addition, the Jointly Administered Knowledge Environment (JAKE), developed by Yale's medical library, identifies which standard indexes and abstracts contain specific journals, and which online services provide access to the full text of their articles (http://jake.med.yale.edu/).

The Library operates its library management system on an IBM S/390 model 115 and supports telnet, TN3270, Lynx, Z39.50 and web-based access to its catalog. Its public workstations are both PCs running NT and Macs; staff workstations are all NT. Netscape is the supported web browser. The current campus email system supports PINE, Eudora, and a local web-based email interface called ITS-mail.

This document outlines the functional activities and specific tasks which the software we select must support. We also identify the minimum software capabilities thus far identified as important to the operation of this program. Key requirements include:

 

 

1. Patron Submits a Request

A patron should be able to initiate a request for a known item without staff mediation. The system should be readily available and easy to use and should eliminate the need for repetitive entry of patron information.

 

  1. Reader initiates requests for known items without staff mediation.
  2. The system prompts patron to use ILL/DD system as a component of the search process.
  3. Reader-initiated requests incorporate bibliographic data from other databases without re-keying, e.g., via download or cut-and-paste.
  4. The system provides a single, easy-to-use Web interface which can be customized locally.
  5. The system provides seamless access to materials in a variety of formats which may be located locally (at Yale) or externally (from other libraries and information suppliers).
  6. The system is accessible from anywhere patron has access to the Internet.
  7. The system is available 24/7 (24 hours a day, 7 days a week, 52 weeks a year).
  8. The system authenticates reader as eligible for ILL/DD services based upon valid Yale ID and email address, valid local NetID or other password, or interaction with local authentication system.
  9. The system archives a secured personal patron profile which
    1. Stores detailed patron information and preferences
    2. Is set up by reader once and can be modified by the reader on a one-time or permanent basis
    3. Is automatically invoked whenever a new request is submitted.
  1. The system detects duplicate requests initiated by the same patron.
  2. The system permits editing and cancellation of requests by the reader.
  3. Reader's personal information is persistent through various transactions after initial log-on.
  4. Reader can indicate preferred format for article delivery.
    1. Photocopies
    2. Fax
    3. Electronic document delivery
  1. Reader can indicate preferred pick-up location.
  2. Reader can indicate method of payment and authorize it.
    1. University account
    2. Bursar account
    3. Credit card
    4. Check
    5. Cash

2. Item Is Searched

After a patron initiates a request, the system should automatically search for the item both locally and externally.

 

  1. Constructs valid bibliographic searches based on the nature of the material sought. For example:
    1. Constructs author/title, title, or other standard search for monographic material from data input without an ISBN
    2. Constructs title searches for serials data input without an ISSN
    3. Constructs ISBN or ISSN searches when this data is present
  1. Searches internal and external databases in a customizable order determined by criteria drawn from the patron request. For example:
    1. Type of material
    2. Turnaround time specified
    3. Whether the patron is willing to pay
  1. Returns the results of the searches sequentially to a staff member for selection of the appropriate source and initiation of request, OR
  2. Searches multiple databases, both internal and external, and returns results from each separately.
  3. Default order for the searching of internal and external databases in the absence of limiting criteria should be:
    1. Local LMS (including the ability to report the status of the item: checked out, on reserve, missing, etc.)
    2. Consortial ILL program (including the ability to report the status of the item: checked out, on reserve, missing, etc.)
    3. Specified individual library catalogs (including the ability to report the status of the item: checked out, on reserve, missing, etc.)
    4. National utilities (RLIN, OCLC, DOCLINE)
    5. Document suppliers when applicable
    6. Book venders/sellers

3. Request Goes to Provider

Having identified the most suitable location from which to retrieve the material and recognizing its format, the system will initiate appropriate request procedures. Requests will meet ISO specifications.

  1. Will the patron be notified that the item is available at a Yale Library?
  2. Will the patron have the option to select that the item be:
    1. Forwarded to a specific pick-up location via Eli Express (Intra-campus delivery)?
    2. Processed via MACS (in-house photocopy service) for pick-up at a specific location?
    3. Sent via EDD (Electronic Document Delivery) to a specific E-mail address?
  1. Will the system automatically complete a Borrow Direct (consortial borrowing) request for monographs when suitable?
  2. Will the system automatically complete an RLIN request?
  3. Will the system automatically complete an OCLC request?
  4. Will the system automatically complete a DOCLINE request?

4. Provider Locates Item and Sends

The system will provide standard bibliographic information in an easily customizable format to assist the provider in locating the correct item. The system will generate any paperwork required to send the item.

 

  1. Generate paging request at correct campus location
  2. Do you allow the operator to customize the display of information related to the request? For example, to print requests in order by shelving location?
  3. How can an operator confirm that an item has been located or indicate that an item is not available?
  4. Can a routing slip be generated to send an item to another library on campus?
  5. What paperwork do you generate automatically for external shipping? Shipping memoranda? Mailing labels?
  6. Update tracking system for staff/patron
  7. How can you link to other systems (consortial ILL program) and national utilities (OCLC, RLIN) to receive and to update request information?

5. Item Received and Processed in Document Delivery

The system will allow for a quick and efficient updating procedure as each order is received by the requesting library.

  1. How does system allow for a standardized way of updating a filled request?
  2. Will system send an update to the particular system on which order originated?
    1. RLIN
    2. OCLC
    3. DOCLINE
    4. consortial ILL programs
    5. document suppliers
    6. book vendors/sellers
  1. Can system make the necessary record of receipt so electronic debit can be made when order has been received for IFM on OCLC or EFTS for DOCLINE?
  2. Will system send an e-mail to patron notifying patron of receipt and confirm method of delivery?
  3. Does the system support electronic delivery options (EDD)?
  4. Will system print book wraps, cover sheets, etc for delivery to patron?
  5. Can system integrate a temporary circulation record for a borrowed ILL book?
  6. Can system track and archive a request's history?
  7. Can system send automatic reports on a request's status
    1. to staff?
    2. to patron?
  1. Can pending requests be easily identified and a list printed out?
  2. Can the system send out a status request to the supplier?

6. Item Delivered to Patron

The system must allow the user to select the most suitable means of delivery depending on its format and make staff response to that request easy.

 

  1. If the material is in returnable form, can the system review whether patron requested the material to be:
    1. Held for In Library pick-up. If so, can the system automatically e-mail the patron that the requested item is ready for pick-up?
    2. Held for pick-up at another Yale Library location. If so, can the system prompt staff to forward material to specified pick-up location via intra-campus mail?
    3. Forwarded via US mail (or alternative). Can automatic email be sent to patron notifying them that material has been shipped to them?
  1. Does the system include an electronic delivery (EDD) module?
  2. Can the EDD module automatically inform the ILL unit that the material was received by the patron?
  3. Can the system update records when the transaction is complete?
  4. Can the system notify patron where billing charges are applicable?

 

7. Patron Returns Item and It Is Returned to Provider

The system will be able to check out/in books, communicate via email/print with patrons, update national utility systems, and provide ILL documentation and 'route to' slips

1. Item is checked in system's circulation module.

    1. IF system does not include a circulation module, then it should interface with the LMS circulation module

2. When item is checked in the system automatically:

    1. Sends a message to the patron acknowledging that the item has been returned
    2. Updates the national utility (OCLC, RLIN, DOCLINE, etc.) or consortial ILL program that the book is being returned (when applicable)
    3. Prints a return label for the book
    4. Prints a copy of the transaction's record with ID number
    5. Prints a 'route to' slip for the Yale Library that processed the request (when applicable)

 

8. Item Received by Provider

The system should verify that the item has been returned to the correct lending location.

 

  1. Can the system provide an alert to the borrowing library that a returned item hasn't been received?
  2. Can all national utilities automatically be updated by the system once the item has been received by the owning or home library?
  3. Can all consortial ILL programs be automatically updated by the system once the item has been received by the owning or home library?
  4. Can the local LMS be automatically updated once the item has been received by the owning or home library?

9. Tracking status of request and item

Both patrons and staff should be able to access the document delivery system in order to determine the status of a particular request. The system should be able to indicate each item's stage in the document delivery process and clearly communicate that information to the requesting patron or staff member.

 

  1. Does your system provide a security measure upon login to ensure that only the requesting patron has access to tracking information of their own requests. How is this done? Can any staff member working with Document Delivery have access to this information as well?
  2. Can patrons and staff view the status of all their requests at once, regardless of the type of request (i.e.. interlibrary loan, campus delivery, paging)?
  3. Is the logging of every transaction affecting a request visible to both the requesting patron and staff?
  4. Is a change in the status of a request reflected in real time?
  5. Does your system allow patrons to call up and modify requests, depending on the status, after sending? Can all notes and tracking of an item be retained by the system regardless of the modification?

 

10. Report Function

The library management software will record and save information about each request so different types of statistics can be compiled for internal and external reporting. These reports should capture and compile data on the aggregate and unit levels and be customizable. The ability to query the database and compile data should be available at any time.

 

  1. Can system collate data such as:
    1. Number of requests by type (loans, copies)
    2. Number of requests by format (print, electronic)
    3. Number of requests ordered/filled/unfilled by supplier (RLIN, DOCLINE, OCLC, Document suppliers, Book vendors, etc.)
    4. Total number of orders
    5. Total number of filled/unfilled requests
    6. Number of requests by patron (filled/unfilled)
    7. Number of in-house requests
    8. Number of unfilled requests, by reason
    9. Patrons by status and department
    10. Journal titles requested (title list and number of requests)
  1. Can system calculate the following:
    1. Fill rate (total orders requested/total orders received) as both borrower and lender (by unit and total)
    2. Fill rate by type of transaction as both borrower and lender (by unit and total)
    3. Fill rate by supplier (by unit and total)
    4. Turnaround time for each vendor (by unit and total)
    5. Internal turnaround time (from request receipt to ordering or sending, from receipt of item to delivery to patron)
    6. Costs for total orders (by unit and total)
    7. Costs per vendor (by unit and total)
    8. Amount billed to each patron (by unit and total)
    9. Amount billed to borrowing libraries (by unit and total)
    10. Number of times each journal was requested (by unit and total)
  1. Can system produce a copyright compliance report sorted by title and by year (by unit and total)?
  2. Can system print reports sorted by data from any field or combination of fields?
  3. Can system print invoices?
  4. Can system print paper logs for a designated time frame (from daily to annual)?
  5. Can all fields be queried?
  6. Can system tabulate amount owed to various electronic debiting systems?
  7. Can system transfer data to commercial software packages so presentation-quality reports can be generated?
  8. Can system connect to circulation software to block delinquent library patrons' use of document delivery privileges?
  9. Financial Management

The system will maintain financial data which provides an audit trail, as defined by standard accounting practices, for ILL/DD transactions, i.e., fees charged and fees paid. The system will also inform statistical and financial reporting related to copyright compliance. In addition, the system will make it possible for patrons to access financial information about their ILL/DD requests.

 

  1. Reports all transactions involving fees and fines by maintaining financial data which provide an audit trail, as defined by standard accounting practices, for ILL/DD transactions.
  2. Incorporates a standard schedule of fees for various ILL/DD services, as determined and set locally.
  3. Alerts reader of applicable fee at time of request or at other appropriate point during the ILL/DD process.
  4. Provides multiple payment options for borrowing and lending transactions.
  5. A. Cash

    B. Check

    C. University and grant accounts

    D. Bursar accounts

    E. Credit cards

  6. Can be linked to an ODBC compatible application such as Excel.
  7. Generates invoices and tracks billing information for lending transactions.
  8. Supports electronic debit/credit systems, such as OCLC IFM
  9. Calculates copyright fees due and generates payment to the Copyright Clearance Center or copyright holder.
  10. Tracks payments to document suppliers and from Yale readers.
  11. Triggers internal accounting transfers (debit/credit) for ILL/DD services.
  12. Provides financial reports on demand using standardized or customizable templates.
  13. Patron Notification

 

The system will notify patrons automatically at each stage in the document delivery process. Locally customizable content relevant to that stage will be included e.g., due date and fine information is needed when the item is delivered to the patron.

 

  1. In general, patrons will be automatically notified of the status of their ILL requests. Specifically, patrons will receive notices (e-mail or print) when
    1. The patron submits a request
    2. The item is available at the designated pickup point.
    3. The item is delayed or unavailable
    4. The item is returned to the local ILL office
    5. The item is due back from the patron in a few days (courtesy notice)
    6. The item is recalled by another patron
    7. The item is overdue for return by the patron
    8. The patron owes fees or fines
  1. Content at all stages should include the following.
    1. Patron's name and contact information
    2. Bibliographic or citation information for each item requested (or otherwise relevant to the stage of the process)
    3. Text about the request and ILL process (brief)
    4. What to do in case of problems (contact information for problem resolution person)
    5. Thank you, etc.
    6. An opportunity to give feedback to staff (contact information, email link, etc.)

13. Business Performance

The company which will provide us with a document delivery management system should offer us a contract and support of their product, including assistance with installation. In addition, customized training should be provided to Yale staff working with the system.

 

  1. Does your company provide contracts renewable on a yearly basis?
  2. Will your company provide us with unlimited email support?
  3. Will your company provide us with unlimited telephone support? If not, what are the additional costs?
  4. Provide a general description of the levels and degrees of support you offer.
  5. What support services are available during normal business hours?
  6. What support services are available 24 hours a day, 7 days a week year around?
  7. How many product support staff do you employ?
  8. Can your company provide customized training, in person, at Yale, in the following areas?
    1. System installation
    2. User training (both staff and patron interfaces)
    3. Customization
    4. Programming
    5. Generation of Reports
  1. What varieties of instructional support (instructor-led, online help, AV modules, etc) do you provide?
  2. Does your company offer a site license?
  3. Can you customize your software based on the LMS we have or may have? Which LMS's have you worked with?
  4. Will your company customize based on suggestions by staff?
  5. What user groups do you sponsor; how long have they been in existence? Do you support a listserv for users?
  6. What range of product support and development activities is conducted through user groups?
  7. What staff are assigned to these user groups?
  8. What warranties does your company make to its customers?
  9. How frequently do you issue new software releases?
  10. How many staff do you now employ? How many are librarians?

 

  1. Systems and Protocol Requirements

The Library runs its current library management system using NOTIS but by June 2002 a new LMS will be implemented from among these choices: Endeavor Voyager, Ex Libris ALEPH, Innovative Interfaces Millennium, or SIRSI Unicorn. The document delivery management system we choose should interface with one of these systems and conform to standard ISO protocols.

 

Current systems environment

Library management system mainframe

Hardware: IBM S/390 model 115 (running MVS 2.7 and CICS 4.2)

Software: NOTIS

Servers

Hardware: IBM, Sun, Dell, Gateway

Software: AIX, Solaris, Windows NT 4.0

Other

Network (TCPIP)

Database management on campus (Oracle)

Security (Kerberos)

Barcode format (Codabar 39)

Hardware requirements

  1. System runs on a Unix platform from either IBM or Sun

System Architecture

  1. System must provide Windows, web browser, and text -based clients
  2. Data must be stored in a RDBMS or ODBMS conforming to industry standards, i.e., non-proprietary
  3. System must support use of standard WWW servers and browsers
  4. Each layer of the architecture must be scalable and manageable independently from every other layer
  5. System should support all Z39.50 compliant clients
  6. Browser clients should run in either a Windows or Mac/OS environment
  7. Staff clients should run in all Windows environments (Win 95+)
  8. The architecture should support multiple processors.
  9. The system should provide tools for ISO 10160/10161 protocols for interlibrary loan
  10. The system should provide tools for an X12 interface to EDI
  11. The system should conform to the ISO 9000-3 guidelines for the development and support of quality software products

 

System Operations

  1. Responds to problems within a one-hour notice
  2. Established procedures to report application problems, distribute bug fixes, and release updates and new versions of the application
  3. Browsers and staff clients must run on Windows NT and Windows
  4. Browsers and clients must run on Intel platforms
  5. Browsers and staff clients should run on Linux systems and network appliances
  6. System must have a reliability factor of 99.99%
  7. System must operate on a nearly 24x7 basis
  8. System must provide regular reports on the status of all system management and policy files, as well as all profiles, tables, and other parameters that control the system
  9. Vendor must provide established procedures to report and track application problems as specified in ISO guideline ISO-9000-3
  10. System should be designed to run on parallel system
  11. Transaction response time less that 3.0/secs
  12. Client initialization time less than 30 seconds (after OS initialization)
  13. Batch data loads, indexing, and report generation should not require the system to go down
  14. Batch data loads, indexing and report generation should not significantly impact performance
  15. Vendor must provide documentation for all transactions, batch, and reporting jobs
  16. Vendor must provide recovery procedures for all batch type and reporting jobs
  17. Customization and maintenance tasks of the application, like table changes, should be performed by a graphical tool
  18. Clients used to access the system should be easy to install, maintain, few in number, and able to run in either a Windows or Mac/OS environment

System Development

  1. System must provide a flexible development environment by providing customer access to current source code to facilitate integration of: locally developed applications; third party software; data exchange with external systems (such as document suppliers) and bibliographic utilities; and interoperability with other Yale systems
  2. The ability to demonstrate quality control over vendors, internal processes, and user support interfaces as defined in ISO 9000, 9001-9003
  3. The system must provide both forward and backward version control of all software components both distributed and under development
  4. Only modern and current programming languages, operating systems, network and database interfaces, such as ANSI C, C++, Java, and Visual Basic may be used. Any software content consisting of object code only, or developed using non-industry standard programming languages is unacceptable.
  5. Must support data access via standard, non-proprietary database and network protocols ODBC, JDBC, SQL92, CORBA, IIOP, RMI, or equivalents as well as IETF approved TCP/IP transfer protocols
  6. The development environment should accommodate short development cycles and continuous improvement, without the need for frequent wholesale upgrades to remain current
  7. Access to services should be based on integrated development environments (IDE) provided by IBM, Sun, Microsoft and others.
  8. Scripting interfaces, such as Apache CGI and PERL which work well in the open software environment
  9. Provision of tools/venues/websites for the development and exchange of user-developed software
  10. An active user community, supported by the vendor

System Security

  1. System should be able to demonstrate compliance with DoD Trusted Computer System Evaluation Criteria class (C2)
  2. System must have secure clients; private data is encrypted when passed over the network
  3. Login to staff modules dependent on userid and password which must be encrypted
  4. Secure transactions must cut a log record that can be used to trace a transaction
  5. Authentication and authorization must be able to be applied to a user or workstation or both
  6. System should not adversely affect or be affected by proxies, firewalls, or other university security infrastructure
  7. All scripts should be centrally located and protected with wrappers or sbox or equivalent
  8. Programs must validate user input
  9. System protects information about site and server host
  10. Telnet and FTP access to services should be done via SSH2
  11. Manages user accounts and passwords using a standard implementation of a standard protocol such as LDAP
  12. Reference user account information from external systems using a standard directory protocol such as LDAP