Library Requirements

by Ryan Lee

Documentation : Library Documentation : Library Requirements

I. Introduction

The following is a requirements document for the Library System for OpenACS 3.2.4. The Library System is somewhat narrower in scope than general application packages; this document should reflect that in its vision statement and general brevity.

II. Vision Statement

Most people own a couple books. If such people want to expand their literary explorations without spending much, borrowing from friends, particularly people with similar taste, is an excellent way to find more material. The Library System was conceived of to allow readers an online method of keeping track of their own collection and borrowing from other users.

An important aspect of the Library System is its increased benefit for users geographically close to one another. While borrowing books long-distance is not unheard of, it is somewhat impractial for the average person to ship and reship books. Thus communities using the Library System are more likely to be physical communities as well as virtual ones, such as collegiate campuses.

III. System Overview

The Library System consists of:

The borrowing and merging subsystems may be generalized to facilitate other media such as CDs and magazines.

IV. Use-cases and User-scenarios

The Library System is intended for the following classes of users, which may or may not overlap:


Initial System Installation

Andrew Admin decides his friends at college could use the Library System after a recent book-buying frenzy. After obtaining and unzipping the system, he runs the SQL script by Postgres and places files in their relevant folders. Upon restarting the server, the Library System is freshly installed and ready for use. Andrew Admin then configures the library system to use

Content Population

Joe and Jane User, registered on Andrew Admin's OpenACS site, are avid readers and begin to populate the Library System with entries from their own collection.

Content Management

Maddie Manager, designated by Andrew Admin to manage user-contributed content,

V. Related Links

VI.A Requirements: Data Model

VI.B Requirements: API

The API for APM v3 is explicitly a private API. However, it would be useful to obtain information from the APM through a procedural API. Implementing the API specified below is quite easy given that there are pages that already do all of the below in raw SQL.

VI.C Requirements: Security

Provisions will be made to assure that packages are securely identified.

VI.D Requirements: The User Interface

The user interface is a set of HTML pages that are used to drive the underlying API. It is restricted to site-wide administrators because the actions taken here can dramatically affect the state of the running ACS.

VI.E Requirements: The Developer's Interface

The intent of the developer's interface is to enable the developer to construct and maintain APM packages. It will be possible to disable the developer's interface for production sites to help reduce the chance of site failure; much of the functionality here can have cascading effects throughout the ACS and should not be used on a production site.

VI.F Requirements: The Site-Wide Administrator's Interface

The requirement of the administrator's interface is to enable the administrator to install, enable, upgrade, disable, deinstall, and delete packages.

VI.G Requirements: The Sub-Site Administrator's Interface

If the developer is in charge of creating packages and the administrator for installing them, then the sub-site administrator is responsible for configuring and enabling packages. In order for a package to be available for a sub-site it must be associated with the sub-site's type specification. This interface is part of the sub-site /admin interface.

VII. Revision History

Document Revision # Action Taken, Notes When? By Whom?
0.1 Creation 01/10/2001 Ryan Lee

ryanlee@mit.edu