## 1.1 Purpose

The Publications Management System (PMS) is intended to provide a platform for storing, managing, and accessing bibliographic publications and their full texts. Its purpose is to:
- Maintain a database of bibliographic metadata and, when available, full texts (PDF/PS).
- Support ingestion via web browser and command line, including bulk imports (e.g., BibTeX/RIS).
- Automatically extract bibliographic information from uploaded documents and allow manual correction.
- Normalize identities by letting users indicate equivalences for authors and institutes (e.g., “D. Vermeir” = “Dirk Vermeir”; “VUB” = “Vrije Universiteit Brussel”).
- Enable users to search, view (including abstracts), and download publications.
- Enforce access control based on user roles and network location.

## 1.2 Scope

This Software Requirements Specification defines the Publications Management System (PMS) to be developed and deployed for the Free University of Brussels (VUB).

Products to be produced
- PMS Web Application: a W3C XHTML 1.0 Transitional–compliant web interface accessible via standard and text-based browsers.
- PMS Command Line Interface (CLI): administrator access on the Wilma Linux server for system and data administration.
- PMS Data Store: a MySQL-based repository for bibliographic records, authors/institutes, full texts, statistics, and configuration.

What the PMS will do
- Repository management
  - Store and manage bibliographic information and, where available, full-text publications (PDF, PS) and abstracts.
  - Maintain explicit entities for authors and institutes, including manual aliasing (e.g., “D. Vermeir” = “Dirk Vermeir”; “VUB” = “Vrije Universiteit Brussel”).
  - Support bulk updates/imports (e.g., BibTeX/RIS) and single uploads; automatically extract metadata from documents and allow manual correction.
- Access, search, and retrieval
  - Provide search by keywords (with logical operators), author(s), institute, and publication dates, with advanced search options and result ordering.
  - Allow viewing of publication details, references, and related/similar items; enable display and download of single or multiple publications.
  - Export results/publication content (HTML, PDF, PS) and export references in BibTeX and RIS formats.
- User and access control
  - Enforce a role model: Guest, VUB-Network User, Member, Publisher, Moderator, Administrator.
  - Support account registration/validation, login/logout, and password retrieval.
  - Restrict access for non–VUB-network users to authenticated sessions; grant broader access to VUB-network users recognized by IP.
- Administration and operations
  - Manage users and groups (create, edit, delete, upgrade/downgrade roles), departmental permissions, and global configuration.
  - Enable moderators/administrators to edit publications (departmental/all, respectively).
  - Log errors and notify administrators; support operation over HTTP on TCP/IP port 80.

Application, benefits, objectives, and goals
- Application domain: academic publications management and dissemination for VUB academic personnel and students.
- Benefits:
  - Centralized, consistent, and searchable repository of publications and metadata.
  - Efficient ingestion via bulk import and automated metadata extraction with manual correction to ensure data quality.
  - Controlled access aligned with network location and user roles, enabling secure viewing and downloading of content.
- Objectives and goals:
  - Provide fast, clear, and minimal-click access to search, upload, and administrative functions.
  - Ensure standards-compliant web access and Linux-based deployability on the Wilma server.
  - Support modular design to simplify future extensions (e.g., additional formats or media).
- Consistency:
  - This scope aligns with the overall description and specific requirements stated for interfaces, functions, roles, and constraints in this SRS.

### 1.3.1 Product perspective

The Publications Management System (PMS) is a standalone web application deployed within the VUB infrastructure (Wilma Linux server). It is not specified as a component of a larger software system. PMS comprises:
- A web server process that hosts the PMS application.
- A MySQL database for persistent storage.
- A browser-based user interface over HTTP.
- A command-line interface (CLI) for administrators on the server.
- An email service used for account validation and administrative notifications.

Major elements and interconnections (conceptual):
- Client browsers ↔ HTTP over TCP/IP port 80 ↔ Web server hosting PMS ↔ SQL ↔ MySQL database.
- Administrators ↔ local server shell (CLI) ↔ PMS administrative functions.
- PMS ↔ email service (SMTP) ↔ users/administrators.

No requirements from a larger parent system or additional product integrations are specified. IP-based recognition distinguishes VUB-network users from external users.

#### System interfaces
- MySQL database
  - Functionality supported: persistent storage and retrieval of publications, bibliographic metadata, user accounts, access control, logs, and statistics.
  - Interface: SQL via the standard MySQL client/server interface. Detailed protocol/specification: [N/A].
- Web server runtime
  - Functionality supported: executes PMS application logic, handles HTTP requests/responses, renders user interface, mediates database access.
  - Interface: HTTP service endpoint(s) exposed to browsers. Specific web server product and configuration: [N/A].
- Server shell (CLI) for administrators
  - Functionality supported: administrative operations with full privileges.
  - Interface: local command-line access on the Wilma Linux server. Remote access details: [N/A].

#### User interfaces
- Web UI
  - Logical characteristics: browser-accessible UI that prioritizes clarity, structure, and accomplishing tasks (search, upload, download) in a minimal number of pages/clicks; compliant with W3C XHTML 1.0 Transitional; explicit support for text-based browsers (e.g., Links2).
  - Error handling: user-visible error messages stating cause; errors are logged for administrator notification.
  - Access behavior: outside the VUB network, login is required; within the VUB network, users may search without logging in and are recognized by IP address.
  - Style guide: [N/A].
- CLI (administrators)
  - Logical characteristics: local shell access on the server with administrator privileges.

#### Hardware interfaces
- Users: no specific hardware requirements.
- Server hardware specifics, device counts/ports, and special peripherals: [N/A].

#### Software interfaces
- Linux operating system
  - Purpose: host platform for PMS and supporting services.
  - Name: Linux; Mnemonic: OS; Specification number: [N/A]; Version: [N/A]; Source: [N/A].
  - Interface: standard OS process, file system, and networking facilities.
- Ruby interpreter
  - Purpose: PMS runtime environment.
  - Name: Ruby; Mnemonic: Ruby; Specification number: [N/A]; Version: 1.8 or later; Source: [N/A].
  - Interface: executes PMS application code.
- MySQL database
  - Purpose: data persistence layer for all PMS data.
  - Name: MySQL; Mnemonic: DB; Specification number: [N/A]; Version: [N/A]; Source: [N/A].
  - Interface: SQL queries and results over the MySQL protocol; schema and message formats: [N/A].
- Web server
  - Purpose: hosts PMS web application and serves HTTP content.
  - Name: [N/A]; Mnemonic: Web server; Specification number: [N/A]; Version: [N/A]; Source: [N/A].
  - Interface: HTTP request/response handling; details of modules/connectors: [N/A].
- Web browsers (clients)
  - Purpose: user agent for UI interaction.
  - Requirement: supports W3C XHTML 1.0 Transitional.
  - Interface: HTTP; content formats: XHTML, HTML; downloads may include PDF and PS.

#### Communications interfaces
- Protocols: HTTP over TCP/IP.
- Ports: TCP port 80.
- Network environment: recognition of VUB-network users by IP address; outside users must authenticate.
- Other communications protocols (e.g., HTTPS, SSH): [N/A].

#### Memory constraints
- Application memory usage: no specific limit defined.
- Publication file size: maximum size TBD.

#### Operations
- Modes of operation:
  - Authenticated mode: Members/Publishers/Moderators/Administrators after login.
  - VUB-network user mode: limited access based on IP recognition without login.
  - Guest mode: registration, login, password retrieval only.
- Interaction periods: interactive web sessions; unattended/background operations: [N/A].
- Data processing support:
  - Error logging for operational issues.
  - Database must handle concurrent SQL requests.
- Backup and recovery:
  - A backup structure is required.
  - In case of database corruption, the Administrator replaces the database with the last available backup.
  - During downtime, PMS should display a temporary down message.

#### Site adaptation requirements
- Installation environment: Linux-based system (Wilma server); Ruby 1.8 or later.
- Prohibited/allowed components: no frameworks; only free software for tools and end product.
- Initialization/site-specific data: VUB-network IP recognition; specific values/configuration: [N/A].
- Installation mechanism: easily installable; specific installer/process: TBD.

#### Interfaces with services
- Email service (SMTP)
  - Purpose: send validation emails for new account registration and administrative notifications (e.g., registration requests, password changes).
  - Interface details and service endpoint: [N/A].
- Other SaaS/cloud services: [N/A].

### 1.3.2 Product functions

