# 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 software product to be produced is the Publications Management System (PMS). The system will manage a database of bibliographical information and will be accessible via a command-line interface and a web browser.

The PMS will perform the following functions:
*   Store the full text of publications in PDF and PostScript formats.
*   Automatically retrieve bibliographical information, such as author and title, from the full text of a publication.
*   Provide the ability for users to manually correct any retrieved information that is incorrect or insufficient.
*   Explicitly manage author identities, allowing users to indicate that different name formats (e.g., ‘D. Vermeir’ and ‘Dirk Vermeir’) refer to the same person.
*   Support bulk updates for importing many publications at once.
*   Provide different levels of access to publication content, such as the full text or only the abstract, and support access control.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The Publications Management System (PMS) is a self-contained system that 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:** The 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 their 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 PMS web interface will comply with the W3C XHTML 1.0 Transitional standard.

#### Hardware interfaces
The PMS must be able to run on the Wilma web server, which is a Linux-based server. There are no specific hardware requirements for the end-users.

#### Software interfaces
The system requires the following software:
*   An operating system, specifically a Linux-based environment.
*   A web server.
*   A MySQL database.
*   Ruby version 1.8 or later.
*   A web browser that supports W3C XHTML.

The development will use the following software products:
*   **Git:** for configuration management.
*   **RDoc:** for code documentation.

Only free software can be used for the tools and for the end product. The use of frameworks is not allowed.

#### Communications interfaces
Communication between the web server and users will be via an HTTP connection using TCP/IP port 80. HTTP traffic must be possible on the network connection between the server and the client.

#### Memory constraints
There is no specific limit on the usage of memory by the PMS. However, uploaded publications 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.
*   Command line users have access to the server shell and are granted Administrator privileges.
*   A backup structure is required to save all data in case of server or disk problems. In case of a corrupted database, the Administrator should replace it with the last available backup.

#### Site adaptation requirements
The PMS will be designed for easy installation 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 a set of functions based on a hierarchical user structure. Each user level inherits all the functions of the preceding levels. The user hierarchy is as follows: Guest, VUB-Network User, Member, Publisher, Moderator, and Administrator.

The major functions available to each user level are:

*   **Guest:** A user who is not logged in and not on the VUB network.
    *   Register for a new user account.
    *   Log in to an existing account.
    *   Validate a new account.
    *   Retrieve a forgotten password.

*   **VUB-Network User:** A user connected to the VUB network but not logged in. This role inherits Guest functions and adds:
    *   Search for publications using basic and advanced criteria.
    *   View and order search results.
    *   Export and download publications from the search results.
    *   Find similar publications based on author or institute.

*   **Member:** A registered and logged-in user. This role inherits VUB-Network User functions and adds:
    *   Manage personal account details.
    *   Request an account upgrade.
    *   Log out of the system.

*   **Publisher:** A logged-in user with publication rights. This role inherits Member functions and adds:
    *   Upload publications in PDF or PostScript format, using BibTeX or RIS for metadata.
    *   Perform bulk uploads of multiple publications.
    *   Edit their own uploaded publications.

*   **Moderator:** A user with departmental management rights. This role inherits Publisher functions and adds:
    *   Manage user roles within their department.
    *   Manage permissions for groups under their jurisdiction.
    *   Edit author information.
    *   Edit any publication belonging to their department.

*   **Administrator:** A user with full system control. This role inherits Moderator functions and adds:
    *   Access a system control panel.
    *   Create, delete, and manage all user accounts and user levels.
    *   Create, delete, and manage all groups.
    *   Edit any publication in the system.

Possible future expansions of the system include:
*   Support for additional document formats.
*   Displaying lists of documents that cite a given publication.
*   Automatic consolidation of author and institute name variations.
*   Automated retrieval of full-text articles from URLs provided in uploaded files.
*   Support for managing audio and video files.

### 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
*   **Hardware and Platform:** The system must be able to run on a Linux-based environment, specifically the Wilma web server. It requires Ruby 1.8 or later to be installed.
*   **Interfaces to Other Applications:** The system will interface with a MySQL database. Communication between the web server and users will be via HTTP over TCP/IP port 80.
*   **Language and Development:** The system must be implemented in the Ruby programming language using an object-oriented approach. The use of frameworks is not permitted. Only free software can be used for the development tools and the final product. Git will be used for configuration management.
*   **Quality and Standards:** The design must be modular. The web interface must comply with the W3C XHTML 1.0 Transitional standard. The implementation must adhere to the specified coding conventions of SE1. All code must be documented using RDoc, and design diagrams must follow the UML standard.
*   **Security:** User accounts must be protected with personal passwords. Passwords must be encrypted during transmission and when stored in the database. Direct access to the database is only permitted for Administrators using the command line interface.
*   **Regulatory Policies:** [N/A]
*   **Parallel Operation:** [N/A]
*   **Audit Functions:** [N/A]
*   **Control Functions:** [N/A]
*   **Signal Handshake Protocols:** [N/A]
*   **Criticality of the Application:** [N/A]
*   **Safety Considerations:** [N/A]
*   **Physical/Mental Considerations:** [N/A]

