## 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
This document specifies the requirements for the System Administration Module, a component of a larger Integrated Library System (ILS).

The objective of the System Administration Module is to facilitate the management of every aspect of the ILS. It will replace and enhance the current capabilities of commercially available ILSes and add new functionality.

The software will support the following activities:
*   Configuring the ILS to enable and support features and processes required for the management of 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.

This specification is limited to the functional characteristics of the System Administration Module. It presupposes the general functionality of other ILS modules, such as Acquisitions and Serials Management, Circulation, and Cataloging, which have been specified previously. Requirements for the Online Public Access Catalog (OPAC) and web services are currently under development and are not covered in this document. Data structures and user interfaces will be specified later in the development process.

### 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 module will replace and enhance the current capabilities of commercially available ILSes.

This module relies on the data structures and functionality of other ILS modules, including Acquisitions and Serials Management, Circulation, and Cataloging. It also interacts with the patron-facing Online Public Access Catalog (OPAC).

#### System interfaces
The System Administration Module interfaces with:
*   A patron interface, also known as an Online Public Access Catalog (OPAC).
*   A variety of vendor websites, via published APIs and/or automated transfer of standard-format data files (e.g., USMARC21, EDIFACT). This includes vendors such as OCLC for importing and exporting MARC records.

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

#### Hardware interfaces
The system shall support the definition and selection of receipt printers, standard printers, label printers, and forms printers. All Windows-compatible printers are supported.

#### Software interfaces
The System Administration Module operates within the following software environment:
*   **Operating System:** The server shall operate on Linux or Solaris.
*   **Database:** The module shall use a fully relational, SQL-based database back-end that is accessible as an ODBC source.
*   **Web Browsers:** If web-based, the module must be accessible through Microsoft Internet Explorer (v.6.0 and later) and Mozilla Firefox (v.2.0 and later).
*   **Third-Party Software:** The system supports the use of third-party backup software such as EMC NetWorker. Client software can be managed with VNC and Remote Desktop.

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

#### Memory constraints
[N/A]

#### Operations
*   The system must support a development and training environment with the ability to migrate configurations to a production environment.
*   It must provide the capability to perform live incremental and full backups of data and transaction logs.
*   The system shall support server clustering for failover capability.
*   It is highly desirable that searches and reports can be processed during the library's open hours without disrupting other system functions.

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

#### Interfaces with services
The module will interface with various 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 (ILS). A summary of the major functions includes:
*   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 user classes for the system are:

*   **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**: Includes managers, librarians, library technicians, library assistants, and library pages who are involved in designing and providing services for the Library. It is assumed that staff users have a general understanding of Library services and processes.
*   **System Administrators**: Staff with responsibility for managing servers, databases, applications, services, ports, and APIs related to the ILS.
*   **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.

The system shall be accessible with screen-reading software, screen-magnification software, and other software programs designed to increase accessibility.

### 1.3.4 Limitations
The System Administration Module is a component of a larger Integrated Library System (ILS) and is not a standalone product. Its design and implementation are limited by the following factors:

*   **System Dependencies**: The module relies on the pre-existing data structures and functionality of the core ILS, including its Acquisitions, Cataloging, and Online Public Access Catalog (OPAC) modules. This specification presupposes this core functionality and does not define it.
*   **Interfaces**: The module must interface with various third-party vendor websites using their published APIs or through standard data file transfers (e.g., USMARC21, EDIFACT).
*   **Operating Environment**: The server software is restricted to operating on a Linux or Solaris server. Client access is limited to either a Windows-compatible client application or specific web browsers (Microsoft Internet Explorer v.6.0 and later, and Mozilla Firefox v.2.0 and later).
*   **Technology Stack**: The system must be implemented using a fully relational, SQL-based database back-end. Any web-based components must produce standards-compliant HTML.
*   **Security Model**: The design for user rights and privileges is constrained to a model based on security groups and/or roles.
*   **Specification Scope**: This document is focused on functional characteristics. Data structures and user interface specifics are outside the scope of this specification and are intended to be defined during a later, iterative development phase.

## 1.4 Definitions