The Publications Management System (PMS) provides the following major functions, organized by functional domain. Access to each function is controlled by user role and, in some cases, by network origin (VUB-network vs. external). Roles include Guest, VUB-Network User, Member, Publisher, Moderator, and Administrator.

- Access and identity
  - Account registration and email validation.
  - Login from the internet or via the VUB-network; logout.
  - Password retrieval/reset.
  - IP-based recognition of VUB-network users.
  - Role-based access control and privileges.

- Search and discovery
  - Basic and advanced publication search by keywords (including logical operators), author(s) with ranking, and publication date range.
  - Search by references and similarity (same author(s), same institute, cited/mentioning publications).
  - Browse “My Publications” (for Publishers/Moderators/Administrators).
  - View author details.

- Results handling
  - Paginated results viewing and navigation.
  - Sorting of results by title, author(s), and year.
  - Viewing publication details (title, authors, date, abstract, cited references).
  - Navigating to and viewing details of cited references.
  - Displaying full text or abstract when available.

- Downloading and exporting
  - Download single or multiple publications from search results or detail views.
  - Export references of a publication in BibTeX (BIB) or RIS format.
  - Export/download publications or result sets to HTML, PDF, and PS.

- Publication management
  - Upload publications (supported document formats include PDF, PS, ODT).
  - Automatic extraction of bibliographic metadata from uploaded content; manual correction when needed.
  - Import of metadata via BibTeX/RIS; bulk upload (e.g., BibTeX files).
  - Manage equivalences/aliases (e.g., “D. Vermeir” ≡ “Dirk Vermeir”; “VUB” ≡ “Vrije Universiteit Brussel”).
  - Edit own publications (Publisher+).
  - Edit departmental publications (Moderator+).
  - Edit any publication (Administrator).

- User and group administration
  - Search users; edit user settings.
  - Create/delete users.
  - Manage user levels (upgrade/downgrade) within scope (Moderator) or globally (Administrator).
  - Create/search/edit/delete groups.
  - Manage group permissions.

- System operations and configuration
  - Administrative control panel access (Administrator).
  - Edit system configuration settings.
  - Command-line administration on the server (Administrator).
  - User-facing error messages and server-side error logging.

- Optional/future functions
  - Additional document formats (e.g., MS Word).
  - Display of documents that cite a given publication.
  - Automatic disambiguation of authors and institutes.
  - Retrieval of full texts from URLs contained in uploaded BibTeX files (abstract-only records).
  - Support for audio/video uploads with automatic recognition.

### 1.3.3 User characteristics

The PMS is intended for academic personnel and students affiliated with the VUB and external visitors. Users are expected to have basic internet literacy and access the system primarily via a standards-compliant web browser; some administrative operations may use a Linux command line.

- Educational level and domain background
  - Academic staff and students with tertiary education in diverse disciplines.
  - Various technical backgrounds are expected.

- General experience and skills
  - All users should have a basic knowledge of the internet and web browsing.
  - Users may perform searches using logical expressions (e.g., AND, OR, NOT).

- User groups and expected technical expertise
  - Guests and VUB-Network Users: casual web users; no prior training required beyond basic browsing and search.
  - Members: registered users with the same general web skills as above; capable of managing their own account data.
  - Publishers: capable of uploading publications and handling supported formats (pdf, ps, odt) and bibliographic exchange formats (BibTeX, RIS); able to review and correct extracted bibliographic metadata.
  - Moderators: departmental users responsible for managing group permissions and editing author and publication metadata; moderate technical proficiency expected.
  - Administrators: technically proficient users with responsibility for system and user management; capable of using a Linux-based CLI on the server and performing administrative tasks; may access the database via CLI.

- Accessibility and disability considerations
  - [N/A]

### 1.3.4 Limitations

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

- b) Hardware limitations
  - The PMS must run on a Linux-based environment, specifically the Wilma web server.
  - No specific user-side hardware requirements are stated.
  - Memory usage has no specific limit; however, publication file size has a maximum that is TBD.

- c) Interfaces to other applications
  - Must interface with a MySQL database.
  - Must operate via a web server and standard web browsers that support W3C XHTML.
  - Communication is via HTTP over TCP/IP port 80.
  - Command Line Interface access for administrators (server shell on Wilma).
  - Import/export constrained to specified formats: import (e.g., BibTeX, RIS; documents such as pdf, ps, odt), export (e.g., html, pdf, ps; references in BibTeX and RIS).

- d) Parallel operation
  - Database must handle several concurrent requests; no additional constraints specified.

- e) Audit functions
  - System must log errors to notify administrators; no comprehensive audit trail or transaction logging is specified.

- f) Control functions
  - Role-based access control (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator) must be enforced.
  - Access from outside the VUB network requires login; unlogged users are restricted to Guest privileges.
  - VUB-network users are identified by IP address.
  - Administrators can manage users and groups (create, edit, delete; change user levels); Moderators manage within their departments.
  - Direct database access is limited to administrators via CLI.

- g) Higher-order language requirements
  - Implementation language is Ruby (1.8 or later), object-oriented.
  - No frameworks permitted; code must be documented with RDoc.

- h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK)
  - [N/A]

- i) Quality requirements (e.g., reliability)
  - Database consistency must be maintained; backup structure required.
  - Availability depends on the Wilma server; during downtime, the PMS should present a temporary error message.
  - Passwords must be encrypted in transit and stored encrypted.
  - Performance requirements are TBD.

- j) Criticality of the application
  - [N/A]

- k) Safety and security considerations
  - No safety-related constraints specified.
  - Security constraints include password protection and encryption, role-based access enforcement, and restricted direct database access (administrators via CLI only).

- l) Physical/mental considerations
  - Users are academic personnel and students; basic internet knowledge is expected.
  - The web interface must be accessible, including via text-based browsers on Linux (e.g., Links2).

- m) Limitations sourced from other systems (including real-time)
  - Availability and connectivity depend on external infrastructure: Wilma server uptime and network permitting HTTP traffic on port 80.
  - Command line access requires server shell access within the VUB network.
  - Real-time requirements are not specified.

## 1.4 Definitions

- Customer: Person(s) who pay for the product and usually (but not necessarily) decide the requirements. May be in the same organization as the supplier.
- Supplier: Person(s) who produce the product for a customer. May be in the same organization as the customer.
- User: Person(s) who operate or interact directly with the PMS. Users and customers are often not the same.

- Publication Management System (PMS): The product described in this SRS; manages bibliographic records and optionally full-text publications.
- Publication: A bibliographic record stored in the PMS, including metadata (e.g., title, authors, institute, dates, references) and optionally the full text (e.g., PDF, PS, ODT).
- Reference: A citation recorded for a publication; references can be consulted and followed within the PMS.
- Author: An explicitly modeled entity (e.g., name, first name, institute) for which the PMS supports indicating equivalences between name variants (e.g., “D. Vermeir” = “Dirk Vermeir”).
- Institute: The organization affiliated with an author; the PMS supports indicating equivalences between institute name variants (e.g., “VUB” = “Vrije Universiteit Brussel”).

- User levels (roles): A hierarchical set of permissions where each level inherits the permissions of the preceding one:
  - Guest: Anonymous user not connected to the VUB-network; may register, log in, validate a new account, or retrieve a password; cannot search, view results, upload, or edit publications.
  - VUB-Network User: Not logged in but connected to the VUB-network (recognized by IP address); can search the database, view results, and download available publications.
  - Member: Logged-in user; can search and download; may change own account details and log off.
  - Publisher: Logged-in user; can upload publications (including bulk uploads), edit own publications, and use Member capabilities.
  - Moderator: Logged-in user; can edit departmental publications, edit author information, manage user levels within their department, and manage group permissions, in addition to Publisher capabilities.
  - Administrator: Logged-in user; has full permissions including creating/deleting users and groups, changing any user level, editing any publication, and accessing the control panel.

- VUB-network: The internal network of the Vrije Universiteit Brussel; users connected to it can access certain PMS functions without logging in and are recognized by IP address.
- Command Line Interface (CLI): Shell access on the Wilma server; a CLI user is assumed to be local on Wilma and is automatically granted Administrator privileges.
- Control Panel: Administrative interface enabling management of users, groups, and system configuration settings.
- Group: A set of PMS users used for organizing permissions and administration (e.g., searchable, editable by administrators; moderators may manage permissions for groups under their responsibility).
- Department: Organizational unit used to scope certain permissions and responsibilities (e.g., moderators manage users/publications within their own department).
- Bulk Upload / Bulk Update: Importing many publications (or abstracts) at once, e.g., from BibTeX or RIS files.
- My Publications: A user-specific view that lists all publications previously uploaded by the logged-in user.
- Wilma: The Linux server specified by the customer as the target deployment environment for the PMS.

