# 1 Introduction
[NULL]

## 1.1 Purpose
This Software Requirements Specification (SRS) describes 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, as well as add new functionality.

The requirements were developed specifically for King County Library System, but are believed to be suitable for many large, urban, multiple-branch, centralized library systems.

## 1.2 Scope
The software product to be produced is the System Administration Module for an Integrated Library System (ILS).

The System Administration Module will facilitate the management of every aspect of the ILS. The objectives of the module are to replace and enhance the current capabilities of commercially available ILSes and to add new functionality. The module is designed for large, urban, multiple-branch, centralized library systems.

Specifically, the System Administration Module 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 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.

This specification is part of a larger set of requirements for a full-fledged ILS. It presupposes the general data structures and functionality of an ILS and specifies only those requirements that directly or indirectly relate to system administration activities. Specifications for Acquisitions and Serials Management, Circulation, and Cataloging modules have been previously published. This document focuses on the functional characteristics of the System Administration Module; data structures and user interfaces will be specified later.

## 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). The requirements in this SRS presuppose the general data structures and functionality of a full-fledged ILS. The System Administration Module relies on and interacts with other ILS modules, including Acquisitions and Serials Management, Circulation, Cataloging, and the Online Public Access Catalog (OPAC).

#### System interfaces
The System Administration Module interfaces with a variety of external systems:
*   It interfaces with vendor websites via published APIs and/or automated transfer of standard-format data files such as USMARC21 and EDIFACT.
*   It provides support for SNMP for monitoring system resources.
*   It supports protocols such as SIP2/NCIP2 for interaction with other library systems and self-service stations.

#### User interfaces
The logical characteristics of the user interface are as follows:
*   The module shall be accessible through a web-browser (Microsoft Internet Explorer v.6.0 and later, Mozilla Firefox v.2.0 and later) or a Windows-compatible client.
*   The module shall produce standards-compliant HTML.
*   The module shall be accessible with screen-reading software, screen-magnification software, and other accessibility programs.
*   The user interface will be refined using an iterative, prototype-oriented software development methodology in collaboration with end-users.

#### Hardware interfaces
The software shall support and be able to define various types of printers, including receipt printers, standard printers, label printers, and forms printers. All Windows printers are supported.

#### Software interfaces
The System Administration Module will operate within the following software environment:
*   Operating System: Linux or Solaris server.
*   Database: A fully relational, SQL-based database system. The database must be accessible as an ODBC source.
*   Third-Party Software: The system must support the use of third-party backup software, such as EMC NetWorker. It must also be manageable via remote tools like VNC and Remote Desktop.

#### Communications interfaces
The system shall support the following communications protocols:
*   Secure protocols including SFTP (in both active and passive modes), SSL, and SSH.
*   SMTP for email transport.

#### Memory constraints
[N/A]

#### Operations
The system shall support the following operations:
*   A development and training environment shall be provided, with the ability to migrate configurations to the production environment.
*   Searches and reports should be processable during open hours without disrupting other system functions.
*   The system must provide for live incremental and full backups of data and transaction logs.
*   The system shall provide server management utilities for software startup/shutdown and server restart/shutdown.
*   The system shall log data changes and provide "undo" functionality.

#### Site adaptation requirements
The system is intended for large, multiple-branch library systems and its processes are consolidated at a central location to provide services to multiple locations. It must be configurable to support a library system with 50 locations, 20 million circulations, and the processing of over 500,000 items per year.

#### Interfaces with services
The System Administration Module will interface with a variety of vendor websites and services via published APIs.

### 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 intended users of the System Administration Module and the overall Integrated Library System (ILS) can be categorized into the following groups:

*   **Patron**: A customer of the King County Library System. They may or may not possess a library card and use library resources either on-site or remotely.
*   **Staff**: Includes managers, librarians, library technicians, library assistants, and library pages who are involved in designing and providing library services. It is assumed that staff have a general understanding of library services and processes.
*   **System Administrators**: Staff responsible for managing the technical aspects of the ILS, including servers, databases, applications, services, ports, and APIs. This group possesses a high level of technical expertise.
*   **Managers**: Management staff who oversee library processes.
*   **Library Managers**: Cluster and Site Managers who provide input to the design and implementation of library services.
*   **Library Directors**: Members of the Library Executive Team who plan and direct library services and priorities.

General user characteristics are as follows:

*   **Educational Level**: [N/A]
*   **Experience**: Technical expertise varies by role, from non-technical staff to expert System Administrators. All staff users are assumed to have a general understanding of library services and processes.
*   **Disabilities**: The system must be accessible to users with disabilities, supporting assistive technologies such as screen-reading and screen-magnification software.

### 1.3.4 Limitations
The System Administration Module is a component of a larger, pre-existing enterprise-level Integrated Library System (ILS). It is not a standalone product and relies on the data structures and functionality of the ILS, particularly the Acquisitions and Cataloging modules. The module must also interface with the Online Public Access Catalog (OPAC) and various external vendor websites via APIs or standard data file formats such as USMARC21 and EDIFACT.

The system is limited to specific operating environments. The server-side application must operate on a Linux or Solaris server. The client-side application must be accessible either through a web browser (specifically, Microsoft Internet Explorer v.6.0 and later or Mozilla Firefox v.2.0 and later) or a Windows-compatible client.

There are several design and implementation constraints. The system must use a fully relational, SQL-based database back-end. Any web-based interfaces must produce standards-compliant HTML.

Security is a key consideration that limits design options. All patron data must be secured during transfer. The system must support secure protocols, including SFTP, SSL, and SSH. User access and privileges must be controlled through a system of security groups and/or roles.

The system must be designed for accessibility and must be compatible with screen-reading software, screen-magnification software, and other assistive technologies.

## 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 run on a fully relational, SQL-based database system.
*   The system shall provide the ability to run SQL queries against any table in the database.
*   The system shall provide the ability to access the database as an ODBC source.
*   All data tables and data storage shall be fully accessible.
*   The system shall provide real-time processing.
*   The system shall allow multiple staff members and patrons to simultaneously access and update patron and item records.
*   The system shall apply record changes in a reasonable way, with prompts to warn when a record has been changed since it was displayed.
*   For any patron record or item record, staff shall be able to identify where it is in use, including the location, user, and date and time it was placed in use.
*   The system shall support individual and shared staff login accounts.
*   Access to modules shall be granted by the use of "roles" or "privileges".
*   The system shall provide access to all configuration files.
*   The system shall provide full access to all log files, which can be reviewed without stopping the system.
*   Logs shall be configurable to be enabled, disabled, and set to a specific retention threshold.
*   The system shall provide access to the root shell.

### 3.1.2 Consoles and Dashboards
*   The system shall support the creation of custom dashboards that display current and historical data about system performance, record creation and modification, and circulation transactions.
*   Administrators shall be able to create dashboards and grant access to selected users and groups.
*   The system shall provide full support for SNMP and support monitoring of system resources, including disk space, CPU load, memory load, system processes, system interfaces, and ports.
*   Alert thresholds shall be configurable.
*   Alerts shall be sent via administrative dashboards, email messages, and text messages to an unlimited number of recipients.
*   The system shall provide the ability to set thresholds on the length of time records are locked.
*   The system shall provide a list of records in a sustained use/locked condition and a console to unlock one or more records.
*   The system shall provide a dashboard of performance monitoring and management tools, identifying processes with process ID, owner username, IP address, CPU utilization, memory utilization, and run time.
*   Runaway processes shall be identified.
*   System status shall be represented by visual indicators.
*   The system shall provide a server management console including utilities for software shutdown, software startup, server shutdown, and server restart.
*   The system shall provide an administrative dashboard displaying the last full and incremental backup, last planned and unplanned system reboot, last software upgrade, current software version, transactions waiting to be processed, size of log-files, current count of records by record type, and database utilization.
*   The system shall provide a management console displaying workstations running client software, including workstation name and IP address, and utilities for managing and killing 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. Indicators can be limited to a single branch or set to systemwide.
*   The system shall provide a single console with access to all configuration files. Read and write permission to individual configuration files shall be 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 scheduled tasks, including staff-scheduled tasks, automated reports, scheduled imports and exports, and software updates.
*   The system shall provide the ability to access and edit email configuration, including a quick menu of common settings.
*   The system shall support SMTP for email transport.

