## 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 customers and suppliers of the system, including designers, testers, and the implementation unit.

## 1.2 Scope
The software product to be produced is the Publications Management System (PMS).

The PMS will perform the following functions:
*   Manage a database of bibliographical information.
*   Store the full text of publications in PDF and PostScript formats.
*   Automatically retrieve bibliographical information, such as author and title, from the text of a publication.
*   Allow users to manually correct automatically retrieved information if it is incorrect or insufficient.
*   Manage author identities, allowing users to consolidate different name variations (e.g., ‘D. Vermeir’ and ‘Dirk Vermeir’) for the same individual.
*   Support bulk updates to import multiple publications at once.
*   Provide access to publication content, including full text and abstracts, where available.
*   Enforce access control based on user roles.
*   Be accessible via a command-line interface and a web browser.

The application of the software is to manage academic publications. [N/A]

### 1.3.1 Product perspective
The Publications Management System (PMS) will rely on a database and a web server. It can be accessed by a web browser and by a command line interface.

#### 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 OS using a web browser that has a connection to the web server running the PMS. The PMS should explicitly 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.

There are no specific hardware requirements for the users.

If an error occurs during a request, the user will receive an error message stating the cause of the error. The error will also be logged in the PMS to notify the Administrator(s).

The PMS web interface will comply with the W3C XHTML 1.0 Transitional standard.

#### Hardware interfaces
[N/A]

#### Software interfaces
The PMS requires the following software:
*   A MySQL Database.
*   A web server.
*   Ruby version 1.8 or later.
*   A Linux-based operating system.

#### Communications interfaces
Communication between the PMS webserver 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 has to be logged into the PMS or connected to the VUB-network to be able to use the functionality of the PMS. A backup structure is required to save all data in case of server or disk problems.

#### 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 Publications Management System (PMS) will provide functions based on a hierarchical user structure. Each user role in the hierarchy inherits all the functions of the preceding one. The user roles are:

*   Guest
*   VUB-Network User
*   Member
*   Publisher
*   Moderator
*   Administrator

The major functions available to each user role are summarized below.

*   **Guest:** An anonymous user not connected to the VUB network can:
    *   Register for a new user account.
    *   Log into an existing account.
    *   Validate a new account via email.
    *   Retrieve a forgotten password.

*   **VUB-Network User:** A user connected to the VUB network but not logged in can perform all Guest functions, and can also:
    *   Search for publications using basic and advanced criteria.
    *   View, order, and download search results.
    *   Export publication data.
    *   Search for similar publications based on authors or institute.

*   **Member:** A logged-in user can perform all VUB-Network User functions, and can also:
    *   Change their own account information.
    *   Request an account upgrade.
    *   Log out of the system.

*   **Publisher:** A logged-in user with publishing rights can perform all Member functions, and can also:
    *   Upload single or multiple publications (bulk upload).
    *   Edit their own uploaded publications.

*   **Moderator:** A user with departmental management rights can perform all Publisher functions, and can also:
    *   Manage user levels and group permissions within their department.
    *   Edit author information.
    *   Edit any publication belonging to their department.

*   **Administrator:** A user with full system control can perform all Moderator functions, and can also:
    *   Access a system control panel.
    *   Create, delete, and manage any user account or group.
    *   Change the user level of any user.
    *   Edit any publication in the system.

Future expansions may include support for more document formats, automatic retrieval of full-text articles from URLs, and automatic disambiguation of author and institute names.

### 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.

Command line users are assumed to have access to the server shell and will have Administrator privileges, implying a higher level of technical expertise.

### 1.3.4 Limitations
The system must be developed using the Ruby programming language without the use of frameworks. Only free software can be used for the tools and the end product. The system must be able to run on a Linux-based environment, specifically the Wilma web server.

The design of the system must be modular and object-oriented. All design diagrams must follow the UML standard. The web interface must comply with the W3C XHTML 1.0 Transitional standard.

User accounts must be protected with personal passwords that are encrypted during submission and storage. Direct access to the database is only allowed for Administrators using the Command Line Interface. The system's availability is dependent on the availability of 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.
*   **BibTEX:** A tool for formatting lists of references, typically used with the LATEX document preparation system.
*   **Bulk Update:** Importing many publications or abstracts at once (e.g., through BibTeX files).
*   **RIS:** A tagged file format for expressing bibliographic citations.
*   **Wilma:** A multifunctional linux server for the students of the faculty of sciences at the VUB.