# 2 References

## Compliance

- 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/

- SE1 Coding Conventions
  - 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
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://www.uml.org/

## Guidance

- IEEE Std 830-1998
  - Report number: IEEE Std 830-1998
  - Date: [N/A]
  - Publishing organization: IEEE
  - Source: http://www.scribd.com/doc/2620639/IEEE-8301998

- Software Engineering course page
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://tinf2.vub.ac.be/~dvermeir/courses/software_engineering/projects/2007-2008/index.html

- Git
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://git.or.cz/

- IEEE (organization website)
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: IEEE
  - Source: http://www.ieee.org/

- RDoc
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://rdoc.sourceforge.net/

- SE1 Group 1 website
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://wilma.vub.ac.be/~se1_0708/

- Vrije Universiteit Brussel (VUB) website
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://www.vub.ac.be

- World Wide Web Consortium (W3C) website
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: World Wide Web Consortium (W3C)
  - Source: http://www.w3.org/

- Software Quality Assurance Plan (SQAP)
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: http://wilma.vub.ac.be/~se1_0708/docs/sqap/sqap.pdf

- Software Test Plan (STD)
  - Report number: [N/A]
  - Date: [N/A]
  - Publishing organization: [N/A]
  - Source: [N/A]

## 3.1 Functions

This section defines the externally observable software functions of the Publications Management System (PMS). Functions are grouped into sub-functions. For each, inputs, validity checks, sequence of operations, outputs, responses to abnormal situations, effects of parameters, and the relationship of outputs to inputs are described. Items not specified in the original SRS are marked [N/A].

### 3.1.1 Access control and session management

- Inputs
  - Login: username, password.
  - Registration: username, password, name, email address, university, department.
  - Account validation: user action via validation email (accept/confirm).
  - Password change/retrieval: username and new password.
  - Network location parameter: client IP address (for VUB-network recognition).
- Validity checks
  - Login: username exists; password matches stored (encrypted) password.
  - Registration: username does not already exist; mandatory fields present; email address provided.
  - Account validation: requested account exists and is pending validation/acceptance.
  - Password change: username exists.
- Sequence of operations
  - Login (internet or VUB-network):
    1) Display login screen (internet: required; VUB-network: login or direct search).
    2) Accept credentials.
    3) Validate credentials.
    4) On success, establish session with role (Guest/VUB-Network User/Member/Publisher/Moderator/Administrator).
    5) On failure, display error and remain on login screen.
  - Registration:
    1) Display registration form.
    2) Accept user data.
    3) Check username uniqueness.
    4) Record request; send email to Administrator.
    5) If accepted, send validation mail to user; user validates to complete registration.
  - Password change/retrieval:
    1) Display change password screen.
    2) Accept username and new password.
    3) Verify username exists.
    4) Record request; send email to Administrator.
  - Log off:
    1) User invokes logout.
    2) Terminate session.
    3) Redirect: if on VUB-network, to search page; otherwise to login page.
- Outputs
  - Successful login: active session and access to authorized functions.
  - Registration: registration request recorded; email sent to Administrator; upon acceptance, validation email to user.
  - Password change: request recorded; email sent to Administrator.
  - Log off: session terminated; user redirected as above.
- Abnormal situations and handling
  - Invalid credentials, duplicate username, unknown username: display error message; log error.
  - Communication/request error: display error message; log error.
  - Hardware/unavailability (e.g., server down): PMS presents downtime error to visitors. Recovery per backup/restore is administrative (see 3.1.9).
  - Overflow: [N/A].
- Effects of parameters
  - Network location (VUB-network via IP): enables search and download without login (as VUB-Network User); from outside, only logged-in users may access.
  - Role parameter (Member/Publisher/Moderator/Administrator): governs accessible functions throughout the PMS.
- Relationship of outputs to inputs
  - Valid credentials → session established; invalid → error.
  - Unique registration data → registration recorded; duplicate username → error.
  - Provided username for password change → request recorded; unknown username → error.
  - No formulas for conversion: [N/A].

### 3.1.2 Search and results navigation

- Inputs
  - Search criteria: keywords (including logical expressions such as AND/OR/NOT and symbols like quotes), author name(s) ordered by importance, publication date range.
  - Advanced search criteria: additional keyword(s) and/or specifying publications that refer to a target publication.
  - Result actions: sort order (by title, author(s), year), next/previous page navigation, select items, “View All,” “Download All.”
  - Similarity search parameter: by same author(s), same institute, or publications mentioned in a result.
- Validity checks
  - Search form acceptability: [N/A] (no explicit validation rules beyond field presence).
- Sequence of operations
  1) Display search form (available without login on VUB-network; otherwise to logged-in users).
  2) Accept search criteria (basic and optional advanced).
  3) Execute search against database.
  4) Display paginated results (title, main author).
  5) Accept result-level actions: sort, navigate, select items, “View”/“View All,” “Download All,” similarity searches.
- Outputs
  - Zero or more search result entries; detailed views for selected publications; optional bulk actions applied to selected/all items.
- Abnormal situations and handling
  - No results: display “no results” information.
  - Communication/request error: display error message; log error.
  - Overflow (e.g., excessive result size): [N/A].
- Effects of parameters
  - Sort parameter changes ordering of the same result set.
  - Advanced criteria constrain results further.
  - Similarity parameter switches the filter to related publications.
  - Role/network parameters determine access to search (Guests without VUB-network access cannot search).
- Relationship of outputs to inputs
  - Given search criteria → returns list of publications matching criteria.
  - Given sort parameter → same list ordered accordingly.
  - Given selection → corresponding detailed views or downloads produced.
  - Formulas for ranking/scoring: [N/A].

### 3.1.3 Publication details, references, and author views

- Inputs
  - Selection of a publication from results or “View All.”
  - Reference action: “Reference(s)” for a publication or “All References.”
  - Author selection: click author name.
- Validity checks
  - Target publication/reference exists in system.
- Sequence of operations
  1) User selects a publication.
  2) System displays detailed view: title, authors, publication date, abstract, cited references.
  3) User may:
     - Display full text (if available).
     - View cited references (per-publication or for multiple).
     - Navigate to detailed view of a cited reference present in the system.
     - View author details.
- Outputs
  - Detailed publication/author/reference screens; full text display when available.
- Abnormal situations and handling
  - Reference not present in system: access to its detailed view is not provided.
  - Full text not available: display that full text is unavailable.
  - Communication/request error: display error message; log error.
  - Overflow: [N/A].
- Effects of parameters
  - Availability flag for full text governs the “Full Text” action.
- Relationship of outputs to inputs
  - Publication selection → detailed view.
  - “References” action → list of cited references; if “All References,” aggregates across selected publications.
  - Author selection → author details.
  - Formulas: [N/A].

### 3.1.4 Downloading publications and exporting results

- Inputs
  - Download single publication: selection of a publication in results or detailed view.
  - Download multiple publications: “Download All” in a result set.
  - Export format (for results export): html, pdf, ps.
- Validity checks
  - Requested file exists and is accessible per user role/network.
- Sequence of operations
  - Download single:
    1) User clicks “Download” for a publication (from results or detailed view).
    2) System streams the file to the user.
  - Download multiple:
    1) User clicks “Download All.”
    2) System prepares and streams the set (format unspecified).
  - Export results:
    1) User selects export format for selected/all results.
    2) System generates and returns export in chosen format.
- Outputs
  - Electronic copy of requested publication(s); exported results file in chosen format.
- Abnormal situations and handling
  - File not found/unavailable: display error; log error.
  - Communication/request error: display error; log error.
  - Overflow (e.g., oversized archive for multiple download): [N/A].
- Effects of parameters
  - Export format parameter determines output representation (html, pdf, ps).
  - User role/network parameter determines eligibility to download.
- Relationship of outputs to inputs
  - Selected items + chosen format → generated file(s) in that format.
  - Formulas for any conversions: [N/A].

### 3.1.5 Exporting cited references (BIB, RIS)

