# 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). This module is intended to replace and enhance current capabilities of commercially available ILSes, as well as add new functionality. While developed for the King County Library System, the requirements are designed 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, which is a component of an Integrated Library System (ILS). This module is designed to facilitate the comprehensive management of every aspect of the Integrated Library System.

The System Administration Module will perform the following key functions:
*   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 their associated privileges.
*   Managing server and client software installation, upgrades, and updates.
*   Backing up databases, configuration files, log files, and other critical data.

The application of this software is to replace and enhance the current system administration capabilities found in commercially available ILSes, while also introducing new functionality. The primary objective is to provide robust and efficient administrative control over the ILS, supporting the operational demands of a large, multiple-branch library system such as King County Library System, which includes 50 locations, 20 million circulations, and the purchasing and processing of over 500,000 items per year. This specification focuses exclusively on the requirements for system administration activities, presupposing the general data structures and functionality of other ILS modules like Acquisitions, Serials Management, Circulation, and Cataloging.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The System Administration Module is an integral component of a larger Integrated Library System (ILS). It is designed to replace and enhance existing capabilities of commercially available ILSes, as well as add new functionality. The module presupposes the general data structures and functionality of a full-fledged ILS. It is part of an enterprise-level Library Automation System.

The System Administration Module relates to other modules within the ILS, including previously published specifications for Acquisitions and Serials Management, Circulation, and Cataloging modules. It also interacts with modules currently under development, such as the Online Public Access Catalog (OPAC) and web services.

#### System interfaces
The System Administration Module is an element of an enterprise-level Library Automation System. It interfaces with:
*   Acquisitions module
*   Serials Management module
*   Circulation module
*   Cataloging module
*   Online Public Access Catalog (OPAC)
*   Various vendor websites

#### User interfaces
The System Administration Module shall be accessible through:
*   A web-browser (Microsoft Internet Explorer v.6.0 and later, Mozilla Firefox v.2.0 and later)
*   A Windows-compatible client
*   Screen-reading software, screen-magnification software, and other software programs designed to increase accessibility.

The system shall produce standards-compliant HTML. User rights and privileges will be controlled through security groups and/or "roles" that allow access control for individuals, workgroups, and arbitrary staff groups. An online, hierarchical, and cross-linked help system in HTML shall be provided, describing and illustrating all system functions.

#### Hardware interfaces
The System Administration Module shall operate on a Linux or Solaris server. The system supports server clustering for failover capability. It supports defining and selecting four types of printers: receipt printer, standard printer, label printer, and forms printer, with support for all Windows printers.

#### Software interfaces
The System Administration Module relies on the following software interfaces:
*   **Operating System:** Linux or Solaris.
*   **Database:** A fully relational, SQL-based database back-end. It must allow running SQL queries against any table and be accessible as an ODBC source.
*   **Web Browsers:** Microsoft Internet Explorer (v.6.0 and later) and Mozilla Firefox (v.2.0 and later).
*   **Client Software:** Windows-compatible client software.
*   **Other ILS Modules:** Acquisitions, Cataloging, Circulation, Serials Management, and OPAC.
*   **Third-party Backup Software:** Supports use of third-party backup software such as EMC NetWorker.
*   **Network Management Tools:** Standard or proprietary network management tools for central client software installation and updates.
*   **Remote Access Tools:** VNC and Remote Desktop for client software management.
*   **Data Formats:** USMARC21, EDIFACT for vendor interfaces.
*   **APIs:** Published APIs for vendor websites.
*   **Accessibility Software:** Screen-reading software, screen-magnification software, and other accessibility programs.

#### Communications interfaces
The System Administration Module supports:
*   Secure protocols, including SFTP, SSL, and SSH. SFTP is supported in both active and passive modes, configurable per vendor.
*   Printing to a file on the server, FTP, email, or a physical printer from any part of the application.
*   Interfacing with a variety of vendor websites.

#### Memory constraints
[N/A]

#### Operations
The System Administration processes are consolidated at a central location, accepting input and providing services to multiple locations. The system provides capabilities for:
*   Performing live incremental and full backups of data and transaction logs.
*   Logging data changes (such as record deletions) and providing "undo" functionality, ideally with revision control.
*   Scheduling maintenance tasks, reports, and data exports. Jobs can be scheduled in sequence and modified or cancelled at any time prior to starting.
*   Centrally managing client software installation and updates.
*   Providing a development and training environment with the ability to migrate configurations to a production environment.

#### Site adaptation requirements
The System Administration Module provides:
*   A development and training environment with the ability to migrate configurations to a production environment.
*   Consolidated System Administration processes at a central location, accepting input and providing services to multiple locations.
*   Server-based client configuration files, with the ability to export and import configurations between clients.

#### Interfaces with services
The System Administration Module interfaces with a variety of vendor websites via published APIs and/or automated transfer of standard-format data files (e.g., USMARC21, EDIFACT).

