# 1 Introduction
[NULL]

## 1.1 Purpose
The purpose of this document is to present an overall description and listing of the functionality of a Publications Management System (PMS). This document is intended for the customer(s) and suppliers of the system including designers, testers and the implementation unit.

## 1.2 Scope
The product, the Publications Management System (PMS), will manage a database with bibliographical information. It will support accessing this information via a command line interface and through a web browser.

The software will perform the following functions:
*   Manage a database of bibliographical information.
*   Store the entire text of a publication in PDF and PostScript formats.
*   Automatically retrieve bibliographical information (e.g., author, title) from the full text of a publication.
*   Allow manual correction of retrieved bibliographical information.
*   Manage author information, allowing the system to recognize that different name formats (e.g., ‘D. Vermeir’ and ‘Dirk Vermeir’) refer to the same person.
*   Support bulk updates, such as importing many publications at once.
*   Provide access to publication content, including full text and abstracts.
*   Implement access control based on user roles.

The application of the software is to provide a centralized system for managing academic publications for an institution. The objective is to streamline the process of storing, searching, and retrieving scholarly articles.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The PMS will rely on a database and a web server, which can be accessed by a web browser and by command line. The system is a standalone product but depends on the underlying database and web server infrastructure.

#### System interfaces
*   Database: The system contains an interface with a MySQL-Database.
*   Webserver: This server is responsible for the execution of the PMS, sending queries to the database, and generating the user interface.

#### User interfaces
*   Users can access the PMS from any operating system using a web browser that has a connection to the web server running the PMS.
*   The PMS must be accessible for users with Linux as an OS and using a text-based web browser.
*   Administrators can access the system by command line from within the VUB network.
*   If an error occurs during a request, the user will receive an error message stating the cause. The error will also be logged to notify administrators.
*   The web interface will comply with the W3C XHTML 1.0 Transitional standard.

#### Hardware interfaces
There are no specific hardware requirements for the users.

#### Software interfaces
The system will interface with the following required software:
*   A MySQL Database for data storage.
*   A web server for hosting the application.
*   The Ruby programming language (version 1.8 or later) as the execution environment.
*   A Linux-based operating system.

#### Communications interfaces
Communication between the web server and users will be via an HTTP connection using TCP/IP port 80.

#### Memory constraints
There is no specific limit on the usage of memory by the PMS. The publications themselves will have a maximum file size, which is to be determined.

#### Operations
*   A user must be logged into the PMS or connected to the VUB network to use the system's functionality.
*   Administrators have access to the server shell for command line operations.

#### Site adaptation requirements
The PMS will be easy to install on a Linux-based environment where Ruby 1.8 (or later) is installed.

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

### 1.3.2 Product functions
The PMS will provide functions based on a hierarchical user structure. Each user level inherits all functions of the preceding one. The user roles are:

*   **Guest**: A user not connected to the VUB network nor logged in. Can register, log in, validate an account, and retrieve a password.
*   **VUB-Network User**: A user connected to the VUB network but not logged in. Can perform basic and advanced searches for publications, order results, and export/download results.
*   **Member**: A logged-in user. Can change their own account details and log off.
*   **Publisher**: A logged-in user with publishing rights. Can upload publications (individually or in bulk) and edit their own publications.
*   **Moderator**: A logged-in user with moderation rights. Can manage user levels (Member to Publisher and vice-versa) within their department, manage group permissions, edit author information, and edit any publication within their department.
*   **Administrator**: A logged-in user with full system privileges. Has access to a control panel to manage all users and groups, and can edit all publications in the system.

### 1.3.3 User characteristics
The users of the PMS are expected to be academic personnel and students with various technical backgrounds. All users should have a basic knowledge of the internet.

### 1.3.4 Limitations
The PMS must be able to run on a Linux operating system, specifically the Wilma web server.

## 1.4 Definitions
*   **Customer**: The person, or persons, who pay for the product and usually (but not necessarily) decide the requirements.
*   **Supplier**: The person, or persons, who produce a product for a customer.
*   **User**: The person, or persons, who operate or interact directly with the product.