- Inputs
  - Selection of a publication in detailed view.
  - Export format parameter: BIB or RIS.
- Validity checks
  - Publication exists; references available to export.
- Sequence of operations
  1) In detailed view, user chooses BIB or RIS.
  2) System compiles cited references and produces a file in the selected format.
- Outputs
  - File containing the publication’s references in BIB or RIS format.
- Abnormal situations and handling
  - No references: display information; generate empty or no file as appropriate.
  - Communication/request error: display error; log error.
  - Overflow: [N/A].
- Effects of parameters
  - Selected format determines serialization (BIB vs RIS).
- Relationship of outputs to inputs
  - Chosen format + selected publication → reference file in that format.
  - Conversion formulas/specification details: [N/A].

### 3.1.6 Uploading and bulk importing publications

- Inputs
  - Single upload: document file in a supported format (pdf, ps, odt).
  - Bulk upload: one or more files containing many publications/abstracts (BibTeX or RIS).
  - Optional user edits to retrieved metadata.
  - Equivalence mappings provided by user (e.g., mapping author aliases, institute aliases).
- Validity checks
  - User role: Publisher/Moderator/Administrator only.
  - File format is supported; file present and readable.
  - Publication file size does not exceed maximum (TBD).
- Sequence of operations
  - Single upload:
    1) User selects file and confirms.
    2) System attempts to extract bibliographic information from the document (or abstract).
    3) System presents the new publication with extracted fields.
    4) User accepts or corrects metadata; confirms.
    5) System stores publication and metadata.
  - Bulk upload:
    1) User selects BibTeX or RIS file(s) and confirms.
    2) System parses records; attempts metadata extraction.
    3) System presents results for review/correction as needed.
    4) User confirms; system stores publications.
- Outputs
  - New publication records with stored files and metadata.
- Abnormal situations and handling
  - Unsupported format, unreadable file, or exceeded size: display error; log error; do not import.
  - Metadata extraction incomplete/incorrect: allow manual correction prior to commit.
  - Communication/request error: display error; log error.
  - Overflow (e.g., bulk file too large): reject and log (max size TBD).
- Effects of parameters
  - User-provided equivalence mappings affect normalization of author and institute identities.
  - Selected import format (BibTeX/RIS) selects corresponding parser.
- Relationship of outputs to inputs
  - Input files → publication records with metadata derived from file contents plus user corrections.
  - Extraction/conversion formulas: [N/A].

### 3.1.7 Editing publications

- Inputs
  - Selection of a publication.
  - Edited bibliographic fields and, where allowed, file replacement.
- Validity checks
  - Authorization:
    - Publisher: may edit own publications only.
    - Moderator: may edit publications owned by their department/group.
    - Administrator: may edit any publication.
- Sequence of operations
  1) User opens edit view for an authorized publication.
  2) User modifies fields.
  3) User confirms changes.
  4) System validates authorization and applies updates.
- Outputs
  - Updated publication metadata (and file if replaced).
- Abnormal situations and handling
  - Unauthorized edit attempt: display error; log event.
  - Target publication not found: display error; log error.
  - Communication/request error: display error; log error.
  - Overflow: [N/A].
- Effects of parameters
  - User role and group/department membership determine edit scope.
- Relationship of outputs to inputs
  - Submitted changes → persisted updates to the selected publication.

### 3.1.8 User and group management

- Inputs
  - User search criteria; group search criteria.
  - User details for create/edit: username, password, email, group, level.
  - Group details for create/edit: group name, users.
  - Administrative actions: create, edit, delete users/groups; change user level; manage group permissions.
- Validity checks
  - Administrator privileges required for create/delete and global level changes.
  - Moderator may upgrade/downgrade users within their department/group and manage group permissions under their jurisdiction.
  - Create user: username must be unique.
  - Delete user: username must exist.
  - Create group: group name must be unique.
  - Delete group: group must exist and be empty (no users).
- Sequence of operations
  - Search users/groups:
    1) Administrator/Moderator enters criteria.
    2) System displays results.
  - Create user/group:
    1) Administrator enters details.
    2) System validates constraints.
    3) System creates entity.
  - Edit user/group:
    1) Select entity from search results.
    2) Change settings.
    3) Confirm to apply.
  - Delete user/group:
    1) Administrator enters identifier.
    2) System displays details for confirmation.
    3) Administrator confirms; system deletes if constraints met.
  - Change user level:
    1) Select user.
    2) Choose new level.
    3) Confirm; system applies change within authorization scope.
- Outputs
  - Lists of users/groups; created/updated/deleted users/groups; applied permissions and levels.
- Abnormal situations and handling
  - Duplicate username/group name: display error; log error.
  - Unknown user/group: display error; log error.
  - Group not empty on delete: display error; log error.
  - Unauthorized action: display error; log event.
  - Communication/request error: display error; log error.
  - Overflow: [N/A].
- Effects of parameters
  - Selected user level changes effective permissions system-wide for that user.
  - Group membership affects Moderator jurisdiction and department-scoped operations.
- Relationship of outputs to inputs
  - Search criteria → filtered lists.
  - Valid entity details → created/updated entities; invalid → error.

### 3.1.9 System configuration and administration

- Inputs
  - Administrator access to control panel.
  - Configuration settings to change.
- Validity checks
  - Administrator privileges required.
- Sequence of operations
  1) Administrator opens configuration panel.
  2) Adjusts settings.
  3) Confirms; system applies configuration changes.
- Outputs
  - Applied configuration changes.
- Abnormal situations and handling
  - Communication/request error: display error; log error.
  - Hardware faults/failures:
    - Wilma (server) unavailable: PMS unavailable; show downtime error to visitors.
    - Corrupted database: Administrator restores last available backup; PMS reinitialized after resolving failure.
  - Overflow: [N/A].
- Effects of parameters
  - Changed settings affect subsequent PMS behavior as configured.
- Relationship of outputs to inputs
  - Submitted configuration changes → system configuration updated.

### 3.1.10 Common security, error handling, and logging behaviors

- Inputs
  - User passwords (submitted and stored).
  - Any operation that triggers an error condition.
- Validity checks
  - Password submission and storage are encrypted; direct database access restricted to Administrators via CLI.
- Sequence of operations
  - On any error during a request:
    1) PMS generates an error message stating the cause.
    2) PMS logs the error for Administrator notification.
- Outputs
  - User-visible error messages; logged error records.
- Abnormal situations and handling
  - Communication/request errors: handled as above.
  - Hardware faults/unavailability: error page; administrative recovery as described in 3.1.9.
  - Overflow cases not otherwise specified: [N/A].
- Effects of parameters
  - User role consistently enforced for access control across all functions.
- Relationship of outputs to inputs
  - Error condition → user message + logged event.
  - Formulas: [N/A].

## 3.2 Performance requirements

Static numerical requirements (Capacity)
- Number of terminals to be supported: [N/A]
- Number of simultaneous users to be supported: [N/A] (The database must be capable of handling several requests at once.)
- Amount and type of information to be handled:
  - Bibliographic metadata (titles, authors, institutes, dates, references).
  - Full-text documents in PDF and PS; ODT is also supported for uploads.
  - Abstracts.
  - Static and dynamic information, statistics, and administrator settings.
  - Maximum per-publication file size: TBD.
  - Memory usage: no specific limit on PMS memory usage.

Dynamic numerical requirements (Throughput and response time)
- Search requests:
  - Normal and peak transactions per second: [N/A]
  - Response time percentiles (e.g., 95th): [N/A]
- Result viewing and navigation:
  - Page rendering time targets: [N/A]
- Downloading publications (single and multiple):
  - Time to initiate download: [N/A]
  - Sustained throughput under normal/peak load: [N/A]
- Viewing full text:
  - Time to render first page/content: [N/A]
- Bulk upload/import (including metadata extraction):
  - Files per minute under normal/peak conditions: [N/A]
  - Per-file extraction/ingestion time: [N/A]
- Exporting references (BIB/RIS):
  - Time to generate and deliver export for a typical result set: [N/A]
- User management operations (create, edit, delete users/groups):
  - Response time per operation: [N/A]
- Backup/restore operations:
  - Backup window and restore time objectives: [N/A]

## 3.3 Usability requirements

### Contexts of use
- Web browser use:
  - Accessible from any OS via a web browser; no specific hardware required.
  - Supports text-based web browsers on Linux (e.g., Links2).
  - Compliant with W3C XHTML 1.0 Transitional.
  - Users outside the VUB network must log in; users on the VUB network can search without logging in.