### 1.3.2 Product functions
The System Administration Module will perform the following major functions:

*   **System Configuration Management**: Facilitate the configuration of the Integrated Library System (ILS) to support library operations, including managing business rules (e.g., loan, requesting, suppression rules, data validation), email settings, and client software configurations.
*   **Performance Monitoring and Control**: Provide tools and dashboards for monitoring, troubleshooting, and controlling the performance of servers, databases, applications, services, ports, and APIs. This includes identifying runaway processes, managing record locks, and offering server and client management consoles.
*   **User and Access Management**: Manage user and group accounts and privileges for both staff and patrons, enabling granular access control based on roles and ensuring the security of patron data. This includes dedicated interfaces for staff and patron account setup.
*   **Software Lifecycle Management**: Oversee the installation, upgrades, and updates of both server and client software components, including providing guidelines for system upgrades and centrally managing client software updates.
*   **Data Backup and Recovery**: Provide capabilities for performing live incremental and full backups of data and transaction logs, supporting data rollback, and enabling server clustering for failover.
*   **Data Management**: Support the import and export of various record types (e.g., MARC bibliographic and authority records) and allow for the creation and manipulation of record sets for batch operations and data maintenance.
*   **Job Scheduling**: Offer a centralized interface for scheduling and controlling automated tasks, reports, data imports/exports, and software updates, with options for sequential execution and management by authorized staff.
*   **Reporting and Querying**: Provide a user-friendly interface for designing and running queries against all record types, generating customizable reports with various output formats, and managing report templates and permissions.
*   **System Access and Security**: Control access to critical system files such as configuration files and log files, and ensure support for secure communication protocols like SFTP, SSL, and SSH.

### 1.3.3 User characteristics
The intended users of the System Administration Module include various groups within the King County Library System, as well as external software development personnel.

The primary user groups for the module's functionality are:
*   **Patrons**: Customers of the King County Library System, who may or may not possess a library card, and may be on-site or off-site, utilizing print, media, or electronic resources.
*   **Staff**: This broad category includes managers, librarians, library technicians, library assistants, and library pages who are involved in designing and providing library services. They are assumed to have a general understanding of Library services and processes.
*   **System Administrators**: Staff responsible for managing servers, databases, applications, services, ports, and APIs related to the Integrated Library System (ILS). These users are expected to have technical expertise in system and database administration.
*   **Managers**: Management staff who oversee Library processes. This includes Library Managers (Cluster and Site Managers) who provide input to service design and implementation, and Library Directors (members of the Library Executive Team) who plan and direct Library services and priorities.

The system is designed to accommodate users with varying technical expertise. While some users (e.g., System Administrators) will have high technical proficiency, the system aims for a high level of readability for non-technical audiences in its documentation and is expected to be refined through iterative development with end-user feedback.

The system also supports users with disabilities, as it is required to be accessible with screen-reading software, screen-magnification software, and other accessibility programs.

### 1.3.4 Limitations
The following items limit the supplier's options for the System Administration Module:

*   **Product Scope and Dependencies**
    *   The module presupposes and relies on the general data structures and functionality of a full-fledged Integrated Library System (ILS), including existing Acquisitions, Cataloging, and OPAC modules.
    *   The module is focused solely on system administration activities; other ILS functionalities are out of scope for this module.
    *   Data structures and user interfaces will require further specification and development using an iterative, prototype-oriented software development methodology.
    *   Software development is assumed to occur in a highly collaborative and iterative environment with end-user review of prototypes.
*   **Platform and Operating Environment**
    *   The system must operate on a Linux or Solaris server.
    *   Client access must be 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 system must support a large, multiple-branch library system, specifically 50 locations, 20 million circulations, and purchasing/processing over 500,000 items per year.
*   **Design and Implementation Constraints**
    *   The module shall use a fully relational, SQL-based database back-end, allowing SQL queries against any table and access as an ODBC source. All data tables and storage must be fully accessible.
    *   The module shall produce standards-compliant HTML.
    *   A development and training environment must be provided, with the ability to migrate configurations to a production environment.
    *   User rights and privileges must be controlled through security groups and/or "roles" for access control.
    *   The system shall provide an online, hierarchical, and cross-linked help system in HTML.
    *   Client software installation and updates must be centrally managed, allowing streaming updates from the server and management with VNC and Remote Desktop.
    *   All client configuration files must be server-based, with the ability to export and import configurations between clients.
*   **Interfaces and Protocols**
    *   The module relies on the data structures and functionality of an enterprise-level Library Automation System, including Acquisitions and Cataloging modules.
    *   The module must interface with a variety of vendor websites via published APIs and/or automated transfer of standard-format data files (e.g., USMARC21, EDIFACT).
    *   The module must interact with a patron interface (OPAC).
    *   The system must support secure protocols, including SFTP (active and passive modes, configurable per vendor), SSL, and SSH.
    *   The system must provide full support for SNMP for monitoring system resources.
    *   The system must support SMTP for email transport.
    *   The system must support SIP2/NCIP2 and similar protocols and APIs for simultaneous access and updates to patron and item records.
    *   The system must support the use of third-party backup software such as EMC NetWorker.
    *   MARC bibliographic and authority records must be importable and exportable, singly and in batch, to and from vendors including OCLC.
