GENERAL SYSTEM OPERATIONAL REQUIREMENTS FOR MakLIBIS

1.1 System Functions

In accordance with the University Draft ICT policy to improve the efficiency and effectiveness of library operations and services through the implementation of an integrated on-line Library information system, the integrated library system must include the following functions:

·  Acquisition

·  Cataloguing

·  Authority control

·  Circulation

·  Closed access ordering

·  Closed stacks ordering

·  OPAC, including Web-access

·  Serials control

·  Import/export of records

·  Statistics

·  Reporting

·  Systems management

1.2 Systems Standards

1.2.1 The OS Architecture

  1. The system must be an open system in the sense that open, de facto, and international standards are supported by the architecture of the system.

1.2.2 Supported formats

The University Main library as a unit centre exchanges data with other university organs that includes specialised libraries, academic registrar department, human resources department, finance department and others. As result data exchange is mandatory and the system must be able to support the following formats:

·  ISO2709 exchange format.

·  Common export/import formats, such as delimited ASCII, dBase, and MS Excel

·  HTML/XML

1.2.3  Bibliographical Formats

The required formats, conversion, updates and matches for bibliographical information are specified in section *** , under the cataloguing chapter.

1.2.4  Internet Protocols

i.  The system must support the following protocols, as users will heavily be using Internet their operations:

·  TCP/IP

·  SMTP, MIME

·  HTTP

ii.  Makerere University Library is currently in process of formalising partnership with other libraries on the continent. The library expects to get and give support for transparent interaction with external systems in accordance to:

·  ANSI/ISO Z39.50-1995(ISO23950) or later version on both server and client

·  Extended services: Update, Item Order

·  Record syntaxes: USMARC, South Africa MARC, UKMARC, UNIMARC, OPAC

·  ILL (ISO 10161) entirely or partially (especially ILL Request and Status/Error to be implemented in connection with Z39.50 Item Order, as specified by the ILL Protocol Implementers Group IPIG)

·  SQL ANSI 92

·  ODBC

1.3  Character sets.

The systems should support the following sets. Those mandatory sets are specified with a must in bold:

i.  ISO 8859-1 (Latin-1) must be available for input, display, and printing

ii.  ISO 6937/2 should be available for input, display, and printing.

iii.  Unicode/ISO 10646 should be supported. Describe your existing or intended Unicode implementation.

iv.  Mapping of imported LIBRIS characters (Unicode/ISO 10646) must be possible for all import methods.

