# 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 PMS will manage a database containing bibliographical information and provide functionalities to save the entire text of a publication in PDF and Postscript formats. It will automatically retrieve bibliographical information from the complete text of a publication and allow manual corrections if necessary. The system will recognize authors and allow users to indicate that different references refer to the same author or institute. It will support bulk updates and provide access control, allowing users to access publication contents if available. The PMS can be accessed via command line and web browser, adhering to W3C XHTML standards. The primary objective is to facilitate efficient management and retrieval of publication data, benefiting academic personnel and students by streamlining access to bibliographical resources.

## 1.3 Product overview
[NULL]

### 1.3.1 Product perspective
The Publications Management System (PMS) is designed to function as a standalone system that manages bibliographical information and publication texts. It interfaces with a MySQL database and a web server, which are integral components of the system. The PMS can be accessed via a web browser or command line, providing flexibility in user interaction.

#### System interfaces
- **Database Interface**: The PMS interfaces with a MySQL database to store and retrieve bibliographical data and publication texts.
- **Web Server Interface**: The web server executes the PMS and handles user queries, generating user interfaces accordingly.

#### User interfaces
- The PMS is accessible through any web browser, with specific support for text-based browsers like Links2 on Linux OS. The interface is designed to be compliant with W3C XHTML 1.0 Transitional standards, ensuring a consistent and accessible user experience.

#### Hardware interfaces
- There are no specific hardware requirements for users accessing the PMS. The system is designed to be accessible from any operating system that supports a web browser.

#### Software interfaces
- The PMS requires Ruby 1.8 or later for its operation and is designed to run on a Linux-based environment, specifically the Wilma server at VUB.

#### Communications interfaces
- Communication between the PMS and users is facilitated via HTTP connections using TCP/IP port 80.

#### Memory constraints
- There are no specific memory constraints for the PMS, although the maximum file size for publications is yet to be determined (TBD).

#### Operations
- Users must be logged into the PMS or connected to the VUB network to access its functionalities. The system supports various user operations, including registration, login, and publication management.

#### Site adaptation requirements
- The PMS is designed to be easily installable on a Linux-based environment with Ruby 1.8 or later. It requires minimal site-specific adaptations.

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

### 1.3.2 Product functions
The Publications Management System (PMS) provides a range of functions organized in a hierarchical user structure, where each user type inherits the functions of the preceding one. The major functions include:

- **Guest Functions**: 
  - Register an account
  - Log into the PMS
  - Validate a new account
  - Retrieve password

- **VUB-Network User Functions**:
  - Search for publications using keywords, authors, and publication dates
  - Perform advanced searches with additional criteria
  - Order, export, and download search results
  - Search for publications based on similarity

- **Member Functions**:
  - Change account details
  - Log off the PMS

- **Publisher Functions**:
  - Upload publications in supported formats (e.g., PDF, PS)
  - Edit own publications
  - Bulk upload publications

- **Moderator Functions**:
  - Manage user levels within their department
  - Manage group permissions
  - Edit author information
  - Edit departmental publications

- **Administrator Functions**:
  - Access the control panel for user account management
  - Create and delete users and groups
  - Edit all publications

These functions are designed to facilitate the management and retrieval of bibliographical information, ensuring that users can efficiently access and manage publications within the system.

### 1.3.3 User characteristics
The users of the Publications Management System (PMS) are expected to be academic personnel and students with various technical backgrounds. All users should have a basic knowledge of the internet. [N/A]

### 1.3.4 Limitations
- **Regulatory Requirements and Policies**: The PMS web interface must comply with the W3C XHTML 1.0 Transitional standard.
- **Hardware Limitations**: There are no specific hardware requirements for users accessing the PMS.
- **Interfaces to Other Applications**: The PMS interfaces with a MySQL database and a web server.
- **Higher-Order Language Requirements**: The PMS is developed using the Ruby programming language.
- **Quality Requirements**: The PMS is designed to minimize software faults and ensure reliability through a spiral model with two iterations.
- **Security Considerations**: User accounts are protected with personal passwords, which are encrypted during transmission and storage. Direct database access is restricted to administrators using the CLI.
- **Portability**: The PMS is developed to run on the Wilma server, a Linux-based platform, but can be relocated to other servers with necessary software and adjustments.
- **Modular Design**: The PMS design is modular to facilitate expansions and replacements.
- **Software Configuration Management**: Git is used for configuration management, and the use of frameworks is not allowed.
- **Documentation**: The code will be documented using RDoc, and design diagrams must follow the UML standard.