# 2 References
*   IEEE Std 830-1998, http://www.scribd.com/doc/2620639/IEEE-8301998.
*   Software Engineering Course, http://tinf2.vub.ac.be/~dvermeir/courses/software_engineering/projects/2007-2008/index.html.
*   W3C XHTML 1.0, http://www.w3.org/TR/xhtml1/.
*   Git, http://git.or.cz/.
*   IEEE, http://www.ieee.org/.
*   RDoc, http://rdoc.sourceforge.net/.
*   Software Engineering group 1, http://wilma.vub.ac.be/~se1_0708/.
*   VUB, http://www.vub.ac.be.
*   W3C, http://www.w3.org/.
*   SE1 Coding Conventions, http://wilma.vub.ac.be/~se1_0708/docs/coding_conventions/conventions.pdf.
*   UML, http://www.uml.org/.
*   SQAP, http://wilma.vub.ac.be/~se1_0708/docs/sqap/sqap.pdf.
*   STD, TBDstdlink.

# 3 Requirements
[NULL]

## 3.1 Functions
*   **Log in to the system from the internet**: Any user with internet access can access the login screen. A registered user can log in with their username and password.
*   **Log in to the system via the VUB-network**: A user on the VUB network can access a screen to either log in or start a search immediately without logging in.
*   **Register for an account**: A user can select the register function, fill in personal data (name, login name, email, university, department), and confirm. The system checks if the username already exists.
*   **Log off**: A logged-in user can select the logout function and will be directed to the system start page.
*   **Change password**: A registered user can request to change their password by providing their username and a new password.
*   **Search for publications**: A logged-in user or a VUB-network user can search for publications using criteria such as keyword, author, and period of publication. Advanced criteria include keywords and references.
*   **View the results of a Search**: The system will display a list of publications matching the search criteria, showing the title and main author for each result.
*   **View publication details**: A user can click on a publication in the search results to view detailed information, including title, authors, publication date, abstract, and cited references.
*   **View detailed information for multiple publications**: A user can select multiple publications from the search results to view their detailed information together.
*   **Download a single publication**: A user can download the full text of a publication from the search results screen or the detailed view screen.
*   **Download multiple publications**: A user can download the full text of all publications in a search result at once.
*   **Consult publication references**: A user can view the references cited in a publication from the search results screen or the detailed view screen.
*   **Consult references for multiple publications**: A user can view all references cited in all publications from a search result.
*   **Display the full text of a publication**: A user can view the full text of a publication within the system if it is available.
*   **View details of a reference**: If a cited reference is also in the system, a user can click on it to view its details.
*   **Export the references cited in a publication (BIB format)**: A user can export the references of a publication in BibTEX format.
*   **Export the references cited in a publication (RIS format)**: A user can export the references of a publication in RIS format.
*   **View authors**: A user can click on an author's name to view details about that author.
*   **Editing personal data**: A logged-in user can edit their personal data, such as password, university, and department.
*   **Access to your own publications**: A Publisher (or higher role) can directly access a list of all publications they have uploaded.
*   **Edit your own publications**: A Publisher (or higher role) can modify the information of publications they have uploaded.
*   **Upload publications**: A Publisher (or higher role) can upload a publication in a supported format (pdf, ps). The system will attempt to automatically retrieve bibliographic details, which the user can then confirm or edit.
*   **Search users**: A Moderator or Administrator can search for users in the system based on search criteria.
*   **Edit user settings**: A Moderator or Administrator can select a user from a search result and change their settings.
*   **Create User**: An Administrator can create a new user by providing details such as username, password, email, and group.
*   **Delete User**: An Administrator can delete an existing user from the system.
*   **Create Group**: An Administrator can create a new group.
*   **Search Group**: An Administrator can search for a group to view its details.
*   **Delete Group**: An Administrator can delete an existing group, provided it is empty.
*   **Edit group settings**: An Administrator can select a group and change its settings.
*   **Edit system configuration settings**: An Administrator can access a configuration panel to change system-wide settings.

## 3.2 Performance requirements
[N/A]

## 3.3 Usability requirements
*   The web interface shall be attractive, simple, and clear.
*   The web interface shall be designed to be fast and efficient, allowing users to complete tasks in the minimum number of pages and clicks.
*   All functions and options shall be available in the least amount of clicks possible, while maintaining a clear structure.
*   If an error occurs, the user shall receive a clear error message explaining the cause of the error.