*   **Parallel Operation and Performance**
    *   The system must provide real-time processing (e.g., pull lists, live shelf reading).
    *   Searches and reports must be processable during open hours without disrupting other system functions.
    *   The system must allow multiple staff members and patrons to simultaneously access and update patron and item records.
    *   The system must provide record lock management, including identifying where records are in use and the ability to unlock records.
    *   The system must support server clustering for failover capability.
*   **Audit and Control Functions**
    *   Individual logins must allow for user-level preferences and an audit trail.
    *   The system must log data changes (e.g., record deletions) and provide "undo" functionality, ideally with revision control.
    *   The system must provide full visibility and control of user privileges to administrative staff.
    *   Administrators must control staff access to database tables and fields.
    *   The system must provide fine-grained permissions for running specific reports and ad hoc reports on specific data sets.
    *   Access to record numbers must be controlled at the user/group level.
    *   Read and write permissions to individual configuration files must be assignable to users and groups.
    *   The system must provide a single interface for reviewing and controlling scheduled tasks (e.g., staff-scheduled tasks, automated reports, imports/exports, software updates).
    *   The system must provide a server management console including software shutdown/startup and server shutdown/restart utilities.
    *   The system must provide a client management console displaying workstations and utilities for managing/killing client sessions.
    *   Alert thresholds for system monitoring must be configurable, with alerts sent via dashboards, email, and text messages to an unlimited number of recipients.
    *   The system must support administrator-programmable and user-programmable macros and/or keyboard shortcuts, centrally managed with restricted use/editing permissions.
*   **Quality Requirements**
    *   The system must ensure patron data is secure in all transfers.
    *   Record changes must be applied in a reasonable way, with prompts to warn when a record has been changed.
*   **Criticality of the Application**
    *   The System Administration Module facilitates the management of every aspect of the Integrated Library System, implying high criticality for overall ILS operation.
    *   The system must provide capability to perform live incremental and full backups of data and transaction logs, indicating high importance of data integrity.
*   **Security Considerations**
    *   Patron data must be secure in all transfers to and from the system.
    *   System administrative staff must have full visibility and control of user privileges.
    *   The system must provide access to root shell.
    *   User rights and privileges will be controlled through security groups and/or "roles".
*   **Physical/Mental Considerations**
    *   The system must be accessible with screen-reading software, screen-magnification software, and other software programs designed to increase accessibility.
*   **Data Management and Business Rule Limitations**
    *   The system must support restrictions based on business rules (e.g., deleting records in use).
    *   The system must provide customizable 'Rules of Suppression' for viewing records in staff and public interfaces.
    *   The system must allow creation and modification of requesting rules and loan rules based on various criteria (e.g., patron type, item status, location).
    *   The system must allow specification of default values, data validation, automatic formatting, and required status for any field.
    *   The system must support an unlimited number of record sets, with batch import/export, batch field updates, query limiting, and deletion with review/undo capabilities.

## 1.4 Definitions
[N/A]

# 2 References
## Compliance

The following documents contain requirements that are included by citation or are foundational to the System Administration Module's functionality and integration within the Integrated Library System.

*   **Title:** Specifications for Acquisitions and Serials Management Module
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: King County Library System
    *   Source: [N/A]
*   **Title:** Specifications for Circulation Module
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: King County Library System
    *   Source: [N/A]
*   **Title:** Specifications for Cataloging Module
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: King County Library System
    *   Source: [N/A]
*   **Title:** USMARC21 Standard
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: [N/A]
    *   Source: [N/A]
*   **Title:** EDIFACT Standard
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: [N/A]
    *   Source: [N/A]
*   **Title:** HTML Standard
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: [N/A]
    *   Source: [N/A]

## Guidance

The following documents contain information that provides context or background for the System Administration Module, but do not prescribe specific requirements.

*   **Title:** Process Flowcharts for System Administration at King County Library System
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: King County Library System
    *   Source: [N/A]

# 3 Requirements
[NULL]

## 3.1 Functions
The System Administration Module shall provide the following fundamental actions and capabilities:

### 3.1.1 System Core Operations and Management