[N/A] for any other limitations not explicitly mentioned in the original SRS.

## 1.4 Definitions
- **Customer**: The person or persons who pay for the product and usually decide the requirements. In this context, the customer and the supplier may be members of the same organization.
- **Supplier**: The person or persons who produce a product for a customer. In this context, the customer and the supplier may be members of the same organization.
- **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 with the LATEX document preparation system.
- **Bulk Update**: Refers to 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 created by Linus Torvalds.
- **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 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.

# 2 References
## 2.1 Compliance

1. **IEEE Std 830-1998**  
   Title: IEEE Recommended Practice for Software Requirements Specifications  
   Publishing Organization: Institute of Electrical and Electronics Engineers (IEEE)  
   Source: [IEEE](http://www.ieee.org/)

2. **W3C XHTML 1.0 Transitional**  
   Title: XHTML 1.0: The Extensible HyperText Markup Language (Second Edition)  
   Publishing Organization: World Wide Web Consortium (W3C)  
   Source: [W3C](http://www.w3.org/TR/xhtml1/)

## 2.2 Guidance

1. **Software Engineering Course**  
   Title: Software Engineering Course Projects 2007-2008  
   Publishing Organization: Free University of Brussels  
   Source: [Course Projects](http://tinf2.vub.ac.be/~dvermeir/courses/software_engineering/projects/2007-2008/index.html)

2. **Git**  
   Title: Git - Fast Version Control System  
   Publishing Organization: Git  
   Source: [Git](http://git.or.cz/)

3. **RDoc**  
   Title: RDoc: Document Generator for Ruby Source  
   Publishing Organization: RDoc  
   Source: [RDoc](http://rdoc.sourceforge.net/)

4. **SE1 Coding Conventions**  
   Title: SE1 Coding Conventions  
   Publishing Organization: Free University of Brussels  
   Source: [Coding Conventions](http://wilma.vub.ac.be/~se1_0708/docs/coding_conventions/conventions.pdf)

5. **UML**  
   Title: Unified Modeling Language  
   Publishing Organization: Object Management Group  
   Source: [UML](http://www.uml.org/)

6. **SQAP**  
   Title: Software Quality Assurance Plan  
   Publishing Organization: Free University of Brussels  
   Source: [SQAP](http://wilma.vub.ac.be/~se1_0708/docs/sqap/sqap.pdf)

7. **VUB**  
   Title: Free University of Brussels  
   Source: [VUB](http://www.vub.ac.be)

[N/A] for any additional references not explicitly listed in the original SRS.

# 3 Requirements
[NULL]

## 3.1 Functions
The Publications Management System (PMS) is designed to handle various user interactions and manage bibliographical data effectively. The following outlines the fundamental actions and processes within the system:

### 3.1.1 User Authentication and Account Management
- **Log in to the system from the internet**: Users can access the system remotely, provided they have a valid username and password. The system checks for valid credentials before granting access.
- **Register for an account**: Users can request access by providing necessary personal information. The system checks for existing usernames to prevent duplicates.
- **Log off**: Users can securely log out, redirecting them to the appropriate start page based on their network connection.
- **Change password**: Users can update their password, which requires entering their current username and a new password.

### 3.1.2 Publication Search and Retrieval
- **Search for publications**: Users can search using keywords, author names, and publication dates. The system processes these inputs to generate a list of matching publications.
- **View the results of a search**: Users can navigate through search results, with options to view detailed information about each publication.
- **Download publications**: Users can download full texts of publications, provided they have access rights.

### 3.1.3 Publication Management
- **Upload publications**: Users with appropriate permissions can upload new publications. The system attempts to extract bibliographical information automatically.
- **Edit publications**: Users can modify details of publications they own or have permissions to edit.

### 3.1.4 User and Group Management
- **Search users**: Moderators and administrators can search for users within the system.
- **Edit user settings**: Authorized users can modify settings for other users, such as changing user levels or group memberships.

### 3.1.5 Error Handling and Recovery
- **Error messages**: Users receive error messages for invalid inputs or system errors, which are also logged for administrative review.
- **System recovery**: In case of database corruption or other failures, administrators can restore the system using backups.

### 3.1.6 Communication and Security
- **Communication facilities**: The system uses HTTP connections for web interactions, ensuring secure data transmission.
- **Security measures**: User passwords are encrypted during transmission and storage, and access to sensitive data is restricted to authorized personnel.

### 3.1.7 System Constraints and Dependencies
- **Effect of parameters**: User roles and network connections influence the available functions and access levels within the system.
- **Relationship of outputs to inputs**: The system processes user inputs to generate corresponding outputs, such as search results or account changes, following predefined sequences and validation checks.

The PMS is structured to ensure efficient processing of user requests while maintaining data integrity and security. Each function is designed to handle specific user needs, with built-in mechanisms for error handling and recovery.

## 3.2 Performance requirements
[N/A]

## 3.3 Usability requirements
[N/A]

## 3.5 Logical database requirements
The logical database requirements for the Publications Management System (PMS) are as follows:

a) **Types of Information Used by Various Functions:**
   - The database will store static and dynamic information, including bibliographical details, user accounts, publication texts, and system settings.

b) **Frequency of Use:**
   - The database must handle multiple simultaneous requests, as users will frequently access, search, and update publication records.

c) **Accessing Capabilities:**
   - Users will access the database through web and command line interfaces, with different levels of access based on user roles (e.g., Guest, Member, Publisher, Moderator, Administrator).

d) **Data Entities and Their Relationships:**
   - Key data entities include Users, Publications, Authors, and Departments. Relationships will be established between these entities to support functionalities like searching, uploading, and editing publications.

e) **Integrity Constraints:**
   - The database must maintain consistency, ensuring no pointers to deleted records and avoiding redundant information.

f) **Security:**
   - Direct access to the database is restricted to Administrators using the CLI. User passwords must be encrypted during transmission and storage.

g) **Data Retention Requirements:**
   - A backup structure is required to save all data in case of server or disk failures, ensuring data retention and recovery. 

The database must be capable of supporting the PMS's operations while ensuring data integrity, security, and availability.

## 3.6 Design constraints
- The PMS web interface must conform to the W3C XHTML 1.0 Transitional standard.
- The implementation must comply with the Coding Conventions of SE1.
- The implementation must be object-oriented.
- Design diagrams must be created following the UML standard.
- The design of the PMS should be modular to simplify the design and implementation of expansions and replacements.
- The PMS must be able to run on Linux, specifically the Wilma web server.
- The use of frameworks is not allowed.
- Only free software can be used for the tools and for the end product. The use of certain libraries and aids is justified in the SCMP.
- The PMS should be easily installable, with specific installation requirements to be determined.

## 3.7 Software system attributes
### 3.7.1 Reliability
The PMS is developed to minimize software faults by employing a spiral model with two iterations. For more information about the reliability of the PMS and the testing processes used, refer to the Software Quality Assurance Plan (SQAP) and Software Test Plan (STD) of SE1.

### 3.7.2 Availability
The PMS will be available at all times from any computer that meets the assumptions and dependencies specified, except when the Wilma server is unavailable. In case of a corrupted database, the Administrator should replace it with the last available backup. For other failures, the problem should be resolved, and the PMS should be reinitialized. During downtime, an error message should inform visitors that the PMS is temporarily unavailable.

### 3.7.3 Security
- Every user account is protected with a personal password, and only the specific user should be able to log into that account and change personal information.
- User passwords should be encrypted during transmission and stored in an encrypted format in the database, with access restricted to the PMS.
- Direct access to the database is only allowed for Administrators using the Command Line Interface (CLI).
- User levels must be respected regarding editing, deleting, and uploading publications and their bibliographical details.

### 3.7.4 Maintainability
- The database should be maintained by the Administrator(s).
- The PMS, concerning user levels and special privileges, should be maintained by Administrators globally and by Moderators at the departmental level.
- No additional maintenance measures are required if the PMS remains available under all circumstances.

### 3.7.5 Portability
The PMS is developed and tested to run on the Wilma server, a Linux-based platform. It can be relocated to a server with a different operating system, provided all necessary software is available and some adjustments are made. However, full implementation of this feature was not demanded by the customer.

## 3.8 Supporting information
[N/A]

# 4 Verification
[NULL]

## 4.1 Functions
The verification of the functions for the Publications Management System (PMS) will involve several approaches to ensure that the software meets the specified requirements. The verification methods will be aligned with the functional requirements outlined in Section 3.1 of the SRS.

### Verification Approaches

1. **Validity Checks on Inputs:**
   - Ensure that all input fields, such as those for registration and search, are validated for correct data types and formats.
   - Test cases will be designed to check for invalid inputs and ensure appropriate error messages are displayed.

2. **Exact Sequence of Operations:**
   - Verify that the sequence of operations, such as user login, search, and publication upload, follows the specified order.
   - Automated test scripts will simulate user interactions to confirm the correct sequence of operations.

3. **Responses to Abnormal Situations:**
   - **Overflow:** Test the system's ability to handle data overflow scenarios, such as large file uploads or excessive search results.
   - **Communication Facilities:** Verify the system's response to network interruptions and ensure it can resume operations smoothly.
   - **Hardware Faults and Failures:** Simulate hardware failures to test the system's fault tolerance and recovery mechanisms.
   - **Error Handling and Recovery:** Ensure that the system provides meaningful error messages and can recover from errors without data loss.

4. **Effect of Parameters:**
   - Test the system's behavior with different parameter values to ensure consistent and expected outcomes.
   - Parameter boundary testing will be conducted to verify the system's robustness.

5. **Relationship of Outputs to Inputs:**
   - **Input/Output Sequences:** Verify that the outputs, such as search results and publication details, are correctly generated based on the inputs provided.
   - **Formulas for Input to Output Conversion:** Ensure that any calculations or data transformations are performed accurately and yield the expected results.

### Sub-functions and Sub-processes

The functional requirements will be further divided into sub-functions, such as user management, publication management, and search functionalities. Each sub-function will undergo targeted verification to ensure comprehensive coverage of all functional aspects of the PMS.

## 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 PMS is developed to minimize software faults by employing a spiral model with two iterations. For more information about the reliability of the PMS and the testing processes used, refer to the Software Quality Assurance Plan (SQAP) and Software Test Plan (STD) of SE1.

### Availability
The PMS will be available at all times from any computer that meets the assumptions and dependencies specified in Section 2.6, except when the Wilma server is unavailable. In case of a corrupted database, the Administrator should replace it with the last available backup. For other failures, the problem should be resolved before reinitializing the PMS. During downtime, an error message should inform visitors that the PMS is temporarily unavailable.

### Security
- Every user account is protected with a personal password, and only the specific user should be able to log into that account and change personal information.
- User passwords should be encrypted during transmission and stored in an encrypted format in the database, accessible only by the PMS.
- Direct database access is restricted to Administrators using the Command Line Interface (CLI).
- User levels must be respected regarding editing, deleting, and uploading publications and their bibliographical details.

### Maintainability
- The database should be maintained by the Administrator(s).
- The PMS, concerning user levels and special privileges, should be maintained by Administrators globally and by Moderators at the departmental level.
- No additional maintenance measures are required if the PMS remains available under all circumstances.

### Portability
The PMS is developed and tested to run on the Wilma server, a Linux-based platform. It can be relocated to a server with a different OS, provided all necessary software is available and some adjustments are made. However, full implementation of this feature was not demanded by the customer.

# 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 client.
- Command line users have access to the server shell, granting them Administrator privileges.

## 5.2 Acronyms and abbreviations
- **BibTEX**: A tool for formatting lists of references, typically used with the LATEX document preparation system.
- **CLI**: Command Line Interface.
- **Git**: A distributed revision control/software configuration management project created by Linus Torvalds.
- **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 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.
