# 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 core component of an Integrated Library System (ILS).

The System Administration Module will facilitate the comprehensive management of every aspect of the Integrated Library System. This includes, but is not limited to, the following activities:
*   Configuring the ILS to enable and support features and processes necessary for the management of 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 (APIs).
*   Managing user and group accounts and their associated privileges.
*   Managing server and client software installation, upgrades, and updates.
*   Performing backups of databases, configuration files, log files, and other critical data.

The application of this software is to replace and enhance the current capabilities of commercially available ILSes, as well as to introduce new functionality specifically tailored for large, urban, multiple-branch, centralized library systems. The primary objective is to provide robust tools for system administrators and library managers to efficiently oversee and maintain the ILS environment. This specification focuses exclusively on the functional characteristics related to system administration activities, presupposing the general data structures and functionality of a full-fledged ILS.

## 1.3 Product overview
[NULL]

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

The System Administration Module interacts with other existing and developing modules of the ILS, including:
*   Acquisitions and Serials Management modules
*   Circulation module
*   Cataloging module
*   Online Public Access Catalog (OPAC) and web services (currently under development)

#### System interfaces
The system provides interfaces for:
*   Controlling user rights and privileges through security groups and/or roles.
*   Simultaneous access and updates to patron and item records via SIP2/NCIP2 and similar protocols and APIs.
*   Monitoring system resources (disk space, CPU load, memory load, system processes, interfaces, and ports) with full support for SNMP.
*   Managing client workstations through a dedicated client management console.

#### User interfaces
The System Administration Module is accessible through:
*   A web-browser (Microsoft Internet Explorer v.6.0 and later, Mozilla Firefox v.2.0 and later).
*   A Windows-compatible client.
The system shall produce standards-compliant HTML. It is also designed to be accessible with screen-reading software, screen-magnification software, and other accessibility software.

#### Hardware interfaces
The System Administration Module shall operate on a Linux or Solaris server. It also supports the ability to cluster servers for failover capability.

#### Software interfaces
The System Administration Module relies on the data structures and functionality of an enterprise-level Library Automation System, including its Acquisitions and Cataloging modules.
*   **Database:** The module uses a fully relational, SQL-based database back-end. The database is accessible as an ODBC source, and all data tables and storage are fully accessible.
*   **Other ILS Modules:** It interacts with a patron interface, also known as an Online Public Access Catalog (OPAC).
*   **Backup Software:** The system supports the use of third-party backup software, such as EMC NetWorker.
*   **Record Management:** It supports MARC bibliographic and authority record import and export to and from vendors, including OCLC.
*   **Client Management:** Client software updates can be managed using standard or proprietary network management tools, as well as VNC and Remote Desktop.

#### Communications interfaces
The System Administration Module interfaces with:
*   Various vendor websites via published APIs and/or automated transfer of standard-format data files (e.g., USMARC21, EDIFACT).
*   Secure protocols, including SFTP (in both active and passive modes, configurable per vendor), SSL, and SSH.
*   SMTP for email transport.
Patron data is secured in all transfers to and from the system. The system also supports SIP2/NCIP2 and similar protocols and APIs for simultaneous record access and updates.

#### Memory constraints
[N/A]

#### Operations
The System Administration Module supports the following operations:
*   **Environment Management:** Provides a development and training environment with the ability to migrate configurations to a production environment.
*   **Centralized Processing:** System Administration processes are consolidated at a central location, accepting input and providing services to multiple locations.
*   **File Access:** Provides access to all configuration files and full access to all log files. Log files can be reviewed without stopping the system and can be enabled, disabled, and set to specific retention thresholds. The system also provides access to the root shell.
*   **System Control:** Includes a server management console with utilities for software shutdown/startup and server shutdown/restart. A client management console displays workstations running client software and provides utilities for managing and killing client sessions.
*   **Data Management:** Provides capability to perform live incremental and full backups of data and transaction logs. It logs data changes (e.g., record deletions) and provides "undo" functionality, ideally with revision control.
*   **Job Scheduling:** Supports scheduling of maintenance tasks, reports, and data exports.
*   **Client Software Management:** Client software installation and updates are centrally managed.

#### Site adaptation requirements
The System Administration Module is designed to support the needs of a large, multiple-branch library system, specifically one with 50 locations, 20 million circulations, and purchasing/processing over 500,000 items per year. System Administration processes are consolidated at a central location, accepting input and providing services to multiple locations.

#### Interfaces with services
[N/A]

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