- Command Line Interface (CLI) use:
  - Administrators access the system locally on the Wilma server with administrator privileges.

### User population
- Academic personnel and students with basic knowledge of the internet.

### Effectiveness objectives
- Role-appropriate task completion:
  - Guests: register, log in, validate account, retrieve password.
  - VUB-network users and logged-in users: search, view results and details, download publications, export references (BIB, RIS), view authors.
  - Publishers: upload publications, bulk upload, review and correct auto-extracted metadata before saving, edit own publications.
  - Moderators: edit departmental publications, manage user levels (within department), manage group permissions, edit author information.
  - Administrators: full user and group management, system configuration.
- Error feedback:
  - When an error occurs during a request, the user is shown a message stating the cause; the error is logged for administrators.
- System state feedback:
  - During downtime or failures, the system informs visitors that the PMS is temporarily down.

### Efficiency objectives
- Minimal interaction cost:
  - The web interface is designed to be fast and efficient, enabling common tasks (upload, download, search) in the smallest feasible number of pages and clicks while maintaining structure.
  - Search results can be ordered (by title, author, year) and filtered/extended (advanced search) to reduce user effort.
  - Logoff behavior directs users appropriately (VUB-network users to the search page; others to the login page) to minimize navigation steps.

### Satisfaction objectives
- User interface qualities:
  - The interface is attractive, simple, and standard-compliant (W3C XHTML), with clarity and structure emphasized.
  - Clear error messages are provided to support user understanding and recovery.
- Accessibility and compatibility:
  - Works with text-based browsers and across operating systems; uses standard HTTP over TCP/IP port 80.

### Avoidance of harm (from use)
- Role-based safeguards:
  - User level restrictions are always enforced for editing, deleting, and uploading publications to prevent unauthorized or accidental changes.
  - Direct database access is limited to administrators via CLI.
- Data entry safeguards:
  - Registration checks for existing usernames to prevent conflicts.
  - Upload workflow presents auto-extracted bibliographic details for user confirmation and correction prior to saving, reducing incorrect data entry.

### Measurable quality-in-use criteria
- Task success rate thresholds: [N/A]
- Maximum number of steps/clicks per primary task (search, download, upload): [N/A]
- Time-on-task targets for primary tasks: [N/A]
- User satisfaction (e.g., survey score targets): [N/A]
- Accessibility conformance beyond W3C XHTML 1.0 Transitional (e.g., WCAG levels): [N/A]

## 3.5 Logical database requirements

Overview
- All static and dynamic information, statistics, publications, and administrator settings shall be stored in the database. The database shall remain consistent at all times (no pointers to deleted records, no redundant information) and support several concurrent SQL requests. A backup mechanism is required to safeguard data against server or disk failures.

a) Types of information used by various functions
- Authentication and accounts
  - Username (unique), password (encrypted), email address, first name, last name.
  - User level/role (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator).
  - University and department; group membership(s); account status/validation.
  - Upgrade/downgrade requests and administrative actions.
- Access control and configuration
  - Group definitions and group permissions.
  - System configuration settings editable via the configuration panel.
- Publications and files
  - Bibliographic metadata: title, authors, publication year/date, institute/affiliation, abstract, keywords.
  - Availability flags and locations for full text (pdf, ps, odt) and/or abstract.
  - Ownership (uploader/owner) and department/group association.
  - Cited references and publications that cite a given publication.
- Authors and institutes
  - Author entities with support for multiple name variants/aliases (e.g., “D. Vermeir” = “Dirk Vermeir”).
  - Institute entities with support for synonyms/aliases (e.g., “VUB” = “Vrije Universiteit Brussel”).
- Search and result handling
  - Criteria used (keywords with logical operators, author list, date range).
  - Result ordering fields (title, author, year).
- Exports
  - Data necessary to produce reference exports in BibTeX (BIB) and RIS formats.
- Operational logs and statistics
  - Error/event logs to notify administrators of technical issues.
  - Usage statistics. 

b) Frequency of use
- The database shall support several concurrent SQL requests.
- Specific operation frequencies and volumes: [N/A]

c) Accessing capabilities
- Support queries for:
  - Authentication by unique username and encrypted password.
  - Search by keywords (with logical expressions), authors (ranked), publication date ranges, and advanced criteria (keywords and/or references).
  - Retrieval of publication detail pages (title, authors, date, abstract, cited references, full-text availability).
  - Retrieval of related publications by same author or same institute.
  - Ordering of search results by title, author, or year.
  - Retrieval and export of references of a publication in BIB and RIS formats.
  - Author detail views.
  - “My Publications” (filter by owner/uploader).
  - Administrative functions: user/group search, create, edit, delete; configuration read/write.
- Provide relational joins to traverse:
  - Publication–Author, Publication–Institute, Publication–Publication (cites/is-cited-by), User–Group, Group–Permissions, User–Department/Institute.

d) Data entities and their relationships
- User
  - Attributes: username, encrypted password, email, first name, last name, role, university, department, account status.
  - Relationships: User 1..* uploads Publication; User 0..* belongs to Group.
- Group
  - Attributes: group name (unique), permissions.
  - Relationships: Group 0..* has Users.
- Author
  - Attributes: canonical name, aliases/variants.
  - Relationships: Author *..* writes Publication.
- Institute
  - Attributes: canonical name, aliases/synonyms.
  - Relationships: Institute 1..* affiliated-with Publication; optionally related to User/Department where applicable.
- Publication
  - Attributes: title, abstract, keywords, publication date/year, file references (pdf/ps/odt), availability flags.
  - Relationships:
    - Publication *..* has Authors.
    - Publication 0..1 has Institute (or primary affiliation).
    - Publication *..* cites Reference/Publication; Publication *..* is cited by Publication.
    - Publication *..1 owned by User (uploader).
- Reference (citation entry)
  - Attributes: bibliographic fields sufficient for BIB/RIS export.
  - Relationships: Reference 0..1 links to a Publication when the cited work exists in the system; Publication *..* has References.
- Configuration
  - Attributes: key, value pairs for system settings.
- Logs/Statistics
  - Attributes: timestamp, severity/type, message/context, user/session, function invoked.

e) Integrity constraints
- User.username and Group.groupname shall be unique.
- Passwords shall be stored only in encrypted form.
- A Group may be deleted only if it has no Users.
- Deleting or modifying records shall not leave dangling references:
  - Publication–Author, Publication–Institute, and Publication–Publication (cites) relationships must remain valid.
  - References to deleted Publications must be removed or re-linked to standalone Reference entries.
- Publication records shall contain, at minimum, a title; referenced file entries shall indicate available formats.
- Role-based editing constraints shall be enforceable at the data level (e.g., Publishers can edit only their own publications; Moderators can edit departmental publications; Administrators can edit all), preventing unauthorized updates.
- Alias mappings shall ensure that multiple name variants resolve to the same Author/Institute entity.

f) Security
- Store user passwords encrypted; no plaintext passwords in the database.
- Enforce role- and group-based access control over create/read/update/delete operations on Users, Groups, Publications, Authors, Institutes, References, and Configuration.
- Direct database access is restricted to Administrators via CLI; all other access occurs via the application.
- Logged errors/events shall not expose sensitive data.

g) Data retention requirements
- A backup structure is required to preserve all data in case of server or disk problems.
- Retention periods, archival policies, and deletion schedules: [N/A]

## 3.6 Design constraints

- External standards and conventions
  - Web interface must comply with W3C XHTML 1.0 Transitional [3].
  - Design diagrams must follow UML [11].
  - Implementation must comply with the SE1 Coding Conventions [10].
  - Communication shall use HTTP over TCP/IP port 80.
  - Supported bibliographic formats: BibTeX and RIS (import/export).
  - Supported publication/document formats: PDF and PS (upload/download); ODT supported for upload; export to HTML, PDF, and PS.

- Platform and technology constraints
  - Must run on Linux, specifically the Wilma server environment.
  - Requires Ruby 1.8 or later; implementation must be object-oriented in Ruby.
  - Database interface is to MySQL.
  - No frameworks are allowed.
  - Only free software may be used for tools and the end product; exceptions must be justified in the SCMP.
  - Git must be used for configuration management.
  - Must be accessible via web browsers on any OS, explicitly including text-based browsers on Linux (e.g., Links2).
  - Command-line access for administrators is within the VUB-network.