*   The system shall operate on a fully relational, SQL-based database system, enabling the ability to run SQL queries against any table in the database and 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 operations such as updating pull lists, live shelf reading, and weeding.
*   The system shall support simultaneous access and updates to patron and item records by multiple staff members and patrons across various interfaces, including staff check-in/check-out terminals, self-checkout stations, SIP2/NCIP2 and similar protocols/APIs, and the OPAC.
*   The system shall apply record changes in a reasonable way, providing prompts to warn users when a record has been changed since it was displayed.
*   The system shall allow staff to identify where any patron or item record is currently in use, including its location, the user, and the date and time it was placed in use.
*   The system shall provide full access to all configuration files.
*   The system shall provide full access to all log files, allowing them to be reviewed without stopping the system. Logs can be enabled, disabled, and set to a specific retention threshold.
*   The system shall provide access to the root shell.

### 3.1.2 Monitoring 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 can create dashboards and grant access to selected users and groups.
*   The system shall provide full support for SNMP and monitor system resources, including disk space, CPU load, memory load, system processes, system interfaces, and ports. Alert thresholds shall be configurable, and alerts can be sent via administrative dashboards, email messages, and text messages to an unlimited number of recipients.
*   The system shall allow administrators to set thresholds on the length of time records are locked and provide a list of records in sustained use/locked condition for all record types. From the same console, administrators shall be able to unlock one or more records.
*   The system shall provide a dashboard of performance monitoring and management tools, identifying processes by process ID, owner username, IP address (if applicable), CPU utilization, memory utilization, and run time. Runaway processes shall be identified, and system status 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 information such as 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 (item, bibliographic, patron, etc.), and database utilization (size, processes running).
*   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, holds placed per hour, and holds paged per day. Indicators can be limited to a single branch or set to system-wide.
*   The system shall provide a single console with access to all configuration files, allowing read and write permissions to individual configuration files to be assigned to users and groups.
*   The system shall provide a dashboard for locating and viewing log files.

### 3.1.3 Configuration and Business Rules

*   The system shall support restrictions based on business rules, such as prohibiting the deletion of item records that are in checked-out status or bibliographic records with existing holds.
*   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 (OPAC) interfaces. Records may be visible to specific workgroups only, to all staff and patrons at specific locations, or to all staff and all patrons.
*   The system shall allow the creation and modification of requesting rules that determine whether a patron can place a hold on an item. These rules may evaluate patron type, current number of holds, current patron account balance, item type, item status, owning location code, and other criteria. Requesting rules shall also 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. These rules may evaluate patron type, current number of items checked out, current patron account balance, item type, item status, owning location code, check-out location code, and other criteria. Loan rules can access check-out location open/closed schedules in calculating due dates and specify whether a specific criterion may be overridden by staff with specific privileges or roles.
*   The system shall provide the ability to specify default values, data validation rules, automatic formatting, and required status for any field.

### 3.1.4 Data Management and Recovery

*   The system shall provide the capability to perform live incremental and full backups of data and transaction logs, supporting the use of third-party backup software.
*   The system shall log data changes (such as record deletions) and provide "undo" functionality. Ideally, the system shall provide revision control.
*   The system shall provide the ability to cluster servers for failover capability.

### 3.1.5 User and Access Management

*   The system shall support individual and shared staff login accounts. Access to modules shall be granted by "roles" or "privileges" that allow each account to access as many (or as few) modules as needed. Individual logins shall allow user-level preferences and an audit trail.
*   System administrative staff shall have full visibility and control of user privileges.
*   The system shall provide a dedicated interface for creating new staff accounts. The new staff account creation process shall provide configurable templates for account administrator use and granular privileges for account creation, modification, and deletion.
*   The system shall provide a dedicated interface for creating new patron accounts. The patron account creation process shall provide configurable templates for staff use, support field validation and required fields, and provide configurable defaults.

### 3.1.6 Client Management

*   Staff and group accounts shall be independent from workstations, and client installation shall not be tied to a specific location.
*   Client software installation and updates must be centrally managed, using standard or proprietary network management tools, allowing streaming updates from the server. The system shall provide the ability to specify specific clients to be updated and allow client software to be managed with VNC and Remote Desktop.
*   All client configuration files shall be server-based, and configurations can be exported and imported between clients.

### 3.1.7 Reporting and Queries

*   The system shall allow full customization of the layout and appearance of reports. Reports can be displayed, printed, emailed, or saved 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 can 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.
*   System administrators can create report templates that are available to front-line staff and can be run as is or modified to the staff person's particular needs.
*   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 generate reports for each record type (patron, bibliographic, item, order, invoice, etc.) showing the 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 support defining and selecting four types of printers: receipt printer, standard printer, label printer, and forms printer. All Windows printers shall be supported.
*   The system shall provide multiple print output options, including 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 allow selecting record fields and controlling the order of fields when printing.

### 3.1.8 Maintenance and Automation

