docs: define milestone v1.1 requirements
This commit is contained in:
+55
-163
@@ -1,185 +1,77 @@
|
|||||||
# Requirements: Tessera
|
# Requirements — Milestone v1.1: Ausschreibungs-Radar
|
||||||
|
|
||||||
**Defined:** 2026-06-18
|
**Module:** Ausschreibungs-Radar — durchsucht deutsche Vergabeportale nach Ausschreibungen, filtert nach Kriterien, zeigt Treffer im Portal an und versendet optional per E-Mail.
|
||||||
**Core Value:** Eine zentrale Plattform, in der beliebige Workflow-Tools als Module lizenziert, aktiviert und genutzt werden koennen — ohne zwischen verschiedenen Anwendungen wechseln zu muessen.
|
**Basis-Research:** `.planning/research/SUMMARY.md`, `.planning/research/ausschreibungs-portale-feasibility.md`
|
||||||
|
**Defined:** 2026-07-17
|
||||||
|
|
||||||
## v1 Requirements
|
> v1.0-Requirements sind ausgeliefert und in PROJECT.md (Validated) nachgehalten. Diese Datei enthält nur die v1.1-Requirements. REQ-IDs setzen neue, modul-lokale Kategorien.
|
||||||
|
|
||||||
Requirements for initial release. Each maps to roadmap phases.
|
## v1.1 Requirements
|
||||||
|
|
||||||
### Authentication & User Management
|
### INGEST — Datenquellen
|
||||||
|
|
||||||
- [ ] **AUTH-01**: Initialer Admin-Account wird beim Setup via Docker-ENV erstellt
|
- [ ] **INGEST-01**: Das System ruft Ausschreibungen zeitgesteuert über die DÖE OpenData-API (oeffentlichevergabe.de, eForms/OCDS, auth-frei) ab.
|
||||||
- [x] **AUTH-02**: Admin kann Benutzer manuell anlegen, bearbeiten und loeschen
|
- [ ] **INGEST-02**: Das System importiert Ausschreibungen von Administration-Intelligence-NetServer-Portalen (lhs-vpbw, tender24, vergabe.landbw) über einen konfigurierbaren Adapter.
|
||||||
- [x] **AUTH-03**: Benutzer kann sich anmelden und abmelden
|
- [ ] **INGEST-03**: Das System importiert Ausschreibungen vom cosinex-Vergabemarktplatz (DTVP) über einen Adapter.
|
||||||
- [x] **AUTH-04**: Benutzer-Session bleibt ueber Browser-Refresh bestehen
|
- [ ] **INGEST-04**: Das System importiert Ausschreibungen aus RSS-Feeds (subreport-elvis, service.bund.de).
|
||||||
- [ ] **AUTH-05**: Rollenbasierte Zugriffskontrolle (Admin, User)
|
- [ ] **INGEST-05**: Das System liest Portal-Benachrichtigungs-E-Mails aus einem konfigurierten Postfach ein (nutzt bestehende DKV-Inbox-Infrastruktur) und extrahiert daraus Ausschreibungen.
|
||||||
- [ ] **AUTH-06**: Benutzer koennen per LDAP/AD importiert werden
|
- [ ] **INGEST-06**: Jede Quelle wird einmal zentral pro Zeitplan abgefragt (poll-once-fan-out-many), Intervall pro Quelle im Admin-Bereich konfigurierbar; das Ergebnis wird an alle passenden Mandanten-Suchprofile verteilt.
|
||||||
|
- [ ] **INGEST-07**: vergabe24 und aumass sind als harte Denylist hinterlegt und können nicht als automatische Scraping-Quelle registriert werden (AGB-Verbot).
|
||||||
|
|
||||||
### Multi-Tenancy
|
### SCHEMA — Normalisierung & Deduplizierung
|
||||||
|
|
||||||
- [ ] **TNNT-01**: Daten sind per PostgreSQL Row-Level Security mandantengetrennt
|
- [ ] **SCHEMA-01**: Alle Quellen werden in ein einheitliches, OCDS-orientiertes Ausschreibungs-Schema normalisiert (Titel, Auftraggeber, CPV-Codes, Region/PLZ, Frist, geschätzter Wert, Verfahrensart, Quell-URL, Rohdaten). Ausschreibungsdaten sind plattform-global, nicht mandantengebunden.
|
||||||
- [x] **TNNT-02**: Admin kann Mandanten anlegen und verwalten
|
- [ ] **SCHEMA-02**: Das System erkennt Änderungen an bereits importierten Ausschreibungen (Fristverlängerung, Aufhebung) über einen Content-Hash und aktualisiert den Datensatz.
|
||||||
- [ ] **TNNT-03**: Jeder Request wird automatisch dem richtigen Mandanten zugeordnet
|
- [ ] **SCHEMA-03**: Dieselbe Ausschreibung aus mehreren Quellen wird zu einem Eintrag mit mehreren Quell-Links dedupliziert (Schlüssel: OCID → Quelle:NoticeId → Fuzzy-Fingerprint aus Auftraggeber+Titel+CPV+Frist+Wert). Dedup greift erst ab der zweiten aktiven Quelle.
|
||||||
|
|
||||||
### Portal Shell
|
### FILTER — Suche & Profile
|
||||||
|
|
||||||
- [x] **PRTAL-01**: Schmale Kopfzeile mit Branding und Benutzer-Menu
|
- [ ] **FILTER-01**: Nutzer kann per Volltext-Stichwort (Titel/Beschreibung) suchen.
|
||||||
- [ ] **PRTAL-02**: Linke Seitenleiste zeigt Kategorien und aktivierte Module
|
- [ ] **FILTER-02**: Nutzer kann nach Region / PLZ / Bundesland filtern.
|
||||||
- [ ] **PRTAL-03**: Ausgewaehltes Modul oeffnet sich im Hauptbereich (Mitte)
|
- [ ] **FILTER-03**: Nutzer kann nach CPV-Code / Branche filtern (hierarchische Auswahl mit Autocomplete).
|
||||||
- [x] **PRTAL-04**: Responsive Layout fuer verschiedene Bildschirmgroessen
|
- [ ] **FILTER-04**: Nutzer kann nach Abgabefrist filtern, inkl. Option „nur noch offene".
|
||||||
- [ ] **PRTAL-05**: Module koennen in der Seitenleiste durchsucht und gefiltert werden
|
- [ ] **FILTER-05**: Nutzer kann nach geschätztem Auftragswert (min/max) filtern; Ausschreibungen ohne Wertangabe werden korrekt behandelt.
|
||||||
|
- [ ] **FILTER-06**: Nutzer kann Suchprofile (Kombination aus Filterkriterien) speichern, bearbeiten und löschen — pro Nutzer, mandantenbewusst.
|
||||||
|
|
||||||
### Marketplace
|
### UI — Anzeige & Triage
|
||||||
|
|
||||||
- [ ] **MRKT-01**: Uebersicht aller verfuegbaren Module mit Beschreibung und Kategorie
|
- [ ] **UI-01**: Nutzer sieht eine durchsuchbare, sortierbare Trefferliste (Sortierung nach Frist, Wert, Veröffentlichungsdatum).
|
||||||
- [ ] **MRKT-02**: Admin kann Module pro Mandant aktivieren und deaktivieren
|
- [ ] **UI-02**: Nutzer öffnet eine Detailansicht einer Ausschreibung mit Link zur Quelle und ggf. Dokument-URLs (keine lokale Spiegelung der Vergabeunterlagen).
|
||||||
- [ ] **MRKT-03**: Nur aktivierte Module erscheinen in der Seitenleiste des Mandanten
|
- [ ] **UI-03**: Nutzer kann Treffer als gelesen/ungelesen markieren (pro Nutzer).
|
||||||
- [ ] **MRKT-04**: Module sind in Kategorien gruppiert
|
- [ ] **UI-04**: Nutzer kann Treffer als Favorit/Merkliste markieren und eine Merklisten-Ansicht filtern (pro Nutzer).
|
||||||
|
- [ ] **UI-05**: Die UI weist die Abdeckung transparent aus (Oberschwelle vs. Unterschwelle), damit „keine Treffer" nicht als Fehler missverstanden wird.
|
||||||
|
- [ ] **UI-06**: Ausgeschlossene Portale (vergabe24, aumass) werden als „manuell zu überwachen" mit Direktlink angezeigt.
|
||||||
|
|
||||||
### Dashboard
|
### NOTIFY — Benachrichtigung
|
||||||
|
|
||||||
- [x] **DASH-01**: Konfigurierbares Dashboard als Startseite mit Drag & Drop Grid
|
- [ ] **NOTIFY-01**: Nutzer erhält einen periodischen E-Mail-Digest passender Treffer; Intervall im Webinterface konfigurierbar.
|
||||||
- [x] **DASH-02**: Widgets koennen frei positioniert und in der Groesse geaendert werden
|
- [ ] **NOTIFY-02**: Nutzer erhält optional eine Sofort-E-Mail bei einem neuen Treffer eines aktiven Suchprofils; im Webinterface aktivierbar.
|
||||||
- [x] **DASH-03**: Uhr-Widget (analog oder digital)
|
- [ ] **NOTIFY-03**: Das System unterscheidet „getroffen" von „benachrichtigt" (kein Doppelversand Digest+Sofort; kein Rückstau-Massenversand beim Anlegen eines Suchprofils).
|
||||||
- [x] **DASH-04**: Suchleiste-Widget (oeffnet Google/Suchmaschine im Browser)
|
- [ ] **NOTIFY-04**: Der E-Mail-Versand nutzt die mandantenspezifische SMTP-Konfiguration (bestehendes DKV-Mail-Muster).
|
||||||
- [x] **DASH-05**: Kalender-Widget mit Terminvorschau
|
|
||||||
- [x] **DASH-06**: Notiz-Widget (Freitext-Kachel)
|
|
||||||
- [x] **DASH-07**: Dashboard-Layout wird pro Benutzer gespeichert
|
|
||||||
- [ ] **DASH-08**: Taschenrechner-Widget (Grundrechenarten, Tastatureingabe)
|
|
||||||
- [ ] **DASH-09**: Favoriten-Widget mit Backend-Persistenz (Links mit Titel, URL, Icon)
|
|
||||||
- [ ] **DASH-10**: Stoppuhr-Widget (Start/Stop/Reset, Rundenzeiten)
|
|
||||||
- [ ] **DASH-11**: Alle Widgets haben einheitliche Grid-Constraints (gleiche minW/minH/defaultW/defaultH)
|
|
||||||
|
|
||||||
### Kalender-Integration
|
### CONFIG — Modul & Verwaltung
|
||||||
|
|
||||||
- [ ] **CAL-01**: In Einstellungen koennen mehrere Kalenderquellen eingebunden werden (WebDAV, Exchange, ICS-Link)
|
- [ ] **CONFIG-01**: Das Modul ist im Marketplace registriert und pro Mandant aktivierbar (wie DKV-Fleet- und Cert-Manager-Modul).
|
||||||
- [x] **CAL-02**: Benutzer kann waehlen welche Kalender im Widget angezeigt werden
|
- [ ] **CONFIG-02**: Admin verwaltet Quellen-Poll-Konfiguration sowie das E-Mail-Ingestion-Postfach pro Mandant (Zugangsdaten verschlüsselt gespeichert).
|
||||||
- [x] **CAL-03**: Benutzer kann waehlen fuer welche Kalender Terminvorschauen angezeigt werden
|
- [ ] **CONFIG-03**: Die gesamte Modul-UI ist mehrsprachig (Deutsch + Englisch, i18n).
|
||||||
|
|
||||||
### Module System
|
## Future Requirements (deferred)
|
||||||
|
|
||||||
- [ ] **MOD-01**: Versioniertes Modul-SDK mit standardisiertem Interface (@tessera/sdk)
|
- [ ] TED API v3 (EU-weite Redundanz) — für DE-only weitgehend redundant zu DÖE.
|
||||||
- [ ] **MOD-02**: Module werden per Datenbank-Registry verwaltet
|
- [ ] Relevanz-/Ranking-Score innerhalb eines Suchprofils.
|
||||||
- [ ] **MOD-03**: Module koennen ohne Neustart aktiviert/deaktiviert werden
|
- [ ] Dashboard-Widget „Ausschreibungen mit naher Frist" (nutzt Phase-8-Widget-Framework).
|
||||||
- [ ] **MOD-04**: Modul-UIs werden per Lazy Loading geladen (kein Bundle-Bloat)
|
- [ ] CSV/Excel-Export gefilterter Ergebnisse.
|
||||||
|
- [ ] Team-/Kollaborationsfunktionen (Zuweisung, interne Notizen).
|
||||||
|
|
||||||
### Domaincheck (Erstes Modul)
|
## Out of Scope (explizit ausgeschlossen)
|
||||||
|
|
||||||
- [ ] **DCHK-01**: Benutzer kann eine Domain in ein Eingabefeld eingeben
|
- Direktes Scraping von vergabe24 & aumass — AGB-Verbot automatisierter Zugriffe; Oberschwellen-Daten kommen ohnehin über DÖE.
|
||||||
- [ ] **DCHK-02**: System prueft ob die Domain registriert oder frei ist
|
- Generisches „beliebiges Portal scrapen"-Framework — zu fragil über inkompatible Portal-Familien, dauerhafter Wartungsaufwand.
|
||||||
- [ ] **DCHK-03**: Ergebnis wird klar angezeigt (frei/registriert)
|
- Sub-stündliches Polling — Ausschreibungs-Lebenszyklen laufen über Tage/Wochen; erhöht nur Last/ToS-Risiko.
|
||||||
|
- Vollständiges Bid-Management/CRM (Angebotserstellung, Einreichung, Win/Loss) — anderes Produktsegment.
|
||||||
### UI & Internationalisierung
|
- KI-Zusammenfassungen / Bid-Fit-Scoring — verfrüht, eigener AI-SPEC-Phase vorbehalten.
|
||||||
|
- Lokale Spiegelung/Hosting der Vergabeunterlagen — rechtlich unklar; nur Verlinkung zur Quelle.
|
||||||
- [x] **UI-01**: Light/Dark Theme umschaltbar pro Benutzer
|
|
||||||
- [x] **UI-02**: Zweisprachig: Deutsch und Englisch mit Sprachwahl
|
|
||||||
- [x] **UI-03**: i18n-Framework von Anfang an integriert (alle Strings ueber t('key'))
|
|
||||||
|
|
||||||
### Infrastruktur
|
|
||||||
|
|
||||||
- [x] **INFRA-01**: Komplette Anwendung laeuft als Docker-Compose-Stack
|
|
||||||
- [x] **INFRA-02**: PostgreSQL-Datenbank im Container
|
|
||||||
- [x] **INFRA-03**: Docker-Netzwerksegmentierung (Frontend/Backend/Data)
|
|
||||||
- [x] **INFRA-04**: Automatisierte Gitea-Integration (Commits, Pushes, Merges)
|
|
||||||
|
|
||||||
### Desktop-Client
|
|
||||||
|
|
||||||
- [x] **DESK-01**: Tauri-basierter Desktop-Wrapper fuer Windows und Linux
|
|
||||||
- [x] **DESK-02**: Desktop-App verbindet sich mit dem Web-Backend (kein eigenstaendiger Server)
|
|
||||||
|
|
||||||
## v2 Requirements
|
|
||||||
|
|
||||||
Deferred to future release. Tracked but not in current roadmap.
|
|
||||||
|
|
||||||
### Authentication Erweiterungen
|
|
||||||
|
|
||||||
- **AUTH-V2-01**: SSO/OIDC-Anbindung
|
|
||||||
- **AUTH-V2-02**: Zwei-Faktor-Authentifizierung (2FA)
|
|
||||||
- **AUTH-V2-03**: Magic-Link Login
|
|
||||||
|
|
||||||
### Marketplace Erweiterungen
|
|
||||||
|
|
||||||
- **MRKT-V2-01**: Bezahlsystem fuer Module (Lizenzschluessel oder Abo)
|
|
||||||
- **MRKT-V2-02**: Drittanbieter koennen Module einreichen
|
|
||||||
- **MRKT-V2-03**: Bewertungen und Reviews fuer Module
|
|
||||||
|
|
||||||
### Erweiterte Features
|
|
||||||
|
|
||||||
- **FEAT-V2-01**: Notification Center (In-App-Benachrichtigungen)
|
|
||||||
- **FEAT-V2-02**: Per-Tenant Branding (Logo + Akzentfarbe)
|
|
||||||
- **FEAT-V2-03**: Keyboard Shortcuts und Command Palette
|
|
||||||
- **FEAT-V2-04**: Admin-Impersonation (als anderer Benutzer agieren)
|
|
||||||
- **FEAT-V2-05**: Onboarding-Wizard fuer neue Mandanten
|
|
||||||
|
|
||||||
## Out of Scope
|
|
||||||
|
|
||||||
| Feature | Reason |
|
|
||||||
|---------|--------|
|
|
||||||
| Mobile App | Web-first, Desktop-Wrapper reicht fuer v1 |
|
|
||||||
| Real-time Chat | Hohe Komplexitaet, nicht Kern der Plattform |
|
|
||||||
| Video/Streaming | Storage/Bandwidth, nicht relevant fuer Workflow-Tools |
|
|
||||||
| Payment/Billing | Lizenzierung erstmal per Admin-Freischaltung |
|
|
||||||
| Third-Party Module SDK | Erst eigene Module, oeffnung spaeter |
|
|
||||||
| Microservice-Architektur | Modular Monolith reicht, Extraction spaeter moeglich |
|
|
||||||
|
|
||||||
## Traceability
|
## Traceability
|
||||||
|
|
||||||
Which phases cover which requirements. Updated during roadmap creation.
|
_(Wird vom Roadmapper befüllt: REQ-ID → Phase.)_
|
||||||
|
|
||||||
| Requirement | Phase | Status |
|
|
||||||
|-------------|-------|--------|
|
|
||||||
| AUTH-01 | Phase 2 | Pending |
|
|
||||||
| AUTH-02 | Phase 2 | Complete |
|
|
||||||
| AUTH-03 | Phase 2 | Complete |
|
|
||||||
| AUTH-04 | Phase 2 | Complete |
|
|
||||||
| AUTH-05 | Phase 2 | Pending |
|
|
||||||
| AUTH-06 | Phase 2 | Pending |
|
|
||||||
| TNNT-01 | Phase 2 | Pending |
|
|
||||||
| TNNT-02 | Phase 2 | Complete |
|
|
||||||
| TNNT-03 | Phase 2 | Pending |
|
|
||||||
| PRTAL-01 | Phase 1 | Complete |
|
|
||||||
| PRTAL-02 | Phase 4 | Pending |
|
|
||||||
| PRTAL-03 | Phase 4 | Pending |
|
|
||||||
| PRTAL-04 | Phase 1 | Complete |
|
|
||||||
| PRTAL-05 | Phase 4 | Pending |
|
|
||||||
| MRKT-01 | Phase 4 | Pending |
|
|
||||||
| MRKT-02 | Phase 4 | Pending |
|
|
||||||
| MRKT-03 | Phase 4 | Pending |
|
|
||||||
| MRKT-04 | Phase 4 | Pending |
|
|
||||||
| DASH-01 | Phase 5 | Complete |
|
|
||||||
| DASH-02 | Phase 5 | Complete |
|
|
||||||
| DASH-03 | Phase 5 | Complete |
|
|
||||||
| DASH-04 | Phase 5 | Complete |
|
|
||||||
| DASH-05 | Phase 5 | Backend Complete (05-03) |
|
|
||||||
| DASH-06 | Phase 5 | Complete |
|
|
||||||
| DASH-07 | Phase 5 | Complete |
|
|
||||||
| CAL-01 | Phase 5 | Backend Complete (05-03) |
|
|
||||||
| CAL-02 | Phase 5 | Backend Complete (05-03) |
|
|
||||||
| CAL-03 | Phase 5 | Backend Complete (05-03) |
|
|
||||||
| MOD-01 | Phase 3 | Pending |
|
|
||||||
| MOD-02 | Phase 3 | Pending |
|
|
||||||
| MOD-03 | Phase 3 | Pending |
|
|
||||||
| MOD-04 | Phase 3 | Pending |
|
|
||||||
| DCHK-01 | Phase 3 | Pending |
|
|
||||||
| DCHK-02 | Phase 3 | Pending |
|
|
||||||
| DCHK-03 | Phase 3 | Pending |
|
|
||||||
| UI-01 | Phase 1 | Complete |
|
|
||||||
| UI-02 | Phase 1 | Complete |
|
|
||||||
| UI-03 | Phase 1 | Complete |
|
|
||||||
| INFRA-01 | Phase 1 | Complete |
|
|
||||||
| INFRA-02 | Phase 1 | Complete |
|
|
||||||
| INFRA-03 | Phase 1 | Complete |
|
|
||||||
| INFRA-04 | Phase 6 | Complete |
|
|
||||||
| DESK-01 | Phase 6 | Complete |
|
|
||||||
| DESK-02 | Phase 6 | Complete |
|
|
||||||
|
|
||||||
**Coverage:**
|
|
||||||
|
|
||||||
- v1 requirements: 44 total
|
|
||||||
- Mapped to phases: 44
|
|
||||||
- Unmapped: 0
|
|
||||||
|
|
||||||
---
|
|
||||||
*Requirements defined: 2026-06-18*
|
|
||||||
*Last updated: 2026-06-18 after roadmap creation*
|
|
||||||
|
|||||||
Reference in New Issue
Block a user