*   **ILS Configuration:** Enable and support the configuration of the Integrated Library System (ILS) for managing library branches, patrons, collections, and circulation transactions.
*   **System Performance Management:** Monitor, troubleshoot, and control the performance of servers, databases, applications, services, ports, and application programming interfaces (APIs).
*   **User and Access Management:** Manage user and group accounts, including the assignment and control of privileges.
*   **Software Deployment and Maintenance:** Manage the installation, upgrades, and updates of server and client software.
*   **Data Backup and Recovery:** Facilitate the backup of databases, configuration files, and log files.

### 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 will limit the supplier's options for the System Administration Module:

*   **Integration and Dependencies:**
    *   The System Administration Module is part of an enterprise-level Library Automation System and relies on its general data structures and functionality, including existing 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, also known as an Online Public Access Catalog (OPAC).
*   **Hardware and Operating Environment:**
    *   The system must operate on a Linux or Solaris server.
    *   The system must support a library system with 50 locations, 20 million circulations, and purchasing and processing over 500,000 items per year.
    *   The system must be accessible through a web-browser (Microsoft Internet Explorer v.6.0 and later, and Mozilla Firefox v.2.0 and later) or a Windows-compatible client.
*   **Design and Implementation Constraints:**
    *   The module must use a fully relational, SQL-based database back-end, allowing SQL queries against any table and access as an ODBC source, with all data tables and data storage fully accessible.
    *   The module must produce standards-compliant HTML.
    *   User rights and privileges must be controlled through security groups and/or "roles" that allow access control for individuals, workgroups, and arbitrary staff groups.
    *   The system must provide a development and training environment with the ability to migrate configurations to a production environment.
*   **Performance and Concurrency:**
    *   The system must provide real-time processing.
    *   Searches and reports must be processed 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 set thresholds on lock duration and unlock records.
*   **Security and Audit:**
    *   Patron data must be secure in all transfers to and from the system.
    *   Individual staff logins must allow for an audit trail.
    *   The system must log data changes (such as record deletions) and provide "undo" functionality, ideally with revision control.
    *   The system must support secure protocols, including SFTP (in both active and passive modes, configurable per vendor), SSL, and SSH.
*   **Accessibility:**
    *   The system must be accessible with screen-reading software, screen-magnification software, and other software programs designed to increase accessibility.
*   **Client Management:**
    *   Staff and group accounts must be independent from workstations; client installation should not be tied to a specific location.
    *   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 configurations exportable and importable between clients.
*   **Protocol Support:**
    *   The system must support SMTP for email transport.
*   **Printer Support:**
    *   The system must support defining and selecting four types of printers (receipt, standard, label, and forms printer), and all Windows printers must be supported.

## 1.4 Definitions
[N/A]

# 2 References
## Compliance

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

## Guidance

*   **Process Flowcharts for System Administration**
    *   Report Number: [N/A]
    *   Date: [N/A]
    *   Publishing Organization: King County Library System
    *   Source: [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.
*   The system shall ensure all data tables and data storage are fully accessible.
*   The system shall provide real-time processing, ensuring data such as pull lists are up to date at the time of viewing or printing, and supporting live shelf reading and weeding.
*   The system shall allow multiple staff members and patrons to simultaneously access and update patron and item records across various interfaces (staff check-in/check-out terminals, self check-out stations, SIP2/NCIP2, OPAC).
*   The system shall apply record changes reasonably and provide 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 in use (location, user, date, and time placed).
*   The system shall support individual and shared staff login accounts.
*   The system shall grant access to modules based on "roles" or "privileges" assigned to each account.
*   The system shall support user-level preferences and an audit trail for individual logins.
*   The system shall provide library-specific documentation that follows standard formats for technical documentation.
*   The system documentation shall be specific to the particular version of the software in use.
*   The system documentation shall be web-based, indexed, organized by function, and easily searchable.
*   The system shall include written guidelines for updating servers and clients as part of system upgrades and updates.
*   The system upgrade guidelines shall include 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.
*   The system shall allow log files to be reviewed without stopping the system.
*   The system shall allow logs 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.
*   The system shall support monitoring of system resources, including disk space, CPU load, memory load, system processes, system interfaces, and ports.
*   The system shall allow alert thresholds to be configurable.
*   The system shall send alerts via administrative dashboards, email messages, and text messages.
*   The system shall send alerts to an unlimited number of recipients via any or all alert methods.
*   The system shall allow setting thresholds on the length of time records are locked.
*   The system shall provide a list of records in sustained use/locked condition for all record types.
*   The system shall allow unlocking one or more records from the same console.
*   The system shall provide a dashboard of performance monitoring and management tools.
*   The system shall identify processes with their process ID, owner username, IP address (if applicable), CPU utilization, memory utilization, and run time.
*   The system shall identify runaway processes.
*   The system status shall be represented by visual indicators (e.g., green and red lights).
*   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:
    *   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.).
    *   Database utilization (size, processes running).
