## 1.1 Purpose

The purpose of the Publications Management System (PMS) is to provide a centralized, role-based system for storing, managing, discovering, and distributing publications and their bibliographic metadata.

To achieve this, the PMS will:
- Offer access via a web interface and a command-line interface.
- Maintain bibliographic records and full texts (e.g., PDF/PS) in a database.
- Support automatic extraction of bibliographic information from uploaded documents with user-driven correction, and allow aliasing of authors and institutes (e.g., “D. Vermeir” = “Dirk Vermeir”; “VUB” = “Vrije Universiteit Brussel”).
- Enable users to search, view, download, and export results; and allow privileged users to upload, edit, and bulk-import publications (e.g., BibTeX, RIS).
- Enforce access control across user roles (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator) and support account management and administration of users and groups.
- Provide remote access for authenticated users and on-network access for VUB-network users.

## 1.2 Scope

- Product identification
  - Publications Management System (PMS)
  - PMS Web Application (XHTML 1.0 Transitional–compliant UI)
  - PMS Command Line Interface (CLI) for administrative use on the VUB network
  - PMS Database (MySQL) storing bibliographic records, author/institute entities, and publication files

- What the PMS will do
  - Store and manage bibliographic information and full texts of publications (e.g., PDF, PS), including abstracts
  - Support upload of individual publications and bulk imports (e.g., BibTeX, RIS), with automatic extraction of bibliographic metadata from full text/abstract and manual correction when needed
  - Provide powerful search and retrieval by title, author(s), institute, keywords, and date ranges; view details, references, and related items; download and export results (e.g., HTML, PDF, PS; references in Bib/RIS)
  - Maintain explicit entities for authors and institutes, allowing users to indicate equivalences (e.g., “D. Vermeir” ≡ “Dirk Vermeir”; “VUB” ≡ “Vrije Universiteit Brussel”)
  - Enforce access control with role- and network–based permissions (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator); enable user/group management and moderation/administration functions
  - Offer web access over HTTP and administrator CLI access; log errors and notify administrators

- Application, benefits, objectives, and goals
  - Application: Repository and access platform for academic publications used by VUB academic personnel and students, accessible on Linux-based infrastructure (Wilma) via standard web browsers (including text-based) and CLI for administrators
  - Benefits: Centralized, consistent storage of publications and metadata; efficient discovery and access (including full text when available); streamlined ingestion via bulk import and automatic metadata extraction; improved data quality through disambiguation and moderation; controlled access inside/outside the VUB network
  - Objectives and goals: Fast, clear web interface requiring minimal clicks; standards compliance (W3C XHTML 1.0 Transitional); modular design to ease extension (e.g., additional formats); use of free software; ease of installation and administration

This scope is consistent with the overall description and functional intent stated for the Publications Management System in this specification.

### 1.3.1 Product perspective

The Publications Management System (PMS) is a standalone web-based application deployed on a Linux web server (Wilma) with a MySQL database backend. End users access PMS via standard web browsers over HTTP; Administrators may also access PMS via a local command-line interface (CLI) on the server. PMS is not defined as a component of a larger software system; it operates within the VUB network environment, recognizing VUB-network users by IP address, and uses email for account validation and certain notifications.

Major elements and interconnections:
- User web browsers (including text-based browsers) connect over HTTP (TCP/IP port 80) to the web server running PMS.
- PMS (Ruby application) runs on the web server, generates the web UI, and interacts with the MySQL database.
- Administrators can access PMS functions via CLI on the server.
- Email service is used to send account validation and administrative notifications.

System interfaces
- Database (MySQL):
  - Purpose: Persistent storage and retrieval of publications, full texts/abstracts, bibliographic metadata, users, groups, permissions, statistics, and configuration.
  - Interface: PMS issues SQL queries/commands to the MySQL database. Concurrency must be supported; database consistency is required; backup/restore must be possible.
- Web server:
  - Purpose: Hosts and executes the PMS application, mediates HTTP requests, and serves the web UI.
  - Interface: Receives HTTP requests from clients, invokes PMS logic, and returns XHTML pages and downloadable files.

User interfaces
- Web UI:
  - Accessible from any OS using a standards-compliant web browser; explicitly supports Linux and text-based browsers (e.g., Links2).
  - Complies with W3C XHTML 1.0 Transitional.
  - Emphasis on clarity and minimal clicks for tasks (search, upload, download, export).
  - Error handling: user-visible error messages stating the cause; errors are logged for Administrators.
- CLI (Administrators within VUB network):
  - Local shell access to server; provides administrative operations with Administrator privileges.

Hardware interfaces
- Users: No specific hardware requirements.
- Server: Linux-based server (Wilma) hosting web server and database.
- Device-specific or port-level hardware configurations: [N/A]

Software interfaces
- Operating system:
  - Name: Linux; Version: [N/A] (Linux-based environment); Source: [N/A]
  - Purpose: Hosting platform for PMS and supporting services.
- Programming language/runtime:
  - Name: Ruby; Version: 1.8 or later; Source: [N/A]
  - Purpose: Implementation language/runtime for PMS.
- Database:
  - Name: MySQL; Version: [N/A]; Source: [N/A]
  - Purpose: Persistent data storage; interface via SQL.
- Web standards:
  - Name: W3C XHTML 1.0 Transitional; Spec no.: [N/A]; Source: W3C
  - Purpose: Defines structure/format of web UI.
- File formats (import/export):
  - Import: BibTeX (bib) and RIS for bibliographic data; full texts in PDF and PS (ODT also mentioned for upload).
    - Versions/spec numbers: [N/A]; Sources: [N/A]
    - Purpose: Bulk and single publication ingestion; automatic metadata extraction with manual correction.
  - Export: Publications in HTML, PDF, PS; references in BibTeX (bib) and RIS.
    - Versions/spec numbers: [N/A]; Sources: [N/A]
    - Purpose: Dissemination and interoperability.
- Interface definitions (messages/formats):
  - SQL statements for DB operations; HTTP request/response with XHTML content for web interactions; file uploads/downloads using standard HTTP multipart and content types. Detailed protocol specs: [N/A] (standard behaviors implied by referenced technologies).

Communications interfaces
- HTTP over TCP/IP port 80 between clients and the web server.
- Local shell access for CLI within the VUB network.
- Network must allow HTTP traffic between server and clients.

Memory constraints
- No specific limit on PMS memory usage.
- Maximum file size for publication uploads: TBD.

Operations
- Modes of operation:
  - User-initiated interactive sessions via web UI; Administrators via CLI.
  - Access control based on user roles; VUB-network users recognized by IP without login for limited access; full access requires login.
- Periods of operation:
  - Intended to be available at all times except when the Wilma server is unavailable. Specific scheduling: [N/A]
- Data processing support:
  - Search, upload, download, export, metadata extraction, logging of errors.
- Backup and recovery:
  - Database backup structure required; in case of corruption, Administrator restores the last available backup. Other failures require resolution followed by PMS reinitialization; users see a temporary downtime error.

Site adaptation requirements
- Installation:
  - Requires Ruby 1.8 or later; runs under a Linux-based environment; should be easy to install.
  - “Easily installable by using: TBD.”
- Site/mission-specific data or initialization sequences: [N/A]
- Configuration items to adapt to site (e.g., IP ranges, email settings): [N/A]

Interfaces with services
- Email service:
  - Purpose: Send account validation emails and administrative notifications (e.g., registration, password-related actions).
  - Protocols/settings: [N/A]
- Cloud/SaaS integrations: [N/A]

### 1.3.2 Product functions

The Publications Management System (PMS) provides the following major functions, organized by functional domain and constrained by user roles and network access.

- Access and authentication
  - Register a new account; validate account via email.
  - Log in from the internet or via the VUB network; log off.
  - Retrieve/change password.
  - Recognize VUB-network users by IP; enforce access rules for guests vs. authenticated users.

- Search and discovery
  - Basic and advanced search for publications by keywords (with logical operators), author(s), and publication date range; include citation-based criteria.
  - View search results with pagination; sort results by title, author, year.
  - Similarity exploration: find publications by the same author(s), by the same institute, or cited/related works.
  - View details for a single or multiple publications (title, authors, date, abstract, cited references).
  - View author information.

- Content access and export
  - Display full text where available (abstract or full publication).
  - Download single or multiple publications.
  - Export/download search results or publications in HTML, PDF, and PS.
  - Export references of a publication in BibTeX (BIB) and RIS formats.