### 3.1.3 Business Rules
*   The system shall support restrictions based on business rules, such as restrictions on deleting item records that are in checked-out status.
*   The system shall provide customizable 'Rules of Suppression' that specify whether patrons and staff can view authority, bibliographic, order, and item records in staff and public interfaces.
*   The system shall allow the creation and modification of requesting rules that determine whether a patron can place a hold on an item, based on criteria such as patron type, current number of holds, item type, and item status.
*   Requesting rules shall specify whether staff with specific privileges or roles can override specific criteria.
*   The system shall allow the creation and modification of loan rules that allow or disallow check-out of items, calculate loan periods, and determine renewal limits.
*   Loan rules shall evaluate criteria such as patron type, item type, item status, and location codes.
*   Loan rules shall be able to access the check-out location's open/closed schedule in calculating the due date.
*   Loan rules shall specify whether a specific criterion may be overridden by staff with specific privileges or roles.
*   The system shall provide the ability to specify a default value, data validation, automatic formatting, and required status for any field.

### 3.1.4 Data Recovery
*   The system shall provide the capability to perform live incremental and full backups of data and transaction logs.
*   The system shall support the use of third-party backup software.
*   The system shall log data changes and provide "undo" functionality.
*   The system shall provide the ability to cluster servers for failover capability.

### 3.1.5 Security
*   Patron data shall be secure in all transfers to and from the system.
*   System administrative staff shall have full visibility and control of user privileges.
*   The system shall support secure protocols, including SFTP, SSL, and SSH.
*   SFTP shall be supported in both active and passive modes, configurable per vendor.

### 3.1.6 Maintenance
*   MARC bibliographic and authority records shall be importable and exportable, singly and in batch, with all fields or selected fields.
*   Imported records shall be able to overlay existing bibliographic records.
*   The system shall support an unlimited number of record sets, with the ability to import and export set members in batch.
*   Record sets shall be usable as the basis for batch field updates, as a limiting scope for queries, and to delete original records with the ability to review prior to deletion, write errors to a log file, and undo one or more deletions.
*   The system shall provide a dedicated interface for creating new staff accounts, with configurable templates and granular privileges for account creation, modification, and deletion.
*   The system shall provide a dedicated interface for creating new patron accounts, with configurable templates, field validation, required fields, and configurable defaults.
*   The system shall support the scheduling of maintenance tasks, reports, and data exports.
*   Jobs shall be schedulable in sequence and can be modified or cancelled at any time prior to starting.
*   Staff shall be given permission to schedule tasks, reports, and data exports.
*   System administration staff shall be able to view and manage jobs scheduled by other staff.
*   The system shall support administrator-programmable and user-programmable macros and/or keyboard shortcuts.
*   Macros shall be centrally managed on the server, can be imported from and exported to individual users, and can be restricted for use and/or editing through centrally-managed permissions.

### 3.1.7 Client Management
*   Staff and group accounts shall be independent from workstations.
*   Client software installation and updates shall be centrally managed, allowing streaming updates from the server.
*   The system shall provide the ability to specify specific clients to be updated.
*   Client software shall be manageable with VNC and Remote Desktop.
*   All client configuration files shall be server-based.
*   Configurations shall be exportable and importable between clients.

