# 1 Introduction
[NULL]

## 1.1 Purpose
This document specifies the functional and nonfunctional requirements for the System Administration Module of an Integrated Library System (ILS). The System Administration Module will replace and enhance the current capabilities of commercially available ILSes and add new functionality.

## 1.2 Scope
This document specifies the requirements for the System Administration Module of an Integrated Library System (ILS).

The System Administration Module will facilitate the management of every aspect of the ILS. The software will support the following activities:
*   Configuring the ILS to enable and support features and processes required for management of the Library branches, patrons, collections, and circulation transactions.
*   Monitoring, troubleshooting, and controlling server, database, and application performance.
*   Monitoring, troubleshooting, and controlling services, ports, and application programming interfaces.
*   Managing user and group accounts and privileges.
*   Managing server and client software installation, upgrades, and updates.
*   Backing up databases, configuration files, and log files.

The module is being specified for the King County Library System, but the requirements are intended to be suitable for many large, urban, multiple-branch library systems. The objective is to replace and enhance the capabilities of current commercially available ILS products and to add new functionality.

This specification is consistent with previously published specifications for the ILS's Acquisitions and Serials Management, Circulation, and Cataloging modules. It presupposes the general data structures and functionality of a full-fledged ILS and specifies only those requirements that directly or indirectly relate to system management activities.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The System Administration Module is an element of a larger, enterprise-level Integrated Library System (ILS). It presupposes the general data structures and functionality of a full-fledged ILS and relies on other modules, including Acquisitions, Cataloging, and Circulation. It will also interact with a patron interface, also known as an Online Public Access Catalog (OPAC). The module is intended to replace and enhance the current system administration capabilities of commercially available ILSes.

#### System interfaces
The System Administration Module shall interface with a variety of vendor websites and systems, including OCLC, via published APIs and/or automated transfer of standard-format data files such as USMARC21 and EDIFACT.

#### User interfaces
The System Administration Module shall be accessible through a web browser or a Windows-compatible client. If web-based, it shall produce standards-compliant HTML. The user interface will be developed using an iterative, prototype-oriented methodology. The system must be accessible with screen-reading software, screen-magnification software, and other accessibility programs.

#### Hardware interfaces
The system shall support all Windows-compatible printers, with the ability to define and select receipt printers, standard printers, label printers, and forms printers.

#### Software interfaces
The System Administration Module will operate within the following software environment:
*   **Operating System:** The server shall operate on Linux or Solaris.
*   **Database:** The system shall use a fully relational, SQL-based database back-end that is accessible as an ODBC source.
*   **Web Browsers:** If web-based, the system shall be accessible through Microsoft Internet Explorer (v.6.0 and later) and Mozilla Firefox (v.2.0 and later).
*   **Interfacing Software:** The system shall support the use of third-party backup software (e.g., EMC NetWorker) and be manageable via VNC and Remote Desktop.

#### Communications interfaces
The system shall support the following protocols:
*   SIP2/NCIP2 and similar protocols and APIs for patron and item record access.
*   Secure protocols including SFTP (in active and passive modes), SSL, and SSH.
*   SMTP for email transport.

#### Memory constraints
[N/A]

#### Operations
*   The system shall provide a development and training environment with the ability to migrate configurations to a production environment.
*   The system must support live incremental and full backups of data and transaction logs.
*   The system shall support server clustering for failover capability.
*   Searches and reports should be processable during open hours without disrupting other system functions.
*   The system shall provide "undo" functionality for data changes like record deletions.

#### Site adaptation requirements
[N/A]

#### Interfaces with services
The System Administration Module will interface with various external vendor services and websites via published APIs and standard data file transfers.

### 1.3.2 Product functions
The System Administration Module facilitates the management of every aspect of the Integrated Library System. The module supports the following major functions:

*   Configuring the ILS to enable and support features and processes required for management of the Library branches, patrons, collections, and circulation transactions.
*   Monitoring, troubleshooting, and controlling server performance.
*   Monitoring, troubleshooting, and controlling database and application performance.
*   Monitoring, troubleshooting, and controlling services, ports, and application programming interfaces.
*   Managing user and group accounts and privileges.
*   Managing server and client software installation, upgrades, and updates.
*   Backing up databases, configuration files, and log files.