- Publication management
  - Upload publications (PDF, PS) using BibTeX or RIS metadata; automatic extraction of bibliographic data from full text or abstract with manual correction.
  - Normalize entities by linking equivalent author and institute names (e.g., “D. Vermeir” = “Dirk Vermeir”; “VUB” = “Vrije Universiteit Brussel”).
  - Bulk upload/import multiple publications or abstracts.
  - Edit publications:
    - Publishers: edit own publications; access “My Publications.”
    - Moderators: edit departmental publications.
    - Administrators: edit any publication.

- User, group, and permissions administration
  - Manage user accounts and roles/levels:
    - Moderators: upgrade/downgrade users within their department; manage group permissions; edit author records.
    - Administrators: create/delete users; create/search/edit/delete groups; change any user’s role; access control panel; edit system configuration settings.
  - Enforce role-based access control across all functions.

- Operational support
  - Present user-facing error messages on failures; log errors for administrators.
  - Command-line interface access for administrators on the server.

Role-based access summary
- Guest: register, validate account, log in, retrieve password.
- VUB-network user: search, view, sort, explore similarity, download/export results; no upload/edit.
- Member: VUB-network user functions plus manage own account and log off.
- Publisher: Member functions plus upload, bulk upload, entity normalization, edit own publications, “My Publications.”
- Moderator: Publisher functions plus manage user levels (departmental), manage group permissions, edit authors, edit departmental publications.
- Administrator: Moderator functions plus full user/group management, system configuration, and edit all publications.

Optional/future functions (if implemented)
- Support additional document formats (e.g., MS Word).
- Show, in results, the list of documents that cite a given publication.
- Automatic recognition of equivalent author/institute names.
- Fetch full texts via referenced URLs from metadata-only (e.g., BibTeX) uploads.
- Extend to audio/video uploads with automatic recognition.

### 1.3.3 User characteristics

The PMS is intended for academic personnel and students of the VUB (and external users with accounts), with varied technical backgrounds. All users are expected to have basic Internet skills and to access the system primarily via a web browser; some administrative users may access the system via a command line on the VUB server.

General characteristics influencing usability:
- Educational level: academic staff and university students.
- Experience: basic familiarity with web browsing and online forms; ability to perform keyword-based searches.
- Technical expertise: varies by role; most users use a web interface on any OS (including text-based browsers on Linux), while Administrators use command-line and server shell access.
- Disabilities: [N/A]

Intended user groups and role-related characteristics:
- Guest
  - Anonymous, unregistered users.
  - Needs are limited to account registration, login, and password retrieval.
  - Minimal technical skill beyond basic web use.

- VUB-Network User
  - On-campus users identified by VUB IP address; not logged in.
  - Can search and download publications.
  - Requires ability to form search queries and navigate result lists.

- Member
  - Registered and logged-in user.
  - Same search/download capabilities as VUB-Network Users, plus account management (e.g., change password, email).
  - Basic proficiency with account settings.

- Publisher
  - Logged-in user who uploads publications.
  - Must be able to provide documents in supported formats (e.g., pdf, ps) and review/correct automatically extracted bibliographic data (e.g., author, title).
  - Familiarity with publication metadata entry and correction.

- Moderator
  - Logged-in user with departmental responsibilities.
  - Edits departmental publications, manages user levels within the department, and adjusts group permissions.
  - Requires understanding of departmental structure and moderate administrative proficiency.

- Administrator
  - Full system control, including creating/deleting users and groups, editing any publication, and changing system configuration.
  - May access the system via command line on the VUB server; must be proficient with shell/CLI operations and system administration tasks.

### 1.3.4 Limitations

- Regulatory requirements and policies:
  - The web interface must comply with W3C XHTML 1.0 Transitional.
  - Only free software may be used for tools and the end product.
  - Implementation must follow SE1 coding conventions and use UML for design diagrams.
  - Use of Git for configuration management is mandated.
  - Use of frameworks is not allowed.

- Hardware/OS limitations:
  - The system must run on Linux, specifically on the Wilma server.
  - Requires Ruby 1.8 (or later).
  - No specific hardware requirements for end users are stated.
  - No specific limit on application memory usage; publication file size has a maximum size that is TBD.

- Interfaces to other applications:
  - MySQL database backend.
  - Web access via standard browsers, including text-based browsers (e.g., Links2).
  - Command Line Interface access for administrators on the Wilma machine.
  - Supported import/export formats are limited to BibTeX and RIS for references; export of publications to HTML, PDF, and PS; upload of publication documents limited to PDF, PS, and ODT.

- Parallel operation:
  - The database must handle several requests at once; no additional constraints on parallel operation are specified.

- Audit functions:
  - Errors during requests must generate user-visible messages and be logged to notify administrators.
  - No comprehensive audit trail of user actions is specified.

- Control functions:
  - Role-based access control (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator) governs functionality.
  - Administrator Control Panel exists, but its full capabilities are deferred (“to be implemented later”).

- Higher-order language requirements:
  - Implementation must be in Ruby and object-oriented.
  - Code documentation must use RDoc.
  - Use of frameworks is prohibited.

- Signal handshake protocols:
  - Communication is limited to HTTP over TCP/IP port 80; no low-level signal handshake protocols (e.g., XON/XOFF, ACK/NACK) are specified.

- Quality requirements (e.g., reliability):
  - Availability depends on the Wilma server’s availability.
  - Database backup and restore are required; recovery relies on administrator action.
  - Performance requirements are TBD.

- Criticality of the application:
  - [N/A]

- Safety and security considerations:
  - Passwords must be encrypted in transit and stored encrypted.
  - Direct database access is restricted to administrators via CLI.
  - User level permissions must be enforced for editing, deleting, and uploading publications.
  - Access from outside the VUB network is permitted only for logged-in users.
  - No additional safety measures are specified.

- Physical/mental considerations:
  - Users are expected to have basic knowledge of the internet.
  - No additional accessibility or ergonomic requirements are specified.

- Limitations sourced from other systems (including real-time requirements):
  - HTTP traffic must be permitted between clients and the server; only port 80 is specified.
  - CLI users require shell access on the server and consequently hold administrator privileges.
  - No real-time constraints are specified.

## 1.4 Definitions

- Publications Management System (PMS): The system described in this SRS that manages a database with bibliographical information and can store the full text of publications (PDF, PS). It is accessible via a web browser and a command line.

- Customer: The person(s) who pay for the product and usually (but not necessarily) decide the requirements. In this context the customer and the supplier may be members of the same organization.

- Supplier: The person(s) 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(s) who operate or interact directly with the product. The user(s) and the customer(s) are often not the same person(s).

- User levels: A hierarchical set of roles where each role inherits all functions of the preceding one: Guest, VUB-Network User, Member, Publisher, Moderator, Administrator.

- Guest: An anonymous user not connected to the VUB-network; only allowed to register or log in.

- VUB-Network User: A user connected to the VUB-network but not logged in. Recognized by IP address and allowed to access the database, search for publications, and download them.

- Member: A logged-in user allowed to search for publications and download them.

- Publisher: A logged-in user allowed to search for, upload, and download publications.

- Moderator: A logged-in user with the same functions as a Member, extended with the authority to edit and delete publications.

- Administrator: A logged-in user with all moderator capabilities and responsibility for the technical aspects of the PMS. Can change user account levels and expel registered users.

- Bulk Update (Bulk Uploading): Importing many publications (or abstracts) at once (e.g., through BibTeX files).

- Author: An entity explicitly known by the system (name, first name, institute, …). Users can manually indicate that different name variants (e.g., “D. Vermeir” and “Dirk Vermeir”) refer to the same author.

- Institute: The organizational affiliation associated with authors. Users can manually indicate equivalent variants (e.g., “VUB” and “Vrije Universiteit Brussel”).

- VUB-network: The network of the Vrije Universiteit Brussel used by the system to recognize connections (by IP address) and grant VUB-Network User privileges to non-logged-in users.

- Wilma: A multifunctional Linux server for students of the faculty of sciences at the VUB; the PMS is developed to run on Wilma.

- CLI (Command Line Interface): Text-based access to the system from the server. A CLI user is assumed to access the Wilma machine locally and is accredited with Administrator privileges.

- BibTeX: A tool for formatting lists of references, typically used together with the LaTeX document preparation system.

- RIS: A tagged file format for expressing bibliographic citations.

- RDoc: A document generator for Ruby source code.

- Publication: A record in the system containing bibliographical details and, when available, the abstract and/or full text (PDF or PS).

- Reference: A bibliographical citation cited by a publication; can be viewed and exported (e.g., in BibTeX or RIS format).

# 2 References

