Einrichtung erste Welle
This commit is contained in:
@@ -589,3 +589,586 @@ Wenn du sofort in Umsetzung gehen willst, ist die sauberste Reihenfolge:
|
||||
5. Survey Admin MVP und danach Survey Publishing
|
||||
6. Erst danach Payment-Reconciliation, Mailbox-Import und komplexere
|
||||
Identity-Integrationen
|
||||
|
||||
## Ticket-Struktur Fuer Phase 0
|
||||
|
||||
Ziel:
|
||||
- Alle verbleibenden Detailregeln so festziehen, dass danach produktive
|
||||
Implementierung ohne Grundsatzdiskussion starten kann.
|
||||
|
||||
Empfohlene Epics:
|
||||
|
||||
### Epic P0-1. Identity Und Benutzerabgleich
|
||||
|
||||
Tickets:
|
||||
- P0-1.1 Erstlogin-Flow fuer lokale Anmeldung und ADFS/OIDC beschreiben
|
||||
- P0-1.2 E-Mail-Mapping, Dublettenfall und Admin-Klaerprozess definieren
|
||||
- P0-1.3 Reaktivierung, Benutzerzusammenfuehrung und Fehlerfaelle festlegen
|
||||
|
||||
Ergebnis:
|
||||
- Umsetzbare Identity-Spezifikation fuer Authentifizierung und Mapping
|
||||
|
||||
### Epic P0-2. Rollen Und Rechte
|
||||
|
||||
Tickets:
|
||||
- P0-2.1 Rechte-Matrix pro Rolle und Objekt finalisieren
|
||||
- P0-2.2 Tenant-Grenzen und Admin-Override dokumentieren
|
||||
- P0-2.3 Spezialrollen `finance_admin`, `support_contact`, `survey_manager`
|
||||
gegen Fachprozesse pruefen und bestaetigen
|
||||
|
||||
Ergebnis:
|
||||
- Belastbare Rechtebasis fuer alle MVP-Module
|
||||
|
||||
### Epic P0-3. Support-Workflow
|
||||
|
||||
Tickets:
|
||||
- P0-3.1 Statusmodell fuer Supportvorgaenge definieren
|
||||
- P0-3.2 Routing fuer Benutzer, Support-Verantwortliche, Tenant-Admins und
|
||||
Plattform-Administration festlegen
|
||||
- P0-3.3 Sichtbarkeit, Eskalation und Abschlussregeln festziehen
|
||||
|
||||
Ergebnis:
|
||||
- Vollstaendiges Vorgangsmodell fuer Support Requests
|
||||
|
||||
### Epic P0-4. Buchungskorrekturen Und Schutzmechanismen
|
||||
|
||||
Tickets:
|
||||
- P0-4.1 Regeln fuer Storno von Einzahlungen definieren
|
||||
- P0-4.2 Regeln fuer Loeschung von Stricheintraegen definieren
|
||||
- P0-4.3 Begruendung, Auditspur und Historie fuer Korrekturen beschreiben
|
||||
- P0-4.4 Vorschau, Testmodus und tenantweit deaktivierbare Vier-Augen-Freigabe
|
||||
fuer kritische Aktionen festlegen
|
||||
|
||||
Ergebnis:
|
||||
- Verbindliches Regelwerk fuer sichere Korrekturen und risikoreiche Aktionen
|
||||
|
||||
### Epic P0-5. Survey-Freigabe Und Jahresauswertung
|
||||
|
||||
Tickets:
|
||||
- P0-5.1 Survey-Freigabeprozess mit Snapshot-Veroeffentlichung definieren
|
||||
- P0-5.2 Rollen fuer Survey-Erstellung, Freigabe und Veroeffentlichung
|
||||
bestaetigen
|
||||
- P0-5.3 Jahresauswertung mit Parametern, Vorschau und Freigabe spezifizieren
|
||||
- P0-5.4 Bonuslogik fuer fixe und flexible Auszahlungen fachlich schneiden
|
||||
|
||||
Ergebnis:
|
||||
- Nutzbare Fachspezifikation fuer Surveys und Jahresauswertung
|
||||
|
||||
### Epic P0-6. Zahlungsmodell Und Profilfelder
|
||||
|
||||
Tickets:
|
||||
- P0-6.1 Tenant-Zahlungsdaten und Pflichtfelder pro Zahlungsart definieren
|
||||
- P0-6.2 Manuelle Klaerfaelle fuer Buchungen und spaetere Reconciliation
|
||||
beschreiben
|
||||
- P0-6.3 Tenantweite Zusatzfelder wie `paypalname` fachlich festlegen
|
||||
|
||||
Ergebnis:
|
||||
- Saubere Daten- und Konfigurationsbasis fuer Payment und Profile
|
||||
|
||||
## Ticket-Struktur Fuer Das MVP
|
||||
|
||||
Ziel:
|
||||
- Aus den Phase-0-Ergebnissen ein erstes nutzbares Produkt mit stabilem
|
||||
Tenant-Betrieb bauen.
|
||||
|
||||
Empfohlene Epics:
|
||||
|
||||
### Epic MVP-1. Identity Baseline
|
||||
|
||||
Tickets:
|
||||
- MVP-1.1 Lokale Anmeldung produktiv umsetzen
|
||||
- MVP-1.2 ADFS/OIDC als zusaetzlichen Login integrieren
|
||||
- MVP-1.3 E-Mail-Mapping und Admin-Klaerfall implementieren
|
||||
- MVP-1.4 Benutzerabgleich, Reaktivierung und Fehlermeldungen absichern
|
||||
|
||||
Abhaengigkeit:
|
||||
- Phase 0 Epic P0-1
|
||||
|
||||
### Epic MVP-2. Rollen Und Tenant-Administration
|
||||
|
||||
Tickets:
|
||||
- MVP-2.1 Rollenmodell im System anlegen
|
||||
- MVP-2.2 Rechtepruefung pro Modul umsetzen
|
||||
- MVP-2.3 Tenant-Admin- und Spezialrollenverwaltung bereitstellen
|
||||
|
||||
Abhaengigkeit:
|
||||
- Phase 0 Epic P0-2
|
||||
|
||||
### Epic MVP-3. Content Und FAQ
|
||||
|
||||
Tickets:
|
||||
- MVP-3.1 Hinweisverwaltung mit CRUD, Aktivierung und Sichtbarkeit umsetzen
|
||||
- MVP-3.2 FAQ-Verwaltung mit Standardvorlage und Tenant-Override umsetzen
|
||||
- MVP-3.3 Frontend-Ausspielung fuer Hinweise und FAQ anbinden
|
||||
|
||||
Abhaengigkeit:
|
||||
- Phase 0 Epic P0-2
|
||||
|
||||
### Epic MVP-4. Payment Configuration Und Manuelle Buchung
|
||||
|
||||
Tickets:
|
||||
- MVP-4.1 Zahlungsarten pro Tenant konfigurieren
|
||||
- MVP-4.2 Zahlungsdaten und Hinweise pro Zahlungsart pflegen
|
||||
- MVP-4.3 Manuelle Einzahlungsbuchung und Self-Service-Anzeige umsetzen
|
||||
- MVP-4.4 Datenmodell fuer spaetere Reconciliation vorbereiten
|
||||
|
||||
Abhaengigkeit:
|
||||
- Phase 0 Epic P0-6
|
||||
|
||||
### Epic MVP-5. Ledger Korrekturen
|
||||
|
||||
Tickets:
|
||||
- MVP-5.1 Storno fuer Einzahlungen implementieren
|
||||
- MVP-5.2 Loeschung fuer Stricheintraege implementieren
|
||||
- MVP-5.3 Auditspur, Begruendung und Historie fuer Korrekturen umsetzen
|
||||
|
||||
Abhaengigkeit:
|
||||
- Phase 0 Epic P0-4
|
||||
|
||||
### Epic MVP-6. Support Requests
|
||||
|
||||
Tickets:
|
||||
- MVP-6.1 Supportvorgaenge als Datenmodell und UI anlegen
|
||||
- MVP-6.2 Statuswechsel, Routing und Sichtbarkeit implementieren
|
||||
- MVP-6.3 Benutzeransicht fuer eigene Vorgaenge umsetzen
|
||||
- MVP-6.4 Bearbeitungsansicht fuer Verantwortliche und Support-Kontakte
|
||||
umsetzen
|
||||
|
||||
Abhaengigkeit:
|
||||
- Phase 0 Epic P0-3
|
||||
|
||||
### Epic MVP-7. Survey Admin Und Publishing
|
||||
|
||||
Tickets:
|
||||
- MVP-7.1 Survey-Erstellung und Fragenverwaltung umsetzen
|
||||
- MVP-7.2 Freigabeprozess fuer Tenant- und Survey-Verantwortliche umsetzen
|
||||
- MVP-7.3 Snapshot-Veroeffentlichung fuer Benutzer implementieren
|
||||
- MVP-7.4 Grundauswertung fuer Tenant-Admins bereitstellen
|
||||
|
||||
Abhaengigkeit:
|
||||
- Phase 0 Epic P0-5
|
||||
|
||||
### Epic MVP-8. Schutzmechanismen Und Betriebsfaehigkeit
|
||||
|
||||
Tickets:
|
||||
- MVP-8.1 Vorschau und Testmodus fuer kritische Sammelaktionen umsetzen
|
||||
- MVP-8.2 Tenantweite Konfiguration fuer Vier-Augen-Freigabe umsetzen
|
||||
- MVP-8.3 Logging, Audit und Fehlerbenachrichtigung fuer kritische Prozesse
|
||||
umsetzen
|
||||
- MVP-8.4 Abnahmefaelle und Testdaten fuer Kernworkflows anlegen
|
||||
|
||||
Abhaengigkeit:
|
||||
- Phase 0 Epic P0-4
|
||||
|
||||
## Empfohlene Reihenfolge Der MVP-Epics
|
||||
|
||||
1. MVP-1 Identity Baseline
|
||||
2. MVP-2 Rollen Und Tenant-Administration
|
||||
3. MVP-3 Content Und FAQ
|
||||
4. MVP-4 Payment Configuration Und Manuelle Buchung
|
||||
5. MVP-5 Ledger Korrekturen
|
||||
6. MVP-6 Support Requests
|
||||
7. MVP-7 Survey Admin Und Publishing
|
||||
8. MVP-8 Schutzmechanismen Und Betriebsfaehigkeit
|
||||
|
||||
## Backlog-Format Fuer Tickets
|
||||
|
||||
Dieses Format kann direkt fuer Jira, GitHub Issues oder ein internes
|
||||
Projektboard verwendet werden.
|
||||
|
||||
| Feld | Beschreibung |
|
||||
| --- | --- |
|
||||
| Ticket-ID | Eindeutige Kennung, z. B. `P0-1.1` oder `MVP-4.2` |
|
||||
| Titel | Kurzer, umsetzungsorientierter Ticketname |
|
||||
| Prioritaet | `hoch`, `mittel`, `niedrig` |
|
||||
| Ziel | Welches Problem oder Ergebnis das Ticket adressiert |
|
||||
| Beschreibung | Konkreter Umsetzungsumfang |
|
||||
| Akzeptanzkriterien | Pruefbare Bedingungen fuer Abnahme |
|
||||
| Abhaengigkeiten | Vorbedingungen oder vorherige Tickets |
|
||||
|
||||
## PRD-Backlog Fuer Phase 0
|
||||
|
||||
### P0-1.1 Erstlogin-Flow Fuer Lokale Anmeldung Und ADFS/OIDC
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Den verbindlichen Anmelde- und Erstlogin-Prozess beschreiben.
|
||||
|
||||
Beschreibung:
|
||||
- Beschreibt lokale Anmeldung, zusaetzliche ADFS/OIDC-Anmeldung und die
|
||||
Benutzerfuehrung beim ersten externen Login.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Lokale Anmeldung und ADFS/OIDC sind als erlaubte Login-Wege beschrieben.
|
||||
- Erstlogin-Schritte fuer neue und bestehende Benutzer sind dokumentiert.
|
||||
- Fehler- und Sonderfaelle sind benannt.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- keine
|
||||
|
||||
### P0-1.2 E-Mail-Mapping Und Dubletten-Klaerfall
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Den Abgleich externer Identitaeten mit internen Benutzern festlegen.
|
||||
|
||||
Beschreibung:
|
||||
- Definiert E-Mail als primaeren Matching-Schluessel und beschreibt
|
||||
Dubletten- oder Konfliktfaelle samt Admin-Klaerprozess.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Matching-Regel per E-Mail ist eindeutig dokumentiert.
|
||||
- Dublettenfall fuehrt in einen definierten Admin-Klaerprozess.
|
||||
- Reaktivierung bestehender Konten ist beschrieben.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-1.1
|
||||
|
||||
### P0-2.1 Rechte-Matrix Pro Rolle Und Objekt Finalisieren
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Eine abnahmefaehige Rechtebasis fuer alle MVP-Module schaffen.
|
||||
|
||||
Beschreibung:
|
||||
- Finalisiert die Rollen `platform_admin`, `tenant_admin`, `finance_admin`,
|
||||
`support_contact`, `survey_manager`, `member` gegen alle relevanten Module.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Jede Rolle hat dokumentierte Rechte pro Modul.
|
||||
- Tenant-Grenzen und Admin-Override sind beschrieben.
|
||||
- Sonderfaelle fuer Storno, Loeschung und Freigabe sind enthalten.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- keine
|
||||
|
||||
### P0-3.1 Support-Statusmodell Und Routing Festlegen
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Das Vorgangssystem fuer Support fachlich fertig schneiden.
|
||||
|
||||
Beschreibung:
|
||||
- Definiert Statuswerte, Routing, Sichtbarkeit, Verantwortlichkeiten und
|
||||
Eskalation fuer Support Requests.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Statusmodell ist dokumentiert.
|
||||
- Benutzer-, Support- und Admin-Sichtbarkeit ist beschrieben.
|
||||
- Routing zu Tenant-Verantwortlichen und Plattform-Administration ist klar.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-2.1
|
||||
|
||||
### P0-4.1 Regeln Fuer Storno, Loeschung Und Audit
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Korrekturen an Buchungen fachlich und revisionssicher festlegen.
|
||||
|
||||
Beschreibung:
|
||||
- Legt fest, dass Einzahlungen stornierbar und Stricheintraege loeschbar sind,
|
||||
jeweils nur durch Verantwortliche, inklusive Auditspur und Begruendung.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Storno-Regel fuer Einzahlungen ist dokumentiert.
|
||||
- Loeschregel fuer Stricheintraege ist dokumentiert.
|
||||
- Audit- und Historienanforderungen sind beschrieben.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-2.1
|
||||
|
||||
### P0-4.2 Schutzmechanismen Fuer Kritische Aktionen
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Risikoarme Ausfuehrung kritischer Sammelaktionen sicherstellen.
|
||||
|
||||
Beschreibung:
|
||||
- Beschreibt Vorschau, Testmodus und tenantweit deaktivierbare
|
||||
Vier-Augen-Freigabe fuer kritische Aktionen.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Kritische Aktionen sind benannt.
|
||||
- Vorschau/Testmodus-Regeln sind dokumentiert.
|
||||
- Vier-Augen-Freigabe ist als tenantweite Option beschrieben.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- keine
|
||||
|
||||
### P0-5.1 Survey-Freigabe Und Snapshot-Veroeffentlichung
|
||||
|
||||
Prioritaet:
|
||||
- mittel
|
||||
|
||||
Ziel:
|
||||
- Die Freigabe und Sichtbarkeit von Umfrageergebnissen verbindlich festlegen.
|
||||
|
||||
Beschreibung:
|
||||
- Beschreibt Rollen, Freigabeschritte und Snapshot-Veroeffentlichung fuer
|
||||
Survey-Ergebnisse.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Freigabe-Rollen sind benannt.
|
||||
- Snapshot-Mechanik fuer Benutzer ist beschrieben.
|
||||
- Ende und Veroeffentlichung einer Umfrage sind geregelt.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-2.1
|
||||
|
||||
### P0-5.2 Jahresauswertung Und Bonuslogik Spezifizieren
|
||||
|
||||
Prioritaet:
|
||||
- mittel
|
||||
|
||||
Ziel:
|
||||
- Den bedarfsorientierten Jahresauswertungsprozess fachlich festlegen.
|
||||
|
||||
Beschreibung:
|
||||
- Beschreibt Parameter wie Jahr, Bonusart, Betrag/Formel, Vorschau und
|
||||
Freigabeprozess.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Parameterliste ist dokumentiert.
|
||||
- Vorschau- und Freigabeschritt sind festgelegt.
|
||||
- Fixe und flexible Bonuslogik sind fachlich beschrieben.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-4.2
|
||||
|
||||
### P0-6.1 Zahlungsdaten, Pflichtfelder Und Profilfelder Festlegen
|
||||
|
||||
Prioritaet:
|
||||
- mittel
|
||||
|
||||
Ziel:
|
||||
- Konfigurations- und Stammdaten fuer Payment und Matching definieren.
|
||||
|
||||
Beschreibung:
|
||||
- Legt Pflichtfelder pro Zahlungsart und tenantweite Zusatzfelder wie
|
||||
`paypalname` fest.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Pflichtfelder je Zahlungsart sind dokumentiert.
|
||||
- Zusatzfelder sind tenantweit definiert.
|
||||
- Matching-relevante Felder sind gekennzeichnet.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-1.2
|
||||
|
||||
## PRD-Backlog Fuer Das MVP
|
||||
|
||||
### MVP-1.1 Lokale Anmeldung Implementieren
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Die lokale Systemanmeldung produktiv bereitstellen.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert Login, Fehlerbehandlung und Benutzerfuehrung fuer lokale
|
||||
Konten.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Benutzer koennen sich lokal anmelden.
|
||||
- Fehlerfaelle werden verstaendlich angezeigt.
|
||||
- Login ist tenantfaehig eingebunden.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-1.1
|
||||
|
||||
### MVP-1.2 ADFS/OIDC-Login Und E-Mail-Mapping
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Externen Login entsprechend dem Zielbild produktiv aktivieren.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert ADFS/OIDC, E-Mail-Mapping und Admin-Klaerfall bei Konflikten.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Login via ADFS/OIDC funktioniert.
|
||||
- E-Mail-Mapping wird korrekt angewendet.
|
||||
- Konfliktfaelle werden in einen Admin-Klaerprozess geleitet.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-1.2
|
||||
- MVP-1.1
|
||||
|
||||
### MVP-2.1 Rollenmodell Und Rechtepruefung Umsetzen
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Das fachlich definierte Rollenmodell im System verankern.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert Rollen, Modulrechte und Tenant-Grenzen.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Alle definierten Rollen sind im System vorhanden.
|
||||
- Rechtepruefung greift pro Modul.
|
||||
- Tenant-Admin hat Vollzugriff im eigenen Tenant.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-2.1
|
||||
|
||||
### MVP-3.1 Hinweise Und FAQ Verwalten
|
||||
|
||||
Prioritaet:
|
||||
- mittel
|
||||
|
||||
Ziel:
|
||||
- Ein erstes produktiv nutzbares Content-Modul bereitstellen.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert CRUD fuer Hinweise und FAQ inklusive Tenant-Override.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Hinweise koennen angelegt, bearbeitet und deaktiviert werden.
|
||||
- FAQ koennen gepflegt werden.
|
||||
- Standardvorlagen koennen tenantseitig ueberschrieben werden.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- MVP-2.1
|
||||
|
||||
### MVP-4.1 Zahlungsarten Und Zahlungsdaten Pro Tenant
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Tenant-spezifische Zahlungsarten produktiv verwaltbar machen.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert Bar, Ueberweisung und PayPal als konfigurierbare Zahlungsarten
|
||||
inklusive Pflichtfeldern und Hinweisen.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Zahlungsarten sind tenantweit konfigurierbar.
|
||||
- Pflichtfelder werden validiert.
|
||||
- Zahlungsinformationen werden im Frontend korrekt angezeigt.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-6.1
|
||||
- MVP-2.1
|
||||
|
||||
### MVP-4.2 Manuelle Einzahlungsbuchung Und Reconciliation-Vorbereitung
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Manuelle Zahlungsbuchung stabil umsetzen und spaetere Reconciliation
|
||||
vorbereiten.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert manuelle Buchung und bereitet Statusfelder fuer spaetere
|
||||
Reconciliation vor.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Einzahlungen koennen manuell gebucht werden.
|
||||
- Buchungsstatus fuer spaetere Erweiterung ist im Modell vorhanden.
|
||||
- Kein automatischer Mailbox-Import ist Teil des MVPs.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- MVP-4.1
|
||||
|
||||
### MVP-5.1 Einzahlungs-Storno Und Strich-Loeschung
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Korrekturen gemaess Fachregel umsetzen.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert Storno fuer Einzahlungen und Loeschung fuer Stricheintraege
|
||||
inklusive Auditspur.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Nur berechtigte Rollen duerfen korrigieren.
|
||||
- Einzahlungen werden als Storno gefuehrt.
|
||||
- Stricheintraege werden nachvollziehbar geloescht.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-4.1
|
||||
- MVP-2.1
|
||||
|
||||
### MVP-6.1 Supportvorgaenge Mit Status Und Routing
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Support direkt als vollstaendiges Vorgangssystem bereitstellen.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert Datenmodell, Statuswechsel, Routing und Ansichten fuer Benutzer
|
||||
und Verantwortliche.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Benutzer koennen Vorgaenge anlegen und verfolgen.
|
||||
- Verantwortliche koennen Vorgaenge bearbeiten.
|
||||
- Routing und Sichtbarkeit folgen dem Phase-0-Modell.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-3.1
|
||||
- MVP-2.1
|
||||
|
||||
### MVP-7.1 Survey-Verwaltung Und Snapshot-Publishing
|
||||
|
||||
Prioritaet:
|
||||
- mittel
|
||||
|
||||
Ziel:
|
||||
- Surveys fuer Tenant-Betrieb und Benutzerveroeffentlichung bereitstellen.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert Survey-Erstellung, Freigabe und Snapshot-Ausgabe fuer Benutzer.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Surveys koennen angelegt und freigegeben werden.
|
||||
- Benutzer sehen nur freigegebene Snapshots.
|
||||
- Tenant-Admins und Survey-Manager koennen Ergebnisse auswerten.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-5.1
|
||||
- MVP-2.1
|
||||
|
||||
### MVP-8.1 Vorschau, Testmodus Und Vier-Augen-Konfiguration
|
||||
|
||||
Prioritaet:
|
||||
- hoch
|
||||
|
||||
Ziel:
|
||||
- Kritische Aktionen sicher und tenantkonfigurierbar ausfuehren.
|
||||
|
||||
Beschreibung:
|
||||
- Implementiert Vorschau, Testmodus und die tenantweite Konfiguration der
|
||||
Vier-Augen-Freigabe.
|
||||
|
||||
Akzeptanzkriterien:
|
||||
- Kritische Aktionen bieten Vorschau oder Testmodus.
|
||||
- Vier-Augen-Freigabe ist pro Tenant aktivier- und deaktivierbar.
|
||||
- Kritische Aktionen werden sauber protokolliert.
|
||||
|
||||
Abhaengigkeiten:
|
||||
- P0-4.2
|
||||
- MVP-2.1
|
||||
|
||||
Reference in New Issue
Block a user