v.  The client and server sides should support Z39.50 character set and language negotiation, as agreed by the ZIG (http://lcweb.loc.gov/z3950/agency/defns/charsets.html)

vi.  The Z39.50 client and the Z39.50 server, also in batch mode, should be able to covert on the fly from any specified character set to the internal one, and vice versa.

1.4  Barcodes.

i.  It must be possible to use the item barcodes and the patron barcodes that are in use in the current system (Codabar).

ii.  The system should be able to handle different barcode formats. For example, EAN-13,SIC/SISAC, Codabar.

1.5 Systems Operation

A Library integrated system is a realisation of different software modules that are compiled to work together to accomplish different library functions. These modules can be precompiled by the vendor and acquired at once all together or can be acquired separated and compiled by the user under the guidance of the user manuals provided by vendor. In addition stable and reliable system should allow a recommendable degree of customisation to meet local specific requirements. It is envisaged that for MakLIBIS purpose:

i.  All software needed for systems operation must be listed

ii.  The system must provide a variety of access levels and capabilities, including the ability for Systems Administrator to obtain and modify file listings, resource allocations, and security features and functions

iii.  It must be possible for a person, without special knowledge, to bring down the system in an orderly fashion. In UNIX this means, that it should be possible to extend the shutdown command in some standard way, so that it brings down the system and the database handler as well as the operation system

iv.  The system must have in built backup and recovery mechanism

v.  It must be possible to do backup, in such a way, that the system can be restored to its state at any earlier point in time

vi.  The system must be designed so that when the system or the operating system crashes, no transactions are lost except for possibly the last one

vii.  The user must be notified, in case some entered data is lost, when the system or the operating system crashes

viii.  It should be possible to do backup with the system in full operation

ix.  It should be possible to use backup software from other vendors

1.6 Systems Security

i.  The system must have functionality that can securely verify the identity of users that enter data into the system. It must not be possible to circumvent this by monitoring network traffic, using IP-spoofing, hi-jacking sessions, or using some similar method. One time passwords, access lists, fire walls, and such are therefore not enough

ii.  All entering of data into the system must be logged in a safe and tamper proof way, with respect to time, activity, and user. The logging should be tamper proof even against a user that has broken into the system or the operating system. One way of achieving this is by logging to a remote machine that is "safe"

iii.  It must be possible to delegate authority in a flexible way so that users can be given just enough authority to do their job.

iv.  The client, that is intended for users that enter data into the system, must be designed in such a way that a user by modifying the client cannot bypass the security system or gain access to functions for which he is not authorised.

v.  Web based clients must not require Java or Java Script. The reason for this is that it would force users to turn on the corresponding support in their web browsers, thus compromising security in their own computers.

vi.  All software distributed must be electronically signed using PGP or similar software.

1.7  Data communication.

  1. All communication between server, clients, printers, and other subsystems, must use IP
  2. On a higher protocol level the system must be able to communicate via HTTP and Z39.50 (on top of TCP/IP).

1.8  Systems estimated loads and response times.

This will be estimated after the ongoing data collection exercise is completed. The items to be considered are:

  1. Estimated number of loads of records by the time of the system test Dec 2002 (Ref. MakLIBIS Operational Plan – time schedule )

Records/users/transactions Total number Increase/year

Bibliographic records

Authority records (permanent)

Holding records (serials)

Item records

Patron records

Check-out/-in transactions per year

Closed access requests per year

Closed stacks requests per year

Serials check-in transactions per year

New acquisition requests per year

Suppliers

Concurrent staff client users

Concurrent OPAC client users

Concurrent Web OPAC users

·  Number of transactions per hour Average Peak

Searches

Entry of new records

Edited records

Issues (check-out)

Returns (check-in)

Renewals

Holds/reservations

Stack requests

For scalability purposes, the system must be capable of handling more than twice the above-specified loads.

  1. The system must be capable of processing during normal and peak workload periods within an acceptable range of performance parameters as guaranteed in the service level agreements

1.9  System Support

  1. Problem reports must be logged in some sort of help desk database.
  2. Confirmation, that a problem report has been received, must be sent back as soon as possible.
  3. Anyone reporting a problem must be kept informed of what is being done to solve the problem.

2.  GENERAL OPERATIONAL REQUIREMENTS FOR MAKLIBIS APPLICATION SOFTWARE

2.1  General

  1. The system architecture must be a so-called client/server solution.
  2. To accommodate flexibility and minimise network load the system should have a so-called multi-tier architecture.
  3. The vendor must describe the programming language and the development tools for both client and any server programs.
  4. It must be possible to adapt the system to UUL needs using parameters in the system.
  5. The system must have a graphical user interface.
  6. The GUI should be consistent, predictable, and uniform across all modules.
  7. It should be possible to transfer a key value from one function to another, e.g from the acquisitions function to the circulation function.
  8. The system should allow Ugandan/British formatting of dates (DP MM YY) in MARC and should also support the ISO 8106 for date and time.

2.2 Server Software

  1. The system must use a standardised generally available relational database management system.
  2. The system administrator should have full direct access to all tables and other data in the database.
  3. Application Programming Interfaces (API) should be fully available.

2.3 Database Architecture and Performance

  1. Variable and repeatable fields must be handled.
  2. The indexing methods must permit efficient full text and field delimited searches. Describe the indexing method used by the system.
  3. Proposal must state when real-time update does not work.
  4. Data update in one module must be reflected in al modules
  5. There must be efficient methods for reorganisation of databases without bringing the system down for maintenance.
  6. There must not be any limitations to the size of the database or the database indexes during the expected life span of the system.
  7. The database architecture must make it possible to handle at least 500 concurrent users.
  8. Data entered must be safely validated immediately.

2.4  Client Software

  1. All functions required by

- Staff

- WWW users

Must be fulfilled

  1. The complete client software must be available for the Microsoft Windows operating environments.
  1. The MS-Windows Client should have a published API (Application Programming Interfaces)
  1. The client must be Z39.50 complaint.
  1. The main OPAC interface for the users outside the Library must be a web browser, such as Netscape Communicator or Microsoft Internet Explorer.
  1. The system’s WWW interface must comply with HTML version 3.0 or later.
  1. The WWW OPAC must include a Z39.50/HTTP gateway, which makes it possible to search the MakLib OPAC and external OPACs in the same way.

viii.  It Should be possible to clear the current window from al patron – related information (barcodes, activity information) in circulation as well as in the OPAC (Web and client) – a reset function.

2.5  Printing

  1. It must be possible to export search results to file, for printing and sending by e-mail.
  1. It must be possible to start all kinds of printing from the client software (search results, notices, orders, claims, etc.).
  1. It must be possible to use printers defined directly in the operating system.
  1. It must be possible to designate the printouts, concerning a specific library unit, to a printer in that specific location.
  1. Communication intended for mail must be possible to store in a format that will be accepted by the MakLib service or be possible to store as unformatted text.
  1. It must be possible to use pre-printed forms in well known standard (A4, A5, etc.) or in Library – defined formats (yet to be defined by Mak.Lib).
  1. A facility for sending e-mail (SMTP) from applicable parts of the system must be available.

2.6  Import and Export of Records

  1. The system must support the import and export of records in batch from data media such as tape, CD-ROM, hard disk, and diskette.
  1. The system must support the import and export of records by secure file transfer.
  1. It must be possible to import all types of records/information, bibliographic (bib), authority (auth) and holdings from LIBRIS.
  1. The system must be able to import batches of records in a MARC format (yet to be decided on) and automatically convert/index them.
  1. The system must be able to import single records in MARC format and convert/index them in real-time.
  1. The system must be able to import MARC records through Z39.50.
  1. The system should support online import and conversion of records from Z39.50 complaint databases other than LIBRIS.
  1. It should be possible to export batches of records in internal MARC format.
  1. It should be possible to upload single bib/auth records from the local database to LIBRIS online.
  1. The system should support other common import/export formats for all record types, such as comma delimited text files.
  1. When importing and exporting it should be possible to exclude certain fields or subfields.
  1. The system should provide a mechanism to extract all data to facilitate further migration.

2.7  Reports and Statistics

  1. The Library system must support management statistics and reporting .
  1. The system must be capable of logging all transactions for statistical purposes.
  1. It must be possible for the library to define which data it wishes to log for each transaction.
  1. It must be possible to pre-program and schedule standard reporting.
  1. It must be possible for others than system staff to set parameters for and order, ad-hoc reports.
  1. Selection options must include, but not be limited to:

¨  presence of data element

¨  absence of data element

¨  combination of elements by Boolen operators

¨  defining data elements by ranging

  1. All report, lists and statistics must be available in a variety of output options, including but not limited to:

¨  Batch printout

¨  Printout on demand

¨  Viewable online

¨  Electronic file in standard formats (comma separated or others)

  1. It should be possible for the user to save report generation specifications for future use.

3.  GENERAL OPERATIONAL REQUIREMENTS FOR MAKLIBIS CIRCULATION SYSTEM

3.1  Introduction

MakLib currently has three types of loans to the patrons. These items are basically from as Bank libraries, Closed/slack access section and open shelves.

All these material have varying period of loaning depending where it is hosted. Large parts of the collections at the Main Library are held in closed access stacks and the items have to be requested by the users. This implies that a large amount of requests will be made from the OPAC and printed on call slips, which will be used to fetch the items from the stacks.