This section lists all documents cited in the SRS, subdivided into Compliance (normative, containing requirements adopted by citation) and Guidance (informative). For each reference, the title, report number (if applicable), date, publishing organization, and the source from which it can be obtained are identified where available. Any missing information from the original SRS is indicated as [N/A].

## Compliance

- W3C XHTML 1.0 Transitional standard
  - Title: W3C XHTML 1.0 Transitional standard
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: World Wide Web Consortium (W3C)
  - Source: http://www.w3.org/TR/xhtml1/
- Coding Conventions of SE1
  - Title: Coding Conventions of SE1
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: SE1
  - Source: http://wilma.vub.ac.be/~se1_0708/docs/coding_conventions/conventions.pdf
- Unified Modelling Language (UML) standard
  - Title: Unified Modelling Language
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://www.uml.org/

## Guidance

- IEEE Std 830-1998
  - Title: [N/A]
  - Report number: IEEE Std 830-1998
  - Date: [N/A]
  - Publishing organization: Institute of Electrical and Electronics Engineers (IEEE)
  - Source: http://www.scribd.com/doc/2620639/IEEE-8301998
- Software Engineering course (VUB)
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: Vrije Universiteit Brussel (VUB)
  - Source: http://tinf2.vub.ac.be/~dvermeir/courses/software_engineering/projects/2007-2008/index.html
- Git
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://git.or.cz/
- IEEE (organization site)
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: Institute of Electrical and Electronics Engineers (IEEE)
  - Source: http://www.ieee.org/
- RDoc
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://rdoc.sourceforge.net/
- SE1 group site
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: Vrije Universiteit Brussel (VUB)
  - Source: http://wilma.vub.ac.be/~se1_0708/
- Vrije Universiteit Brussel (VUB) site
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: Vrije Universiteit Brussel (VUB)
  - Source: http://www.vub.ac.be
- World Wide Web Consortium (W3C) site
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: World Wide Web Consortium (W3C)
  - Source: http://www.w3.org/
- Software Quality Assurance Plan (SQAP)
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: SE1
  - Source: http://wilma.vub.ac.be/~se1_0708/docs/sqap/sqap.pdf
- Software Test Plan (STD)
  - Title: [N/A]
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: SE1
  - Source: TBDstdlink
- Software Configuration Management Plan (SCMP)
  - Title: Software Configuration Management Plan
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: [N/A]

## 3.1 Functions

This section defines the fundamental software actions to accept/process inputs and to generate outputs for the Publications Management System (PMS). Functions are grouped by sub-process. For each, input validity checks, exact operation sequences, responses to abnormal situations, parameter effects, and input/output relationships are stated where available.

### 3.1.1 Access and session management

- Register account
  - Inputs
    - Username, password, name, email address, university, department.
  - Validity checks
    - Username must not already exist.
    - Email address must be provided and valid.
  - Sequence
    - User selects Register.
    - User enters required data and confirms.
    - System checks username uniqueness.
    - System sends a validation email to the user to confirm registration.
    - System sends a notification email to the Administrator.
  - Outputs
    - Confirmation of registration request.
    - Validation email sent to user; notification email sent to Administrator.
  - Abnormal responses
    - If username exists: registration is rejected; error is shown and logged.

- Validate new account
  - Inputs
    - Validation action initiated from received email.
  - Validity checks
    - Validation token/link must be present and unexpired. [N/A]
  - Sequence
    - User follows validation email.
    - System activates the account. [N/A]
  - Outputs
    - Account becomes usable for login. [N/A]
  - Abnormal responses
    - Invalid/expired validation: show error and log. [N/A]

- Log in (internet or VUB network)
  - Inputs
    - Username and password (internet access) or optional login when on VUB network (recognized by IP).
  - Validity checks
    - User must be registered (except guest/VUB-network user without login).
    - Password is verified; password is encrypted in transit and stored encrypted.
  - Sequence
    - User opens login screen (internet) or search/login screen (VUB network).
    - User provides credentials (if logging in).
    - System verifies credentials and establishes a session with the correct user level (Member, Publisher, Moderator, Administrator).
  - Outputs
    - Authenticated session; access to functions per user level.
  - Abnormal responses
    - Invalid credentials: show error and log.

- Retrieve/change password
  - Inputs
    - Username; new password (for change).
  - Validity checks
    - Username must exist.
  - Sequence
    - User requests password change.
    - User provides username and new password and confirms.
    - System updates password and sends an email to the Administrator.
  - Outputs
    - Confirmation of password change.
  - Abnormal responses
    - Unknown username: show error and log.

- Log off
  - Inputs
    - Logout action.
  - Sequence
    - User selects Logout.
    - If user is on VUB network, redirect to search page; otherwise redirect to login page.
  - Outputs
    - Session terminated; redirect as above.

### 3.1.2 Search and discovery

- Search
  - Inputs
    - Keywords (with logical expressions and symbols), author names (ranked), publication date range; optional advanced criteria (additional keyword(s) and/or publications that refer to it).
  - Validity checks
    - Search fields accept text/date formats; date range consistency.
  - Sequence
    - User opens search form (available to VUB-network users and logged-in users).
    - User enters criteria and submits.
    - System queries the database.
    - System presents a paginated result list.
  - Outputs
    - List of publications matching criteria (title and main author shown).
  - Abnormal responses
    - No results: show empty result message.

- Order and refine results
  - Inputs
    - Ordering choice: title, author(s), year; similarity request (same author, same institute, cited/mentioning publications).
  - Sequence
    - User selects ordering or similarity option on the results page.
    - System re-queries or re-sorts accordingly.
  - Outputs
    - Reordered results; result sets by similarity.

- View details (single or multiple)
  - Inputs
    - Selection of one or more results; View command.
  - Sequence
    - User clicks title/View button (single) or selects items/“View All” (multiple).
    - System shows details: title, authors, publication date, abstract, cited references, etc.
  - Outputs
    - One or more detail views.

- View author
  - Inputs
    - Click on an author name.
  - Sequence
    - System shows author details.
  - Outputs
    - Author information page.

### 3.1.3 Accessing content and exports

- Display full text
  - Inputs
    - Full text request from a publication detail page.
  - Validity checks
    - Full text must be available in the system.
  - Sequence
    - User clicks Full Text.
    - System retrieves and displays the full text.
  - Outputs
    - Rendered full text.
  - Abnormal responses
    - If full text unavailable: show error.

- Download publications
  - Inputs
    - Download request for a single item, selected items, or all results.
  - Sequence
    - From results or detail view, user clicks Download (single) or Download All (multiple).
    - System prepares files for download.
  - Outputs
    - Electronic copy/copies of publication(s) (supported formats include pdf, ps, odt as available).
  - Abnormal responses
    - Missing file: show error and log.

- Export publications (results)
  - Inputs
    - Selection of one or more results; export format selection: html, pdf, ps.
  - Sequence
    - User selects items and export format; confirms export.
    - System renders/export-transforms publications to selected format.
  - Outputs
    - Downloadable exported files in chosen format.

- Consult references
  - Inputs
    - Reference button click for a publication; “references for all” on the results page.
  - Sequence
    - System retrieves references cited by the selected publication(s).
  - Outputs
    - List/detail of cited references with title, authors, publication date, abstract, cited references.

- Export references
  - Inputs
    - Format selection: BibTeX (BIB) or RIS from the publication detail page.
  - Sequence
    - User selects format; confirms.
    - System converts the publication’s references to the selected format.
  - Outputs
    - File with references in BIB or RIS format.

### 3.1.4 Publication management

- Upload publication (Publisher/Moderator/Administrator)
  - Inputs
    - Document file in supported formats: pdf, ps, odt.
  - Validity checks
    - File exists; format supported; maximum file size TBD.
  - Sequence
    - User selects Upload, chooses a file, and confirms.
    - System extracts bibliographic metadata (author, title, etc.) from full text or abstract.
    - System presents the extracted metadata for review.
    - User accepts or corrects metadata and confirms.
  - Outputs
    - New publication stored with metadata and file.
  - Abnormal responses
    - Unsupported/invalid file: show error and log.
    - Extraction failure: present empty/partial fields for manual correction.

- Bulk upload (Publisher/Moderator/Administrator)
  - Inputs
    - Metadata file(s) in BibTeX or RIS; optional referenced URLs to full texts.
  - Validity checks
    - File follows BibTeX/RIS format.
  - Sequence
    - User selects Bulk Upload, provides file(s), and confirms.
    - System parses metadata and creates/imports multiple publications (or abstracts).
    - User reviews and confirms.
  - Outputs
    - Multiple publications/records added.
  - Abnormal responses
    - Parse errors: show error summary; log; allow correction/retry.