- Project and architectural limitations
  - System design must be modular to simplify expansions and replacements.
  - Max publication file size: TBD.
  - Installation should be easy: TBD.

- Regulatory requirements
  - [N/A]

## 3.7 Software system attributes

### Reliability
- The system shall maintain database consistency at all times (e.g., no pointers to deleted records and no redundant information).
- The database subsystem shall support handling several concurrent requests via SQL without corrupting data.
- The system shall log errors that occur during requests and present an error message to the user stating the cause; logged errors shall be available to Administrator(s) for diagnosis.
- The system shall be verified and tested according to the referenced SQAP and STD to minimize software faults at delivery.

### Availability
- The system shall be available at all times from any computer that meets the assumptions in the SRS, except when the Wilma server is unavailable.
- The system shall provide a backup structure to enable restoration of data in case of server or disk problems.
- In case of a corrupted database, the Administrator shall be able to restore the system using the last available backup.
- In case of hardware or software failure, the system shall display a temporary downtime message to users until the issue is resolved and the PMS is reinitialized.

### Security
- Access from outside the VUB network shall require a successful login.
- Each user account shall be protected by a personal password.
- Passwords shall be encrypted during transmission from client to server and stored in the database in encrypted form; only the PMS shall access stored passwords.
- Direct access to database-stored data shall be restricted to Administrator(s) using the CLI.
- Role-based access control shall be enforced at all times according to user levels (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator), including restrictions on searching, uploading, editing, and deleting publications.

### Maintainability
- The system shall employ a modular design to simplify expansions and replacements.
- The database shall be maintainable by Administrator(s); global user-level and privilege configurations shall be maintainable by Administrator(s), and departmental configurations by Moderator(s).
- The system shall log errors to support maintenance and troubleshooting.
- The implementation shall be documented using RDoc to facilitate maintenance.

### Portability
- The system shall run on Linux, specifically the Wilma server environment, with Ruby 1.8 or later installed.
- While developed and tested for Linux/Wilma, relocation to other operating systems is possible if required software is available and adjustments are made; full cross-platform portability is not required nor fully implemented.

## 3.8 Supporting information

- a) Sample input/output formats, cost analysis, and user surveys
  - Supported import formats:
    - Bibliographic data: BibTeX, RIS.
    - Document files for full text: PDF, PS, ODT.
  - Supported export formats:
    - Publications: HTML, PDF, PS.
    - References: BibTeX (BIB), RIS.
  - Cost analysis studies: [N/A]
  - User surveys: [N/A]

- b) Supporting/background information
  - Target environment and interfaces:
    - Linux-based server (Wilma) with a web server and MySQL database.
    - Web access over HTTP (TCP/IP port 80); CLI access for administrators on the server.
  - Technology and standards:
    - Ruby 1.8 or later; object-oriented implementation; no frameworks.
    - UI conforms to W3C XHTML 1.0 Transitional.
    - UML for design diagrams; RDoc for code documentation; Git for configuration management.
    - Only free software tools for development and the end product.
  - User model and access:
    - Roles: Guest, VUB-Network User, Member, Publisher, Moderator, Administrator.
    - Network-based access recognition (VUB IP); account registration with email validation.
  - Installation/site adaptation:
    - Intended to be easy to install on Linux with Ruby 1.8+.
    - Installer or exact procedure: TBD.
  - Operational notes:
    - Publication file size limit: TBD.
    - Errors presented to users and logged for administrators.

- c) Problems to be solved by the software
  - Centralize storage and management of bibliographic records and associated full texts.
  - Enable automatic extraction of bibliographic metadata from uploaded documents with user correction when needed.
  - Support disambiguation and normalization of author and institute names (e.g., mapping “D. Vermeir” to “Dirk Vermeir”; “VUB” to “Vrije Universiteit Brussel”).
  - Provide efficient search, viewing, download, and export of publications and their references.
  - Support bulk importing of publications and/or abstracts from standard bibliographic formats.
  - Enforce role-based access control for upload, edit, delete, and administrative operations (including departmental moderation and global administration).
  - Maintain database consistency and ensure backup/restore capability.

- d) Special packaging instructions for code and media (security, export, initial loading)
  - [N/A]

Unless an item above is already specified in Sections 3.1–3.7, the information in this section is provided for background only and is not, by itself, a requirement.

## 4.1 Functions

This section outlines how the functional requirements will be verified, consistent with the SQAP [12] and STD [13] referenced by the project. Verification activities trace to the functional requirements listed in Section 3.2 (3.2.1–3.2.31) and will confirm preconditions, input validity, sequences of operations, exception handling, and expected results.

- a) Validity checks on the inputs
  - Authentication and account lifecycle (3.2.1–3.2.5, 3.2.19)
    - Verify login accepts only registered users and rejects invalid credentials; verify logoff requires a logged-in session.
    - Verify registration checks for an already existing username and handles it per the requirement; verify required personal data is provided; verify registration-triggered email notifications occur as specified.
    - Verify password change requires a valid username and handles a non-existent username as an exception.
  - Access level and network origin (Sections 2.1, 2.3; 3.2.x preconditions)
    - Verify functional access based on user role (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator) and on VUB-network connectivity (IP-based recognition).
  - Search and view (3.2.6–3.2.9, 3.2.12–3.2.18)
    - Verify search input fields accept specified keywords (including logical expressions), author names, and valid date ranges; verify malformed or empty criteria are handled per the requirements (e.g., no-results case).
  - Download and export (3.2.10–3.2.11, 3.2.14, 3.2.16–3.2.17)
    - Verify selection-based operations (single vs. multiple) require a valid prior selection or “All” invocation; verify format selection (BIB/RIS) produces the chosen format.
  - Publication upload/edit (3.2.20–3.2.22)
    - Verify upload accepts only supported formats (pdf, ps, odt) and rejects unsupported ones; verify metadata is retrieved when available and that manual correction is possible.
    - [N/A] for maximum file size verification (file size limit is TBD; see 2.2.4).
  - User and group administration (3.2.23–3.2.31)
    - Verify Create User rejects duplicate usernames; Delete User rejects non-existent usernames.
    - Verify Create Group rejects duplicate group names; Delete Group enforces “group must be empty” precondition.
    - Verify search functions require valid criteria and return only matching entities; verify edits require a selected entity.
- b) Exact sequence of operations
  - Access paths (3.2.1–3.2.4)
    - Outside VUB-network: present login screen; upon successful login, grant appropriate role-based access; verify logout redirects per requirement.
    - Within VUB-network: present login or allow immediate search as specified.
  - Search-to-result workflows (3.2.6–3.2.9, 3.2.12–3.2.18)
    - Execute: Search → Results pagination → Detailed view → References/Authors → Full text/Download/Export.
    - Verify that each step is reachable only after its stated preconditions (e.g., a search has been executed; a publication has been selected).
  - Publication ownership workflows (3.2.20–3.2.22)
    - Execute: My Publications → Select → Edit; Upload → Metadata extraction → Review/Confirm.
  - Administration workflows (3.2.23–3.2.31)
    - Users: Search → Select → Edit; Create → Confirm; Delete → Confirm.
    - Groups: Search → Select → Edit; Create → Confirm; Delete (only when empty) → Confirm.
    - Configuration: Access Control Panel → Change settings → Confirm.
- c) Responses to abnormal situations
  - 1) Overflow
    - [N/A]
  - 2) Communication facilities
    - [N/A]
  - 3) Hardware faults and failures (3.6.2)
    - Verify that when the hosting server (Wilma) is unavailable, the PMS displays a temporary-down error to visitors.
    - Verify presence and restorability of database backups per the backup requirement (3.4).
  - 4) Error handling and recovery (2.2.2; exceptions in 3.2.x)
    - Inject representative operation failures (e.g., invalid inputs, missing entities, no search results) and verify user-visible error messages are shown and the errors are logged by the PMS.
    - Verify exception cases stated in the requirements (e.g., duplicate usernames/groups; non-existent users; non-empty group deletion; invalid username in password change) produce the specified outcomes.