# 2 References
*   IEEE Std 830-1998. Source: http://www.scribd.com/doc/2620639/IEEE-8301998
*   Course Software Engineering, Free University of Brussels. Source: http://tinf2.vub.ac.be/~dvermeir/courses/software_engineering/projects/2007-2008/index.html
*   W3C XHTML 1.0 Standard. Source: http://www.w3.org/TR/xhtml1/
*   Git. Source: http://git.or.cz/
*   Institute of Electrical and Electronics Engineers (IEEE). Source: http://www.ieee.org/
*   RDoc - Document Generator for Ruby Source. Source: http://rdoc.sourceforge.net/
*   Software Engineering group 1 (SE1). Source: http://wilma.vub.ac.be/~se1_0708/
*   Free University of Brussels (VUB). Source: http://www.vub.ac.be
*   World Wide Web Consortium (W3C). Source: http://www.w3.org/
*   Coding Conventions of SE1. Source: http://wilma.vub.ac.be/~se1_0708/docs/coding_conventions/conventions.pdf
*   Unified Modelling Language (UML). Source: http://www.uml.org/
*   Software Quality Assurance Plan (SQAP). Source: http://wilma.vub.ac.be/~se1_0708/docs/sqap/sqap.pdf
*   Software Test Plan (STD). Source: To Be Determined.

## 3.1 Functions

### 3.1.1 User Account Management

*   **Register for an account**
    *   Any user can select the register function.
    *   The user must provide their first and last name, a username, a password, and a valid email address. They may also provide their university and department.
    *   The system shall check if the chosen username already exists.
    *   Upon confirmation, the system sends a validation email to the provided address and notifies the Administrator.

*   **Validate a new account**
    *   To complete the registration process, the user must validate their account via a link sent to their email address.

*   **Log in**
    *   A registered user can log in by providing their username and password.
    *   Users accessing the system from within the VUB network are recognized by their IP address and can perform searches without logging in.

*   **Log off**
    *   A logged-in user can select the logoff function.
    *   If the user is connected to the VUB network, they are redirected to the search page. Otherwise, they are redirected to the login page.

*   **Retrieve/Change password**
    *   A registered user who has forgotten their password can request a new one by providing their username.
    *   A logged-in user can change their password and other personal data.

*   **Edit personal data**
    *   A logged-in user can change their account information, such as password and email address.
    *   A user can send a request to an Administrator for an account upgrade.

### 3.1.2 Publication Management

*   **Search for publications**
    *   VUB-network users and all logged-in users can search for publications.
    *   The user can search using a form with the following criteria:
        *   Keywords with logical expressions (e.g., AND, OR, NOT).
        *   Author(s).
        *   A date range for publication.
    *   An advanced search allows specifying additional keywords and/or publications that refer to it.

*   **View search results**
    *   The system shall display a list of publications matching the search criteria, showing the title and main author for each result.
    *   Users can navigate through multiple pages of results.
    *   Users can order the results by title, author(s), and year of publication.

*   **View publication details**
    *   The user can select a single publication from the results list to view its detailed information, including title, authors, publication date, abstract, and cited references.
    *   The user can also select multiple publications from the results list to view their details.

*   **Download publications**
    *   The user can download the full text of a single publication from the search results list or the detailed view page.
    *   The user can download the full text of multiple publications from the search results list.
    *   This function is only available if the full text of the publication is stored in the system.

*   **Consult publication references**
    *   From the search results or detailed view, the user can view the references cited in a publication.
    *   If a cited reference is also in the system, the user can navigate to its detailed view.

*   **Export publication data**
    *   The user can export and download one or more search results in HTML, PDF, and PS formats.
    *   The user can export the references cited in a publication in BibTeX (BIB) and RIS formats.

*   **Upload publications**
    *   Publishers, Moderators, and Administrators can upload publications.
    *   The user selects a document in PDF or PostScript format, which must follow the BibTeX or RIS format.
    *   The system automatically retrieves bibliographical information (author, title, etc.) from the document.
    *   The user can manually correct or add to the retrieved information.
    *   The user can specify that different names (e.g., 'D. Vermeir' and 'Dirk Vermeir') refer to the same author.
    *   A "bulk upload" function allows importing many publications at once from BibTeX files.

*   **Edit publications**
    *   A Publisher can edit the publications they have uploaded.
    *   A Moderator can edit any publication owned by their department or group.
    *   An Administrator can edit any publication in the system.

### 3.1.3 User and Group Administration

*   **Search for users**
    *   Moderators and Administrators can search for users in the system by filling in search criteria.

*   **Manage user accounts**
    *   A Moderator can upgrade a Member from their own department to a Publisher, or downgrade a Publisher to a Member.
    *   An Administrator can create new user accounts by providing a username, password, email, and group. An exception occurs if the username already exists.
    *   An Administrator can delete any user account. An exception occurs if the username does not exist.
    *   An Administrator can change the user level of any user to any other user level.
    *   An Administrator can edit any user's settings.