- Edit publication
  - Inputs
    - Edit request; modified metadata fields.
  - Validity checks
    - Authorization: Publisher may edit own publications; Moderator may edit department/group publications; Administrator may edit any publication.
  - Sequence
    - User opens publication, edits fields, confirms changes.
    - System validates and saves.
  - Outputs
    - Updated publication record.
  - Abnormal responses
    - Insufficient privileges: show error and log.

### 3.1.5 User and group administration

- Search users (Moderator/Administrator)
  - Inputs
    - Search criteria.
  - Sequence
    - User enters criteria; system returns matching users.
  - Outputs
    - User list.

- Edit user settings (Moderator/Administrator)
  - Inputs
    - Selected user; modified settings (e.g., account details, level within allowed scope).
  - Validity checks
    - Authorization: Moderators limited to their jurisdiction; Administrators unrestricted.
  - Sequence
    - User selects target user, edits settings, confirms.
    - System applies changes.
  - Outputs
    - Updated user account.

- Manage user levels
  - Inputs
    - Target user; target level.
  - Validity checks
    - Moderator can upgrade/downgrade users in own department between Member and Publisher; Administrator can change any user level.
  - Sequence
    - Actor selects user and target level; confirms.
    - System updates level.
  - Outputs
    - Changed privileges.

- Create/Delete user (Administrator)
  - Inputs
    - Create: username, password, email, group; Delete: username.
  - Validity checks
    - Create: username must be unique; Delete: username must exist.
  - Sequence
    - Create: enter details; confirm; system creates user.
    - Delete: enter username; system shows details; confirm; system deletes user.
  - Outputs
    - User created or deleted.
  - Abnormal responses
    - Username conflict or not found: show error and log.

- Group management (Administrator)
  - Inputs
    - Create group: group name, users; Search group: criteria; Delete group: group name; Edit group settings: changes.
  - Validity checks
    - Create: group name must be unique.
    - Delete: group must exist and be empty (no users).
  - Sequence
    - Create/Search/Delete/Edit per described inputs; confirm changes.
  - Outputs
    - Group created, listed, deleted, or updated.
  - Abnormal responses
    - Name conflict, non-empty group on delete, or not found: show error and log.

- System configuration (Administrator)
  - Inputs
    - Configuration changes from control panel.
  - Sequence
    - Administrator opens control panel, changes settings, confirms.
  - Outputs
    - Configuration changes applied.

### 3.1.6 Error handling, logging, and abnormal situations

- General error handling
  - For any request error, the system displays an error message stating the cause and logs the error to notify Administrator(s).

- Overflow
  - [N/A]

- Communication facilities
  - Normal operation uses HTTP over TCP/IP port 80.
  - Response to communication failures: [N/A]

- Hardware faults and failures
  - If the PMS is temporarily down (e.g., Wilma unavailable), users receive a message indicating temporary unavailability.
  - In case of a corrupted database, the Administrator replaces it with the last available backup.

- Error recovery
  - After resolving failures (hardware or software), the PMS is reinitialized; during downtime an error is shown to visitors.

### 3.1.7 Effects of parameters

- User level (Guest, VUB-network user, Member, Publisher, Moderator, Administrator) determines accessible functions (e.g., upload/edit scope, administration actions).
- Network context (VUB IP vs. outside) affects access: anonymous VUB-network users can search and download; guests can only register/login.
- Search parameters (keywords, authors, date range, advanced criteria) filter result sets; ordering parameters change result ordering.
- Selection parameters (checked items, “All”) determine the scope of view/download/export actions.
- Export format parameters (html, pdf, ps, BIB, RIS) determine the produced output file format.
- Group/user selection parameters scope administrative edits and deletions.
- File parameters (type, size TBD) affect upload acceptance and metadata extraction behavior.

### 3.1.8 Input/output relationships

- Authentication inputs (username/password) produce an authenticated session or an error.
- Registration inputs produce a pending account plus validation and notification emails; validation produces an active account.
- Search inputs produce a paginated list of matching publications; ordering inputs re-sequence the same set.
- View inputs (selection) produce one or more detailed publication views.
- Reference consult inputs produce lists/details of cited references.
- Export inputs (selection + format) produce downloadable files in the chosen format.
- Upload inputs (file) produce a new publication record with extracted metadata, subject to user confirmation.
- Edit inputs (modified fields) update publication/user/group records if authorized.
- Formulas for input-to-output conversion
  - [N/A]

## 3.2 Performance requirements

- Capacity (static numerical requirements)
  - Number of terminals/clients to be supported: [N/A]
  - Maximum number of simultaneous users/sessions: [N/A]
  - Amount and type of information to be handled:
    - Types: bibliographic records (publications, authors, institutes), user and group accounts, configuration data, statistics; full-text files (PDF, PS; ODT also referenced).
    - Maximum publication file size: TBD.
    - Total storage capacity for publications and metadata: [N/A]
  - Memory usage limits: No specific limit on PMS memory usage stated.

- Dynamic performance requirements
  - Normal-load transaction throughput (search, view, download, upload) and response times: [N/A]
  - Peak-load transaction throughput and response times: [N/A]
  - Concurrency:
    - The database must handle several requests at once (quantitative limit): [N/A]
  - Bulk operations (e.g., bulk upload/import) processing rates and completion times: [N/A]
  - Backup and restore time objectives (RTO/RPO): [N/A]

- Network performance
  - Communication uses HTTP over TCP/IP port 80.
  - Required bandwidth/latency for acceptable operation: [N/A]

## 3.3 Usability requirements

- Contexts of use and users
  - The system shall be usable by academic personnel and students with basic knowledge of the internet.
  - The system shall be usable from any OS via a web browser; it shall be explicitly accessible for users on Linux with a text-based browser (e.g., Links2).
  - Administrators may operate the system via a command line interface from within the VUB-network.

- Effectiveness (task completion)
  - The web interface shall provide clear structure and navigation so that users can complete core tasks (register, log in/out, search, view details, download, upload, edit within role permissions) without unnecessary steps.
  - All functions and options shall be available in the least amount of clicks while maintaining structure.
  - The web interface shall emphasize clarity and structure over aesthetics.
  - Measurable targets:
    - Task success rate for core tasks: [N/A]
    - User error rate during core tasks: [N/A]

- Efficiency (time and effort)
  - The web interface shall be designed to be fast and efficient, enabling tasks (upload, download, search, etc.) in the smallest number of pages and clicks.
  - Measurable targets:
    - Average time-on-task for searching and downloading a publication: [N/A]
    - Average number of page transitions/clicks for core tasks: [N/A]

- Satisfaction (perceived quality)
  - The web interface shall be attractive, simple, and standard-compliant (W3C XHTML 1.0 Transitional), with clarity and structure being very important.
  - Measurable targets:
    - User satisfaction rating (e.g., post-task or overall usability score): [N/A]
    - Learnability (time to first successful search by a new user): [N/A]

- Accessibility and compatibility
  - The web interface shall comply with W3C XHTML 1.0 Transitional.
  - There shall be no specific hardware requirements for users.
  - The system shall support use via text-based browsers on Linux.
  - Measurable targets:
    - Browser and assistive technology compatibility coverage: [N/A]
    - Conformance to additional accessibility guidelines beyond XHTML conformance: [N/A]

- Feedback, guidance, and error handling
  - If an error occurs during a request, the user shall receive an error message stating the cause of the error.
  - Errors shall be logged to notify administrators of technical difficulties.
  - During downtime, the system shall inform visitors that the PMS is temporarily down.
  - Measurable targets:
    - Presence and clarity of user-facing error messages for defined error classes: [N/A]
    - Mean time to recover (from user perspective) after a recoverable error: [N/A]

- Freedom from risk (quality in use)
  - User levels and access control shall always be respected for editing, deleting, and uploading publications to prevent unauthorized changes through the user interface.
  - User passwords shall be encrypted in transit and at rest; only the PMS shall have access to stored passwords. Direct database access is allowed only for administrators using the CLI.
  - Measurable targets:
    - Number of unauthorized changes achievable via the UI under normal use: [N/A]
    - Incidents of sensitive information exposure through UI messages: [N/A]

## 3.5 Logical database requirements

General
- All static and dynamic information required by the PMS (publications, metadata, user and group information, configuration, statistics) shall be stored in a database and remain consistent at all times (no pointers to deleted records, no redundant information).
- The database shall handle concurrent requests issued via SQL statements.
- A backup structure is required to allow restoration in case of server or disk problems.

