Nichtfunktionale Anforderungen (NFR)

Status: Entwurf · Spec-Kandidat: ja (Querschnitt über mehrere Specs)

ID	Anforderung	Ziel
NFR-001	Datenkonsistenz	ACID-konforme Speicherung
NFR-002	Verfügbarkeit	produktionsgeeigneter Betrieb mit Monitoring und Backup
NFR-003	Performance	übliche Listen- und Filterabfragen performant ausführbar
NFR-004	Erweiterbarkeit	neue Typen ohne Datenbankschemaänderung
NFR-005	Integrität	relationale Beziehungen und kontrollierte Löschregeln
NFR-006	Sicherheit	Authentifizierung, Autorisierung, TLS, Audit
NFR-007	Wartbarkeit	klare API, Migrationen, Versionierung
NFR-008	Beobachtbarkeit	Logging, Metriken, Health Checks
NFR-009	Portabilität	containerisierter Betrieb
NFR-010	SQL-Fähigkeit	ad-hoc Abfragen und Reporting sollen möglich bleiben

Querverweise

NFR	Verantwortliche Spec(s)
NFR-001, NFR-005	DDL, Trigger, Validierung
NFR-002	Backup und Restore, Beobachtbarkeit
NFR-003	Indizes, Suche und Filterung
NFR-004	Domänenmodell
NFR-006	Autorisierung, Authentifizierung, Transport und Sicherheits-Audit
NFR-007	REST API, CI/CD und Migrationen
NFR-008	Beobachtbarkeit
NFR-009	Laufzeitumgebung
NFR-010	Views, SQL / Reporting

V1-Ziele, P95-orientiert. P99 toleriert bis 3× P95; alles darüber ist Capacity-Issue.

Metrik	V1-Ziel
Read-by-ID (Single Entity inkl. JSONB-Casts)	P95 ≤ 50 ms
Liste à 50 Records mit Filter + Volltext	P95 ≤ 200 ms
Single-Insert / -Update einer Entität	P95 ≤ 150 ms
`relate` / `unrelate` einer Beziehung	P95 ≤ 200 ms
Throughput pro Tenant — Reads	sustained 200 req/s
Throughput pro Tenant — Writes	sustained 50 req/s
Datenvolumen pro Tenant	bis 5 Mio Entities, 20 Mio Relations
Concurrent active User je Tenant	50
Worker-Pool je `AA_JOB.job_kind`	4 parallel

Lasttest-Profile decken Worst-Case-Tenant (volles Datenvolumen + voller Cache-Refresh) und Cold-Start (leerer Redis-Cache, OP-24) ab.