### 1.3.3 User characteristics
The users of the Integrated Library System (ILS) and its System Administration Module are categorized into the following groups. It is assumed that all staff users have a general understanding of Library services and processes. The system shall be accessible to users with disabilities via screen-reading and screen-magnification software.

*   **System Administrators**: Staff with technical expertise and responsibility for managing the ILS servers, databases, applications, services, ports, and APIs.
*   **Library Staff**: Includes managers, librarians, library technicians, library assistants, and pages who are involved in providing library services. Their technical expertise varies, but they are experienced in library operational processes.
*   **Management**: Includes Library Managers and Directors who oversee library processes, plan services, and direct priorities. They require access to the system for oversight and strategic planning.
*   **Patrons**: Customers of the library system. This is a diverse group with a wide range of technical skills and educational backgrounds. They interact with other ILS modules (e.g., the OPAC) whose configuration is managed by the System Administration Module.

### 1.3.4 Limitations
The scope of this specification is limited to the System Administration Module. It presupposes the existence and general functionality of a full-fledged Integrated Library System (ILS), including its data structures and modules for Acquisitions, Cataloging, and the Online Public Access Catalog (OPAC). This specification is further limited to the functional characteristics of the administration module; data structures and user interfaces require separate, future specification.

The system's implementation is limited by several technical and environmental constraints. The server application must operate on a Linux or Solaris server, and the back-end database must be a fully relational, SQL-based system. Client access is restricted to either a Windows-compatible client or specific web browsers (Microsoft Internet Explorer v.6.0 and later, Mozilla Firefox v.2.0 and later). Web-based components are required to produce standards-compliant HTML.

The module must interface with other ILS components and a variety of external vendor websites. These interfaces are constrained to use published APIs or standard protocols and data formats, including SFTP, SSL, SSH, USMARC21, and EDIFACT.

The system is required to be accessible to users with disabilities, limiting implementation choices to those compatible with screen-reading and screen-magnification software.

## 1.4 Definitions
*   **Library Directors**: Members of the Library Executive Team who plan and direct Library services and priorities.
*   **Library Managers**: Cluster and Site Managers who provide input to the design and implementation of Library services.
*   **Managers**: Management staff who oversee Library processes.
*   **Online Public Access Catalog (OPAC)**: The patron interface to the Integrated Library System.
*   **Patron**: A customer of King County Library System, either possessing a library card or not, either on site of a community library or not, using either print materials, media materials, or electronic resources.
*   **Staff**: Managers, librarians, library technicians, library assistants, and library pages who are involved in designing and providing services for the Library.
*   **System Administrators**: Staff with responsibility for managing servers, databases, applications, services, ports, and APIs related to the ILS.

# 2 References
[N/A]

# 3 Requirements
[NULL]

## 3.1 Functions
### 3.1.1 General System Functions

The system shall provide real-time processing, ensuring data such as pull lists are current at the time of viewing and supporting live inventory activities like shelf reading and weeding.

The system shall allow multiple staff members and patrons to simultaneously access and update patron and item records. It shall provide prompts to warn a user when a record has been changed by another user since it was displayed.

The system shall allow staff to identify which user and location are using a specific patron or item record, including the date and time the record was locked.

The system shall support both individual and shared staff login accounts. Access to modules shall be controlled by assigning roles or privileges to accounts. Individual logins shall support user-level preferences and provide an audit trail.

The system shall provide administrators with access to all configuration files.

The system shall provide administrators with full access to all log files. Log files must be reviewable without stopping the system. The system shall allow logs to be enabled, disabled, and have their retention threshold set.

The system shall provide administrators with access to the root shell.

### 3.1.2 Consoles and Dashboards

The system shall support the creation of custom dashboards to display current and historical data on system performance, record transactions, and circulation statistics. Administrators shall be able to create dashboards and grant access to selected users and groups.

The system shall monitor system resources, including disk space, CPU load, memory load, processes, interfaces, and ports, with support for SNMP. Alert thresholds shall be configurable. Alerts shall be sent via administrative dashboards, email, and text messages to an unlimited number of recipients.

The system shall provide a console for administrators to manage record locks. This includes setting thresholds for lock duration, viewing a list of locked records, and unlocking one or more records.