a) Types of information used by various functions
- Registration, login, account management:
  - User accounts, credentials, email, name, department/institute affiliation, account status, user level/role, validation tokens for account confirmation.
- Access control and grouping:
  - User roles/levels (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator), Groups/Departments, group permissions.
- Publication lifecycle (upload, edit, delete, bulk import):
  - Publications (title, abstract, year/date), metadata extracted from files (author list, institute, keywords), source files (pdf, ps, odt), file-format metadata, uploader/owner linkage, bulk import batches (e.g., BibTeX/RIS), manual corrections history.
- Search, view, download, export:
  - Publications, Authors, Institutes, Keywords, citation references (publication-to-publication), search parameters, export jobs for references (Bib/RIS), download events.
- Similarity and aliasing:
  - Author aliases (e.g., “D. Vermeir” ≡ “Dirk Vermeir”), Institute aliases (e.g., “VUB” ≡ “Vrije Universiteit Brussel”).
- Administration:
  - Users, Groups, group membership, configuration settings, system statistics.
- Error reporting:
  - Error logs for failed requests and system issues.

b) Frequency of use
- High frequency: search, view results and publication details, downloads, author/institute lookups.
- Medium frequency: uploads (single), edits of own publications, exports (Bib/RIS).
- Low frequency: bulk uploads, user and group administration, configuration changes.
- Event-driven/occasional: error logging, password retrieval/change, account validation.

c) Accessing capabilities
- Read operations:
  - Query publications by keyword, author(s), institute, and publication date range.
  - Retrieve publication details, authors, affiliations, references, and full text/abstract when available.
  - View author details; list publications by same author/institute; consult references and referenced-by when present.
- Write operations:
  - Create/update/delete publications (subject to role and ownership).
  - Bulk import metadata/publications via BibTeX/RIS.
  - Manage users and groups; update user levels within permitted scope.
  - Update configuration settings.
- Export operations:
  - Export references of a publication in Bib or RIS format.
- Concurrency:
  - Concurrent reads and writes must be supported without breaking consistency.
- Interfaces:
  - All database access is mediated by the web server or CLI; direct database access is restricted to Administrators via CLI.

d) Data entities and their relationships
- User:
  - Attributes: username, password hash, email, name, department/institute, role/level, status, created/updated timestamps, validation token/state.
  - Relationships: belongs to zero or more Groups; owns zero or more Publications; created/updated by (audit) relationships.
- Role/UserLevel:
  - Predefined levels: Guest, VUB-Network User, Member, Publisher, Moderator, Administrator.
  - Relationship: assigned to User.
- Group/Department:
  - Attributes: group name, description.
  - Relationships: has Users; may scope Moderator permissions; may own Publications at departmental level.
- Publication:
  - Attributes: title, abstract, publication date/year, keywords, uploader/owner, created/updated timestamps, availability flags (full text/abstract).
  - Relationships: has many PublicationFiles; has many Authors via Authorship; has optional Institute affiliations; cites many Publications and is cited by many Publications (References); may belong to a Group/Department.
- PublicationFile:
  - Attributes: format (pdf, ps, odt), file size (max size TBD), storage path/URI, checksum, availability.
  - Relationship: belongs to Publication.
- Author:
  - Attributes: full name, normalized name fields.
  - Relationships: has many Publications via Authorship; may belong to or be affiliated with an Institute; may have many Aliases.
- Authorship (junction):
  - Attributes: author order/rank, corresponding-author flag.
  - Relationships: links Author and Publication (many-to-many).
- Institute:
  - Attributes: official name.
  - Relationships: has many Authors; may be linked to Publications; may have many Aliases.
- Alias (AuthorAlias, InstituteAlias):
  - Attributes: alias string, canonical reference.
  - Relationships: maps many aliases to one canonical Author or Institute.
- Reference/Citation:
  - Attributes: optional citation context.
  - Relationships: Publication cites Publication (self-referential many-to-many).
- ImportBatch:
  - Attributes: source type (BibTeX/RIS), status, log.
  - Relationships: creates many Publications and related entities.
- ExportJob:
  - Attributes: format (Bib/RIS), scope (single publication), created timestamp, status.
- Configuration:
  - Attributes: key/value settings affecting system behavior.
- ErrorLog:
  - Attributes: timestamp, user (if any), request context, error code/message, stack trace or details.
- Statistics:
  - Attributes: aggregated counters (e.g., searches, downloads), timestamps.

e) Integrity constraints
- Uniqueness:
  - Username and group name must be unique.
  - A Publication may not contain duplicate Authors for the same rank/order.
  - Author and Institute canonical records unique per normalized name.
- Not-null and validity:
  - Required fields must be present: for User (username, password hash, email, role), for Publication (title, publication date/year, owner/uploader), for PublicationFile (format, path/URI).
  - File size must not exceed the maximum allowed size (TBD).
- Referential integrity:
  - All foreign keys must reference existing records (no dangling references), including Authorship, PublicationFile, Group membership, References, Aliases.
  - Deleting an Author/Institute with dependencies is disallowed unless no dependent records remain or appropriate cascades/soft deletes are defined.
  - Deleting a Publication must prevent orphaned PublicationFiles, Authorships, and References; apply cascading deletes where appropriate.
- Normalization:
  - Author, Institute, and Alias data shall be normalized to avoid redundancy; alias mappings shall resolve to a single canonical record.
- Ownership and scope:
  - Publication.owner must reference an existing User.
  - Departmental ownership, when used, must reference an existing Group/Department.
- Concurrency and transactions:
  - Multi-step updates (e.g., upload with metadata extraction, bulk import) must be atomic; partial writes must be rolled back on failure.

f) Security
- Credentials:
  - Passwords shall be stored in the database only in encrypted/hashed form; no plaintext passwords.
  - Passwords must be encrypted in transit when submitted from user to server.
- Access control:
  - CRUD operations on Publications, Users, and Groups must be authorized according to user level and ownership/group rules defined in the system.
  - Direct database access is restricted to Administrators using the CLI.
- Data exposure:
  - Only data required for the requested function is returned; sensitive fields (e.g., password hashes, validation tokens) must never be exposed via interfaces.
- Logging:
  - Security-relevant events and errors are logged without storing sensitive secrets in plaintext.

g) Data retention requirements
- Backups:
  - The database must support periodic backups and restoration from the last available backup.
  - Backup schedule, media, and retention duration are [N/A].
- Operational retention:
  - Retention periods for user accounts, publications, files, logs, and statistics are [N/A].
- Deletion:
  - Requirements for soft-delete vs hard-delete behavior and data erasure policies are [N/A].

## 3.6 Design constraints

The PMS design is constrained by the following external standards and project limitations:

- The web interface must comply with the W3C XHTML 1.0 Transitional standard.
- Design diagrams must follow the UML standard.
- The implementation must comply with the SE1 coding conventions.
- The system must be implemented in Ruby, using an object-oriented approach, and run with Ruby 1.8 or later.
- The use of frameworks is not allowed.
- Source code must be documented using RDoc.
- Git must be used for configuration management.
- The database must be MySQL.
- The system must run on a Linux-based environment and be deployable on the Wilma server.
- Communication between clients and the system must use HTTP over TCP/IP port 80.
- The system must be accessible via web browsers on any OS, explicitly including support for a text-based browser (e.g., Links2).
- Administrators must be able to access the system via a command line interface from within the VUB-network.
- Only free software may be used for development tools and for the end product.
- The web interface should be attractive and simple, with all functions available in the least number of clicks while maintaining structure.

## 3.7 Software system attributes

### Reliability
- The PMS shall be developed to minimize software faults.
- The project uses a spiral model with two iterations to reduce defects; testing activities are defined in the SQAP and STD.
- If an error occurs during a request, the user shall receive an error message stating the cause, and the error shall be logged to notify the Administrator(s).

### Availability
- The PMS shall be available at all times from any computer that fulfills the stated assumptions and dependencies, except when the Wilma server is not available.
- A backup structure shall exist to preserve all data in case of server or disk problems.
- In case of a corrupted database, the Administrator shall restore from the last available backup; in case of other failures (hardware or software), the problem shall be resolved and the PMS reinitialized.
- During downtime, the PMS shall inform visitors that the system is temporarily unavailable.

### Security
- Each user account shall be protected by a personal password; only the account owner shall be able to log in and change personal information.
- Passwords shall be encrypted in transit and stored in encrypted form in the database; no one except the PMS shall access stored passwords.
- Direct access to stored data shall be restricted to Administrator(s) using the command line interface.
- User levels and associated permissions shall be enforced for editing, deleting, and uploading publications and their bibliographical details.