*   The system shall provide a management console displaying workstations running client software, including workstation name and IP address.
*   The system shall provide 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.
*   The circulation 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.
*   The system shall allow read and write permission to individual configuration files to 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 allow access and editing of 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.

### 3.1.3 Business Rules Management
*   The system shall support restrictions based on business rules (e.g., restrictions on deleting item records that are in checked-out status, or restrictions on deleting 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.
*   The system shall allow records to 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 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, owning location code, and other criteria.
*   Requesting rules shall specify whether staff with specific privileges or roles can override specific criteria.
*   The system shall allow 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, 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 shall access check-out location open/closed schedules in calculating due dates.
*   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 default values, data validation, automatic formatting, and required status for any field.

### 3.1.4 Data Recovery Functions
*   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 such as EMC NetWorker.
*   The system shall log data changes (such as record deletions) and provide "undo" functionality.
*   The system shall ideally provide revision control.
*   The system shall provide the ability to cluster servers for failover capability.

### 3.1.5 Security Functions
*   The system shall ensure patron data is 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 Functions
*   The system shall allow MARC bibliographic and authority records to be imported and exported, singly and in batch, including all fields or selected fields, to and from vendors (e.g., OCLC).
*   Imported records shall be able to overlay existing short or full bibliographic records.
*   Imported batches shall be able to be maintained and manipulated as selection lists.
*   The system shall support an unlimited number of record sets.
*   The system shall provide the ability to import and export record set members in batch.
*   Record sets can be the basis for batch field updates.
*   Record sets can be used as a limiting scope for queries.
*   Record sets can be 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 provide a dedicated interface for creating new staff accounts.
*   The new staff account creation process shall provide configurable templates for account administrator use.
*   The new staff account creation process shall provide 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.
*   The patron account creation process shall support field validation and required fields.
*   The patron account creation process shall provide configurable defaults.
*   The system shall support scheduling of maintenance tasks, reports, and data exports.
*   Jobs can be scheduled in sequence ("start job B when job A finishes").
*   Jobs can be modified or cancelled 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.
*   Macros can be imported from and exported to individual users.
*   Macros can be restricted for use and/or editing through centrally-managed permissions.

### 3.1.7 Client Management Functions
*   Staff and group accounts shall be independent from workstations.
*   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.
*   The system shall allow streaming updates from the server to clients.
*   The system shall provide the ability to specify specific clients to be updated.
*   Client software can be managed with VNC and Remote Desktop.
*   All client configuration files shall be server-based.
*   Configurations can be exported and imported between clients.

### 3.1.8 Queries and Reports Functions
*   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 picklists 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 queries.
*   System administrators shall be able to create report templates that are available to front-line staff.
*   Report templates 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 report for each record type (patron, bibliographic, item, order, invoice, etc.): 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 multiple print output options, including printing 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 Administration Module shall meet the following performance requirements:

*   **Static Numerical Requirements:**
    *   The system shall support a library system with 50 locations.
    *   The system shall support 20 million circulations per year.
    *   The system shall support purchasing and processing over 500,000 items per year.

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

## 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
### a) Types of information used by various functions
The System Administration Module uses and manages a wide array of information types, including:

*   **Core Library Records:** Authority records, bibliographic records, order records, item records, hold/request records, patron records, and invoice records.
*   **System Management Data:**
    *   Configuration files for the Integrated Library System (ILS) and its clients.
    *   Log files and transaction logs.
    *   System performance data (e.g., disk space, CPU load, memory load, system processes, interfaces, ports).
    *   Application performance data (e.g., database utilization, transactions waiting to be processed, record counts by type).
    *   Circulation transaction data (e.g., check-outs, check-ins, holds placed/paged).
    *   Historical data related to system performance, record creation, and modification.
*   **User and Security Data:**
    *   User and group accounts, including individual and shared staff login accounts.
    *   User privileges, roles, and security groups for access control.
    *   User-level preferences.
    *   Audit trails for individual logins.
*   **Business Rule Data:**
    *   Business rules for restrictions (e.g., on deleting records).
    *   Suppression rules for record visibility.
    *   Requesting rules for placing holds.
    *   Loan rules for check-out, loan periods, and renewals.
*   **Maintenance and Automation Data:**
    *   Record sets for batch operations.
    *   Scheduled tasks, reports, and data exports.
    *   Keyboard macros and shortcuts.
    *   Email configuration settings.
    *   Report templates.

### b) Frequency of use
The system is designed for high-frequency, real-time data access and processing:

*   The system provides real-time processing for operations such as updating pull lists, live shelf reading, and weeding.
*   Multiple staff members and patrons can simultaneously access and update patron and item records.
*   Searches and reports are expected to be processed during open hours without disrupting other system functions.
*   Live incremental and full backups of data and transaction logs are supported.
*   Dashboards display current and historical data about system performance, record creation and modification, and circulation transactions.

### c) Accessing capabilities
The system provides extensive data accessing capabilities:

*   The system runs on a fully relational, SQL-based database system.
*   Ability to run SQL queries against any table in the database.
*   Ability to access the database as an ODBC source.
*   All data tables and data storage are fully accessible.
*   A user-friendly interface is provided for designing queries against all record types, allowing staff to select fields, values from picklists, regular expressions, and Boolean operators.
*   Full access to all configuration files and log files is provided, including the ability to review log files without stopping the system.
*   MARC bibliographic and authority records can be imported and exported, singly and in batch, including selected fields, to and from vendors.
*   Record sets support batch import and export of members.
*   Client configuration files can be exported and imported between clients.
*   Administrator-programmable and user-programmable macros can be imported from and exported to individual users.
*   Ability to access and edit email configuration settings.

### d) Data entities and their relationships
The system manages various data entities, including:

*   **Primary Entities:** Patron, bibliographic, item, order, authority, hold/request, and invoice records.
*   **Supporting Entities:** Staff accounts, user accounts, security groups, roles, business rules, suppression rules, requesting rules, loan rules, configuration files, log files, record sets, report templates, keyboard macros, and client configurations.

The SRS presupposes the general data structures and functionality of a full-fledged Integrated Library System (ILS). Complete data specifications for authority records, bibliographic records, order records, item records, hold/request records, and other records maintained or accessed by the System Administration Module are to be provided by the software developer. Explicit relationships between these entities are not detailed in this specification but are implied by the functional requirements (e.g., items are associated with patrons for circulation, holds are placed on items).

### e) Integrity constraints
The system enforces several integrity constraints:

*   Record changes are applied in a reasonable way, with prompts to warn when a record has been changed since it was displayed.
*   Ability to set thresholds on the length of time records are locked.
*   Restrictions are supported based on business rules, such as prohibiting the deletion of item records that are in checked-out status or bibliographic records with existing holds.
*   Ability to specify default values, data validation rules, automatic formatting, and required status for any field.
*   Imported MARC records can overlay existing short or full bibliographic records.
*   Deletion of records via record sets includes the ability to review prior to deletion, write errors to a log file, and undo one or more deletions.
*   Patron account creation processes support field validation and required fields.

### f) Security
Data security and access control are critical:

*   User rights and privileges are controlled through security groups and/or "roles" that allow access control for individuals, workgroups, and arbitrary staff groups.
*   Depending on assigned privileges, staff can view all patron and item fields, while patrons can access only selected fields.
*   System administrative staff has full visibility and control of user privileges.
*   Patron data is secure in all transfers to and from the system.
*   Read and write permissions to individual configuration files can be assigned to users and groups.
*   Customizable 'Rules of Suppression' specify whether patrons and staff can view authority, bibliographic, order, and item records in staff and public (OPAC) interfaces.
*   Requesting rules and loan rules specify whether staff with specific privileges or roles can override specific criteria.
*   Staff account creation provides granular privileges for account creation, modification, and deletion.
*   Permissions can be granted to staff to schedule tasks, reports, and data exports, with system administration staff able to view and manage jobs scheduled by others.
*   Keyboard macros can be restricted for use and/or editing through centrally-managed permissions.
*   Administrators control staff access to tables and fields when designing queries.
*   Fine-grained permissions allow or disallow staff to run specific reports and/or ad hoc reports on specific sets of data.
*   Access to record numbers (for patron, bibliographic, item, order, invoice, etc.) 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 logs data changes (such as record deletions) and provides "undo" functionality, ideally including revision control, implying retention of historical data for recovery and auditing purposes.

## 3.6 Design constraints
The system design is subject to the following constraints:

*   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 Administration Module shall operate on a Linux or Solaris server.
*   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 shall interface with a variety of vendor websites, via published APIs and/or automated transfer of standard-format data files (e.g., USMARC21, EDIFACT).

## 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
**a) Reliability**
*   **Verification of System Performance under Load:** Performance and load testing will be conducted to ensure the system supports the specified scale (50 locations, 20 million circulations, processing over 500,000 items per year) and that searches and reports can be processed during open hours without disrupting other system functions (OE-1).
*   **Verification of System Backup:** Functional testing will confirm the capability to perform live incremental and full backups of data and transaction logs, including support for third-party backup software (Req ID: 6502).
*   **Verification of Data Rollback:** Functional testing will confirm the logging of data changes and the "undo" functionality (Req ID: 6505).
*   **Verification of Failover Capability:** Failover testing will be conducted to ensure the ability to cluster servers for failover capability (Req ID: 2462).