## 3.5 Logical database requirements
*   All data, including static and dynamic information, statistics, publications, and administrator settings, will be stored in the database.
*   The database must be kept consistent at all times, with no pointers to deleted records and no redundant information.
*   The database must be capable of handling several concurrent requests via SQL statements.
*   A backup structure is required to save all data in case of server or disk problems.

## 3.6 Design constraints
*   The PMS web interface must conform to the W3C XHTML 1.0 Transitional standard.
*   The implementation must be object-oriented.
*   The implementation must be compliant with the Coding Conventions of SE1.
*   Design diagrams must be made following the UML standard.
*   The design of the PMS must be modular to simplify expansions and replacements.
*   The programming language used will be Ruby.
*   The code will be documented using RDoc.
*   Git will be used for configuration management.
*   The use of frameworks is not allowed.
*   Only free software can be used for the tools and for the end product.

## 3.7 Software system attributes
*   **Reliability**: The PMS should not experience software faults. A spiral development model with two iterations will be used to minimize bugs.
*   **Availability**: The PMS will be available at all times, except when the underlying Wilma server is unavailable. In case of a corrupted database, an Administrator should restore it from the last available backup. During downtime, the system should display an error message to visitors.
*   **Security**:
    *   Every user account is protected with a personal password.
    *   User passwords must be encrypted when submitted to the server and when stored in the database.
    *   Direct access to the data stored in the database is only allowed for Administrators using the CLI.
    *   The user level permissions for editing, deleting, and uploading publications must be strictly enforced.
*   **Maintainability**:
    *   The database should be maintained by Administrators.
    *   System-wide settings and user management should be maintained by Administrators.
    *   Department-level management can be performed by Moderators.
*   **Portability**: The PMS is developed to run on the Wilma (Linux-based) platform. It may be possible to relocate the PMS to a server with a different OS as long as all necessary software is available and adjustments are made.

## 3.8 Supporting information
### Apportioning of Requirements
The development will follow two iterations. Functions will be marked as:
*   **Critical (C)**: Needed for the first iteration.
*   **Sufficient (S)**: Needed for the second iteration to have an adequate end product.
*   **Optional (O)**: Implemented if there is enough time.

### Optional Functions
The following are possible future expansions of the PMS:
*   Support for additional formats (e.g., MS WORD).
*   Displaying a list of documents that refer to a given publication.
*   Automatic recognition that different name formats (e.g., ‘D. Vermeir’ and ‘Dirk Vermeir’) refer to the same author.
*   If a BibTEX file with only abstracts and URL fields is uploaded, the PMS could retrieve the full texts from those URLs.
*   Expansion of the system to manage audio and video files.

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

# 5 Appendices
[NULL]

## 5.1 Assumptions and dependencies
*   Users must have a web browser that supports W3C XHTML and a TCP/IP connection to the web server.
*   HTTP traffic must be possible on the network connection between the server and the client.
*   Command line users have access to the server shell and therefore have Administrator privileges.

## 5.2 Acronyms and abbreviations
*   **BibTEX**: A tool for formatting lists of references.
*   **Bulk Update**: Importing many publications or abstracts at once.
*   **CLI**: Command Line Interface.
*   **Git**: A distributed revision control system.
*   **HTML**: Hypertext Markup Language.
*   **HTTP**: Hypertext Transfer Protocol.
*   **IEEE**: Institute of Electrical and Electronics Engineers.
*   **OS**: Operating System.
*   **PDF**: Portable Document Format.
*   **PMS**: Publication Management System.
*   **PS**: Postscript.
*   **RDoc**: Document Generator for Ruby Source.
*   **RIS**: A tagged format for expressing bibliographic citations.
*   **Ruby**: A reflective, dynamic, object-oriented programming language.
*   **SCMP**: Software Configuration Management Plan.
*   **SE1**: Software Engineering group 1.
*   **SQAP**: Software Quality Assurance Plan.
*   **SRS**: Software Requirements Specification.
*   **STD**: Software Test Plan.
*   **TBD**: To Be Determined.
*   **UML**: Unified Modelling Language.
*   **VUB**: Free University of Brussels.
*   **W3C**: World Wide Web Consortium.
*   **Wilma**: A multifunctional linux server for students at the VUB.