The system shall provide a performance monitoring dashboard that identifies processes with their ID, owner, IP address, CPU utilization, memory utilization, and run time. It shall identify runaway processes and use visual indicators for system status.

The system shall provide a server management console with utilities for software startup/shutdown and server restart/shutdown.

The system shall provide an application dashboard displaying key administrative information, such as backup and reboot times, software version, pending transactions, log file sizes, record counts, and database utilization.

The system shall provide a client management console to display workstations running client software (including name and IP address) and provide utilities for managing and terminating client sessions.

The system shall provide a circulation dashboard showing key performance indicators such as check-outs per hour, check-ins per hour, and holds placed per hour. These indicators can be filtered by branch or viewed system-wide.

The system shall provide a single console for accessing all configuration files, with read/write permissions assignable to users and groups.

The system shall provide a dashboard for locating and viewing log files.

The system shall provide a single interface for reviewing and controlling all scheduled tasks, including staff-scheduled tasks, automated reports, and software updates.

The system shall provide an interface to access and edit email configuration, including settings for masquerading, log retention, and bounce management. The system shall support SMTP for email transport.

### 3.1.3 Business Rules Configuration

The system shall support the configuration of business rules to enforce restrictions, such as preventing the deletion of item records that are currently checked out.

The system shall allow administrators to create and modify "Rules of Suppression" that control the visibility of authority, bibliographic, order, and item records in both staff and public interfaces. Visibility can be configured for specific workgroups, locations, or all users.

The system shall allow administrators to create and modify requesting rules that determine if a patron can place a hold on an item. These rules can evaluate criteria such as patron type, item type, item status, and patron account balance. The rules shall also specify staff override capabilities.

The system shall allow administrators to create and modify loan rules that govern item check-outs, calculate loan periods, and determine renewal limits. These rules can evaluate criteria such as patron type, item type, item status, and location. The rules shall use the library's open/closed schedule to calculate due dates and specify staff override capabilities.

The system shall provide the ability to specify a default value, data validation rules, automatic formatting, and required status for any field in a record.

### 3.1.4 Data Recovery and Error Handling

The system shall provide the capability to perform live incremental and full backups of data and transaction logs. It shall support the use of third-party backup software.

The system shall log data changes (e.g., record deletions) and provide "undo" functionality. The system should ideally provide revision control for data.

### 3.1.5 Security and User Management

System administrators shall have full visibility and control over all user account privileges.

The system shall provide a dedicated interface for creating new staff accounts, using configurable templates and granular privileges for account management.

The system shall provide a dedicated interface for creating new patron accounts, using configurable templates, field validation, required fields, and configurable defaults.

### 3.1.6 System Maintenance

The system shall support the import and export of MARC bibliographic and authority records, both singly and in batches. Imported records shall be able to overlay existing records.

The system shall support the creation and management of an unlimited number of record sets. These sets can be used for batch field updates, as a scope for queries, or for batch record deletion with review and undo capabilities.

The system shall support the scheduling of maintenance tasks, reports, and data exports. Jobs can be scheduled to run in sequence, and can be modified or canceled before execution.

System administration staff shall be able to view and manage jobs scheduled by other staff members who have been granted permission to schedule tasks.

The system shall support administrator-programmable and user-programmable macros and keyboard shortcuts. These can be assigned to actions or text strings and shall be centrally managed with import/export capabilities and permission controls.

### 3.1.7 Client Management

The system shall allow for central management of client software installation and updates, including the ability to stream updates from the server and target specific clients. Client software must be manageable with tools like VNC and Remote Desktop.

All client configuration files shall be server-based. The system shall support exporting and importing configurations between clients.

### 3.1.8 Queries and Reports

The system shall provide a user-friendly interface for designing queries against all record types. Staff shall be able to select fields, use picklists and regular expressions, and apply Boolean operators. Administrators shall control access to tables and fields.

The system shall allow for the full customization of the layout and appearance of reports.

Reports shall be able to be displayed, printed, emailed, or saved to standard formats including CSV and Excel.

System administrators shall be able to create report templates for use by other staff members.

The system shall provide fine-grained permissions to control which staff can run specific reports or ad hoc queries on specific data sets.