*   The system shall support importing and exporting MARC bibliographic and authority records, singly and in batch, including all fields or selected fields, to and from vendors (e.g., OCLC). Imported records can overlay existing short or full bibliographic records. Imported batches can be maintained and manipulated as selection lists.
*   The system shall support an unlimited number of record sets, with the ability to import and export set members in batch. Record sets can be the basis for batch field updates, used as a limiting scope for queries, and used 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 support scheduling maintenance tasks, reports, and data exports. Jobs can be scheduled in sequence ("start job B when job A finishes") and can be modified or canceled at any time prior to starting.
*   Staff can be given permission to schedule tasks, reports, and data exports. System administration staff can view and manage jobs scheduled by other staff.
*   The system shall support administrator-programmable and user-programmable macros and/or keyboard shortcuts. Shortcut keys may be assigned to macros (e.g., 'Insert Field') or to text strings. Macros shall be centrally managed on the server, importable from and exportable to individual users, and restricted for use and/or editing through centrally-managed permissions.

### 3.1.9 Communication and Integration

*   The system shall provide the ability to access and edit email configuration, including a quick menu of common settings (such as masquerading, log retention, and bounce management).
*   The system shall support SMTP for email transport.
*   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.2 Performance requirements
The System Administration Module shall meet the following performance requirements:

*   **Static Numerical Requirements:**
    *   The system shall support a library system with 50 locations.
    *   The system shall handle 20 million circulations per year.
    *   The system shall handle purchasing and processing of over 500,000 items per year.
    *   The system shall support simultaneous access and updates by multiple staff members and patrons to patron and item records. The specific number of simultaneous users is not defined.

*   **Dynamic Numerical Requirements:**
    *   The system shall provide real-time processing for operations such as pull list updates, live shelf reading, and weeding. Specific timeframes for "real-time" are not defined.
    *   Searches and reports shall be processed during open hours without disrupting other system functions. Specific metrics for "disrupting" are not defined.
    *   Record changes shall be applied in a reasonable way, with prompts to warn when a record has been changed since it was displayed. Specific timeframes for "reasonable way" are not defined.

## 3.3 Usability requirements
The System Administration Module includes requirements to enhance usability, focusing on accessibility, efficiency, error prevention, and user satisfaction for library staff and system administrators.

*   **Accessibility:**
    *   The system shall be accessible with screen-reading software, screen-magnification software, and other software programs designed to increase accessibility (OE-5).
    *   The System Administration Module shall produce standards-compliant HTML (CO-2).

*   **Efficiency and Effectiveness:**
    *   The system shall provide an online, hierarchical, and cross-linked help system in HTML that describes and illustrates all system functions (UD-3).
    *   Record changes shall be applied in a reasonable way, with prompts to warn when a record has been changed since it was displayed (Req ID: 5323).
    *   Individual staff logins shall allow user-level preferences (Req ID: 2492).
    *   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 (Req ID: 6520).
    *   System status shall be represented by visual indicators (e.g., green and red lights) on the system performance dashboard (Req ID: 2467).
    *   The system shall provide access to and allow editing of email configuration, including a quick menu of common settings (Req ID: 6515).
    *   The system shall provide the ability to specify default values, data validation, automatic formatting, and required status for any field (Req ID: 5328).
    *   The staff account creation process shall provide configurable templates for account administrator use and granular privileges for account creation, modification, and deletion (Req ID: 2420).
    *   The patron account creation process shall provide configurable templates for staff use, support field validation and required fields, and provide configurable defaults (Req ID: 2419).
    *   The system shall support administrator-programmable and user-programmable macros and/or keyboard shortcuts (Req ID: 2220).
    *   The system shall provide a user-friendly interface for designing queries against all record types (Req ID: 5624).
    *   System administrators shall be able to create report templates that are available to front-line staff and can be run as is or modified to the staff person's particular needs (Req ID: 5607).

*   **Satisfaction:**
    *   User-level preferences for individual logins contribute to a personalized experience (Req ID: 2492).
    *   The ability for administrators to create custom dashboards and for staff to modify report templates enhances user control and satisfaction (Req ID: 6520, Req ID: 5607).
    *   Support for user-programmable macros and keyboard shortcuts allows for a more tailored and efficient workflow (Req ID: 2220).

The original requirements specification does not explicitly define measurable effectiveness, efficiency, or satisfaction criteria (e.g., specific task completion times or satisfaction scores).

## 3.5 Logical database requirements
The System Administration Module interacts with and manages various types of information stored in a fully relational, SQL-based database system.

### a) Types of Information

The system utilizes and manages the following types of information:

*   **Core Library Data:**
    *   Authority records
    *   Bibliographic records
    *   Order records
    *   Item records
    *   Hold/request records
    *   Patron records (including patron type, account balance, current number of holds, current number of items checked out)
    *   Staff accounts and user privileges
    *   Library branches and location codes
    *   Collections
    *   Circulation transactions
