• Tidak ada hasil yang ditemukan

FUNCTIONAL REQUIREMENTS

Dalam dokumen TEAM FLY (Halaman 115-119)

According to Shelly, Cashman and Rosenblatt (1998, pp. 1.4-1.6), the fundamental units of information systems are hardware (physical components of a system), software (instruction sequences for a system), data (static representations of system content), procedures (tasks and activities to be performed by people in conjunction with a system), and finally people (stakeholders of a system). Wells (2001) reviews functional requirements within the context of mission statement, personnel (providers & administrators), policy, platform (hardware and software), and evaluation. Both perspectives are useful when deciding upon minimal functional requirements.

Minimum functional requirements focus on a number of parameters. For the purposes of this chapter, only a few of the requirements were chosen out of a larger list of front end and back end requirements (see Table 1 and Table 2). The first discussion point concerns access. Librarians must determine which services they wish to provide, whether they want to provide basic or in-depth service, and how they wish to offer the service. If the goal in this area is to offer the same level of reference service that a user might expect were he or she physically in the library, librarians can then decide what is realistic and what does not readily lend itself to

100 Wells & Hanson

the provision of remote services. The next crucial decision is whether the system is synchronous (real time) or asynchronous (time-delayed).

The next functional requirement concerns affiliation. Although college and university libraries have their faculty, students, and staff as their primary constitu- encies, most academic libraries have special arrangements for local residents, alumni, and persons interested in the institution itself to use the library and its resources. A guideline for this might be whether the primary clientele of the electronic service mirror the primary clientele of the physical reference desk (in terms of categories of users). Validating affiliation is typically handled in one of two ways — by authenticating users based on their (campus assigned) IP(s) and then sometimes requiring a corresponding user ID or by permitting anyone to submit the query while soliciting self-disclosed membership information, i.e., student, faculty, alumni, or other formal or informal affiliation (e.g., by requiring an email address).

This latter approach has the advantage of permitting an individual who is not formally related to the institution to ask questions about the institution, its services, or its resources. The approach to accessing licensed e-reference content is handled in much the same way. Affiliates gain access via their IP or use a proxy server to self- identify and authenticate.

A customizable interface — both graphical and text — includes basic features such as the ability to include logos, text, and/or re-arrange or completely (re)design the interface from the main page throughout the system as a whole.

Text-based chat interfaces such as one-to-one chatting or MOOs or even chat rooms are common components of the Web. For a library patron trying to navigate an online database, it is far easier to connect to a reference service with chat than to perhaps go offline and pick up a telephone. Chat interfaces also allow the easy transfer of clickable URLs and blocks of instruction.

Some text-based chat interfaces are outsourced applications. Advantages of outsourced applications include: no hardware or software installation, no dedicated library servers, no plug-ins for patrons to install, and no special setup or mainte- nance. HTML links are simply placed on the web site pages that will be linked to the application. As with all things, there are advantages and disadvantages with outsourced applications.

Page pushing allows the librarian to “push” a page over to the client and the patron to “push” a page to the librarian. Using this feature, a librarian can demonstrate a search strategy for a patron or provide a web page for the patron to consult, without the patron having to go through all the steps.

Librarians should evaluate the use of plug-ins when deciding upon a CRM.

Depending upon a “guesstimate” of the average user’s skills, workstation, and bandwidth, one can choose a system where the plug-ins are hosted on the vendor’s site, locally hosted by the library, or must be loaded on the user’s PC.

E-Reference 101

Predefined or standardized responses are useful for certain types of reference interactions. For example, simple questions such as those concerning hours can be written once, but sent many times. Alternatively, very complex or ambiguous questions may be answered by a pre-formatted, response asking/

requesting that the patron contact the library staff by phone or by email with more details.

E-mail default is an option that provides the patron with the option of sending email rather than waiting for librarian when no one is available.

System stallers are phrases that are sent automatically to patrons when they are ‘on hold’ waiting for a librarian. Messages such as “Just a moment please” and

“Thank you for waiting. I’ll be with you momentarily” are sent automatically to reassure the user that someone is still at the other end of the chat. Alternatively, some systems provide patrons with an option to “leave a message” and have the librarian call back via phone or email.

Queue information can permit the librarian to know how many patrons are waiting for assistance, their respective order “in line,” and how long each patron has been on-hold.

Routable queries permit librarians to forward patrons to another librarian. So, for example, if a question requires the need for a subject-specialist, the patron is directed the appropriate person. In addition, call escalation can permit a patron’s call to be rerouted after a period of time during which their call is not answered. So, during a peak period, another librarian would automatically receive calls to reduce wait times.

Patron information includes specifics attributes for a given individual from relationship to the institution to questions previously asked to actual transcripts of past interactions.

Co-browsing or escorting permits the librarian to see what the patron is seeing and vice versa, by permitting the librarian to push content (e.g., a webpage, scroll to a certain part of the item), and, by means of a secondary pointer, to direct the patron’s eyes to specific text, for example, rather than the site as a whole which would then require the librarian to communicate a series of steps in order to share specifics.

User feedback is another nice feature to have with this type of software. Often the CRM software will allow the librarian to create a quality of service questionnaire to rate the service and to generate demographics. General demographic and frequency questions include user affiliation, whether they are repeat users, and how they rate this service. The better CRM programs have built-in statistical packages that can tabulate frequency of response by category and graph the results.

The definition (and examples) of knowledge bases is growing. One definition that is more inclusive might be

102 Wells & Hanson

“…a(n)…engine that allows us to keyword-search the full text of our entire electronic reference collection regardless of which publisher created the source. Plus…librarians should be able to bookmark or annotate the sources to help others find the answers to difficult questions more easily, and we should also be able to refer others from a source to supplemental material…So when somebody listed in one of our biographical dictionaries dies, for example, we should be able to annotate the entry with their obituary plus references to the spate of articles that typically appear after their demise. If we could incorporate some of these ideas, our reference collections would …be living and breathing things which would develop and improve as we worked with them.” (Coffman, 2001)

An additional component might be the ability to add locally scanned print to this electronic wonder. A unitary system for resource integration might include information such as library hours, a bibliography of the Dalai Lama’s correspon- dence from 1949 on to session transcripts from a reference interview (whether the original session was conducted in text or voice). It would not only allow users (patrons or librarians) to query this singular source, it would allow librarians to desist from developing and maintaining separate resource lists and FAQs. There are many complementary issues including the role of metadata, rights and record manage- ment, quality control, etc. that can be learned from cataloging.

Record format is ongoing as well. In a collaborative model whether within a singular library or involving any number of disparate institutions, the issue of a reference record format or encoding structure for exchange, storage, reporting and harvesting is moving slowly toward standardization.

Returning though to a more basic function is the need to generate and maintain statistics, i.e., reports, to capture such basic information as how many calls are logged during any timeframe, peak times, wait times, question topics, affiliation of patron, response time, librarian involved, any need for follow-up, etc.

Table 1: Front-end issues Access - synchronous or asynchronous or both

Call back option Authentication and/or ID

requirements

Routable queries Customizable graphical and/or

text interface

Call escalation

Plug-ins Co-browsing or escorting

E-mail options User feedback

E-Reference 103

An issue that can be linked with privacy concerns or conversely as a resource saving measure is local vs. remote hosting wherein the e-reference software (and hardware) is administered and maintained on campus or in another part of the country altogether.

The point of this definitional analysis is that, while resource issues may determine staffing levels, purchasing timeframes, etc., any discussion must include basic service expectations and, ultimately, functional requirements.

Dalam dokumen TEAM FLY (Halaman 115-119)