*   **Search for groups**
    *   An Administrator can search for groups in the system.

*   **Manage groups**
    *   An Administrator can create new groups. An exception occurs if the group name already exists.
    *   An Administrator can delete existing groups. An exception occurs if the group name does not exist or the group is not empty.
    *   An Administrator can edit group settings.

*   **Manage group permissions**
    *   A Moderator can change the group permissions for any group under their jurisdiction.

### 3.1.4 System Administration

*   **Access control panel**
    *   An Administrator has access to a control panel for managing the system.

*   **Edit system configuration settings**
    *   An Administrator can change system configuration settings via the control panel.

### 3.1.5 Error Handling

*   If an error occurs during a user request, the system will display an error message to the user stating the cause of the error.
*   The error will also be logged to notify the Administrator of the technical difficulty.

## 3.2 Performance requirements
[N/A]

## 3.3 Usability requirements
*   The web interface shall be designed to be fast and efficient, allowing users to fulfill all available tasks in the minimum number of pages and clicks.
*   The web interface shall be attractive, simple, clear, and well-structured.
*   The system shall be accessible to users with a text-based web browser on a Linux operating system.
*   If an error occurs during a user request, the system shall provide an error message to the user stating the cause of the error.

## 3.5 Logical database requirements
All data will be saved in the database, including static and dynamic information, statistics, publications, and administrator settings.

The types of information to be stored include:
*   Bibliographical information for publications, such as title, author(s), institute, publication date, abstract, and cited references.
*   The full text of publications in PDF and PostScript formats.
*   User account information, including name, login name, password, email address, university, and department.
*   Administrator settings.

The database must be capable of handling several concurrent requests via SQL statements. Direct access to the data stored in the database is only allowed for Administrators using the Command Line Interface (CLI).

The database must be kept consistent at all times, with no pointers to deleted records and no redundant information.

User passwords must be saved in an encrypted format in the database. Only the PMS application should be able to access these passwords.

A backup structure is required to save all data in case of server or disk problems.

The frequency of use for different types of information is [N/A].

Specific data entities and their relationships are [N/A].

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

## 3.7 Software system attributes
### Reliability
The system shall be developed to minimize software faults.

### Availability
The system shall be available at all times, contingent on the availability of the Wilma web server. In case of a database corruption, an Administrator must be able to restore it from the last available backup. Following any other system failure, the system should be reinitialized. During downtime, the system shall display an error message indicating it is temporarily unavailable.

### Security
*   Every user account shall be protected with a personal password.
*   User passwords shall be encrypted during submission to the server and stored in an encrypted format in the database.
*   Direct access to the data stored in the database shall be restricted to Administrators using the Command Line Interface (CLI).
*   The system shall enforce user levels to control access to editing, deleting, and uploading publications.

### Maintainability
*   The system design shall be modular to simplify expansions and replacements.
*   The implementation shall be object-oriented.
*   The source code shall be documented using RDoc.

### Portability
The system is required to run on the Wilma web server, which is a Linux-based platform. It may be possible to relocate the system to a server with a different operating system, provided all necessary software (e.g., Ruby 1.8 or later) is available and adjustments are made.

## 3.8 Supporting information
Following the demand of the customer to have an early prototype available, the first iteration of the PMS will include the basic functions. Afterwards, in the second iteration, more functions will be added to the PMS and the previous ones will be enhanced. For this purpose, the different functions will be marked as follows:

*   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 left.

## 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: The testing processes used to ensure reliability are detailed in the Software Quality Assurance Plan (SQAP) and the Software Test Plan (STD).
*   Availability: [N/A]
*   Security: [N/A]
*   Maintainability: [N/A]
*   Portability: [N/A]

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

## 5.2 Acronyms and abbreviations
*   **BibTEX**: A tool for formatting lists of references, typically used with the LATEX document preparation system.
*   **Bulk Update**: Importing many publications or abstracts at once (e.g., through BibTeX files).
*   **CLI**: Command Line Interface.
*   **Git**: A distributed revision control / software configuration management project.
*   **HTML**: Hypertext Markup Language.
*   **HTTP**: Hypertext Transfer Protocol.
*   **IEEE**: Institute of Electrical and Electronics Engineers.
*   **OS**: Operating System (e.g., Linux, MS Windows XP, Mac OS X).
*   **PDF**: Portable Document Format.
*   **PMS**: Publication Management System.
*   **PS**: Postscript.
*   **RDoc**: Document Generator for Ruby Source.
*   **RIS**: A tagged file 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 the students of the faculty of sciences at the VUB.