## 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. The user(s) and the customer(s) are often not the same person(s).
*   **BibTEX:** A tool for formatting lists of references, typically used together 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.

# 2 References
1. IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications. Source: http://www.scribd.com/doc/2620639/IEEE-8301998
2. Software Engineering Course (2007-2008), Prof. Dr. Dirk Vermeir, Free University of Brussels. Source: http://tinf2.vub.ac.be/~dvermeir/courses/software_engineering/projects/2007-2008/index.html
3. XHTML 1.0 The Second Edition, W3C Recommendation. Source: http://www.w3.org/TR/xhtml1/
4. Git, Distributed revision control system. Source: http://git.or.cz/
5. Institute of Electrical and Electronics Engineers (IEEE). Source: http://www.ieee.org/
6. RDoc, Document Generator for Ruby Source. Source: http://rdoc.sourceforge.net/
7. Software Engineering group 1 (SE1) Project Website (2007-2008). Source: http://wilma.vub.ac.be/~se1_0708/
8. Vrije Universiteit Brussel (VUB). Source: http://www.vub.ac.be
9. World Wide Web Consortium (W3C). Source: http://www.w3.org/
10. SE1 Coding Conventions. Source: http://wilma.vub.ac.be/~se1_0708/docs/coding_conventions/conventions.pdf
11. Unified Modelling Language (UML). Source: http://www.uml.org/
12. SE1 Software Quality Assurance Plan (SQAP). Source: http://wilma.vub.ac.be/~se1_0708/docs/sqap/sqap.pdf
13. SE1 Software Test Plan (STD). Source: To Be Determined.

# 3 Requirements
[NULL]

## 3.1 Functions
### 3.1.1 User Account Management

#### 3.1.1.1 Register for an Account
Any user can request an account. The user must provide a username, password, and personal data including name, email address, university, and department. The system shall check if the username already exists and notify the user if it does. Upon successful submission, a validation email is sent to the user's email address to confirm the registration. An email is also sent to the system Administrator.

#### 3.1.1.2 Log In
A user with a validated account can log in using their username and password. Users on the VUB network will be presented with a screen where they can either log in or start a search immediately. Users outside the VUB network will be presented with a login screen. If the credentials are invalid, an error message shall be displayed.

#### 3.1.1.3 Log Off
A logged-in user can log off from the system. If the user is connected to the VUB network, they shall be redirected to the search page. Otherwise, they shall be redirected to the login page.

#### 3.1.1.4 Retrieve or Change Password
A registered user can change their password. A user who has forgotten their password can request a new one. The user must provide their username and a new password. An exception occurs if the provided username is not valid.

#### 3.1.1.5 Edit Personal Data
A logged-in user can edit their personal data, such as their password, email address, university, and department. Users can also submit a request to an Administrator for an account upgrade.

### 3.1.2 Publication Management

#### 3.1.2.1 Upload a Publication
A Publisher, Moderator, or Administrator can upload a publication. The supported formats are PDF and PostScript. The upload can also be performed using BibTEX or RIS formats. The system shall automatically attempt to retrieve bibliographical information (e.g., author, title) from the document. The user will be shown the retrieved information and can manually correct or complete it. The user can also specify that different variations of an author's name or an institute's name refer to the same entity.

#### 3.1.2.2 Bulk Upload Publications
A Publisher, Moderator, or Administrator can import multiple publications or abstracts at once using BibTEX files.

#### 3.1.2.3 Edit a Publication
- A Publisher can edit the publications they have personally uploaded.
- A Moderator can edit any publication owned by the department or group they are associated with.
- An Administrator can edit any publication in the system.

#### 3.1.2.4 Download a Publication
A VUB-Network User or any logged-in user can download the full text of publications. This can be done for a single publication or for multiple selected publications from a search results screen.

### 3.1.3 Search and Retrieval

#### 3.1.3.1 Search for Publications
A VUB-Network User or any logged-in user can search for publications. The search form shall allow users to enter criteria such as:
*   Keywords, with support for logical expressions (e.g., AND, OR, NOT).
*   Author(s).
*   Publication date range.
*   Advanced criteria such as publications that are referenced.

#### 3.1.3.2 View and Organize Search Results
The system shall display a list of publications matching the search criteria, showing the title and main author for each. If no results are found, a message shall be displayed. The user shall be able to:
*   Navigate through multiple pages of results.
*   Order the results by title, author(s), and year of publication.

#### 3.1.3.3 Export Search Results
The user can export one or more publications from the search results. The supported export formats are HTML, PDF, and PostScript.

#### 3.1.3.4 View Publication Details
The user can select a publication from the search results to view its detailed information, including title, authors, publication date, abstract, and cited references. The user can also select multiple publications to view their details.