### Maintainability
- The database shall be maintained by the Administrator(s).
- Global maintenance of user levels and special privileges shall be performed by Administrator(s); at departmental level, Moderator(s) shall maintain the PMS accordingly.

### Portability
- The PMS is developed and tested to run on the Wilma (Linux-based) server.
- Relocation to a server with a different operating system is possible if all necessary software is available and appropriate adjustments are made; this has not been fully implemented.

## 3.8 Supporting information

This section consolidates auxiliary information that supports understanding and use of the SRS. Unless explicitly referenced as a requirement elsewhere in this SRS, the items below are informational only and not, by themselves, binding requirements.

a) Sample inputs/outputs and related artifacts
- User account inputs
  - Registration data: name, username/login name, password, email address, university, department.
  - Account management: change password, change profile details (e.g., password, email, university, department).
- Search inputs
  - Basic: keywords (with logical operators such as AND, OR, NOT and quote symbols), author(s), publication date range.
  - Advanced: additional keyword(s) and/or cited reference constraints.
- Upload inputs
  - Document formats accepted for upload: pdf, ps, odt.
  - Metadata formats for ingest/bulk upload: BibTeX, RIS.
- System outputs
  - Search results list (sortable by title, author(s), year).
  - Publication detail view: title, authors, publication date, abstract, cited references.
  - Full text display (when available) and file download.
  - Export of publications/results: html, pdf, ps.
  - Export of references: BibTeX (BIB) and RIS.
  - Error messages presented to users; errors logged for administrator notification.
- Interfaces (I/O channels)
  - Web access over HTTP (TCP/IP port 80) using standards-compliant browsers (including text-based).
  - Command Line Interface available on the server for administrators.

b) Supporting/background information
- User role hierarchy and access model
  - Guest: register, log in, validate account, retrieve password.
  - VUB-Network User: anonymous access from VUB network; can search, view, download.
  - Member: authenticated; search, view, download; manage own account and log off.
  - Publisher: all Member capabilities plus upload publications (single/bulk), edit own publications.
  - Moderator: Publisher capabilities plus edit departmental publications; manage user levels within department; manage group permissions; edit author data.
  - Administrator: full system management; user/group lifecycle and levels; edit any publication; access control panel.
- Execution environment and standards
  - Runs on a Linux-based server (Wilma) with Ruby 1.8 or later; uses a MySQL database and a web server.
  - Web interface conforms to W3C XHTML 1.0 Transitional.
  - Object-oriented implementation; UML for design diagrams; SE1 coding conventions.
  - Tooling: Git for configuration management; RDoc for code documentation.
  - Only free software to be used for tools and end product.
- Operational assumptions
  - Users require a standards-compliant web browser and network connectivity allowing HTTP.
  - CLI users access the server shell and have administrator privileges.

c) Problem description (context and goals)
- Provide a Publications Management System that:
  - Manages bibliographic records and associated full texts (pdf/ps) in a centralized database with backup.
  - Enables efficient search, filtering, viewing, exporting, and downloading of publications.
  - Supports automatic extraction of bibliographic metadata from uploaded documents, with manual correction when needed.
  - Allows users to assert equivalence of author and institute variants (e.g., name synonyms).
  - Supports bulk ingestion of publications/abstracts via standard bibliographic formats (BibTeX/RIS).
  - Enforces access control based on network origin (VUB vs. external) and authenticated roles.
  - Provides administrative functions for user and group management, and moderation of departmental content.

d) Special packaging and media instructions
- Installation and packaging
  - The PMS should be easy to install on a Linux-based environment with Ruby 1.8 (or later) installed. Detailed easy-install method: TBD.
- Security/export/initial loading instructions
  - [N/A] (no specific packaging instructions for security, export compliance, media handling, or initial loading are provided in this SRS).

Normative status of this information
- The details above are supporting information. Where the same items are specified within the Requirements (e.g., supported formats for upload/export, role capabilities, interface standards), those instances are binding requirements. Otherwise, the information in this section is non-normative and provided for clarity.

## 4.1 Functions

This section defines the verification approaches and methods planned to qualify the software functions described in the Requirements, with coverage aligned to: a) input validity checks; b) exact sequence of operations; c) responses to abnormal situations (overflow, communication facilities, hardware faults/failures, error handling and recovery); d) effect of parameters; and e) relationship of outputs to inputs (input/output sequences and formulas). Detailed procedures and test cases are to be provided in the Software Test Plan (STD) and Software Quality Assurance Plan (SQAP) referenced in the SRS.

- Input validity checks (a)
  - Authentication and account lifecycle
    - Login: verify required fields, valid credentials, encrypted transmission and storage of passwords, rejection of invalid or missing credentials, and informative error messages logged by the PMS.
    - Registration: verify uniqueness of username, required fields (name, login name, email, university, department, password), email format, and that submission triggers Administrator notification email.
    - Password change/retrieval: verify valid username required, new password policy checks [N/A], and Administrator email notification.
  - Access policy by location
    - VUB-network detection: verify access level based on IP recognition; outside VUB-network Guests can only register, log in, validate account, or retrieve password.
  - Search and results
    - Verify accepted search criteria (keywords with AND/OR/NOT and quoted phrases, authors ranked by importance, date ranges), rejection of malformed inputs, and safe handling of empty criteria.
  - Upload/edit
    - Verify supported file formats (pdf, ps, odt; bibtex/RIS for metadata) and rejection of unsupported formats; verify required mappings present to create a publication; maximum file size is TBD [N/A].
  - Administration
    - User/group creation: verify required attributes, uniqueness of usernames and group names, and constraints such as “Delete Group” requires the group to be empty.

- Exact sequence of operations (b)
  - Registration and validation: register → system checks username → system notifies Administrator → user validates account via email → user can log in.
  - Login: access login screen (internet) or login/search screen (VUB-network) → authenticate → success redirects to appropriate start page; failures show logged error.
  - Logout: logged-in user selects logout → redirect to search page if on VUB-network, else to login page.
  - Search-to-consume flow: enter criteria → receive paginated results → optional ordering/export/similarity search → select item(s) → view details → download full text (if available) → consult references → optionally view details of cited references present in system.
  - Upload flow: select document → system extracts metadata → system displays editable metadata → user confirms → publication created.
  - My Publications: invoke → list own publications → select → edit → confirm → verify changes persisted.
  - Administration flows: Search Users/Groups → select entity → edit settings → confirm; Create/Delete User; Create/Search/Delete Group (deletion only when empty).

- Responses to abnormal situations (c)
  - Overflow
    - Input length and file size limits are not specified; tests for boundary and overflow conditions will be designed when limits are defined [N/A].
  - Communication facilities
    - HTTP over TCP/IP port 80: simulate blocked or dropped connections to confirm user-facing error messages and internal logging.
    - Access control by network: attempt restricted operations as Guest outside VUB-network; verify denial with explanation and logging.
  - Hardware faults and failures
    - Web server unavailable (Wilma down): verify PMS displays a temporary-down error as specified.
    - Database corruption/restore: execute restore-from-latest-backup procedure and verify system recovery as per Availability requirements.
    - Other hardware failures and disk-full behaviors are not specified [N/A].
  - Error handling and recovery
    - For each user-visible exception in the Requirements (e.g., username exists/does not exist, group not empty, no search results, full text not available, unsupported upload format), verify:
      - Clear error message returned to the user.
      - Corresponding error logged for Administrator(s).
      - System state remains consistent; no partial writes.
    - Retry/redirect behaviors where specified (e.g., logout redirects; advanced search fallbacks).

- Effect of parameters (d)
  - User level: verify effective permissions per role hierarchy (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator), including scope limits (e.g., Moderator limited to own department/group).
  - Network location: verify capability differences when connected via VUB-network vs. outside.
  - Group membership/department: verify access to “Manage User Level(s)” and “Edit Departmental Publication(s)” is constrained to jurisdiction.
  - System configuration: verify that changes made via the Control Panel modify behavior accordingly; specific configurable parameters are not detailed [N/A].

- Relationship of outputs to inputs (e)
  - Input/output sequences
    - Search: given defined criteria, verify result lists reflect keyword logic, author importance order, and date range filters; verify ordering by title/author/year; verify pagination.
    - Export: verify selected results or publication references export to HTML/PDF/PS (results) and BibTeX/RIS (references), and files download successfully.
    - Upload: verify provided document yields extracted metadata presented for confirmation; accepted changes result in a new publication record; unsupported/invalid inputs yield errors.
    - References: verify navigation from a publication to its references and to details of references present in the system; verify aggregated references for multiple publications.
    - Access control: verify outside-VUB Guest cannot search or download; verify VUB-Network User can search and download without login; verify role-gated admin operations.
  - Formulas for input-to-output conversion
    - Specific formulas or algorithms for metadata extraction from pdf/ps/odt, keyword boolean parsing, and export format mappings are not specified; verification will be via black-box comparison of expected vs. actual outputs on representative fixtures [N/A].