*   **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**: Includes managers, librarians, library technicians, library assistants, and library pages who are involved in designing and providing services for the Library.
*   **System Administrators**: Includes staff with responsibility for managing servers, databases, applications, services, ports, and APIs related to the ILS.
*   **Managers**: Includes management staff who oversee Library processes.
*   **Library Managers**: Includes Cluster and Site Managers who provide input to the design and implementation of Library services.
*   **Library Directors**: Includes members of the Library Executive Team who plan and direct Library services and priorities.

# 2 References
[N/A]

## 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. For example, pull lists are up to date at the time of viewing or printing, and the system supports live shelf reading and weeding.
*   The system shall allow multiple staff members and patrons to simultaneously access and update patron and item records.
*   The system shall provide 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 (location, user, date and time placed).
*   The system shall support individual and shared staff login accounts.
*   Access to modules shall be granted by use of "roles" or "privileges".
*   Individual logins shall allow for user-level preferences and an audit trail.
*   The system shall provide access to all configuration files.
*   The system shall provide full access to all log files.
*   Log files shall be reviewable without stopping the system.
*   Logs shall be able 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 give 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, for all record types, a list of records in a sustained use/locked condition.
*   The system shall provide the ability to unlock one or more records from a console.
*   The system shall provide a dashboard of performance monitoring and management tools, including identification of 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 a software shutdown utility, software startup utility, server shutdown utility, and server restart utility.
*   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 can be assigned 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. Requesting rules may evaluate patron type, current number of holds, current patron account balance, item type, item status, and owning location code.
*   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 may evaluate patron type, number of items checked out, account balance, item type, item status, owning location code, and check-out location code.
*   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 revision control.
*   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 able to be imported and exported, singly and in batch, with all fields or selected fields.
*   Imported records shall be able to overlay existing short or full 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 able to be scheduled in sequence and can be modified or canceled at any time prior to starting.
*   Staff shall be able to 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 of 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 able to be exported and imported 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.
*   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.
*   The system shall provide the ability to define and select four types of printers: receipt printer, standard printer, label printer, and forms printer.
*   The system shall support all Windows printers.
*   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.
*   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 a library system with 50 locations, 20 million circulations per year, and purchasing and processing 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 shall 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, select values from picklists, use regular expressions from a drop-down menu, and use a full range of Boolean operators.
*   System status shall be represented by visual indicators (e.g., green and red lights).
*   The system shall support administrator-programmable and user-programmable macros and keyboard shortcuts.
*   System administrators shall be able to create report templates that are available to front-line staff.

## 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 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 use a fully relational database back-end.
*   The System Administration Module shall produce standards-compliant HTML.
*   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.
*   The system shall support secure protocols, including SFTP, SSL, and SSH.

## 3.7 Software system attributes

### Reliability
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 and support the use of third-party backup software. The system shall log data changes and provide "undo" functionality or revision control.

### Availability
The system shall provide real-time processing. 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, workgroups, and arbitrary staff groups.
- The system shall support individual and shared staff login accounts. Individual logins shall allow for a user-level audit trail.
- System administrative staff 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 fine-grained permissions to allow or disallow staff to run specific reports and ad hoc queries on specific sets of data.
- Administrators shall control staff access to database tables and fields.
- Read and write permission to individual configuration files shall be assignable to users and groups.

### Maintainability
- The system shall provide a development and training environment with the ability to migrate configurations to a production environment.
- The system shall provide access to all configuration files, log files, and the root shell.
- Logs shall be configurable to be enabled, disabled, and set to a specific retention threshold.
- Client software installation and updates shall be centrally managed.
- All client configuration files shall be server-based and allow for export and import between clients.
- System upgrades and updates shall include written guidelines for updating servers and clients, including a list of new, changed, and removed features.
- The system shall provide an online, hierarchical, and cross-linked help system in HTML that describes and illustrates all system functions.

### 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.1 Functions
[N/A]

## 4.2 Performance requirements
[N/A]

## 4.3 Usability requirements
[N/A]

## 4.5 Logical database requirements
[N/A]

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
[N/A]

## 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 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
[N/A]