**b) Availability**
*   **Verification of Continuous Operation:** Performance and load testing will confirm that searches and reports can be processed during open hours without disrupting other system functions (OE-1).
*   **Verification of System Monitoring:** Functional testing will be performed on SNMP support and the monitoring of system resources (disk space, CPU load, memory load, system processes, interfaces, ports). Alert thresholds and notification mechanisms (dashboards, email, text messages) will be tested for configurability and delivery to multiple recipients (Req ID: 6501).
*   **Verification of Server Clustering:** Failover testing will confirm the ability to cluster servers for high availability (Req ID: 2462).

**c) Security**
*   **Verification of User Rights and Privileges:** An access control matrix will be used to test that user rights and privileges are controlled through security groups and roles, allowing granular access to modules and functions (CO-4, Req ID: 2492, Req ID: 6509).
*   **Verification of Patron Data Security:** Penetration testing and data transfer interception analysis will be conducted to ensure patron data is secure in all transfers to and from the system (Req ID: 6510).
*   **Verification of Secure Protocol Support:** Protocol compliance testing will confirm support for SFTP (active and passive modes), SSL, and SSH (Req ID: 6511).
*   **Verification of Data Access Control:** Functional testing will verify that staff and patrons can only access selected fields based on assigned privileges (Req ID: 5323) and that customizable 'Rules of Suppression' correctly control visibility of records in staff and public interfaces (Req ID: 5278).
*   **Verification of Business Rule Overrides:** Functional testing will confirm that staff with specific privileges or roles can override specific criteria in requesting and loan rules (Req ID: 5190, Req ID: 5057).
*   **Verification of Configuration File Access Control:** Functional testing will confirm that read and write permissions to individual configuration files can be assigned to users and groups (Req ID: 6517).
*   **Verification of Report Permissions:** Functional testing will confirm fine-grained permissions to allow or disallow staff to run specific reports and/or ad hoc reports on specific sets of data (Req ID: 5617).
*   **Verification of Record Number Access Control:** Functional testing will confirm that access to record numbers is controlled at the user/group level (Req ID: 2465).