Notes
- All error conditions must produce a user-visible explanation and a logged event, per the SRS.
- Conformance checks to W3C XHTML 1.0 Transitional and security of password transmission/storage will be included in testing, with implementation specifics such as cryptographic algorithms not specified [N/A].
- Detailed test cases and data sets will be maintained in the STD (reference link TBD).

## 4.2 Performance requirements

This subsection defines how the performance requirements in Section 3.2 will be verified. The original SRS does not include measurable performance requirements; therefore, the verification items below are marked as [N/A]. Performance verification procedures are deferred to the SQAP [12] and STD [13].

- Capacity (static numerical requirements: supported terminals/clients, simultaneous users, data volume): [N/A]
- Throughput and latency (dynamic numerical requirements for normal and peak workloads): [N/A]
- Transaction processing rates and timelines (e.g., searches, uploads, downloads): [N/A]
- Resource utilization limits under load (CPU, memory, storage, network I/O): [N/A]
- Concurrency handling (simultaneous requests to the database/web server): [N/A]
- Degradation behavior under stress and recovery to normal conditions: [N/A]
- Test methods (e.g., load, stress, endurance, scalability testing; measurement approach and tooling): [N/A]
- Test environment and configuration (platform, database, network configuration, datasets): [N/A]
- Acceptance criteria (quantitative pass/fail thresholds for each metric): [N/A]
- Evidence and reporting (collected metrics, logs, analysis, and test reports): [N/A]

## 4.3 Usability requirements

This section defines how the usability-related requirements and constraints stated in the SRS will be verified.

- Standards-conformant web UI (XHTML 1.0 Transitional)
  - Source: Sections 2.2.2, 2.5, 3.5
  - Verification method: Validate all user-facing pages with the W3C Markup Validation Service for XHTML 1.0 Transitional.
  - Acceptance criteria: No validation errors are reported for the pages under test.

- Support for text-based browsers on Linux (e.g., Links2)
  - Source: Section 2.2.2
  - Verification method: Perform task-based walkthroughs using a text-based browser (Links2) covering representative tasks: register/login (Sections 3.2.1, 3.2.3), search and view results/details (Sections 3.2.6–3.2.9), and download (Sections 3.2.10–3.2.11).
  - Acceptance criteria: Each task can be completed successfully in the text-based browser and required content is accessible.

- Minimal pages/clicks to complete key tasks
  - Source: Sections 2.5, 3.1.1
  - Verification method: For representative tasks—login/logoff (Sections 3.2.1, 3.2.4), search and view (Sections 3.2.6–3.2.9), download (Sections 3.2.10–3.2.11), upload/edit publications (Sections 3.2.21–3.2.22), and edit personal data (Section 3.2.19)—record the number of page transitions and user interactions (clicks/submit actions).
  - Acceptance criteria: [N/A]

- Immediate search access for VUB-network users without login
  - Source: Section 3.2.2
  - Verification method: When accessing from within the VUB network, open the start page and verify that search can be initiated and executed without logging in.
  - Acceptance criteria: Search can be performed without prior login when connected to the VUB network.

- Clear, cause-indicating error messages with logging
  - Source: Section 2.2.2
  - Verification method: Induce representative errors (e.g., invalid form inputs, attempting to access unavailable resources) and observe user-facing messages; verify corresponding entries in the PMS error logs.
  - Acceptance criteria: For each induced error, a user-visible message indicating the cause is displayed and the event is logged.

- Web interface clarity and structure (attractive, simple, standard)
  - Source: Sections 2.5, 3.1.1
  - Verification method: [N/A]
  - Acceptance criteria: [N/A]

## 4.5 Logical database requirements

The following verification approaches and methods will be used to qualify compliance with Requirements §3.5 Logical database requirements. They are organized in parallel with items (a) through (g).

- a) Types of information used by various functions
  - Requirements-to-schema review: trace system functions to the data they require and verify presence in the logical schema for at least the following categories named in the SRS: publications (metadata, full-text files where stored, references), authors, institutes, users (accounts, roles/levels), groups/departments, system configuration, statistics/operational data, and administrator settings.
  - Schema inspection: check entities and attributes needed for upload, search, view, download, user/group management, and configuration.
  - CRUD test suites: execute representative create/read/update/delete scenarios for Registration, Login/Logout, Upload/Edit Publications, Search/View/Download, User/Group Create-Edit-Delete, and Configuration changes; verify persistence and correctness of stored data.

- b) Frequency of use
  - Concurrency tests: simulate several simultaneous SQL-based requests (reads/writes) driven by typical workflows (upload, search, edit) to verify the database “is capable to handle several requests at once.”
  - Transactional integrity under load: verify absence of deadlocks/timeouts causing data loss; confirm committed changes are durable and partially applied updates do not occur.

- c) Accessing capabilities
  - Access path verification: confirm that application access to the database occurs via the web server and that direct database access is restricted to Administrator(s) via CLI as stated.
  - Negative testing: attempt remote direct database connections using non-administrator credentials and from unauthorized hosts to ensure denial.
  - Functional access checks: through the application, verify that roles can perform only the read/write operations described for them (e.g., Member read-only, Publisher create/edit own, Moderator departmental edits, Administrator unrestricted), demonstrating the database supports necessary queries and updates for each role.

- d) Data entities and their relationships
  - Model review: inspect the logical data model to confirm entities and relationships implied by the SRS: Publication; Author; Institute; User; Group/Department; relationships including Publication–Author (many-to-many), Publication–Publication (cited references), User–Publication (ownership/uploader), User–Group, and Publication–Group/Department (departmental ownership).
  - Fixture-driven validation: populate the database with linked test data (e.g., publications with authors, references, and ownership) and verify relationship navigations used by search, view, “My Publications,” and departmental edit functions return correct and complete results.

- e) Integrity constraints
  - Referential integrity tests: attempt deletes/updates that would create “pointers to deleted records” (e.g., deleting an author or a cited publication in use) and verify foreign key constraints prevent or correctly cascade such operations so no orphans remain.
  - Uniqueness checks: verify rejections of duplicate usernames during registration and duplicate group names during group creation, as specified by the functional exceptions.
  - Redundancy control: design review to confirm normalization consistent with “no redundant information”; data mutation tests to ensure a single authoritative record drives all views (e.g., editing publication details updates all dependent views without duplicate storage).
  - Consistency after concurrent operations: run simultaneous edits on the same records and verify resulting data remains consistent.

- f) Security
  - Credential storage verification: inspect database to ensure user passwords are stored only in encrypted/hashed form; confirm no plaintext passwords exist.
  - In-transit protection check: verify the application encrypts passwords when submitted from user to server, and that only encrypted values reach the database.
  - Authorization enforcement tests: using each user level (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator), attempt operations beyond their privileges (edit/delete/upload) and verify denial; confirm Administrator-level direct database access via CLI only.
  - Data exposure checks: ensure direct database reads of sensitive fields (e.g., password hashes) are restricted to authorized administrative contexts.

- g) Data retention requirements
  - Backup and restore drills: validate the “backup structure” by performing full database backups and restoring them onto a clean instance; confirm all categories of data (publications, users, groups, configuration, statistics) are fully recovered and the system returns to an operational state.
  - Failure recovery rehearsal: simulate database corruption and verify the Administrator can replace the database with the last available backup as described in Availability, with the application properly reporting downtime and resuming normal operation after restoration.

## 4.6 Design constraints

This subsection defines how each design constraint in Requirements 3.6 will be verified.

- Constraint: The PMS web interface must conform to W3C XHTML 1.0 Transitional [3].
  - Verification methods:
    - Automated markup validation of all unique page templates and generated pages using a standards-compliant XHTML validator.
    - Inspection of DOCTYPE and charset declarations in templates.
  - Evidence/artifacts: Validation reports for each template/page; issue logs for any nonconformities and their resolutions.
  - Acceptance criteria: Zero validation errors; any warnings are reviewed and formally dispositioned.

