Download - UKCS Version3 CC Licensed Rev
-
7/31/2019 UKCS Version3 CC Licensed Rev
1/35
United Kingdom Core Specification
(UKCS)Functional Requirements for Library Management Systems
Compiled by Juliet Leeves
Library Systems Consultant
Version 3.0The UKCS has 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. www.kenchadconsulting.com
Creative Commons Attribution Share-Alike Non-Commercial 3.0 License.
Prepared in consultation with:DS
Ex Libris UK
Infor
Innovative Europe
IS Oxford
Sirsi/Dynix
Talis Information Systems
1 For the background to this imitative see: 'Making it easier to specify systems'. By Ken Chad & Juliet Leeves. CILIP
Libraries+Information Gazette. 2nd December 2010. Available from the Ken Chad Consulting websitehttp://www.kenchadconsulting.com/wp-content/uploads/2010/12/Making_it_easier_to_specify_systems_Dec2010.pdf
You are free:
to Share to copy, distribute and transmit the workto Remix to adapt the work
Under the following conditions:
Attribution You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse
you or your use of the work).
Noncommercial You may not use this work for commercial purposes.Share Alike If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to thisone.
With the understanding that:
Waiver Any of the above conditions can be waived if you get permission from the copyright holder.Public Domain Where the work or any of its elements is in the public domain under applicable law, that status is in no way affected by the
license.
Other Rights In no way are any of the following rights affected by the license:
Your fair dealing or fair use rights, or other applicable copyright exceptions and limitations;The author's moral rights;
Rights other persons may have either in the work itself or in how the work is used, such as publicity or privacy rights.
Notice For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to thisweb page.
http://www.kenchadconsulting.com/http://www.creativecommons.org/licenses/by-nc-sa/3.0http://www.creativecommons.org/licenses/by-nc-sa/3.0http://www.kenchadconsulting.com/wp-content/uploads/2010/12/Making_it_easier_to_specify_systems_Dec2010.pdfhttp://www.creativecommons.org/licenses/by-nc-sa/3.0http://www.kenchadconsulting.com/wp-content/uploads/2010/12/Making_it_easier_to_specify_systems_Dec2010.pdfhttp://www.kenchadconsulting.com/http://www.creativecommons.org/licenses/by-nc-sa/3.0 -
7/31/2019 UKCS Version3 CC Licensed Rev
2/35
UKCS Version 3.0 LMS Functional Requirements
Juliet Leeves 2007
Juliet Leeves 2007 2
-
7/31/2019 UKCS Version3 CC Licensed Rev
3/35
UKCS Version 3.0 LMS Functional Requirements
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 checklistof 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 basicfunctionality 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 differencesbetween
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 theUK (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
Juliet Leeves 2007 3
-
7/31/2019 UKCS Version3 CC Licensed Rev
4/35
UKCS Version 3.0 LMS Functional Requirements
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 Desirable0 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 therequirement. 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 suppliers 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.
Juliet Leeves 2007 4
-
7/31/2019 UKCS Version3 CC Licensed Rev
5/35
UKCS Version 3.0 LMS Functional Requirements
OR
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 aparticular 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 iscovered. 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 resourcediscovery 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.
Juliet Leeves 2007 5
-
7/31/2019 UKCS Version3 CC Licensed Rev
6/35
UKCS Version 3.0 LMS Functional Requirements
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
Writers Guide to Standards for Library Systems which can be found at:
http://www.niso.org/standards/std_resources.html . 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 requirementsfor 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.
Juliet Leeves 2007 6
http://www.niso.org/standards/std_resources.htmlhttp://www.niso.org/standards/std_resources.html -
7/31/2019 UKCS Version3 CC Licensed Rev
7/35
UKCS Version 3.0 LMS Functional Requirements
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 legaladvice 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.
Juliet Leeves 2007 7
-
7/31/2019 UKCS Version3 CC Licensed Rev
8/35
UKCS Version 3.0 LMS Functional Requirements
Type Requirement
Importance
Compliance
1. General functionalityThe system must:
incorporate the following functions:
i. bibliographic database management (including authority control)
ii. OPAC and end user services
iii. circulation control
iv. acquisitions
v. serials control
vi. document delivery and inter-library loans
vii. management informationviii. be integrated with data only needing to be entered once to support all
functions
ix. support realtime updating in all functions
x. track staff operations for audit purposes
xi. 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
xii. provide for multi-site operation
xiii. comply with the relevant provisions of the Disability Discrimination Act
1995
xiv. comply with the Web Accessibility Initiative Level AA
xv. comply with the relevant provisions of the Special Educational Needs and
Disability Act 2001
xvi. comply with the provisions of the Data Protection Act 1998
Operation and user interface
The system must:
xvii. provide a graphical user interface in all functions
xviii
.
provide for direct access between functions where workflows dictate this
xix. allow staff to initiate a database search from any point in the system where
workflows dictate thisxx. provide for use of function/hot keys for frequently used functions
xxi. allow navigation tasks to be performed via the keyboard as well as with a
mouse
xxii. allow different searching/display options for staff for different functions
xxiii
.
allow library-defined inactivity time-outs in all functions
Help
xxiv
.
The system must have help facilities, to include:
xxv. screen examples
xxvi
.
context-sensitive help
xxvi search option for help on given topics
Juliet Leeves 2007 8
-
7/31/2019 UKCS Version3 CC Licensed Rev
9/35
UKCS Version 3.0 LMS Functional Requirements
xxvi
ii.
tutorials
Customisation and configuration
The Library must be able to customise the system in the following areas:
xxix. screen layouts for public access
xxx. bibliographic fields and field labels
xxxi
.
indexes
xxxi
i.
record displays
xxxi
ii.
help texts
xxxi
v.
The interface for system configuration must be consistent with the rest of the
system
Access to the systemxxx
v.
Access to the system must be password protected
xxx
vi.
Access should be prevented if a pre-set number of tries is exceeded
The system must allow:
xxx
vii.
different levels of access to functions/sub-functions according to level of
user
xxx
viii.
suppression of disallowed options
xxxi
x.
restriction of groups of users/workstations to specific functions
xl. maintenance of access levels by the Library
2. Bibliographic database managementGeneral
The system:
xli. must provide for creating and maintaining bibliographic records
must support:
xlii. MARC21
xliii. Dewey (current edition)
xliv. Library of Congress classification (current edition)xlv. Library of Congress Subject Headings (current edition)
V1 A/S MeSH (current edition)
xlvi. ISO 2108 (ISBN, current revision)
xlvii
.
must allow extra local bibliographic fields to be defined
xlvii
i.
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:
xlix. allow online access to a range of library-defined databases using Z39.50(current version) and provide for the import of bibliographic records
l. provide for the import of authority records
Juliet Leeves 2007 9
-
7/31/2019 UKCS Version3 CC Licensed Rev
10/35
UKCS Version 3.0 LMS Functional Requirements
li. provide for the import of records in batch and in realtime, i.e. direct to the
cataloguing screen
lii. 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
liii. allow the export of records in MARC21 exchange format
Record creation and editing
The system must:
liv. provide a full-screen edit interface for creating bibliographic records
lv. allow for library-defined templates for different types of material, e.g.
monographs, serials
lvi. provide both a MARC and labelled input interface
lvii. prevent the creation of duplicate records by allowing pre-searching and
matching on various fields including control numbers (ISBN, ISSN)
lviii. allow existing records, from external sources or the internal database, to be
copied and used as the basis for a new record
lix. allow data common to more than one record to be duplicated for a successionof records
lx. validate ISBN-10 and ISBN-13
lxi. validate ISSNs
lxii. allow for adding new copies to an existing record
lxiii. 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
lxiv. provide for immediate retrieval on all access points defined by the library
Authority control
The system must:
lxv. support MARC21 Authorities format
allow for authority control on certain fields, to include:
lxvi. authors
lxvii
.
subjects
lxvii
i.
series
lxix. provide for the creation, editing and deletion of authority records
lxx. allow access to authority records during record creation for
checking/selecting headings
lxxi. allow display of works associated with an authority headinglxxii
.
allow for global changes of headings and merging of headings, with
associated records amended automatically
Electronic resources
lxxii
i.
The system must allow for the input of URLs, URNs and other URIs in
bibliographic records for electronic location and access information
lxxi
v.
The system must incorporate a link checker
Item (copy) record management
lxxv
.
The system must allow unique item identifiers (e.g. barcodes, RFID tags) to
be assigned to item records on the system
lxxv
i.
There must be no effective limit to the number of item records linked to the
bibliographic record
lxxv It must be possible to specify library-defined defaults for item data and to
Juliet Leeves 2007 10
-
7/31/2019 UKCS Version3 CC Licensed Rev
11/35
UKCS Version 3.0 LMS Functional Requirements
copy item data from one record to another
lxxv
iii.
It must be possible to mark copies as withdrawn or deleted
lxxi
x.
The system must give a warning if the last copy is being withdrawn or
deleted
lxxx
.
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
lxxx
i.
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
lxxx
ii.
The system must provide routines for bulk changes of data, e.g. location,
loan category
3. OPAC and end user servicesNB: 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:
lxxx
iii.
provide an online public access catalogue (OPAC) for use by end users
lxxx
iv.
provide additional access to the bibliographic database for staff use only in
the different functions, to include:
lxxx
v.
additional indexes
lxxx
vi.
ability to access all records in stock, on order, in process etc.
lxxx
vii.
additional information relating to loans, borrowers, items on order etc.
lxxx
viii.
additional displays, e.g. MARC format
lxxx
ix.
The system must support Z39.50 (current version) client and server
xc. It must be possible to display help, including examples, on search screens
xci. It must be possible to suppress certain categories of material from display to
the end user on the OPAC (e.g. no copies available for loan/request)
xcii. It must be possible to suppress individual bibliographic records from display
to the end user on the OPACIndexing
The system must allow the Library to define:
xciii
.
which fields/subfields or combination of fields/subfields are indexed for the
different search options
xciv
.
which search options are offered to staff and end users
xcv. the type of indexing applied, e.g. keyword, phrase/browse (i.e. with implicit
right-hand truncation)
The system must be able to sort the classification index for the following
schemes, in accordance with general principles for the scheme:
xcvi
.
Dewey (current edition)
xcvi Library of Congress (current edition)
Juliet Leeves 2007 11
-
7/31/2019 UKCS Version3 CC Licensed Rev
12/35
UKCS Version 3.0 LMS Functional Requirements
Interface
The system must provide:
xcvi
ii.
a simple (novice) interface, including non-Boolean searching
xcix. an advanced search interface, including:
c. explicit use of Boolean operators AND, OR, NOT
ci. specific fields to search
cii. left-hand truncation
ciii. right-hand truncation
civ. wildcards
cv. links on search screens and results displays to other search options, e.g.
browse index
cvi. at all times, a display of the current search
Searching
cvii. It must be possible to perform a keyword search across all defined indexes oron selected indexes
cviii
.
All commands and search keys must be case-insensitive and it must be
possible to ignore diacritics and punctuation for searching
cix. The system must allow searching using variant spellings
Search limits
The system must offer the ability to pre-limit searches:
cx. by date (including open and closed range of dates)
cxi. by language
cxii. by format of publication (e.g. video, serial)
cxiii. to particular collections
cxiv
.
by location
The system must offer the ability to post-limit searches:
cxv. by date (including open and closed range of dates)
cxvi
.
by language
cxvi
i.
by format of publication (e.g. video, serial)
cxvi
ii.
to particular collections
cxix
.
by location
Display of search results and navigation
The system must:
cxx. provide different levels of display (brief, full) and allow the Library to define
which elements in a record are included in each display
cxxi
.
allow default sort order of search results to be library-defined for each search
type
cxxi
i.
allow the user to be able to change the default sort order
cxxi
ii.
allow users to view serial holdings, including serials check-in and latest issue
information
Juliet Leeves 2007 12
-
7/31/2019 UKCS Version3 CC Licensed Rev
13/35
UKCS Version 3.0 LMS Functional Requirements
cxxi
v.
display the record immediately in the event of a single hit being retrieved
(rather than intermediate index display)
cxxv
.
support hypertext links between elements in records allowing highlighted
index terms to be used as the basis of further searches
cxxv
i.
support hypertext links from cross references to authorised headings
cxxv
ii.
support hypertext links from bibliographic records to other electronic
information resources both local and remote via URLs, URNs and other
URIs
Output and saving
The system must:
cxxv
iii.
allow users to mark or select references for printing and downloading
cxxi
x.
allow users to review and edit the list and to sort items
cxxx
.
allow users to download lists of saved records to disk or e-mail or to send to
an attached or network printercxxx
i.
offer a range of output formats for exported records, including:
cxxx
ii.
full and brief records
cxxx
iii.
MARC21
cxxx
iv.
ASCII
cxxx
v.
EndNote
cxxx
vi.
ProCite
cxxx
vii.
library-defined formats
Self-service options
cxxx
viii.
The system must allow users access to their own records and transaction
details (as authorised by user ID/PIN). Transaction details must include:
cxxx
ix.
loans
cxl. reservations
cxli. finescxlii
.
ILL requests
cxlii
i.
purchase requests
Users must be able to:
cxli
v.
make reservations
cxlv
.
cancel reservations
V2 A make bookings for short loan material
cxlv
i.
make renewals
cxlv make ILL requests and view progress
Juliet Leeves 2007 13
-
7/31/2019 UKCS Version3 CC Licensed Rev
14/35
UKCS Version 3.0 LMS Functional Requirements
cxlv
iii.
make purchase requests
cxli
x.
update their contact details
cl. The system must interface with automated telephone renewal systems for
self-service renewals via this method, using the SIP2/NCIP standards
cli. The system must interface with self-issue/return devices using the
SIP2/NCIP standards
clii. All circulation parameter settings (e.g. loan rules, borrower blocks) must also
apply to self-service functions
4. Circulation controlCirculation policies
cliii. Circulation policies must be library-defined
Circulation policies must be determined by a combination of:
cliv. borrower categoryclv. item category
clvi. location
Circulation policies determined in this way must include:
clvii
.
loan periods (expressed in days, weeks, months, extended/fixed date)
clvii
i.
reference only
clix. loan entitlements (per item category and overall)
clx. renewal periods (according to method, e.g. phone, self-service etc)
clxi. renewal limits by methodclxii
.
reservations - charges
clxii
i.
reservations allow/disallow
clxi
v.
reservations - maximum number (by item category and overall)
clxv
.
reservations - loan period reduction if more than one
clxv
i.
reservations - length of time held on reservations shelf
clxvii.
reservations - expiry period for unsatisfied reservations
clxv
iii.
fine rates (normal and special rates, e.g. overdue reserved item)
clxi
x.
maximum fines
clxx
.
charges subscription/membership
clxx
i.
charges hire charges
clxxii. notice production type (e.g. overdue and frequency)
clxx notice production - format (e.g. print or e-mail)
Juliet Leeves 2007 14
-
7/31/2019 UKCS Version3 CC Licensed Rev
15/35
UKCS Version 3.0 LMS Functional Requirements
clxx
iv.
It must be possible to apply library-defined grace periods
clxx
v.
The system must maintain a calendar of closed dates for each location. All
circulation transactions including due dates, fines, recalls and reservations
awaiting collection must take account of closed days
clxx
vi.
Authorised library staff must be able to update parameters with immediate
effect
General circulation functions
clxx
vii.
The system must provide automatic blocks/alerts on borrowers, including:
clxx
viii.
expired ticket
clxx
ix.
outstanding fines/fees (library-definable threshold)
clxx
x.
overdue/recalled items (library-defined threshold)
clxx
xi.
over entitlement
clxx
xii.
Automatic blocks/alerts must be automatically removed
clxx
xiii.
The system must allow authorised staff to input manual blocks with an
explanatory message
clxx
xiv.
Authorised staff must be able to override any borrower or item block.
clxx
xv.
The system must show the status of items (e.g. reserved, awaiting collection)
at all times to both staff and end users
clxx
xvi.
The system must maintain a loan history for both items and borrowers,
retrievable for a library-defined period
clxx
xvii.
The system must support the circulation of uncatalogued items and recording
of brief information when issuing, using library-defined defaults for loan
control and trapping such items on return to allow full details to be input
clxx
xviii
.
The system must allow for loans of multiple sets, e.g. music, drama sets
V3 P The system must allow end users to borrow, return and renew items at any
service point
V4 P The system must alert the operator to items which need to be returned totheir home location and manage the transit of such items, showing their
current status at all times
Issue, return and renewal
clxx
xix.
It must be possible to enter the unique item identifier (e.g. barcode, RFID
tag) by machine (e.g. scanner, reader) or manual input
cxc. Item identifier only must be required for return
cxci. Borrower and item status must be automatically checked on all three
functions; any blocks/ accompanying messages must be displayed with an
audible warning
cxcii
.
It must be possible to override the calculated due date at the point of
issue/renewal, subject to borrower and item checkscxcii
i.
Borrower expiry date must override due date; warning of imminent expiry
date must be given on screen
Juliet Leeves 2007 15
-
7/31/2019 UKCS Version3 CC Licensed Rev
16/35
UKCS Version 3.0 LMS Functional Requirements
cxci
v.
The system must allow a means of ending the current transaction (to prevent
the issue of items to a previously accessed borrower)
V5 A It must be possible to backdate the date of return to accommodate book drop
returns
cxcv
.
The system must allow for flagging items as claimed returned, leaving the
item linked to the borrower as a claimed returned item but suppressing
notices and fines
cxcv
i.
It must be possible to flag items as lost, leaving the item linked to the
borrower as a lost item, but suppressing notices and fines
cxcv
ii.
The system must alert staff of lost items on issue and return
cxcv
iii.
It must be possible to flag items as damaged and alert staff and end users
on issue and return
cxci
x.
It must be possible to flag items with multiple elements, e.g. triple CD packs,
and alert staff/users on issue and return to ensure sets are complete
The system must:
cc. allow bulk renewal of all items on loan (subject to borrower and itemchecks), or selected items
cci. prevent renewal of overdue items (library defined threshold), reserved or
recalled items, and items over the renewal limit
allow for renewal of unseen items via:
ccii. telephone
cciii
.
self-renewal via OPAC
cciv. self-renewal via automated telephone answering service
ccv. flag method of renewal
ccvi. provide direct access to the borrower record for personal details and details
of loans, fines and reservations, from issue, return or renewal functions
ccvii
.
provide direct access to the full item record, including reservation
information, from the borrower's loan record
Fines and charges
The system must:
ccvii
i.
show details for each fine or charge, e.g. the loan which incurred the fine
ccix. accumulate fines and charges for payment in a single transaction
ccx. allow for payment to be accepted either in the Return function or by direct
access to the fine payment screen from the Return function
ccxi. allow payment in full or part against any individual chargeccxii
.
allow payment in full or part against all charges
ccxii
i.
allow authorised staff to waive all or some fines/charges owing. The reason
for the waiver must be recorded.
ccxi
v.
It must be possible to defer payment (at the discretion of the library)
ccxv
.
It must be possible to record the payment method
V6 P The system must enable group payment of fines, e.g. families
ccxv
i.
It must be possible to print receipts of fines/charges paid on attached or
networked printer
ccxv
ii.
The system must include cash management functions to enable balancing of
income received on the system with that recorded on tills
Juliet Leeves 2007 16
-
7/31/2019 UKCS Version3 CC Licensed Rev
17/35
UKCS Version 3.0 LMS Functional Requirements
ccxv
iii.
It must be possible to set a default replacement cost (where cost not specified
on item record) for lost books
ccxi
x.
It must be possible to set processing/administration fees
ccxx
.
Financial history should be retrievable for a library-defined period
ccxx
i.
It must be possible to handle other charges, including:
ccxx
ii.
subscription/membership charges
ccxx
iii.
hire charges
ccxx
iv.
reservation charges
ccxx
v.
library sales
ccxxvi.
The system must allow refunds to be made and recorded
Reservations
The system must:
ccxx
vii.
allow title-level (first available copy) reservations by staff and end users
ccxx
viii.
allow item category and copy specific reservations by staff only
V7 P allow grouping of locations to satisfy reservations
ccxx
ix.
allow/disallow reservations on items on order
ccxx
x.
allow/disallow available items (i.e. on shelf) to be reserved if reservation
placed in the library
ccxx
xi.
automatically notify staff at each site of reservations for items not on loan
(remote reservations) for shelf check
ccxx
xii.
allow staff to record not found status against remote reservation request
ccxx
xiii.
allow for remote reservation requests to be routed between sites if on shelf
copy at more than one site
ccxx
xiv.
allow for a default collection point to be specified which can be changed if
required by staff/end users
ccxxxv.
allow reduction of loan periods when there are outstanding reservations onitems
ccxx
xvi.
allow generation of recall notices for reserved items (recall item due back
soonest), and reduction of the loan period
ccxx
xvii.
alert staff of a reservation on an item on return from loan and notify the
requester that the item is awaiting collection
ccxx
xviii
.
alert staff/end users if a reservation is awaiting collection, whenever the user
record is accessed
ccxx
xix.
allow for reservations to be cancelled automatically on expiration
ccxl. allow for reservations to be cancelled manually by staff (with provision forreason)
ccxli Staff must be able to change the order of the reservation queue
Juliet Leeves 2007 17
-
7/31/2019 UKCS Version3 CC Licensed Rev
18/35
UKCS Version 3.0 LMS Functional Requirements
ccxli
i.
It must be possible to set an expiry date for uncollected reservations, with
automatic notification to staff (to remove from reserve shelf)
ccxli
ii.
It must be possible to set an expiry date for unsatisfied reservations, with
automatic notification to end users
Bookings
ccxli
v.
The system must support booking of equipment, e.g. PCs, either directly on
the system or via an interface with a bookings system using SIP2/NCIP
standards
Borrower records
ccxl
v.
It must be possible to import and update borrower information from the
organisational database
ccxl
vi.
The system must be able to generate a PIN number automatically or to accept
an externally derived PIN
ccxl
vii.
It must be possible to create/edit borrower records manually in addition to
importing them
V8 P It must be possible to duplicate data common to more than one borrower, e.g.family details
ccxl
viii.
Fields for the borrower record must be library-defined. Standard fields must
include:
ccxli
x.
name
ccl. address (provision for at least two addresses)
ccli. e-mail address (provision for at least two addresses)
V9 A automatic use of address by date (term/vacation)
cclii
.
telephone numbers
cclii
i.
borrower category
V10 P date of birth (under 18s)
V11 P home branch
V12 A location/department
V13 A course
ccliv
.
joining date
cclv. date of expiry
cclvi
.
last use
cclvi
i.
free text notes/messages
V14 P The system must provide an automatic change to borrower category, once
the borrower reaches 18
cclvi
ii.
Borrower records must be accessible by name and number
cclix
.
Library staff must be able to delete borrowers' records, in bulk or
individually, except where current transactions or blocks are outstanding
cclx. It must be possible to delete records by the date of expiry
cclxi
.
When a library card is being replaced, the existing borrower's details must be
carried across from the old card
cclxi
i.
It must be possible to flag a borrower barcode/library card as lost,
prohibiting transactions on that card and alerting staff when it is used
Juliet Leeves 2007 18
-
7/31/2019 UKCS Version3 CC Licensed Rev
19/35
UKCS Version 3.0 LMS Functional Requirements
cclxi
ii.
The system must be able to generate unique user numbers and accept
numbers from an externally derived source
Notices
cclxi
v.
The system must allow automatic generation of notices, including:
cclx
v.
overdue letters
cclx
vi.
fines
cclx
vii.
replacement costs
cclx
viii.
recalls
cclxi
x.
notification of item awaiting collection
The system must allow notices to be generated in a range of formats, to
include:cclx
x.
print
cclx
xi.
e-mail
cclx
xii.
SMS messaging
cclx
xiii.
Text and format of notices must be library-defined
A Short loans
V15 A The system must allow for short loan periods to be set, including both hourly
and overnight loans
V16 A Hourly loans must cater for both rolling hourly periods (e.g. items due back
four hours after issue) and fixed times
V17 A It must be possible to maintain items in a short loan collection by allocating
temporary short loan status linked to courses and reading lists
V18 A It must be possible to set specific parameters for short loan items, to include:
V19 A loan periods
V20 A loan entitlements
V21 A renewal periods
V22 A renewal limits
V23 A reservationsV24 A fine rates
V25 A notice production
V26 A The system must support bookings of short loan items for a given date/time
P Mobile library services
P The system must offer equivalent circulation functions to mobile libraries, to
include:
V27 P issue, return and renewal of items
V28 P borrower loans and messages
V29 P fines and charges
V30 P interception of reserved items
V31 P borrower registration
V32 P borrower search
Juliet Leeves 2007 19
-
7/31/2019 UKCS Version3 CC Licensed Rev
20/35
UKCS Version 3.0 LMS Functional Requirements
V33 P OPAC search
V34 P It must be possible to list all stop points and group them into routes
V35 P Loans must be associated with a stop point/route
V36 P The system must support bulk renewals of all loans at a stop point (for use if
stop point is postponed)
V37 P Mobile library transactions must be synchronised with the main librarysystem
P Housebound services
P The system must support services to the housebound to include:
V38 P profiles and borrower history of housebound readers to enable selections to
be made
V39 P generation of pick lists
V40 P issue and return of selected items to individual housebound readers
according to specific parameters
V41 P block issue and return of selected items to day centres, homes etc according
to specific parameters
P Project/group loansV42 P It must be possible to group multiple items for issue under a single parent
identifier
V43 P It must be possible to return items from the project/group loan individually
V44 P The system must automatically return the parent item when the last on-loan
item in the group has been returned
V45 P It must be possible to unlink on-loan items from the project/group loan, so
that the rest of the project/group loan can be re-issued
P Stock rotation
V46 P It must be possible to move collections of stock from branch to branch on a
rotating basis
V47 P The rota must incorporate dates for transfer of collections and produce an
alert when collections are due to be moved
V48 P Items on loan in a collection must be routed to the new location
Back-up circulation
cclx
xiv.
In the event of system or network failure, there must be a back-up circulation
function capable of handling all issue and return transactions without
disruption to services
cclx
xv.
Recovery of transactions must be possible as soon as the system is back
online
cclx
xvi.
All recovered transactions must be time-stamped so that later transactions
supersede earlier onescclx
xvii.
The system must report on current reservations on recovered return
transactions
5. AcquisitionsNB: This section covers the acquisition of all material, including
monographs and serials. Specific reference to serials is made where
necessary. Ongoing control of serial issues (i.e. check-in, claiming, routing
and binding) is covered in 6 below.
General
cclxxviii
.
There must be provision for acquiring print and non-print material, includingmonographs and serials, with integrated financial management and a
common supplier file
Juliet Leeves 2007 20
-
7/31/2019 UKCS Version3 CC Licensed Rev
21/35
UKCS Version 3.0 LMS Functional Requirements
cclx
xix.
An audit trail must be maintained for all material at all stages of the
acquisitions process
The system must support Electronic Data Interchange (EDI) in conformance
with the EDIFACT standards, to include the following EDI transactions for
both monographs and serials:
cclx
xx.
orders
cclx
xxi.
claims
cclx
xxii.
cancellations
cclx
xxiii
.
acknowledgements
cclx
xxiv
.
invoices
cclx
xxv.
reports
cclx
xxvi
.
quotes
cclx
xxvi
i.
fulfilments
cclx
xxvi
ii.
It must be possible to produce acquisitions notices in print format
cclx
xxix
.
Format and content of acquisitions notices must be library-definable
ccxc
.
The system must allow for input to be corrected and amended at all stages,
including undo operations
ccxc
i.
It must be possible to display on order records on the OPAC and
allow/disallow reservations to be placed
ccxc
ii.It must bepossibleto readbarcodes printed on books as an aid in acquisitions
processing
ccxciii.
It must be possible to read barcodes printed on serials as an aid inacquisitions processing
ccxc
iv.
The system must support the import of order/bibliographic data from
suppliers, e.g. from showroom visits or suppliers websites.
Potential requirements file
ccxc
v.
It must be possible to hold potential order records on the system (e.g.
approvals lists).
Bibliographic data
ccxc
vi.
It must be possible to input bibliographic data for order records both by
direct input and by use of imported bibliographic records at the order stage.
Requirements for bibliographic data entry/import are the same as described
under bibliographic database management (see 2 above).ccxc
vii.
It must be possible to input both brief and full data at the order stage
Juliet Leeves 2007 21
-
7/31/2019 UKCS Version3 CC Licensed Rev
22/35
UKCS Version 3.0 LMS Functional Requirements
ccxc
viii.
The system must allow for bibliographic and item information on order
records to be used as the basis for catalogue records and vice-versa
Supplier records
The following fields must be included:
ccxc
ix.
supplier code
ccc. name and address
ccci. telephone, fax, e-mail, web address
cccii
.
contact names
cccii
i.
account number
ccci
v.
standard discount
cccv
.
VAT number
cccvi.
EDI transmission details
cccv
ii.
chasing regime (library-defined)
cccv
iii.
servicing arrangements
ccci
x.
delivery charges
cccx
.
fields for notes to staff and suppliers
cccx
i.
It must be possible to create orders for suppliers not used on a regular basis,
i.e. without having to enter full supplier details
Pre-order searching
cccx
ii.
The system must allow pre-order searching of both stock and order records
using any library-defined index
Ordering
The system must:
cccx
iii.
allow session defaults to be set when creating orders, e.g. default supplier,
fund, currency, location
V49 P allow session defaults to be defined by location
cccx
iv.
allow order data to be carried forward for a succession of records
cccx
v.
allow existing order records to be copied to form new order e.g. for ordering
additional copies
be capable of dealing with a variety of order types, including:
cccx
vi.
firm orders
cccx
vii.
approvals
cccx
viii.
subscriptions
cccxix. payment with order
cccx It must be possible to handle multi-part or standing orders, i.e. where
Juliet Leeves 2007 22
-
7/31/2019 UKCS Version3 CC Licensed Rev
23/35
UKCS Version 3.0 LMS Functional Requirements
multiple parts for a single order need to be receipted, invoiced and
catalogued separately
cccx
xi.
It must be possible to handle donations, i.e. where an order has not been
created.
cccx
xii.
It must be possible to handle exchanges, i.e. where an order has not been
created.
The order record must include the following elements in addition to the
bibliographic data:
cccx
xiii.
supplier
cccx
xiv.
unit price
cccx
xv.
fund
cccx
xvi.
currency
cccxxvii.
location
cccx
xviii
.
number of copies
cccx
xix.
date of order
cccx
xx.
order number
cccx
xxi.
order status e.g. urgent
cccx
xxii.
order type
cccx
xxiii
.
subscription period (if applicable)
cccx
xxiv
.
subscription renewal date (if applicable)
cccx
xxv.
notes to suppliers
cccxxxvi
.
notes to staff
cccx
xxvi
i.
requester/recommender information (if applicable)
cccx
xxvi
ii.
supplier report
cccx
xxix
.
claims
cccx
l.
source, e.g. user request, staff recommendation
Juliet Leeves 2007 23
-
7/31/2019 UKCS Version3 CC Licensed Rev
24/35
UKCS Version 3.0 LMS Functional Requirements
Order records must be accessible by:
cccx
li.
bibliographic data elements
cccx
lii.
order number,
cccx
liii.
supplier,
cccx
liv.
order status
cccx
lv.
order type
cccx
lvi.
order date
It must be possible to access the following data directly from the order record
(where applicable):
cccx
lvii.
full bibliographic record
cccx
lviii.
check-in screens
cccx
lix.
invoicing procedure and payment details
cccl. prediction pattern
cccli
.
supplier record
cccli
i.
The system must allow for multiple copies of all types of items including
subscriptions to be ordered for different locations and from different funds
cccli
ii.
It must be possible to flag subscription orders either to renew automatically
or to alert staff before manual renewal is due
cccli
v.
It must be possible to block automatic renewal if no parts have been received
for any order and/or no payment has been made for purchase orders and to
provide a report/message to supplier on such blocked records.
cccl
v.
Once orders have been placed, funds should be committed immediately.
Any subsequent amendment to price information must automatically update
commitments
cccl
vi.
It must be possible to link to e-mail/fax functions for sending of orders by
these methods rather than print/EDI
Reports from suppliers
The system must:cccl
vii.
alert staff to outstanding reservations when a report on an order is received
cccl
viii.
notify users who have requested/ recommended items when a report on an
order is received
Receipting
The system must:
cccli
x.
allow receipt of items and invoice processing to be carried out in a single
operation or separately as required
be able to handle:
cccl
x.
partial receipt of an order
cccl
xi.
return of damaged, incorrect or unwanted items
Juliet Leeves 2007 24
-
7/31/2019 UKCS Version3 CC Licensed Rev
25/35
UKCS Version 3.0 LMS Functional Requirements
cccl
xii.
variations in price/currency since order
cccl
xiii.
changes in bibliographic information.
cccl
xiv.
orders received on approval
cccl
xv.
It must be possible to record the receipt of items for which there is no order,
e.g. donation
cccl
xvi.
Reservations/requests must be alerted at the receipting stage and the
requester notified
Invoice processing
cccl
xvii.
It must be possible to handle invoices before receipt, at the time of receipt or
at a later date
The system must be able to handle:
cccl
xviii
.
credit notes
cccl
xix.
pro-forma invoices
cccl
xx.
subscription invoices
cccl
xxi.
discounts
cccl
xxii.
on approval payments
cccl
xxiii
.
fund transfers
cccl
xxiv
.
handling charges
Invoice records must include the following details:
cccl
xxv.
supplier details
cccl
xxvi
.
invoice number
ccclxxvi
i.
invoice date
cccl
xxvi
ii.
invoice total
cccl
xxix
.
discount amount
cccl
xxx.
Delivery/postage and packing charges
ccclxxxi
.
VAT
Juliet Leeves 2007 25
-
7/31/2019 UKCS Version3 CC Licensed Rev
26/35
UKCS Version 3.0 LMS Functional Requirements
cccl
xxxi
i.
supplier servicing charges (lamination, labelling etc)
cccl
xxxi
ii.
links to display orders invoiced
cccl
xxxi
v.
free text note field
cccl
xxx
v.
The system must allow online display of invoice data for a library-defined
period
cccl
xxx
vi.
Invoice processing must reconcile invoice totals and individual amounts
charged on invoices with line items
The system must provide an alert before accepting invoice data for the
following:cccl
xxx
vii.
items which have been cancelled
cccl
xxx
viii.
items which have claims outstanding
cccl
xxxi
x.
items which are charged to over-committed and overspent funds
cccx
c.
if no parts have been received
Fund accounting
cccx
ci.
It must be possible to set up and display hierarchies of funds
cccx
cii.
The system must allow transfer of monies between funds
The system must maintain and display for each fund:
cccx
ciii.
fund allocation
cccx
civ.
expenditure
cccx
cv.
commitment
cccx
cvi.
cash balance
cccx
cvii.
Each fund should have the facility for library-defined limits on commitment
and expenditure and warnings must be generated when these are reached
cccx
cviii
.
The system must maintain a currency exchange table which can be updated
regularly; changes to the currency exchange table should automatically
update commitments
cccx
cix.
The system must provide procedures for dealing with closing funds at the
end of the financial year. It must be possible to roll over commitments tonext financial year
cd. For serial subscription renewals, the system must carry forward commitment
Juliet Leeves 2007 26
-
7/31/2019 UKCS Version3 CC Licensed Rev
27/35
UKCS Version 3.0 LMS Functional Requirements
based on the actual total cost of that subscription for the previous financial
year
cdi. It must be possible to compare fund records for a library-defined number of
previous financial years
Claiming and cancellations
The system must:
cdii. allow a library-defined default claim period for each supplier
cdiii
.
allow for the default claim period to be amended on individual orders.
Amendment of the delivery date should automatically reset the claims cycle
cdiv
.
It must be possible to link to e-mail/fax functions for sending of claims by
these methods rather than print/EDI
cdv. allow staff to force or suppress claims for individual items and subscriptions
cdvi
.
allow staff to either review items flagged for claiming before claims are
generated, or generate claims without prior review
cdvi
i.
allow authorised staff to cancel an order
cdviii.
allow authorised staff to transfer an order to another supplier
cdix
.
commitment details must be immediately adjusted upon cancellation of an
order
cdx. notify users who have requested/recommended an item if the order is
cancelled
Export/import of data
cdxi
.
The system must allow the export of financial data to organisational financial
systems
6. Serials controlNB: This section covers ongoing control of serials, i.e. check-in, claiming,routing and binding. Bibliographic record creation for serials is covered in 2
above; ordering, subscription control, invoicing and fund maintenance is
covered in 5 above
General
The system must provide for ongoing control of serial issues with regard to:
cdxi
i.
check-in
cdxi
ii.
claiming
cdxiv.
routing
cdxv
.
binding
cdxv
i.
The system must allow for site-specific check-in, displaying only their
issues for check-in
It must be possible to access directly the following information attached to a
serial title:
cdxv
ii.
receipt details
cdxv
iii.
claims details
cdxi
x.
routing details
Juliet Leeves 2007 27
-
7/31/2019 UKCS Version3 CC Licensed Rev
28/35
UKCS Version 3.0 LMS Functional Requirements
cdxx
.
binding details
cdxx
i.
invoice details
cdxx
ii.
The system must display latest issue information on the OPAC and update
serial holdings data automatically
Check-in
The system must:
allow access to serial records by the following keys:
cdxx
iii.
title
cdxx
iv.
ISSN
cdxx
v.
issue barcode
cdxx
vi.
offer the option to show several expected/outstanding issues as well as just
the next expected issuecdxx
vii.
allow the creation of free-text notes at both title and issue level
cdxx
viii.
display notes at point of check-in
cdxx
ix.
allow for check-in of non-standard issues, including:
cdxx
x.
supplements
cdxx
xi.
special issues
cdxx
xii.
parts received out of sequence
cdxx
xiii.
combined and double-numbered issues
cdxx
xiv.
duplicates
cdxx
xv.
indexes
cdxx
xvi.
allow staff to unreceive an issue receipted in error
cdxxxvii.
alert staff to gaps in receipted issues at point of check-in
Prediction of issues
The system must:
cdxx
xviii
.
provide the facility to predict a wide range of publication patterns in terms of
number of issues per week, per month, per year or over several years
(biennial, triennial etc)
cdxx
xix.
allow patterns to support irregular but predictable publications such as
combined issues, supplements and indexes
cdxl
.
handle irregular and unpredictable publications
cdxli
.
allow for changing the prediction pattern within a subscription year
cdxl allow for stopping or suspending prediction for an individual title
Juliet Leeves 2007 28
-
7/31/2019 UKCS Version3 CC Licensed Rev
29/35
UKCS Version 3.0 LMS Functional Requirements
cdxl
iii.
accommodate delays of any duration between nominal and actual date of
publication
cdxl
iv.
support at least four levels of enumeration
cdxl
v.
allow any combination of numeric, alphanumeric or date descriptors
cdxl
vi.
allow for volumes commencing at any time during the year
cdxl
vii.
allow for volumes covering more than one year
cdxl
viii.
allow for multiple volumes within a year
cdxl
ix.
allow for both continuous and restart issue numbering within volumes
cdl. provide the option either to require a subscription renewal before parts are
predicted for the next subscription period, or to allowsubscriptions/predictions to roll over without manual intervention
Claiming
The system must:
cdli. generate claims based on predicted expected issue date together with library-
defined claim period (by title or supplier)
cdlii
.
allow prior review of claims by staff
cdlii
i.
generate claims for skipped issues automatically on receipt of subsequent
issues
cdli
v.
allow for linking to e-mail/fax functions for sending of claims by these
methods rather than print/EDI
cdlv
.
allow for supplier reports to be added to issues claimed; amendment of
delivery date should reset the claims cycle
cdlv
i.
Claim formats and claim messages must be library-defined
Routing
The system must:
cdlv
ii.
allow the creation and maintenance of routing lists for specific copies of
individual titles using the borrower file
cdlv
iii.
allow lists of titles/recipients to be edited on an individual or global basis
cdli
x.
alert staff to a routing list at check-in
cdlx
.
allow printing of routing lists at check-in, either on an individual basis or at
the end of a check-in session
cdlx
i.
alert staff to routed issues not returned
cdlx
ii.
Format of routing slips must be library-defined
Binding control
The system must:
cdlx
iii.
flag and identify items ready for binding according to library-defined
requirements
cdl hold binder details and instructions
Juliet Leeves 2007 29
-
7/31/2019 UKCS Version3 CC Licensed Rev
30/35
UKCS Version 3.0 LMS Functional Requirements
cdl
xv.
record items at binding (issue, return, overdue)
cdl
xvi.
offer financial controls for binding
7. Document delivery and inter-library loansGeneral
Document delivery and inter-library loans must be integrated with the rest of
the system, including:
cdlx
vii.
the OPAC (for users to input requests and view progress)
cdlx
viii.
borrower records (to control ILL privileges)
cdlx
ix.
circulation control (for ongoing control of inter-library loans)
cdlx
x.
For requests input via the OPAC, there must be facilities for staff to
authorise and process requests
cdlx
xi.
The system must support ISO 10160/10161 ILL protocol (current version)
cdlx
xii.
The system must support the current procedures and formats specified by the
British Library Document Supply Centre (BLDSC)
cdlx
xiii.
The system should support requests to other libraries
cdlx
xiv.
A file of supplying libraries must be maintained, accessible by code and
library namecdlx
xv.
Format and content of notices must be library-definable
cdlx
xvi.
It must be possible to archive completed document delivery/ILL requests and
make them available for access by staff for a library-defined period
Request process
The system must:
cdlx
xvii.
check eligibility to place requests (by borrower category) and any blocks on
the user which may inhibit the request
cdlx
xviii
.
allow a limit to be imposed on the number of concurrent requests from any
user (by borrower category), with an overall limit over a library-defined
period of timecdlx
xix.
provide varying templates for entering the request (for monographs, serials,
serial articles, conferences etc)
cdlx
xx.
allow users entering requests via the OPAC to specify a collection point (if
applicable)
cdlx
xxi.
allow requests to be created by uploading data from external databases, e.g.
BLDSC databases
cdlx
xxii.
allow library staff to amend the bibliographic and other request details before
and after transmission of request
cdlx
xxiii.
allow for checking requests against the OPAC
cdlx allow for special requirements to be added to requests, e.g. loan essential,
Juliet Leeves 2007 30
-
7/31/2019 UKCS Version3 CC Licensed Rev
31/35
UKCS Version 3.0 LMS Functional Requirements
translation only
cdlx
xxv.
allow for BLDSC transaction codes to be added to requests, e.g. RENEW,
CANCEL etc.
cdlx
xxvi
.
handle urgent requests, e.g. phone requests, and suppress transmission of the
request concerned
cdlx
xxvi
i.
allow staff to access the request record in a number of ways, including:
cdlx
xxvi
ii.
bibliographic details
cdlx
xxix
.
from the user record
The user record must display:
cdxc.
ILL items on loan
cdxc
i.
outstanding requests
cdxc
ii.
progress reports
cdxc
iii.
Requests must be displayed in chronological order with most recent first
cdxc
iv.
The system must support the electronic transmission of requests to BLDSC
via ARTTel2/ARTEmail with an option to print or e-mail requests to other
libraries if required.
cdxcv.
Error detection must be provided and it must be possible to amend andretransmit files
cdxc
vi.
It must be possible to change lenders for outstanding requests
cdxc
vii.
It must be possible to initiate action to revive a cancelled request or to re-
request a wrongly-supplied item
Receipt and loan
The system must record the receipt of the following (with date of receipt
automatically recorded):
cdxc
viii.
photocopy for retention
cdxc
ix.
item for loan or use in the Library
d. It must be possible to amend the supplying library if different from the
library from which the item was originally requested
The system must:
di. record the direct delivery of photocopied documents to the end user from
BLDSC (as reported by BLDSC)
dii. produce requesters address in label format for sending out photocopies from
Library
diii. record completion of items sent out from BLDSC/Library
div. allow for ongoing control of reference and loan items (issue, renewal, recall,return, overdues, fines) via the circulation function, with specific parameters
for such items, e.g. loan periods, fines, notices
Juliet Leeves 2007 31
-
7/31/2019 UKCS Version3 CC Licensed Rev
32/35
UKCS Version 3.0 LMS Functional Requirements
dv. allow a default due date to be set for each lending library (library-defined)
for loan items, and for issuing items to be used in the Library
dvi. take account of closed days when calculating return dates
dvii. create a loan period that includes both a return date and an automatic
extension (subject to recall) in line with BLDSC lending policy
dviii
.
notify the requester on receipt of an item, with details of collection point, due
date, renewal conditions, and whether item is for use in the Library only
dix. notify Library staff if an item has not been collected within a library-defined
period of time
dx. notifications must be possible by e-mail, print, and also appear on users
record on OPAC
Renewals
The system must:
dxi. manage renewal of loans, both from other libraries, and from BLDSC who
require renewals to be made on a new request number
dxii. allow for the electronic transmission of the renewal request to BLDSC
dxiii.
produce printed or e-mail notices to renew with other libraries
Reports
The system must:
dxiv
.
recognise standard BLDSC report codes and translate them to appear as text
on the system
dxv. allow free text reports to be input and for standard reports to be amended as
necessary
dxvi
.
generate reports for requesters, lenders and library staff, which may be
printed, e-mailed, and/or displayed on the OPAC (for end users)
dxvi
i.
allow for a reapplication to the same supplier or a different supplier after
receiving a reply from the requester
Chasers and cancellations
The system must:
dxvi
ii.
generate chasers according to library-defined regimes
dxix
.
transmit chasers electronically to BLDSC
dxx. generate printed or e-mail chasers for other suppliers
dxxi
.
allow for requests to be cancelled
dxxii.
allow for logging the reason for the cancellation
dxxi
ii.
generate cancellation notices to the supplier and requester
dxxi
v.
transmit cancellation requests electronically to BLDSC
Charges and funds
dxx
v.
It must be possible to handle charges imposed by document delivery
suppliers
dxx
vi.
The system must support deposit and billing accounts
dxx
vii.
It must be possible to set up a number of accounting methods for one
supplier
dxx The system must allow funds to be set up for document delivery/ILL
Juliet Leeves 2007 32
-
7/31/2019 UKCS Version3 CC Licensed Rev
33/35
UKCS Version 3.0 LMS Functional Requirements
dxxi
x.
Funds in ILL/document delivery should be linked to Acquisitions funds
The system must maintain and display for each fund:
dxx
x.
fund allocation
dxx
xi.
expenditure
dxx
xii.
commitment
dxx
xiii.
cash balance
Loans to other libraries
dxx
xiv.
The system must provide a facility for loaning to other libraries
dxx
xv.
Control of loans (issue, renewal, recall, return, overdues) must use library-
defined parameters.
8. Management informationGeneral
dxx
xvi.
The system must provide standard management information from the main
functional areas (see below)
dxx
xvii.
It must be possible for the Library to define how long data is retained on the
system for use in reporting.
dxx
xviii
.
It must be possible for the Library to define and run its own regular and ad
hoc reports without using a complex query language and without the
intervention of systems staffdxx
xix.
It must be possible to save report specifications for re-use
dxl. It must be possible to tailor pre-defined management information reports and
to run these on a regular or ad hoc basis
dxli. Layout and filing order of reports should be library-definable, with standard
layouts also provided
dxlii
.
The system must be able to provide statistical information on an hourly,
daily, weekly, monthly and annual (academic/financial year) basis
dxlii
i.
It must be possible to produce snapshot statistics
It must be possible to:dxli
v.
view reports and statistics online
dxlv
.
output reports and statistics via e-mail
dxlv
i.
output reports and statistics to electronic files (for ftp, download etc.)
dxlv
ii.
output reports and statistics to local and system printers
dxlv
iii.
download data from the system into standard PC packages for further
analysis, e.g. spreadsheets, databasesdxli
x.
Data must be exportable in ASCII and comma-delimited formats
Juliet Leeves 2007 33
-
7/31/2019 UKCS Version3 CC Licensed Rev
34/35
UKCS Version 3.0 LMS Functional Requirements
V50 A The system must provide pre-defined reports to meet the requirements of
SCONUL
V51 P The system must provide pre-defined reports to meet the requirements of
CIPFA
V52 P The system must provide pre-defined reports to meet Public Lending Right
requirements
Standard reports must include the following:
Bibliographic database management
dl. Statistics of records added to the database, broken down by library-defined
categories, e.g. material type, class mark, type of record (local/external)
dli. Lists of titles selected by a combination of a range of categories, e.g. date of
input, class-mark / shelf-mark, material type
dlii. Bibliographic records with no items attached
dliii. Lists of new authority headings
dliv. Withdrawals
dlv. Inventory and stock check reports
OPACdlvi. Usage statistics by title
dlvii
.
Usage by borrower category
dlvii
i.
Usage by type of search
dlix. Failed searches
dlx. Self-service transactions
Circulation
dlxi. Reports and statistics relating to circulation transactions, including: issues,
returns, renewals, fines, reservations, with accumulation on an hourly, daily,
weekly, monthly and annual basis; breakdown of statistics by borrower/loan
status/collection category/ broad classification and any combination of these
dlxii
.
Reports on reservations: reserved items not on loan (for shelf check);
reserved books with over a library-defined number of reservations (purchase
alert); reserved books that have passed their holding date; uncollected
reservations; outstanding reservations including number of days outstanding
dlxii
i.
Reports on borrowers with fines and overdues
dlxi
v.
Lists of titles with specified loan status or collection category
dlxv.
Lists of borrowers with tickets due to expire within library-defined period
dlxv
i.
Analysis of borrower information: by academic department/borrower
category; levels of library usage and non-usage
V53 P Reports on stock rotation activity, including: items in a particular rotating
collection; current site of any item in a rotating collection; total items at a
given site which are part of a rotating collection
V54 P Mobile library statistics, including stop points
Acquisitions (relating to serial as well as monograph orders)
dlxv
ii.
Acquisitions statistics, by library-defined categories including: gift/purchase;
material type; supplier; fund; country of publication
dlxv
iii.
Outstanding orders by supplier, by fund / order date / order number /
material type
dlxi Completed orders by supplier / fund / material type
Juliet Leeves 2007 34
-
7/31/2019 UKCS Version3 CC Licensed Rev
35/35
UKCS Version 3.0 LMS Functional Requirements
dlxx
.
All orders, by financial year; broken down by material type and supplier
dlxx
i.
Cancelled orders
dlxx
ii.
requests for purchase from users
dlxx
iii.
Lists of suppliers
dlxx
iv.
Analysis of supplier performance e.g. average supply time, price and
discount information, level of non-supply
dlxx
v.
Monthly, annual and on demand fund reports, including commitment and
expenditure
dlxx
vi.
Expenditure by supplier
dlxx
vii.
Expenditure by library-defined subject areas / departments
dlxx
viii.
Lists of recent accessions
dlxx
ix.
Statistics of EDI transactions
dlxx
x.
Reports on unsuccessful transmissions
Serials control
dlxx
xi.
Lists of titles with unfulfilled claims, after penultimate and final claims, by
supplier
dlxx
xii.
Cancelled subscriptions, by supplier / financial year
dlxx
xiii.
Cumulating daily, monthly and annual totals of issues checked-in, by library-
defined categories, e.g. frequency, fund code
dlxx
xiv.
Lists of current serials by combinations of: title, classmark, supplier, material
type, fund code
dlxx
xv.
Binding: number of volumes sent to bind, number returned, analysis of time
spent at binding
Inter-library loans
dlxx
xvi.
Statistics of ILL requests satisfied / unsatisfied / cancelled / outstanding
dlxxxvii.
Statistics of items by supplier: requests satisfied / unsatisfied, by materialtype
dlxx
xviii
.
Costs by supplier/fund/material type
dlxx
xix.
Relative statistics of photocopies supplied / items for home loan / items
issued for reference use
dxc. Supply times: average; shortest; longest
dxci
.
Statistics of items requested, broken down by borrower category and material
type
dxci
i.
Statistics of items supplied to other libraries: requests satisfied / unsatisfied,
by material type