The system shall provide a report showing the current record number, total number of records, number deleted, and number purged for each record type (e.g., patron, bibliographic, item). Access to this data shall be controlled by user/group permissions.

The system shall support printing to various destinations, including a file on the server, FTP, email, or a physical printer. It shall allow for the selection and ordering of record fields for printing.

The system shall allow for the definition and selection of receipt printers, standard printers, label printers, and forms printers, with support for all Windows printers.

## 3.2 Performance requirements
*   The system must support a library system with 50 locations, 20 million circulations per year, and the purchasing and processing of over 500,000 items per year.
*   The system shall provide real-time processing. For example, pull lists must be up to date at the time of viewing or printing.
*   The system must support simultaneous access and updates to patron and item records by multiple staff members and patrons.
*   Searches and reports must be able to be processed during open hours without disrupting other system functions.

## 3.3 Usability requirements
*   The system shall be accessible with screen-reading software, screen-magnification software, and other software programs designed to increase accessibility.
*   The system shall provide an online, hierarchical, and cross-linked help system in HTML that describes and illustrates all system functions.
*   System documentation shall be web-based, indexed, organized by function, and easily searchable.
*   The system shall provide a user-friendly interface for designing queries that allows staff to select fields, use picklists for possible values, use drop-down menus for regular expressions, and apply a full range of Boolean operators.
*   System status shall be represented by visual indicators, such as green and red lights, for quick assessment.
*   To improve data entry efficiency and accuracy, the system shall support the ability to specify default values, data validation, automatic formatting, and required status for any field.
*   The system shall provide configurable templates for common tasks, including the creation of new staff and patron accounts, and for generating reports.
*   The system shall support administrator-programmable and user-programmable macros and keyboard shortcuts.
*   The system shall support the creation of custom dashboards.
*   Users shall have the ability to fully customize the layout and appearance of reports.

## 3.5 Logical database requirements
The system shall run on a fully relational, SQL-based database system.

*   **Types of Information:** The database will store information including, but not limited to:
    *   Authority records
    *   Bibliographic records
    *   Order records
    *   Item records
    *   Hold/request records
    *   Patron records
    *   Invoice records
    *   User and group accounts with associated privileges
    *   System configuration data
    *   System performance and transaction data
    *   Log files

*   **Frequency of Use:** The system must support real-time processing and simultaneous access for updates to patron and item records.

*   **Accessing Capabilities:**
    *   The database must be fully accessible, allowing for SQL queries against any table.
    *   The database must be accessible as an ODBC source.
    *   The system shall provide an interface for authorized staff to design and run queries against all record types.
    *   Staff must be able to identify where a record is in use (location, user, date, and time).
    *   Administrators must be able to view and unlock any locked record.

*   **Data Entities and Their Relationships:** [N/A]

*   **Integrity Constraints:**
    *   The system shall support configurable business rules to restrict actions, such as preventing the deletion of an item record that is currently checked out.
    *   The system shall allow administrators to specify default values, data validation rules, automatic formatting, and required status for any field.
    *   The system shall warn a user attempting to save a record if that record has been changed by another user since it was opened.

*   **Security:**
    *   Patron data must be secure in all transfers to and from the system.
    *   Access to data tables and fields shall be controlled through user rights and privileges assigned to security groups or roles.
    *   System administrators shall have full visibility and control of all user privileges.

*   **Data Retention Requirements:**
    *   Log file retention thresholds must be configurable.
    *   The system shall log data changes to provide "undo" functionality for actions such as record deletions.

## 3.6 Design constraints
*   The system shall operate on a Linux or Solaris server.
*   The system shall be accessible through a web browser or a Windows-compatible client.
*   If web-browser based, the system shall be accessible through Microsoft Internet Explorer (v.6.0 and later) and Mozilla Firefox (v.2.0 and later).
*   The system shall use a fully relational, SQL-based database back-end.
*   The system shall produce standards-compliant HTML.
*   The system shall provide a development and training environment with the ability to migrate configurations to a production environment.
*   User rights and privileges will be controlled through security groups and/or “roles”.
*   The system shall support secure protocols, including SFTP, SSL, and SSH.
*   The system shall support SMTP for email transport.
*   The system shall be accessible with screen-reading software, screen-magnification software, and other software programs designed to increase accessibility.