### 3.1.8 Queries and Reports
*   The system shall provide the ability to fully customize the layout and appearance of reports.
*   The system shall provide the ability to display, print, email, or save reports to standard formats including CSV and Excel, as well as to customizable formats.
*   The system shall provide a user-friendly interface for designing queries against all record types.
*   Staff shall be able to select fields to query, select values from a picklist of possible values, select regular expressions from a drop-down menu, and use a full range of Boolean operators.
*   Administrators shall control staff access to tables and fields for querying.
*   System administrators shall be able to create report templates that are available to front-line staff, which can be run as is or modified.
*   The system shall provide fine-grained permissions to allow or disallow staff to run specific reports and/or to run ad hoc reports on specific sets of data.
*   The system shall report for each record type: current record number, current number of records, number deleted, and number purged. Access to record numbers shall be controlled at the user/group level.
*   The system shall provide the ability to define and select four types of printers: receipt printer, standard printer, label printer, and forms printer. All Windows printers shall be supported.
*   The system shall provide the ability to print to a file on the server, FTP, email, or a printer from any part of the application.
*   When applicable, the system shall provide the ability to select record fields and control the order of fields when printing.

## 3.2 Performance requirements
The system must support the capacity of a large, multiple-branch library system, specifically:
*   50 locations
*   20 million circulations per year
*   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, and the system must support live shelf reading and weeding.

The system must allow multiple staff members and patrons to simultaneously access and update patron and item records.

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.

The following types of information will be stored in the database:
*   Authority records
*   Bibliographic records
*   Order records
*   Item records
*   Hold/request records
*   Patron records
*   Invoice records
*   Configuration files
*   Log files
*   System performance data (current and historical)
*   Circulation transaction data

Frequency of use is not specified.

The system shall provide the following data accessing capabilities:
*   The ability to run SQL queries against any table in the database.
*   The ability to access the database as an ODBC source.
*   All data tables and data storage shall be fully accessible to authorized users.
*   Multiple staff members and patrons must be able to simultaneously access and update patron and item records.
*   A user-friendly interface for designing queries against all record types.

Data entities include patron, bibliographic, item, order, invoice, authority, and hold/request records. The specific relationships between these entities are not defined in this document.

The following integrity constraints shall be enforced:
*   The system shall support restrictions based on business rules, such as preventing the deletion of item records that are in a checked-out status or bibliographic records with existing holds.
*   The system shall provide prompts to warn a user when a record has been changed by another user since it was displayed.
*   The system shall provide the ability to specify a default value, data validation rules, automatic formatting, and required status for any field.

The following security requirements apply to the database:
*   Patron data must be secure in all transfers to and from the system.
*   Access to data tables and fields shall be controlled by administrators.
*   User rights and privileges shall be controlled through security groups and/or roles that allow access control for individuals and groups.
*   Staff shall be able to view all patron and item fields depending on assigned privileges, while patrons can access only selected fields.

The system shall allow log files to be set to a specific retention threshold. Data retention requirements for other types of information are not specified.

## 3.6 Design constraints
*   The System Administration Module shall operate on a Linux or Solaris server.
*   The System Administration Module shall be accessible through a web-browser or a Windows-compatible client.
*   If web-browser based, the System Administration Module shall be accessible through Microsoft Internet Explorer (v.6.0 and later) and Mozilla Firefox (v.2.0 and later).
*   The System Administration Module shall be accessible with screen-reading software, screen-magnification software, and other software programs designed to increase accessibility.
*   The System Administration Module shall use a fully relational, SQL-based database back-end.
*   The System Administration Module shall produce standards-compliant HTML.
*   The System Administration Module shall support secure protocols, including SFTP, SSL, and SSH.
*   The System Administration Module 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” that allow access control for individuals, workgroups, and arbitrary staff groups.

## 3.7 Software system attributes
### 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.
*   The system shall log data changes and provide "undo" functionality.