- Constraint: The implementation must be compliant with the Coding Conventions of SE1 [10].
  - Verification methods:
    - Structured peer code reviews using a checklist derived from SE1 coding conventions.
    - Configuration audit to confirm review coverage of all committed source files.
  - Evidence/artifacts: Completed review checklists, review minutes, defect reports and fixes; configuration audit record.
  - Acceptance criteria: No open major deviations; minor deviations corrected or formally waived.

- Constraint: The implementation must be object-oriented.
  - Verification methods:
    - Design and code inspections to confirm use of classes/modules and encapsulation for all functional components.
    - Architectural review to confirm that the module decomposition is expressed in terms of objects/classes.
  - Evidence/artifacts: Reviewed design package, inspection records highlighting OO structure; list of any procedural exceptions and justifications.
  - Acceptance criteria: All production components implemented as classes/modules (entry points excepted); any exceptions explicitly approved.

- Constraint: Design diagrams must follow the UML standard [11].
  - Verification methods:
    - Document reviews of all design diagrams for UML-conformant notation and semantics.
    - Traceability check ensuring each required diagram is present (e.g., class, sequence, deployment) where applicable to the design.
  - Evidence/artifacts: Annotated diagram reviews, defect logs, updated diagrams.
  - Acceptance criteria: No UML syntax/semantics violations; all required diagrams present and consistent with the design.

## 4.7 Software system attributes

This subsection defines the verification approaches and methods to qualify the software against the Software System Attributes specified in the Requirements section.

### Reliability
- Objectives under test
  - The PMS should not experience software faults; development follows a spiral model with two iterations, with testing governed by the SQAP and STD.
  - Users must receive a meaningful error message on request errors; such errors must be logged.
- Verification methods
  - Test: Execute the full suite of unit, integration, and system tests defined in the STD across two iterations; include positive and negative paths for core scenarios (login, search, view, download, upload, bulk upload, edit, user/group administration).
  - Test: Concurrency testing by issuing several simultaneous requests (e.g., parallel searches/downloads/uploads) to reveal race conditions and stability issues.
  - Test: Error-handling scenarios (malformed inputs, missing files, exceeded file-size limits when defined, unavailable services) to confirm user-facing messages and server-side logging occur.
  - Analysis/Inspection: Review error logs created during testing to confirm that all detected errors are logged with sufficient diagnostic detail for Administrator(s).
  - Analysis: Confirm alignment with processes and exit criteria stated in SQAP and STD (e.g., all planned tests executed, no unresolved critical defects).
- Acceptance evidence
  - All planned tests in STD executed and passed or deferred per SQAP process.
  - No open Severity 1/2 defects at delivery.
  - Demonstrable error messages for handled failures and corresponding log entries.

### Availability
- Objectives under test
  - PMS is available except when the Wilma server is unavailable.
  - On downtime, PMS displays a temporary unavailability error to visitors.
  - Administrator(s) can restore service by replacing a corrupted database with the latest backup.
- Verification methods
  - Test/Demonstration: Simulate application downtime (e.g., stop the PMS/web service) and verify that users see the temporary down message.
  - Test/Demonstration: Simulate database unavailability and recovery (stop/restart DB service) to verify proper error messaging during outage and successful automatic recovery on restart.
  - Test/Demonstration: Perform a backup-and-restore drill: create a backup, introduce controlled corruption or remove data, restore from backup, and verify data and service are fully restored.
  - Inspection: Review the documented admin procedure/runbook for backup and restore and confirm it is complete and executable.
- Acceptance evidence
  - Downtime message observed during simulated outage.
  - Backup/restore drill completes successfully with data and service restored.

### Security
- Objectives under test
  - Each user account is protected with a personal password.
  - Passwords are encrypted when submitted and stored in encrypted form in the database.
  - Direct database access is only allowed for Administrator(s) using the CLI.
  - User levels are enforced for editing, deleting, and uploading publications.
- Verification methods
  - Test: Credential handling
    - Network verification: Capture authentication traffic and verify that the password is not transmitted in plaintext.
    - Database verification: Inspect stored credentials to confirm they are not plaintext and are stored in an encrypted/hashed form.
  - Test: Role-based access control
    - Positive tests: For each role (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator), verify the allowed operations function.
    - Negative tests: Attempt restricted operations for each role and verify access is denied (e.g., Guest cannot search; Member cannot edit others’ publications; non-Administrator cannot perform administrative actions).
  - Test/Inspection: Database access restriction
    - Attempt direct DB access from non-Administrator accounts and from non-CLI contexts; verify access is denied.
    - Confirm that Administrator access via CLI is possible and audited per operational procedures.
  - Inspection: Verify secure password handling is implemented throughout the stack (submission, processing, storage).
- Acceptance evidence
  - Authentication traffic contains no plaintext passwords.
  - Stored passwords are encrypted/hashed.
  - All negative access tests are denied; all positive access tests succeed.
  - Non-Administrator direct DB access attempts fail; Administrator CLI access succeeds.

### Maintainability
- Objectives under test
  - Administrator(s) maintain the database and global PMS settings.
  - Moderator(s) maintain PMS at the departmental level (e.g., group permissions, user level changes within jurisdiction).
- Verification methods
  - Test/Demonstration: Execute maintenance tasks through the system UI/CLI without code changes:
    - Create/Delete User(s), Create/Delete Group(s), Edit user settings, Edit group settings, Manage user levels, Manage group permissions.
  - Test/Demonstration: Database maintenance tasks by Administrator(s), including executing backup and restore, and routine data consistency checks.
  - Inspection: Generate and review RDoc to ensure source documentation exists for maintainers (per constraints).
- Acceptance evidence
  - Maintenance tasks complete successfully using provided interfaces and procedures.
  - RDoc generated and accessible; maintenance procedures documented.

### Portability
- Objectives under test
  - PMS runs on Wilma (Linux-based) with Ruby 1.8 or later; installation is easy.
  - Potential relocation to other OSs is possible with adjustments, but is not fully implemented.
- Verification methods
  - Test/Demonstration: Install PMS on Wilma with Ruby 1.8+ and verify full operation of web access and CLI (core functions: login, search, upload, download, admin tasks).
  - Inspection: Confirm implementation language is Ruby and that no disallowed frameworks are used (per constraints).
  - [N/A]: Quantitative metrics such as percentage of host-dependent code are not specified in the original SRS.
- Acceptance evidence
  - Successful installation and operation on Wilma (Linux) with Ruby 1.8+.
  - Source inspection confirms Ruby usage and adherence to no-framework constraint.

## 5.1 Assumptions and dependencies

- Client browsers support W3C XHTML and users have a TCP/IP connection to the PMS web server; otherwise alternative client/interface requirements would change. 
- HTTP traffic over TCP/IP port 80 is permitted between clients and the PMS; if blocked, communication interface requirements would change.
- VUB-network users are identifiable by their IP addresses; changes in network addressing or proxies that obscure client IPs would affect access control requirements.
- Email infrastructure is available to send validation emails and administrative notifications for registration and password changes; if unavailable, related user management flows and requirements would change.
- Command line users have shell access on the server host and such access implies Administrator privileges; changes to shell access policies would affect authorization requirements.
- The PMS depends on the availability of the hosting environment (Wilma server); downtime or relocation would affect availability and deployment requirements managed by the customer.
- A MySQL database and a web server are available and reachable as external system interfaces; changes to these services would affect interface and data management requirements.
- Restorable database backups exist and can be applied by Administrators; if backup/restore facilities are unavailable, recovery and availability requirements would change.
- The maximum allowable publication file size for uploads is TBD; once defined, it may affect upload and storage requirements.

## 5.2 Acronyms and abbreviations

- BIB: [N/A]
- BibTeX: Tool for formatting lists of references; typically used with the LaTeX document preparation system.
- CLI: Command Line Interface.
- Git: 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.
- IP: [N/A]
- LaTeX: [N/A]
- MP3: [N/A]
- MPEG: [N/A]
- MS: [N/A]
- ODT: [N/A]
- OS: Operating System.
- PDF: Portable Document Format.
- PMS: Publication Management System.
- PS: Postscript.
- RDoc: Document Generator for Ruby Source.
- RIS: Tagged format for expressing bibliographic citations.
- SCMP: Software Configuration Management Plan.
- SE1: Software Engineering group 1.
- SQL: [N/A]
- SQAP: Software Quality Asssurance Plan.
- SRS: Software Requirements Specification.
- STD: Software Test Plan.
- TBD: To Be Determined.
- TCP/IP: [N/A]
- UML: Unified Modelling Language.
- URL: [N/A]
- VUB: Free University of Brussels.
- W3C: World Wide Web Consortium.
- XHTML: [N/A]
- XP: [N/A]