- d) Effect of parameters
  - Role/privilege level (2.1, 2.3; reflected across 3.2.x)
    - Verify function availability and authorization behaviors across Guest, VUB-Network User, Member, Publisher, Moderator, Administrator, including departmental scope for Moderator actions.
  - Network origin (2.1)
    - Verify VUB-network detection (by IP) unlocks access as specified for non-logged-in users; verify outside-network access is restricted to login/registration unless logged in.
  - Configuration settings (3.2.31)
    - Verify that changes in configuration parameters (from the Control Panel) take effect as described for subsequent operations.
  - Search parameters (3.2.6)
    - Verify keyword, author, and date-range choices constrain results as described.
- e) Relationship of outputs to inputs
  - 1) Input/output sequences
    - For each functional requirement (3.2.1–3.2.31), execute the described steps under “Description” and verify the “Result” is produced:
      - Login/logoff produce session start/termination and required redirections.
      - Search produces a results list; no-results case is handled as specified.
      - Detailed view shows title, authors, date, abstract, and cited references.
      - Downloads and full-text display yield electronic copies or on-screen content when available.
      - Exports produce files in BIB or RIS as selected.
      - Upload produces a new publication populated with extracted metadata, allowing corrections before confirmation.
      - User/Group create, edit, delete, and search operations persist and reflect changes as described, honoring stated preconditions and exceptions.
  - 2) Formulas for input to output conversion
    - [N/A]

## 4.2 Performance requirements

This subsection defines the verification approaches and methods for qualifying performance. Because the original SRS does not state measurable performance targets (see 3.3 Performance Requirements: TBD), the items below identify the intended verification focus and explicitly mark missing acceptance criteria as [N/A]. Execution of the methods and collection of evidence shall follow the SQAP [12] and STD [13].

- Verification scope linkage to Requirements (3.2 Performance requirements)
  - Status of quantitative requirements: [N/A]
  - Test environment: Wilma Linux server; Ruby 1.8+; MySQL database; HTTP over TCP/IP port 80; clients via standard web browsers (including text-based browsers such as Links2); CLI for administrators.

- Static capacity verification
  - Number of terminals/browsers to be supported
    - Requirement: [N/A]
    - Verification method: compatibility-based access from multiple client machines/browsers to confirm connectivity and session handling on the web server.
    - Acceptance criteria: [N/A]
  - Number of simultaneous users to be supported
    - Requirement: database must handle several requests at once.
    - Verification method: concurrent access test (parallel searches/downloads/exports) to exercise simultaneous HTTP requests and concurrent SQL operations.
    - Acceptance criteria: [N/A]
  - Amount and type of information to be handled
    - Requirement: publications database stores bibliographical data; full texts in PDF/PS; maximum file size TBD; no specific memory limit.
    - Verification method: upload/download/import of representative PDF/PS files and associated metadata; verify storage and retrieval; verify operation without enforced memory ceilings.
    - Acceptance criteria: [N/A]

- Dynamic performance verification (normal and peak workloads)
  - Search and results pagination responsiveness
    - Requirement: [N/A]
    - Verification method: measure end-to-end response time for search submission to first result render under normal and elevated load.
    - Acceptance criteria: [N/A]
  - Publication upload and metadata extraction
    - Requirement: automatic retrieval of bibliographical information with user correction capability.
    - Verification method: measure time to ingest files (PDF/PS) and complete metadata extraction; include cases requiring manual correction.
    - Acceptance criteria: [N/A]
  - Bulk upload throughput
    - Requirement: ability to import many publications (e.g., via BibTeX/RIS files).
    - Verification method: time a representative bulk import and record throughput and system stability.
    - Acceptance criteria: [N/A]
  - Download/export throughput
    - Requirement: ability to export/download publications to HTML/PDF/PS and export references (BIB/RIS).
    - Verification method: measure time to initiate and complete single and multiple publication downloads/exports under normal and elevated load.
    - Acceptance criteria: [N/A]
  - Concurrent request handling
    - Requirement: database must handle several requests at once.
    - Verification method: mixed-workload load testing (simultaneous search, upload, download, export) to observe contention, error rates, and successful completion.
    - Acceptance criteria: [N/A]

- Evidence and reporting
  - Collected evidence: test procedures, load profiles, timestamps/latency samples, throughput logs, server/application error logs.
  - Pass/fail determination: [N/A]
  - Deviations and limitations: any observed performance behavior will be documented; final qualification against quantitative thresholds is pending until those thresholds are specified.

## 4.3 Usability requirements

This section defines how the usability-related requirements in the SRS will be verified. The approaches below reference the originating requirements to keep verification parallel with the Requirements section.

- Web UI standards compliance (from 2.2.2 User Interfaces; 2.5 Constraints; 3.1.1 Web Interface)
  - Method: Validate all delivered HTML against W3C XHTML 1.0 Transitional using the W3C validator. Perform manual spot checks of doctype and structural markup.
  - Evidence: Validator reports and reviewed pages.

- Cross-platform and text-based browser operability (from 2.2.2 User Interfaces)
  - Method: Execute end-to-end usability tests on Linux using a text-based browser (e.g., Links2) to confirm all user-visible functions are operable and understandable. Perform smoke tests on other OS/browser combinations to confirm basic access and interaction.
  - Evidence: Test logs with screenshots (where applicable) and pass/fail notes per function.

- Interaction efficiency: minimal pages/clicks while maintaining structure (from 2.5 Constraints; 3.1.1 Web Interface)
  - Method: Task-based walkthroughs measuring page loads and clicks for representative user goals, ensuring no unnecessary intermediate steps. Representative tasks include: register (3.2.3), login (3.2.1, 3.2.2), search (3.2.6), view results (3.2.7), view details (3.2.8), download (3.2.10, 3.2.11), export references (3.2.16, 3.2.17), upload publication (3.2.22), log off (3.2.4).
  - Evidence: Click-path records per task with reviewer notes confirming there are no superfluous steps.

- Clarity and structure of the UI (from 3.1.1 Web Interface; 2.5 Constraints)
  - Method: Expert heuristic evaluation and cognitive walkthroughs of the main flows listed above, checking clarity of labels, consistency of navigation, visibility of system status, and overall structure.
  - Evidence: Heuristic evaluation checklists and issue lists with resolutions.

- Error communication and logging (from 2.2.2 User Interfaces)
  - Method: Fault injection during common user actions (e.g., invalid form inputs, failed uploads, permission denials) to verify the user receives an error message stating the cause, and that the error is logged for Administrator notification.
  - Evidence: Collected UI messages (text) and corresponding system log entries.

- Navigation behavior on logout (from 3.2.4 Log off)
  - Method: Scenario tests verifying post-logout redirection behavior differs correctly for users connected to the VUB network versus others.
  - Evidence: Test scripts and observed redirect targets.

- Role-appropriate discoverability of functions (from 2.3 Product functions)
  - Method: For each role (Guest, VUB-Network User, Member, Publisher, Moderator, Administrator), verify that only permitted actions are visible and readily discoverable from the starting context; confirm inherited functions are accessible without excessive navigation.
  - Evidence: Role-based UI inventories and discoverability notes per function.

- Search usability and result handling (from 2.3.2–2.3.6; 3.2.6–3.2.13)
  - Method: Execute search and advanced search flows; verify the availability of ordering options, similarity/refinement options, and multi-select actions (view all, download all, references for multiple) without unnecessary navigation.
  - Evidence: Test run records with observed control availability and interaction steps.

- Download and export flows (from 2.3.2; 3.2.10, 3.2.11, 3.2.16, 3.2.17)
  - Method: Verify that download and export options are presented at the expected locations (results, detail views), are clearly labeled (format: html/pdf/ps/bib/ris), and complete without confusing intermediate steps.
  - Evidence: UI captures and outcome files.

- Accessibility requirements beyond text-browser support
  - [N/A]

- Measurable effectiveness targets (task success rate, error rate)
  - [N/A]

- Measurable efficiency targets (time-on-task, click thresholds)
  - [N/A]

- User satisfaction targets (questionnaires, SUS scores)
  - [N/A]

- Avoidance of harm in specific contexts of use
  - [N/A]

- In-application help, user assistance, training materials
  - [N/A]

- CLI usability criteria
  - [N/A]

## 4.5 Logical database requirements

This section defines the verification approaches and methods to qualify compliance with the logical database requirements in 3.5. Each item mirrors the information items defined for 3.5.