*   **System Configuration and Management Data:**
    *   Configuration files
    *   Log files
    *   Database backup information (last full, incremental)
    *   System performance data (disk space, CPU load, memory load, processes, interfaces, ports)
    *   Record creation and modification data
    *   Application status (reboots, upgrades, software version, transactions waiting, log file sizes, record counts by type, database utilization)
    *   Client workstation information (name, IP address, session status)
    *   Circulation key performance indicators (check-outs, check-ins, holds placed/paged)
    *   Email configuration settings
    *   Business rules, suppression rules, requesting rules, loan rules
    *   Record lock status and usage information
    *   Scheduled tasks, reports, and data exports
    *   Keyboard macros and shortcuts
    *   Client configurations
    *   Report layouts and appearance
    *   Query definitions
    *   Record counts (current, deleted, purged) for patron, bibliographic, item, order, and invoice record types.
    *   Data changes for "undo" functionality and revision control.

### b) Frequency of Use

*   The system supports real-time processing for critical operations such as pull lists, shelf reading, and weeding, implying frequent and up-to-date data access.
*   Patron and item records are subject to simultaneous access and updates by multiple staff members and patrons, indicating high concurrency requirements.
*   System performance, record modification, and circulation transaction data are continuously monitored and stored for current and historical display.

### c) Accessing Capabilities

*   The system shall operate on a fully relational, SQL-based database backend.
*   Users with appropriate privileges shall have the ability to run SQL queries against any table in the database.
*   The database shall be accessible as an ODBC source.
*   All data tables and data storage shall be fully accessible, subject to security controls.
*   The system supports simultaneous access and update of patron and item records.
*   Access to all configuration files and full access to all log files is provided, with log files reviewable without stopping the system.
*   MARC bibliographic and authority records can be imported and exported, singly and in batch, including all or selected fields.
*   Record set members can be imported and exported in batch.
*   A user-friendly interface is provided for designing queries against all record types and fields.
*   Reports can be displayed, printed, emailed, or saved to standard formats (e.g., CSV, Excel) and customizable formats.
*   Printing to a file on the server, FTP, email, or a printer is supported from any part of the application.

### d) Data Entities and Their Relationships

Key data entities include:

*   **Patron Records:** Linked to patron type, account balance, current holds, and checked-out items.
*   **Item Records:** Linked to item type, item status, owning location, and circulation status (e.g., checked-out, on hold).
*   **Bibliographic Records:** Linked to authority records and holds.
*   **Order Records:**
*   **Authority Records:**
*   **User Accounts:** Linked to security groups and roles for privilege management.
*   **Record Sets:** Dynamic collections of various record types.

Relationships are implicitly defined by business rules, such as items being checked out to patrons, holds placed on bibliographic records, and rules evaluating patron and item attributes for loan and requesting eligibility.

### e) Integrity Constraints

*   Record changes shall be applied in a reasonable way, with prompts to warn users when a record has been changed since it was displayed.
*   The system provides record lock management for patron and item records, allowing identification of records in use and the ability to unlock them. Thresholds for record lock duration can be set.
*   Restrictions are enforced on deleting item records that are in a checked-out status.
*   Restrictions are enforced on deleting bibliographic records with existing holds.
*   Customizable 'Rules of Suppression' define visibility of authority, bibliographic, order, and item records based on user type, workgroup, and location.
*   Requesting rules determine whether a patron can place a hold on an item, evaluating criteria such as patron type, current holds, account balance, item type, item status, and owning location.
*   Loan rules determine item check-out eligibility, loan periods, and renewal limits, evaluating criteria such as patron type, items checked out, account balance, item type, item status, and location codes.
*   The system allows specification of default values, data validation rules, automatic formatting, and required status for any field.
*   The system logs data changes (e.g., record deletions) and provides "undo" functionality, ideally including revision control.
*   For batch deletions of record sets, the system provides the ability to review prior to deletion, write errors to a log file, and undo one or more deletions.
*   Patron account creation includes field validation and required fields.

### f) Security

*   User rights and privileges are controlled through security groups and/or "roles" to manage access for individuals, workgroups, and staff groups.
*   Staff can view all patron and item fields, while patrons can access only selected fields, depending on assigned privileges.
*   Read and write permissions to individual configuration files can be assigned to specific users and groups.
*   Customizable 'Rules of Suppression' specify record visibility to patrons and staff based on workgroups and locations.
*   Patron data is secured in all transfers to and from the system.
*   System administrative staff have full visibility and control over user privileges.
*   Granular privileges are provided for staff account creation, modification, and deletion.
*   Permissions can be assigned to staff for scheduling and managing tasks, reports, and data exports.
*   Administrators control staff access to specific tables and fields when using the query tool.
*   Fine-grained permissions allow or disallow staff to run specific reports or ad hoc reports on specific data sets.
*   Access to record numbers (current, deleted, purged) is controlled at the user/group level.

### g) Data Retention Requirements

*   Log files can be enabled, disabled, and set to a specific retention threshold.
*   The system provides the capability to perform live incremental and full backups of data and transaction logs.
*   The system logs data changes and provides "undo" functionality, ideally with revision control, implying a need to retain historical data for recovery.