### Security
*   Patron data shall be secure in all transfers to and from the system.
*   The system shall support secure protocols, including SFTP, SSL, and SSH.
*   User rights and privileges will be controlled through security groups and/or “roles” that allow access control for individuals and groups.
*   System administrative staff shall have full visibility and control of user privileges.
*   The system shall support individual staff login accounts to allow for a user-level audit trail.
*   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 development and training environment with the ability to migrate configurations to a production environment.
*   System upgrades and updates shall include written guidelines for updating servers and clients, including a list of new, changed, and removed features.
*   Client software installation and updates must be centrally managed.
*   All client configuration files shall be server-based.
*   The system shall provide access to all configuration files.
*   The software developer shall provide complete data specifications for all records maintained or accessed by the module.
*   The software developer shall provide a 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
The System Administration Module will replace and enhance the current capabilities of commercially available Integrated Library Systems (ILSes), as well as add new functionality.

Where appropriate, requirements reference process flowcharts. These flowcharts indicate the current approach to System Administration at King County Library System. They should be considered contextual information rather than a prescription or constraint for new software development.

# 4 Verification
[NULL]

## 4.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
[N/A]

## 4.5 Logical database requirements
Verification of the logical database requirements will be achieved through a combination of inspection, analysis, demonstration, and testing.

*   **Database Type and Access:** The requirement for a fully relational, SQL-based database with ODBC access (Req ID: 6512, CO-1) will be verified by inspection of the system's design documentation and by a test involving connecting to the database with a standard SQL client and successfully executing queries.
*   **Data Entities and Relationships:** The requirement for complete data specifications for all record types (UD-1) will be verified by inspection. The provided documentation will be reviewed for completeness and accuracy against the implemented database schema.
*   **Accessing Capabilities:** The ability for multiple users to simultaneously access and update records (Req ID: 5323) and for administrators to manage record locks (Req ID: 6513, 7302) will be verified by test. Test cases will simulate concurrent record access to ensure that record changes are applied correctly and that locking and unlocking mechanisms function as specified.
*   **Integrity Constraints:** The enforcement of business rules (Req ID: 2445) and data validation (Req ID: 5328) will be verified by test. Test cases will involve attempting to enter invalid data and performing actions that violate business rules (e.g., deleting a record with existing dependencies). The system must reject these invalid operations.
*   **Security:** The security of patron data during transfer (Req ID: 6510) will be verified by inspection of the system architecture and by test. Network traffic will be analyzed during operations involving patron data to confirm that the data is encrypted.
*   **Data Retention:** Requirements for log file retention thresholds (Req ID: 2474) will be verified by demonstration. A threshold will be configured, and the system will be monitored to confirm that logs are purged according to the setting. The ability to perform backups (Req ID: 6502) and roll back data changes (Req ID: 6505) will be verified by demonstration. A backup and restore cycle will be performed, and the undo functionality will be tested to ensure data can be recovered correctly.
*   **Frequency of Use:** [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: Central Processing Unit
*   CSV: Comma-Separated Values
*   EDIFACT: Electronic Data Interchange for Administration, Commerce and Transport
*   FTP: File Transfer Protocol
*   HTML: HyperText Markup Language
*   ILS: Integrated Library System
*   IP: Internet Protocol
*   MARC: Machine-Readable Cataloging
*   NCIP: NISO Circulation Interchange Protocol
*   OCLC: Online Computer Library Center
*   ODBC: Open Database Connectivity
*   OPAC: Online Public Access Catalog
*   SFTP: Secure File Transfer Protocol
*   SIP: Standard Interchange Protocol
*   SMTP: Simple Mail Transfer Protocol
*   SNMP: Simple Network Management Protocol
*   SQL: Structured Query Language
*   SRS: Software Requirements Specification
*   SSH: Secure Shell
*   SSL: Secure Sockets Layer
*   USMARC21: United States Machine-Readable Cataloging, 21st edition
*   VNC: Virtual Network Computing