**d) Maintainability**
*   **Verification of System Documentation:** Documentation review will be conducted to ensure documentation is library-specific, follows standard formats, is web-based, indexed, organized by function, and easily searchable (Req ID: 2428).
*   **Verification of System Upgrade Guidelines:** Review of written guidelines for server and client updates will be performed, including verification of lists of new, changed, and removed features (Req ID: 2431).
*   **Verification of Configuration and Log File Access:** Functional testing will confirm access to all configuration files (Req ID: 2479) and full access to all log files, including the ability to review logs without stopping the system, and to enable, disable, and set retention thresholds for logs (Req ID: 2474).
*   **Verification of Root Shell Access:** Functional testing will confirm access to the root shell (Req ID: 2470).
*   **Verification of Centralized Client Management:** Functional testing will confirm the ability to centrally manage client software installation and updates, including streaming updates, specifying specific clients, and management via VNC and Remote Desktop (Req ID: 6504).

**e) Portability**
*   **Verification of Operating System Compatibility:** Installation and functional testing will be performed on both Linux and Solaris servers to confirm system operation (OE-2).
*   **Verification of Database Backend:** Database schema review and functional testing will confirm the use of a fully relational database back-end and the ability to run SQL queries and access the database as an ODBC source (CO-1, Req ID: 6512).
*   **Verification of Standards-Compliant HTML:** Automated validation tools and browser compatibility testing (Microsoft Internet Explorer v.6.0+, Mozilla Firefox v.2.0+) will be used to confirm the production of standards-compliant HTML (CO-2, OE-4).
*   **Verification of Client Accessibility:** Functional testing with screen-reading software, screen-magnification software, and other accessibility programs will be conducted to ensure accessibility (OE-5).

# 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