## 3.7 Software system attributes
### Reliability
*   The system shall log data changes to provide "undo" functionality and, ideally, revision control.
*   The system shall identify runaway processes.

### Availability
*   The system shall support server clustering for failover capability.
*   The system shall provide the capability to perform live incremental and full backups of data and transaction logs.
*   It is highly desirable that searches and reports can be processed during open hours without disrupting other system functions.
*   Log files shall be reviewable without stopping the system.

### Security
*   User rights and privileges shall be controlled through security groups and/or “roles” that allow access control for individuals and groups.
*   System administrators shall have full visibility and control of user privileges.
*   Patron data shall be secure in all transfers to and from the system.
*   The system shall support secure protocols, including SFTP, SSL, and SSH.
*   The system shall provide full access to all log files, which can be enabled, disabled, and set to a specific retention threshold.

### Maintainability
*   The system shall provide a single console with access to all configuration files.
*   Client software installation and updates shall be centrally managed.
*   All client configuration files shall be server-based.
*   System upgrades and updates shall include written guidelines for updating servers and clients, including a list of new, changed, and removed features.
*   The software developer shall provide complete data specifications for all records maintained or accessed by the System Administration Module.
*   The software developer shall provide a thorough high-level description of major processes.

### Portability
*   The system shall operate on a Linux or Solaris server.
*   The system shall be accessible through a web browser or a Windows-compatible client.
*   If web-browser based, the system shall be accessible through Microsoft Internet Explorer (v.6.0 and later) and Mozilla Firefox (v.2.0 and later).
*   The system shall produce standards-compliant HTML.

## 3.8 Supporting information
Process flowcharts are referenced where appropriate. These flowcharts illustrate the current approach to System Administration at King County Library System and should be considered as contextual information rather than as prescriptive requirements.

It is assumed that the reader has a general understanding of Library services and processes and does not require definition of common Library terminology.

*   Sample input/output formats: [N/A]
*   Cost analysis studies or user survey results: [N/A]
*   Special packaging instructions: [N/A]

# 4 Verification
[NULL]

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
Verification of usability requirements will be conducted through a collaborative and iterative process where end-users have multiple opportunities to review prototypes and refine the user interface and software functionality.

*   **Accessibility**: The system's accessibility will be verified by testing with screen-reading software, screen-magnification software, and other programs designed to increase accessibility.
*   **Online Help System**: The online help system will be verified by inspection to ensure it is hierarchical, cross-linked, and provides complete descriptions and illustrations for all system functions.
*   **User Interfaces**: The usability of user interfaces, including dashboards, consoles, and the query tool, will be verified through user acceptance testing. Representative users will perform common tasks to ensure the interfaces are user-friendly, effective, and meet their needs.
*   **Macros and Shortcuts**: The functionality for macros and keyboard shortcuts will be verified by demonstration and testing to ensure they can be programmed, managed, and used by administrators and users as specified.

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
[N/A]

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
*   The System Administration Module is part of an enterprise-level Library Automation System.
*   System Administration processes are consolidated at a central location, and accept input and provide services to multiple locations.
*   The System Administration Module relies on the data structures and functionality of an enterprise-level Library Automation System, including Acquisitions and Cataloging modules.
*   The System Administration Module will interface with a variety of vendor websites, via published APIs and/or automated transfer of standard-format data files (e.g. USMARC21, EDIFACT).
*   The System Administration Module interacts with a patron interface, also known as an Online Public Access Catalog (OPAC).

## 5.2 Acronyms and abbreviations
*   API: Application Programming Interface
*   CPU: [N/A]
*   CSV: [N/A]
*   EDIFACT: [N/A]
*   FTP: [N/A]
*   HTML: [N/A]
*   ILS: Integrated Library System
*   MARC: [N/A]
*   NCIP: [N/A]
*   ODBC: [N/A]
*   OCLC: [N/A]
*   OPAC: Online Public Access Catalog
*   SFTP: [N/A]
*   SIP: [N/A]
*   SMTP: [N/A]
*   SNMP: [N/A]
*   SQL: [N/A]
*   SRS: Software Requirements Specification
*   SSH: [N/A]
*   SSL: [N/A]
*   USMARC21: [N/A]
*   VNC: [N/A]