## 3.6 Design constraints
*   The System Administration Module shall use a fully relational, SQL-based database back-end.
    *   The system shall allow running SQL queries against any table in the database.
    *   The system shall allow accessing the database as an ODBC source.
    *   All data tables and data storage shall be fully accessible.
*   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 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, with access to modules granted by "roles" or "privileges."
*   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 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 shall support secure protocols, including SFTP, SSL, and SSH. SFTP shall be supported in both active and passive modes, configurable per vendor.

## 3.7 Software system attributes
#### a) Reliability
*   The system shall process searches and reports during open hours without disrupting other system functions.
*   Record changes shall be applied in a reasonable way, with prompts to warn when a record has been changed since it was displayed.
*   The system shall support restrictions based on business rules, such as prohibiting deletion of checked-out item records or bibliographic records with existing holds.
*   The system shall provide the ability to specify default values, data validation, automatic formatting, and required status for any field.
*   The system shall provide the capability to perform live incremental and full backups of data and transaction logs.
*   The system shall log data changes (e.g., record deletions) and provide "undo" functionality, ideally including revision control.
*   The system shall support server clustering for failover capability.
*   Scheduled jobs shall be able to be sequenced ("start job B when job A finishes") and modified or cancelled at any time prior to starting.

#### b) Availability
*   The system shall process searches and reports during open hours without disrupting other system functions.
*   The system shall provide full support for SNMP and monitoring of system resources (disk space, CPU load, memory load, processes, interfaces, ports), with configurable alert thresholds and alerts sent via dashboards, email, and text messages to an unlimited number of recipients.
*   The system shall provide a performance monitoring dashboard with visual indicators of system status (e.g., green and red lights).
*   The system shall provide a server management console including software shutdown/startup and server shutdown/restart utilities.
*   The system shall provide an administrative dashboard displaying information such as last full/incremental backup, last planned/unplanned system reboot, last software upgrade, current software version, transactions waiting to be processed, log-file size, current record counts by type, and database utilization.
*   The system shall provide capability to perform live incremental and full backups of data and transaction logs.
*   The system shall support server clustering for failover capability.

#### c) 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.
*   Access to modules shall be granted by use of "roles" or "privileges," and individual logins shall allow user-level preferences and an audit trail.
*   Log files shall be able to be enabled, disabled, and set to a specific retention threshold.
*   The system shall provide access to root shell.
*   Read and write permissions to individual configuration files shall be assignable to users and groups.
*   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, with SFTP supported in both active and passive modes, configurable per vendor.
*   The staff account creation process shall provide granular privileges for account creation, modification, and deletion.
*   System administration staff shall be able to view and manage jobs scheduled by other staff.
*   Macros shall be centrally managed on the server and able to be restricted for use and/or editing through centrally-managed permissions.

#### d) Maintainability
*   The system shall provide a development and training environment with the ability to migrate configurations to a production environment.
*   The system shall allow running SQL queries against any table in the database and accessing the database as an ODBC source, with all data tables and storage fully accessible.
*   Staff shall be able to identify where any patron or item record is in use (location, user, date and time placed).
*   System documentation shall be library-specific, follow standard formats, be web-based, indexed, organized by function, and easily searchable.
*   System upgrades and updates shall include written guidelines for updating servers and clients, and a list of new, changed, and removed features.
*   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, and enabled, disabled, or set to a specific retention threshold.
*   The system shall support creation of custom dashboards displaying current and historical data about system performance, record creation/modification, and circulation transactions.
*   The system shall provide full support for SNMP and monitoring of system resources.
*   The system shall allow setting thresholds on record lock duration and provide a list of records in sustained use/locked condition, with the ability to unlock records from the same console.
*   The system shall provide a performance monitoring dashboard identifying processes by ID, owner, IP, CPU/memory utilization, and run time, and identifying runaway processes.
*   The system shall provide a server management console including software/server shutdown/startup/restart utilities.
*   The system shall provide an administrative dashboard displaying key system and application status information.
*   The system shall provide a client management console displaying workstations running client software, their names and IP addresses, and utilities for managing and killing client sessions.
*   The system shall provide a circulation dashboard showing key performance indicators.
*   The system shall provide a single console with access to all configuration files.
*   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.
*   The system shall provide the ability to access and edit email configuration, including a quick menu of common settings.
*   The system shall support MARC bibliographic and authority record import/export, singly and in batch, with overlay capabilities.
*   The system shall support an unlimited number of record sets for batch field updates, queries, and deletions with review/undo capabilities.
*   The system shall provide a dedicated interface for creating new staff accounts with configurable templates and granular privileges.
*   The system shall provide a dedicated interface for creating new patron accounts with configurable templates, field validation, and defaults.
*   The system shall support scheduling of maintenance tasks, reports, and data exports.
*   The system shall support administrator-programmable and user-programmable macros and/or keyboard shortcuts, centrally managed, with import/export capabilities and restricted use/editing through permissions.
*   Client software installation and updates shall be centrally managed, allowing streaming updates from the server and targeting specific clients.
*   All client configuration files shall be server-based, and configurations shall be exportable and importable between clients.
*   The system shall provide a user-friendly interface for designing queries against all record types.
*   System administrators shall be able to create report templates for front-line staff.

