UKCS Version 3.0 LMS Functional Requirements

UKCS Version 3.0 LMS Functional Requirements

United Kingdom Core Specification

(UKCS)

Functional Requirements for Library Management Systems

Compiled by Juliet Leeves

Library Systems Consultant

Version 3.0

The UKCShas been made available free of charge due to the cooperation of Juliet Leeves and Ken Chad Consulting Ltd.[1] It is downloaded from the LibTechRFP website.

If you require further help in reviewing your library systems or procuring new systems contact Ken Chad at Ken Chad Consulting.

Creative Commons Attribution Share-Alike Non-Commercial 3.0 License.

Prepared in consultation with:

Ex Libris UK

Infor

Innovative Europe

IS Oxford

Sirsi/Dynix

Talis Information Systems

© Juliet Leeves 2007

How to use the UKCS

The UKCS has been developed to reduce the effort involved in specifying standard functionality which is available on all library management systems (LMSs). It was compiled in consultation with a number of LMS suppliers who agreed a core set of requirements, together with a variant set to meet the needs of differing market sectors. The model agreed with suppliers for the UKCS was a checklist of basic functions which could be expected on any LMS. The checklist is intended to form one part of an Operational Requirement (OR), which is normally included in an Invitation To Tender (ITT) in formal procurement procedures. However, it can also be used in less formal procedures as a simple checklist of features.

It is important to recognise that the UKCS is not an accreditation scheme, and whilst suppliers have agreed a core set of functions which should be available on any LMS, validation of individual supplier responses remains the responsibility of individual libraries. It will still be necessary to evaluate core functionality at supplier demonstrations and site visits – for example, libraries will want to ensure a sensible workflow for the issue process, where a ‘full compliance’ response has been given in the core specification. Libraries will not, however, have to spend time specifying basic functionality in detail or evaluating equally detailed responses, but can concentrate on areas of functionality which are not provided on all systems – in other words, on the differences between systems.

The UKCS should not be regarded as a generic specification, but rather as the core of a complete specification, which will take into account both local requirements and the relative importance of the core requirements. It is essential, therefore, that libraries review the requirements in the UKCS, paying particular attention to the Importance column (explained below), rather than just including the UKCS as an ‘added extra’. This will also help avoid duplication of requirements and wasted effort.

The UKCS is, by definition, geared towards UK market requirements. Terminology is as used in the UK (e.g. supplier rather than vendor, reservation rather than hold). Where necessary, compliance is required with UK law, e.g. Disability Discrimination Act.

Checklist model

The UKCS takes the form of a checklist which details core functionality for the following main functional areas:

Bibliographic database management
OPAC and end user services
Circulation control
Acquisitions
Serials control
Document delivery and inter-library loans
Management information

The checklist comprises the following columns:

Requirement number

Each number is prefixed by R for core requirement or V for variant requirement. Libraries should not change the numbering or text of these requirements – this is because suppliers will have set up standard responses to the UKCS.

Additional requirements or changes to the standard requirements for these functional areas should be specified in a separate section of the OR. Other requirements, such as technical, training and support etc, should also be covered separately (see below for what is not covered).

Type

For variant requirements, the type of library is given: A (Academic), P (Public) and/or S (Special).

Requirement

This column contains a text description of the function.

Importance

There is provision for libraries to indicate the importance of each requirement. The following values are suggested:

3 Important (or mandatory)

2 Highly desirable

1 Desirable

0 Not required (or not applicable).

The reason for the zero value is for libraries to indicate to suppliers where a core or variant requirement is not required or not applicable. This allows for the checklist to be used by a wide variety of libraries which may place differing importance on these requirements, or indeed not need them at all. This can also be used to indicate where a complete functional area is not required – for example, if the Document Delivery function is not needed, all requirements in this section could be marked zero and suppliers instructed not to respond to this section.

It is important that requirements are flagged as not required or not applicable, even if the other values are not used. This is so that suppliers will know they do not have to respond to the requirement. Academic libraries, for example, should flag any variant public library requirements (P) as not applicable.

Compliance

This column should be left blank for suppliers to indicate their compliance with each requirement. The form of the supplier’s response should be defined by the library and made clear in the instructions to suppliers. One of the following forms of response is suggested:

1) Yes/No response – this is the simplest form of response for the checklist approach. Suppliers should be instructed that ‘Yes’ means fully supported and on general release.

2) Response codes – the following codes are suggested:

A Fully supported and on general release

B Partially supported and on general release

C Planned for a future release

D Not supported

Additional information – libraries can indicate in their instructions to suppliers if they want suppliers to provide additional information along with the compliance rating. Some libraries find it helpful to have additional information, perhaps explaining how a particular requirement is met. It should be remembered, however, that all these responses have to be read (!) and many of the core requirements can be regarded as standard. A compromise might be to flag a requirement (e.g. by an asterisk) if additional information is required.

