[OPEN-ILS-GENERAL] What are your requirements for Evergreen?

[Dan Scott]

I would like to start a discussion thread on the following subject, as
I believe it's incredibly important to the success of the project and
I don't think we've had much discussion about it yet. Perhaps this
discussion will also be able to feed into the Duke initiative to write
a design requirements document for an academic library system.

(Note that "Project Conifer" refers to the project to implement a
consortial install of Evergreen for Laurentian University, McMaster
University, and the University of Windsor.)

"What are the base requirements that have to be in place before we, as
an academic library, or consortium of academic libraries, can migrate
to Evergreen?"

I'll kick off the discussion by giving an overview of the basic parts
of the library system (both functionality and "soft requirements" like
docs and training) and my understanding of where things are. Please
feel free to broaden beyond what I provide here, as I will undoubtedly
forget or mangle some of these! I believe that the answers may differ
for different institutions, of course.

An acquisitions system is a given for everyone, and we're currently
working on that in the acq-experiment branch, as documented in
http://open-ils.org/blog/?p=101 http://open-ils.org/blog/?p=108 and
http://open-ils.org/blog/?p=115, as well as in the wiki at
http://open-ils.org/dokuwiki/doku.php?id=scratchpad:acq_serials

A serials module is also a base requirement for everyone. On top of
the acquisitions portion (subscription support, vs. basic one-time
purchases), at a basic level we need basic patterns (overlay calendars
with exceptions), a helpful check-in interface, and claiming.

Academic reserves are another base requirement for each site.
Essentially, give the system the ability to associate one or more
items with one or more courses (instructor, course name, course code)
and, by doing so, temporarily override the physical location of the
item. Longer term it would be nice to have integration with courseware
(WebCT / Blackboard / Moodle / Sakai) so that the reserve items would
automatically be displayed as part of the course list, and it would
also be nice if Evergreen could integrate with the campus academic
system to know what courses a student was registered in and display
those courses & reserve lists from the catalogue.

Internationalization (i18n). One facet of this (internationalization
of addresses to allow Canadian / American / arbitrary address formats
from around the world) affects everyone. BC has already been able to
customize Evergreen to support Canadian addresses, so a basic level of
support is there. However, Laurentian in particular requires pervasive
bilingual support - which is one of the development pieces I'm
actively working towards. We hope to have this completed in the next
few weeks; after that, we simply need to send off the strings to
translation and our needs will be met. The new acquisitions system is
being built to be i18n-ready from the ground up.

Circulation: Are there circulation requirements beyond what Evergreen
already offers today?

Cataloguing:
  * We have added infrastructural support for being able to search
multiple Z39.50 sources at once, which was one of the requirements
voiced at the Conifer Acquisitions session.
  * Equinox has stated a number of times that they would like to
rewrite the existing cataloguing client knowing what they do now. If
our staff do not like the current cataloguing client, it might be
possible to use a third-party cataloguing client (OCLC Connexion
Client, for example) instead.
  * Authority control: there is some rudimentary authority control
built into Evergreen today.
  * Bulk import of MARC records and authority records: the current
interface for bulk imports of MARC records is the command line, which
is not particularly friendly when you face the need to import, say,
12,000 records for a new set of Springer e-books.

Catalogue: Do we have requirements beyond surfacing new functionality
like academic reserves, acquisition requests, etc in the catalogue?

Reporting: The current reporting module is extremely powerful, but it
comes with no standard report templates. With that power comes a
certain amount of complexity (it is essentially a nice GUI wrapper
around the relational schema of the database, so understanding
relational databases helps a lot) that means that our best approach
for moving forward will probably be to define what standard report
templates we want out of the box, then assign someone or some people
to create those templates.

Documentation and training: There is currently not much in the way of
official (staff and librarian-oriented) documentation available for
Evergreen. I started an effort to write "The Book of Evergreen", but
that faltered when I turned my attention towards more basic
infrastructure.

Data partitions: in a consortial environment, what is necessary in
terms of separating one Library's data from another's yet? For
example: should a Laurentian acquisitions person be able to see
McMaster's acquisition accounts and individual funds?

Migration of existing data: Apart from bib records / holdings / patron
records / authority records and open transactions (for example, books
that are currently checked out), what other data do we want to migrate
- complete transaction records dating back as far as our existing
systems allow? Or would we be satisfied just exporting a static set of
statistics so that we can combine data from the live system with the
statistics from the old system (for example: circ counts by barcode by
year)? Either way, we will have to define what data we want to
migrate, then figure out how to migrate that into the new system.

-- 
Dan Scott
Laurentian University