#### e) Portability
*   The System Administration Module shall operate on a Linux or Solaris server.
*   The System Administration Module shall produce standards-compliant HTML.
*   Staff and group accounts shall be independent from workstations; client installation should not be tied to a specific location.
*   Client configuration files shall be server-based, and configurations shall be exportable and importable between clients.

## 3.8 Supporting information
This section provides additional background and contextual information to aid readers in understanding the requirements for the System Administration Module. The information presented here is for context and understanding and is not considered part of the formal requirements unless explicitly stated otherwise.

The requirements were developed specifically for the King County Library System, with the aim of replacing and enhancing the current capabilities of commercially available Integrated Library Systems (ILSes), as well as adding new functionality. While developed for KCLS, these requirements are believed to be suitable for many large, urban, multiple-branch, centralized library systems. This SRS presupposes the general data structures and functionality of a full-fledged ILS, focusing specifically on management activities. King County Library has previously published specifications for Acquisitions and Serials Management, Circulation, and Cataloging modules, with requirements for OPAC and web services currently under development. The current specification is focused on functional characteristics of System Administration, with data structures and user interfaces requiring further specification and development using an iterative, prototype-oriented software development methodology.

This SRS is intended for both library managers and staff who may contribute additional requirements or commentary, and for software project managers and developers who will implement the requirements. It is designed for high readability for a non-technical audience while providing sufficient specificity for software developers. It is assumed that software development will occur in a highly collaborative and iterative environment, providing end-users multiple opportunities to review prototypes and refine the user interface and software functionality. Readers are also assumed to have a general understanding of Library services and processes and do not require definitions of common Library terminology.

Where requirements include a reference to a process flowchart, these flowcharts generally indicate the current approach to System Administration at King County Library System. They should be considered to give contextual information rather than to prescribe or constrain new software development.

Sample input/output formats: [N/A]

Descriptions of cost analysis studies or results of user surveys: [N/A]

Special packaging instructions for the code and the media: [N/A]

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

## 4.6 Design constraints
[N/A]

## 4.7 Software system attributes
*   **Reliability and Availability**
    *   The system is required to provide capability for live incremental and full backups of data and transaction logs (Req ID: 6502), log data changes and provide "undo" functionality (Req ID: 6505), and support server clustering for failover capability (Req ID: 2462). It must provide real-time processing (Req ID: 5615) and allow searches and reports to be processed during open hours without disrupting other system functions (OE-1).
    *   *Verification Method:* [N/A]

*   **Security**
    *   The system must ensure patron data is secure in all transfers to and from the system (Req ID: 6510). System administrative staff shall have full visibility and control of user privileges (Req ID: 6509), with user rights and privileges controlled through security groups and/or roles (CO-4, Req ID: 2492). The system shall support secure protocols, including SFTP, SSL, and SSH (Req ID: 6511).
    *   *Verification Method:* [N/A]

*   **Maintainability**
    *   The system requires library-specific, web-based, indexed, organized by function, and easily searchable documentation (Req ID: 2428). System upgrades and updates must include written guidelines for updating servers and clients (Req ID: 2431). The system shall provide access to all configuration files (Req ID: 2479), log files (Req ID: 2474), and root shell (Req ID: 2470). Client software installation and updates must be centrally managed (Req ID: 6504). The system supports scheduling of maintenance tasks, reports, and data exports (Req ID: 6507, Req ID: 6508).
    *   *Verification Method:* [N/A]

*   **Portability**
    *   The system is required to operate on a Linux or Solaris server (OE-2) and be accessible through a web-browser or a Windows-compatible client (OE-3). If web-browser based, it shall be accessible through Microsoft Internet Explorer (v.6.0 and later) and Mozilla Firefox (v.2.0 and later) (OE-4). The System Administration Module shall produce standards-compliant HTML (CO-2).
    *   *Verification Method:* [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 interfaces 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
*   **HTML**: HyperText Markup Language
*   **ILS**: Integrated Library System
*   **IP**: Internet Protocol
*   **MARC**: Machine-Readable Cataloging
*   **NCIP2**: [N/A]
*   **ODBC**: Open Database Connectivity
*   **OCLC**: Online Computer Library Center
*   **OPAC**: Online Public Access Catalog
*   **SFTP**: SSH File Transfer Protocol
*   **SIP2**: [N/A]
*   **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**: US Machine-Readable Cataloging 21
*   **VNC**: Virtual Network Computing