#### 3.1.3.5 Display Full Text
From the publication details view, the user can display the full text of the publication. An exception occurs if the full text is not available in the system.

#### 3.1.3.6 View Author Details
From the search results, the user can select an author's name to view their details.

#### 3.1.3.7 Consult and Export References
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 details page. The user can export the list of references in BibTEX or RIS format.

### 3.1.4 Moderation Functions

#### 3.1.4.1 Search for Users
A Moderator or Administrator can search for users based on specified criteria.

#### 3.1.4.2 Edit User Settings
A Moderator or Administrator can select a user from a search result and change their settings.

#### 3.1.4.3 Manage Departmental User Levels
A Moderator can upgrade a Member from their own department to a Publisher, or downgrade a Publisher from their own department to a Member.

#### 3.1.4.4 Manage Departmental Group Permissions
A Moderator can change the permissions of any group under their jurisdiction.

#### 3.1.4.5 Edit Author Information
A Moderator can edit the information about authors.

### 3.1.5 Administration Functions

#### 3.1.5.1 Access Control Panel
An Administrator has access to a control panel for system management tasks.

#### 3.1.5.2 Create User
An Administrator can create a new user by providing a username, password, email, and group. An exception occurs if the username already exists.

#### 3.1.5.3 Delete User
An Administrator can delete a user. The system shall ask for confirmation before deletion. An exception occurs if the specified user does not exist.

#### 3.1.5.4 Create Group
An Administrator can create a new group by providing a group name and assigning users. An exception occurs if the group name already exists.

#### 3.1.5.5 Delete Group
An Administrator can delete a group. The group must be empty (contain no users) before it can be deleted. An exception occurs if the group does not exist or is not empty.

#### 3.1.5.6 Search and Edit Groups
An Administrator can search for groups and edit the settings of any group.

#### 3.1.5.7 Manage Global User Levels
An Administrator can change the user level of any user to any other user level.

#### 3.1.5.8 Edit System Configuration
An Administrator can access and modify the system's configuration settings.

### 3.1.6 Optional Functions
The following functions are considered for future expansion:
*   Support for additional document formats, such as MS WORD.
*   Display a list of documents that refer to a given publication.
*   Automatically recognize that different name variations refer to the same author or institute.
*   Retrieve the full text of publications from URLs provided in uploaded BibTEX files.
*   Expand the system to manage and automatically recognize audio and video files.

## 3.2 Performance requirements
[N/A]

## 3.3 Usability requirements
*   The web interface shall be attractive, simple, clear, and well-structured.
*   All functions and options shall be available in the minimum number of clicks and pages necessary, while maintaining a clear structure.
*   If an error occurs during a request, the user shall receive an error message stating the cause of the error.

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

The types of information stored include:
*   Publication data, including bibliographical information and the full text of publications in PDF and PostScript formats.
*   User account information, including personal data, user level, and encrypted passwords.
*   Group information.

The database must be capable of handling several concurrent requests via SQL statements. Direct access to the data stored in the database is restricted to Administrators using the Command Line Interface.

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

For security, user passwords must be stored in an encrypted format.

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

Frequency of use: [N/A]

Data entities and their relationships: [N/A]

Data retention requirements: [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 is developed to minimize software faults. The development process uses a spiral model with two iterations to achieve a low number of bugs.

### Availability
The PMS will be available at all times, except when the Wilma server is unavailable. The availability of the Wilma server is the responsibility of the customer.

In case of a corrupted database, an Administrator should replace it with the last available backup. For other hardware or software failures, the problem should be resolved before reinitializing the PMS. During downtime, the system should display an error message to visitors indicating it is temporarily down.

### Security
*   Every user account is protected with a personal password.
*   User passwords must be encrypted during submission and when stored in the database. Only the PMS should be able to access these passwords.
*   Direct access to the data stored in the database is only allowed for Administrators using the Command Line Interface (CLI).
*   The defined user levels must be enforced for all actions, including editing, deleting, and uploading publications.

### Maintainability
*   The PMS database is to be maintained by Administrator(s).
*   Global system maintenance, including user levels and special privileges, is the responsibility of Administrator(s).
*   Moderator(s) will be able to perform maintenance at the departmental level.

### Portability
The PMS is developed and tested to run on the Wilma server, a Linux-based platform. It is possible to relocate the PMS to a server with a different operating system, provided that all necessary software is available and some adjustments are made.

## 3.8 Supporting information
To facilitate a phased delivery with an early prototype, requirements are apportioned into development iterations. The functions are marked with one of the following priorities:

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

# 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
The verification of software system attributes will be conducted as follows.

### Reliability
The reliability of the PMS will be verified through the testing processes described in the Software Quality Assurance Plan (SQAP) and the Software Test Plan (STD).

### Availability
[N/A]

### Security
[N/A]

### Maintainability
[N/A]

### Portability
The PMS will be tested to verify that it can run on the Wilma platform, as specified by the customer.

# 5 Appendices
[NULL]

## 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 and therefore have all 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.