Suppliers can also, at the discretion of the library, be invited to add their own comments, if they feel a particular response needs further clarification, e.g. if a ‘partially supported’ code is used, or a date if planned for a future release.

Further instances where additional information can be useful are detailed below.

Evaluating suppliers’ responses is one of the most time-consuming parts of the procurement process, and it is often difficult to differentiate between systems, particularly at the functional level.

A large number of the core requirements will be available on all library systems, and the differences may lie in newer aspects of functionality or local requirements, which will be specified separately. The advantage of the UKCS is that it allows libraries to concentrate on critical and important aspects of functionality, over and above the core list, safe in the knowledge that the basic functionality is covered. It is also important to recognise that the functional evaluation is only one part of the process, and other evaluation criteria will be equally, if not more, important, such as supplier viability, technical aspects and, not least, cost.

Instructions to suppliers

Instructions to suppliers are normally covered in the ITT. It is important that instructions and information concerning the UKCS are given, including:

codes to be used for indicating importance of requirements
how to respond to requirements which have been coded as ‘not required/applicable’
forms of response for compliance
instructions regarding additional information.

What is not covered

The requirements covered by the UKCS relate to core functionality for the main functional areas listed above. As already mentioned, additional requirements for these areas should be specified separately.

Library management systems often include optional software for other services, such as resource discovery systems/portals, e-resource management and reading lists. These are not currently covered by UKCS. In any case, they may often be supplied independently of the LMS.

Requirements relating to inter-operability with local or corporate systems, e.g. customer contact centres or organisational portals, are not covered and would need to be specified separately.

The UKCS concentrates on library-system specific functionality, and does not cover general techniques provided by underlying operating systems, e.g. Windows techniques such as cut and paste, drop down menus etc.

Users should be aware that functional requirements form only one part of an OR. An OR will normally consist of the following sections:

Introduction
Background information
Technical requirements, e.g. database, networking and operating systems, system operation and administration, character sets, data migration, barcodes/RFID tags, inter-operability with other local or corporate systems
Functional requirements (UKCS plus additional local functional requirements)
Optional software requirements, e.g. resource discovery system/portal, e-resource management, reading lists
Support and training requirements
Various appendices including statistical information about the library

The OR will itself normally form part of an Invitation to Tender (ITT) where a formal procurement is involved. For further advice concerning tender procedures and contracts, libraries should consult a procurement professional.

Standards

Whilst it is important that the relevant standards are specified in the UKCS, the checklist approach may not be sufficient to determine compliance, and this is one area where libraries may wish to ask for additional information to ascertain how the standard is implemented (often involving the use of profiles) and how it affects functionality. A useful guide to standards issued before 2002 is ‘The RFP Writer’s Guide to Standards for Library Systems’ which can be found at: As stated previously, it is important to follow up how standards are used at system demonstrations and site visits.

A particular UK difficulty relates to inter-library loans (ILL). Whilst the UKCS includes reference to the international ILL protocol (ISO 10160/10161), it has also been necessary to include requirements for the British Library Document Supply Centre ARTTel and ARTEmail systems, because only these systems support the full range of services and delivery options which BLDSC offer (the ISO/ILL gateway ARTISO does not yet offer the full range of delivery options).

Customisation

Throughout the UKCS, reference has been made to ‘library-defined’ options, e.g. screen layouts, fields and field labels, indexes, record displays etc. Libraries may wish to ascertain through additional information from the supplier, whether such customisation is done by the supplier or by the library, and if done by the library, whether any special expertise is needed. It is also suggested that suppliers are asked if software upgrades impact on any configuration done by the library. As before, it is important that libraries see the actual interface for system configuration at supplier demonstrations and site visits.

Disclaimer

Every attempt has been made to provide accurate information in the UKCS, but the author accepts no liability for errors or omissions, or for loss or damage arising from using the UKCS.

The guidance given in the section ‘How to use the UKCS’ does not constitute definitive or legal advice and should not be regarded as a substitute therefor. The author does not accept any liability for any loss suffered by persons who consult this section, whether or not such loss is suffered directly or indirectly as a result of reliance placed on guidance given in this section.

Type /

Requirement

/ Importance / Compliance

1.

General functionality

The system must:
incorporate the following functions:

R1

/ bibliographic database management (including authority control)

R2

/ OPAC and end user services

R3

/ circulation control

R4

/ acquisitions

R5

/ serials control

R6

/ document delivery and inter-library loans

R7

/ management information

R8

/ be integrated with data only needing to be entered once to support all functions

R9

/ support realtime updating in all functions

R10

/ track staff operations for audit purposes

R11

/ provide for progressing material through the various stages of processing, so that at all times the current status of an item can be shown, e.g. on order, in cataloguing

R12

/ provide for multi-site operation

R13

/ comply with the relevant provisions of the Disability Discrimination Act 1995

R14

