Stakeholder Requirements¶
Intended use of LQMS, distilled from project_overview.md. This is the level validation (CSV) validates against; software requirements trace here and are what verification tests against.
| ID | Stakeholder requirement |
|---|---|
| STR-001 | LQMS shall manage QMS documents and project records with document control suitable as the basis for an ISO 13485 compliant QMS (define, review, release, revoke). |
| STR-002 | Review and release processes shall be configurable per project and document type, and simple policies (e.g. a four-eyes rule) shall be simple to configure. |
| STR-003 | Data of different mandators and projects shall be strictly separated; no user may access data of scopes they are not authorized for. |
| STR-004 | A shared QMS base (SOPs, WIs, templates) shall be usable as the starting point for every project; projects shall tailor adopted documents without affecting other projects or the base. |
| STR-005 | The base QMS shall be developable (drafted, reviewed, released) independently of and without impact on running projects; projects adopt new base versions consciously. |
| STR-006 | LQMS shall support multiple projects for multiple mandators in one installation, including project-specific role sets. |
| STR-007 | Daily work shall be intuitive and stable — the tool shall not require workflow expertise for routine document tasks (motivating pain: Confluence/Jira-based QMS). |
| STR-008 | Users shall find QMS content via search, including AI-assisted question answering, without confidential content leaving the control of the configured policies. |
| STR-009 | The exact content and approval history of any released document version shall be reproducible for audits, years after release. |
| STR-010 | The entire QMS or any individual project shall be exportable as a self-contained backup and restorable on the same or a different server. |
| STR-011 | LQMS shall support periodic regulatory re-evaluation with automated reporting support, minimizing manual effort. |
| STR-012 | The user interface shall support multiple languages (Swiss language regions, possibly EU). |
| STR-013 | LQMS shall be evolvable without redesign: document files movable to S3-compatible storage, interfaces extensible toward MCP. |
| STR-014 | LQMS itself shall be validatable (CSV) and shall keep the validated state maintainable: changes shall be verifiable by automated regression evidence. |
| STR-015 | The operating organization's own QMS operations shall be managed within LQMS as a first-class managed unit on equal footing with customer product projects, so a single process definition can serve both product and QMS operations instead of parallel process sets. |
| STR-016 | Users shall authenticate via single sign-on against the organization's existing OIDC identity provider; LQMS shall not manage user credentials. Browser sessions shall be protected against cookie/token theft. |
| STR-017 | The system shall be administrable and projects onboardable from within the application; administrative capability shall be assignable to roles; a fresh installation shall be usable out of the box and self-administering. |
| STR-018 | User accounts shall be manageable across their lifecycle (provisioning, deactivation of leavers, reactivation) while permanently preserving the attribution of their past actions. |
| STR-019 | Where regulation requires it, the system shall support electronic signatures that are uniquely attributable, bound to the signed content, manifested with signer/date/meaning, and applied with re-authentication — capable of satisfying FDA 21 CFR Part 11 and EU Annex 11. |
| STR-020 | Controlled documents shall support an effective date distinct from release, scheduled periodic review with recorded evidence, and optional validity, with overdue/expired items surfaced for action (never auto-invalidated) — per ISO 13485 §4.2.4. |
| STR-021 | LQMS shall implement defined record retention with legal hold and controlled disposal, minimize personal data, and support data-subject rights (access, rectification, and erasure where not overridden by retention obligations) under the Swiss FADP and EU GDPR. |
| STR-022 | LQMS shall meet defined non-functional targets for capacity, performance, availability/recoverability, and security appropriate to an internal multi-mandator QMS. |
| STR-023 | Users shall be made aware of, and able to track to completion, the actions they need to take (reviews, approvals, signatures, overdue reviews, disposals) and relevant events, via an in-app inbox and optional email. |
| STR-024 | Document content shall be manageable in multiple languages as independently controlled translations, and all dates/times shall be unambiguous and locale-appropriate across time zones. |
| STR-025 | LQMS shall let authorized users define which roles must be trained on a document, and shall track that users have read and acknowledged controlled documents — optionally gated by a simple questionnaire — as controlled records, with status reporting. |
| STR-026 | LQMS shall support migrating an existing QMS's current released documents into LQMS as a baseline, so adoption does not require manual re-entry. |
| STR-027 | LQMS shall maintain machine-verifiable traceability across the design-control and risk-management artifacts it holds — requirements, risks and their controls, and the verifies/satisfies/mitigates/implements relationships between them and their governing and verifying documents — so that coverage, gaps, suspect (out-of-date) links, and the artifacts backing a regulatory submission are answerable from the tool rather than reconstructed by hand (the ISO 13485 §7.3 design-control and ISO 14971 risk-management expectation; motivating pain: an existing corpus that keeps its requirements as unlinked prose, tables and duplicated issues). |
| STR-028 | An organization brings a person into its QMS through an explicit, recorded invitation the person accepts — membership (being staffable, appearing in the roster) is separate from access (roles), and one organization can never affect a person's standing elsewhere. |
| STR-029 | A regulated deliverable (technical-documentation dossier) issued from the system is a persisted record: byte-stable, hash-identified, and never silently re-derivable — a copy that is not the record says so on its face. |
| STR-030 | The system carries its own user documentation, versioned and shipped with the release it describes, reachable from the surfaces it explains. |