Software Requirements: Migration & Import¶
Introduced in requirements baseline v1.2 (GAP-15, ADR-0023). Detailed import tooling/mapping is deferred to implementation.
The concrete Confluence/Jira importer (ADR-0068, v1.7) is developer tooling, not
shipped product: it runs as a plain authenticated API client under scripts/import/, its
fetched source data lives in a git-ignored staging area and never enters the repository,
and it is explicitly not yet a validated migration. As a shipped, validated product
migration feature REQ-MIG-001..003 therefore remain future (see the traceability
overrides). REQ-MIG-004/005 below capture the tooling's quality-relevant guarantees —
they protect the source system (read-only) and the mandator/scope separation guarantee
(no SQL side door, real gates), which is why they belong in the baseline even though the
importer itself is tooling.
| ID | Requirement | Trace |
|---|---|---|
| REQ-MIG-001 | The system shall support importing the current released documents and their metadata from an existing QMS as an initial baseline; prior version history need not be imported. (refined by ADR-0068: the Confluence page tree becomes the folder tree, source document types map 1:1, and only the current released version is imported — "in Verwendung" → RELEASED, "obsolet" → REVOKED, ticketless → DRAFT.) | STR-026, STR-007; ADR-0023, ADR-0068 |
| REQ-MIG-002 | Imported documents shall enter as released baseline versions, marked as imported with an imported-from provenance reference (source system + import date). (refined by ADR-0068: provenance records the source page URL and page version, ticket key, and fetch timestamp on every imported version.) |
STR-026, STR-009; ADR-0023, ADR-0021, ADR-0068 |
| REQ-MIG-003 | Import shall be validated (metadata mapping checked, conflicts reported) before committing; a dry-run shall be supported. | STR-026, STR-007, STR-014; ADR-0023 |
| REQ-MIG-004 | Import shall execute exclusively through the public authenticated REST API (no SQL side door), so row-level security, authorization, audit, and search behave identically to normal use; a RELEASED import shall pass the real lifecycle gates (submit/approve/release performed by the import persona wearing the required workflow roles), and the audit trail shall attribute the import persona — never fabricated historical actors — with the source actors preserved in the provenance block. | STR-026, STR-003, STR-009; ADR-0068, ADR-0007, ADR-0064 |
| REQ-MIG-005 | The fetch phase shall be strictly read-only against the source system, and fetched or staged source content shall never enter version control (git-ignored staging); the load phase shall be idempotent and repeatable, keyed by source page id, so a re-run against a stack already carrying the import is detected and skipped rather than duplicated. | STR-026, STR-003; ADR-0068 |
| REQ-MIG-006 | The importer shall be a single parameterized code path over a per-source configuration (source space key, target scope with its capability flags, document-type mapping strategy, macro/cross-link handling), so a second independent source imports into its own scope alongside the first with no cross-scope leakage (proven by importing PULSEMED as a distinct scope beside MERIDIAN-QMS, cross-scope links resolving through the loaded set). A companion tooling path shall import external-training history from the legacy system into the training-entry records (REQ-TRN-009) with honest provenance and status mapping (abgeschlossen → RECORDED, never auto-CONFIRMED). This remains developer tooling per the group preamble. |
STR-026, STR-003; ADR-0068, ADR-0071 |
| REQ-MIG-007 | The importer shall recognize an existing QMS's requirement representations — **KEY** (JIRA-key) prose headers AND table-form definition rows (e.g. the PULSEMED REC-007 stakeholder families) — and convert them into :::requirement blocks (stakeholder-requirement rows carrying kind="stakeholder"; non-key columns folded into the block body so nothing is dropped), governed by a name-derived subtype flagged may-define-requirements NARROWLY (the stakeholder-requirements page, never RECORD scope-wide). It shall seed item TRACE LINKS from the source traceability tables — the software requirement key as the satisfies source, the stakeholder key as the target — parsing COLUMN-AWARE (keys taken only from the mapping column, not from rationale prose), expanding hyphen/range and glob conventions to explicit convention-derived edges (carrying the row's rationale in the link note), and LOGGING unparseable fragments rather than guessing. This remains developer tooling per the group preamble. |
STR-026, STR-027, STR-009; ADR-0077, ADR-0068 |