/ comply with the Web Accessibility Initiative Level AA

R15

/ comply with the relevant provisions of the Special Educational Needs and Disability Act 2001

R16

/ comply with the provisions of the Data Protection Act 1998

Operation and user interface

The system must:

R17

/ provide a graphical user interface in all functions

R18

/ provide for direct access between functions where workflows dictate this

R19

/ allow staff to initiate a database search from any point in the system where workflows dictate this

R20

/ provide for use of function/hot keys for frequently used functions

R21

/ allow navigation tasks to be performed via the keyboard as well as with a mouse

R22

/ allow different searching/display options for staff for different functions

R23

/ allow library-defined inactivity time-outs in all functions

Help

R24

/ The system must have help facilities, to include:

R25

/ screen examples

R26

/ context-sensitive help

R27

/ search option for help on given topics

R28

/ tutorials

Customisation and configuration

The Library must be able to customise the system in the following areas:

R29

/ screen layouts for public access

R30

/ bibliographic fields and field labels

R31

/ indexes

R32

/ record displays

R33

/ help texts

R34

/ The interface for system configuration must be consistent with the rest of the system

Access to the system

R35

/ Access to the system must be password protected

R36

/ Access should be prevented if a pre-set number of tries is exceeded
The system must allow:

R37

/ different levels of access to functions/sub-functions according to level of user

R38

/ suppression of disallowed options

R39

/ restriction of groups of users/workstations to specific functions

R40

/ maintenance of access levels by the Library

2.

Bibliographic database management

General

The system:

R41

/ must provide for creating and maintaining bibliographic records
must support:

R42

/ MARC21

R43

/ Dewey (current edition)

R44

/ Library of Congress classification (current edition)

R45

/ Library of Congress Subject Headings (current edition)

V1

/ A/S / MeSH (current edition)

R46

/ ISO 2108 (ISBN, current revision)

R47

/ must allow extra local bibliographic fields to be defined

R48

/ must not impose limits on record, field or subfield size, or the number of fields in a record (beyond that imposed by the MARC format)

Record import and export

The system must:

R49

/ allow online access to a range of library-defined databases using Z39.50 (current version) and provide for the import of bibliographic records

R50

/ provide for the import of authority records

R51

/ provide for the import of records in batch and in realtime, i.e. direct to the cataloguing screen

R52

/ allow imported records, which match records already on the database, to overwrite or merge with those records, or be rejected, according to library-defined parameters

R53

/ allow the export of records in MARC21 exchange format

Record creation and editing

The system must:

R54

/ provide a full-screen edit interface for creating bibliographic records

R55

/ allow for library-defined templates for different types of material, e.g. monographs, serials

R56

/ provide both a MARC and labelled input interface

R57

/ prevent the creation of duplicate records by allowing pre-searching and matching on various fields including control numbers (ISBN, ISSN)

R58

/ allow existing records, from external sources or the internal database, to be copied and used as the basis for a new record

R59

/ allow data common to more than one record to be duplicated for a succession of records

R60

/ validate ISBN-10 and ISBN-13

R61

/ validate ISSNs

R62

/ allow for adding new copies to an existing record

R63

/ provide for the online deletion of bibliographic records; it must not be possible to delete a bibliographic record if it still has item (copy) records attached

R64

/ provide for immediate retrieval on all access points defined by the library

Authority control

The system must:

R65

/ support MARC21 Authorities format
allow for authority control on certain fields, to include:

R66

/ authors

R67

/ subjects

R68

/ series

R69

/ provide for the creation, editing and deletion of authority records

R70

/ allow access to authority records during record creation for checking/selecting headings

R71

/ allow display of works associated with an authority heading

R72

/ allow for global changes of headings and merging of headings, with associated records amended automatically

Electronic resources

R73

/ The system must allow for the input of URLs, URNs and other URIs in bibliographic records for electronic location and access information

R74

The system must incorporate a link checker

Item (copy) record management

R75

/ The system must allow unique item identifiers (e.g. barcodes, RFID tags) to be assigned to item records on the system

R76

/ There must be no effective limit to the number of item records linked to the bibliographic record

R77

/ It must be possible to specify library-defined defaults for item data and to copy item data from one record to another

R78

/ It must be possible to mark copies as withdrawn or deleted

R79

/ The system must give a warning if the last copy is being withdrawn or deleted

R80

/ It must be possible to assign a replacement item identifier to an item, and transfer all transaction data to the new item record

Stock management

R81

/ The system must provide a stock checking facility, allowing the use of portable devices to store and upload item identifiers (e.g. barcodes, RFID tags) to the database, and report inconsistencies

R82

/ The system must provide routines for bulk changes of data, e.g. location, loan category

3.

OPAC and end user services

NB: The term OPAC is used to refer to both staff and end user access to the system. The requirements are defined in the context of a web-based OPAC.

General

The system must:

R83