- a) Types of information used by various functions
  - Sources in SRS: 3.4 (all data saved: static/dynamic information, statistics, publications, administrator-settings), 2.3/3.2 (users, groups, departments, user levels, publications with title/authors/date/abstract/cited references, full-text files pdf/ps/odt, error logs, author/institute synonym indications).
  - Verification methods:
    - Schema and data dictionary review to confirm presence of required entities/attributes (users, groups/departments, roles/user levels, publications, authors, institutes, references, admin settings, statistics, error logs, file pointers for full texts, synonym mappings).
    - Function-to-data trace tests: execute representative scenarios (e.g., Register, Upload publications, Edit user/group, Consult references, View authors, Error generation) and verify the expected records are created/updated/read in the database.
    - Persistence checks: restart server and verify data remains intact.

- b) Frequency of use
  - Sources in SRS: 3.4 (database must handle several requests at once).
  - Verification methods:
    - Concurrency and contention testing: simulate concurrent users performing searches, uploads/edits, and exports; verify successful completion without data loss, deadlocks, or errors.
    - Transaction isolation checks on concurrent updates to the same entities (e.g., publication edit vs. reference edit) to ensure consistent results.
    - Throughput/latency measurements under concurrent load to confirm stable behavior; detailed frequency targets [N/A].

- c) Accessing capabilities
  - Sources in SRS: 2.2.1 (MySQL interface), 2.2.3 (HTTP via web server), 3.1 (Web access and CLI).
  - Verification methods:
    - Connectivity tests: application successfully establishes database connections and executes CRUD operations required by each function (search, view, upload, edit, admin operations).
    - Interface segregation checks: verify all data access originates from the PMS application/web server for end users and only from CLI for administrators where applicable.
    - Error handling checks: induce database errors and verify user-facing error messages and logging per 2.2.2.

- d) Data entities and their relationships
  - Sources in SRS: 2.3/3.2 (Publication–Author, Publication–Publication references, User–Group/Department, ownership of publications, role/user level, author/institute synonym indications).
  - Verification methods:
    - ER/schema review to confirm modeled relationships (e.g., many-to-many Publication–Author, self-referential Publication–Reference, User–Group/Department membership, Publication ownership/scoping, synonym mappings).
    - Referential integrity tests: create linked data, then query “View authors,” “Consult publication references,” “My Publications,” and group-scoped moderation to confirm correct joins and scoping.
    - Round-trip tests: create, update, and delete related records and verify relationships remain valid (or are restricted/cascaded as specified in e).

- e) Integrity constraints
  - Sources in SRS: 3.4 (no pointers to deleted records, no redundant information), 3.2.3 (username uniqueness check), 3.2.29 (group must be empty before deletion).
  - Verification methods:
    - Referential integrity enforcement: attempt to delete parent records with dependents (e.g., group with users, publication with references) and verify the system prevents dangling pointers or performs controlled cascades; afterward scan for orphaned references.
    - Uniqueness tests: attempt to register duplicate usernames and verify rejection per 3.2.3.
    - Consistency checks: merge/alias operations for authors/institutes (as specified by the user) produce a single logical identity in search/results; verify no duplicate/contradictory identities appear.
    - Redundancy scans: identify duplicate bibliographic records after bulk and single uploads and validate deduplication behavior if specified; explicit deduplication rules [N/A].

- f) Security
  - Sources in SRS: 3.6.3 (password encrypted in transit and stored encrypted; direct DB access only for Administrators via CLI; enforcement of user levels).
  - Verification methods:
    - Credential storage inspection: verify passwords are not stored in plaintext (hash/crypto present); attempt DB read to confirm irreversibility.
    - Submission protection check: verify password is encrypted when submitted from client to server as specified; implementation specifics [N/A].
    - Access control tests: ensure application roles (Guest/VUB-Network User/Member/Publisher/Moderator/Administrator) constrain create/read/update/delete operations on database-backed data per functions; direct database access limited to administrators via CLI (attempt remote/non-admin DB access and verify denied).
    - Injection and query safety tests: execute crafted inputs through the PMS to ensure parameterized queries and no unauthorized data exposure; specific controls [N/A].

- g) Data retention requirements
  - Sources in SRS: 3.4 (backup structure requirement), 3.6.2 (restore from last available backup upon corruption).
  - Verification methods:
    - Backup/restore drills: perform full and (if implemented) incremental backups, then restore to a clean environment; verify data completeness (users, groups, publications, files/links, settings, logs).
    - Backup recency and integrity checks: validate backup scheduling and integrity; specific retention periods and policies [N/A].
    - Disaster recovery validation: simulate database corruption/failure and confirm documented procedure restores service with latest backup per 3.6.2.

## 4.6 Design constraints

Verification of design constraints will follow the processes referenced in SQAP [12] and STD [13]. The items below parallel Requirements section 3.6 Design constraints.

- PMS web interface must conform to W3C XHTML 1.0 Transitional standard [3].
  - Planned verification approach: [N/A]
- Implementation must be compliant with the Coding Conventions of SE1 [10].
  - Planned verification approach: [N/A]
- Implementation must be object-oriented.
  - Planned verification approach: [N/A]
- Design diagrams must follow the UML standard [11].
  - Planned verification approach: [N/A]

## 4.7 Software system attributes

The verification items below correspond to Requirements 3.7 Software system attributes and indicate how each attribute will be qualified. Where the original SRS does not define a verification approach or method, this is marked as [N/A].

### Reliability
- Verification approach: Testing processes as defined in the SE1 SQAP and STD; development uses a spiral model with 2 iterations to reduce faults.
- Verification method details: [N/A]
- Evidence sources: SQAP, STD.

### Availability
- Verification approach: [N/A]
- Items to verify:
  - PMS is available from any computer meeting the assumptions and dependencies, except when the Wilma server is not available.
  - During downtime, the PMS presents an error indicating the system is temporarily down.
  - Administrator can replace a corrupted database with the last available backup.

### Security
- Verification approach: [N/A]
- Items to verify:
  - User passwords are encrypted during submission from user to server.
  - User passwords are stored encrypted in the database and are not accessible to anyone except the PMS.
  - Direct access to data stored in the database is restricted to Administrators using the CLI.
  - User levels are enforced for editing, deleting, and uploading publications.

### Maintainability
- Verification approach: [N/A]
- Items to verify:
  - Database maintenance can be performed by Administrator(s).
  - Global maintenance of user levels and special privileges can be performed by Administrators; departmental maintenance by Moderators.

### Portability
- Verification approach: Demonstrate operation on the Wilma Linux-based server as specified by the customer.
- Cross-platform verification: [N/A] (relocation to other OSs is possible in principle but “not fully implemented” in the PMS).

## 5.1 Assumptions and dependencies

- Users have access to a web browser that supports W3C XHTML and a TCP/IP connection to the PMS web server.
- HTTP traffic over TCP/IP port 80 is permitted between client and server.
- Identification of VUB-network users is possible and accurate based on their IP address ranges.
- Email services are available to send validation messages and administrative notifications (e.g., registration confirmation, password-related messages).
- Command line users can access the server shell locally; such access confers Administrator privileges.
- The hosting environment (e.g., the Wilma Linux server) and its network connectivity are available.
- A web server capable of running the PMS and a MySQL database service are available and operational.
- A Ruby 1.8 (or later) runtime is available on a Linux-based environment for installation and operation.
- Users possess basic knowledge of the internet.
- Documents provided for upload adhere to supported formats as specified in the SRS (e.g., pdf, ps, odt; and bibliographic exchange via BibTeX/RIS where applicable).

## 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 system.
- HTML: Hypertext Markup Language.
- HTTP: Hypertext Transfer Protocol.
- IEEE: Institute of Electrical and Electronics Engineers.
- IP: [N/A]
- LaTeX: [N/A]
- MS: [N/A]
- MS Word: [N/A]
- MySQL: [N/A]
- ODT: [N/A]
- 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: Tagged file format for expressing bibliographic citations.
- Ruby: A reflective, dynamic, object-oriented programming language.
- SCMP: Software Configuration Management Plan.
- SE1: Software Engineering group 1.
- SQAP: Software Quality Assurance Plan.
- SRS: Software Requirements Specification.
- STD: Software Test Plan.
- TBD: To Be Determined.
- TCP/IP: [N/A]
- UML: Unified Modelling Language.
- URL: [N/A]
- VUB: Free University of Brussels.
- W3C: World Wide Web Consortium.
- XHTML: [N/A]
- Wilma: Multifunctional Linux server for students of the faculty of sciences at the VUB.