Files
tessera-ctl/.planning/REQUIREMENTS.md
T
schalli 775ed153b7
Tessera CI/CD / Lint & Type Check (push) Successful in 48s
Tessera CI/CD / Tests (push) Successful in 45s
Tessera CI/CD / Build & Publish Images (push) Successful in 3m43s
docs(13-04): complete NetServer adapter plan
2026-07-23 09:16:04 +02:00

7.1 KiB

Requirements — Milestone v1.1: Ausschreibungs-Radar

Module: Ausschreibungs-Radar — durchsucht deutsche Vergabeportale nach Ausschreibungen, filtert nach Kriterien, zeigt Treffer im Portal an und versendet optional per E-Mail. Basis-Research: .planning/research/SUMMARY.md, .planning/research/ausschreibungs-portale-feasibility.md Defined: 2026-07-17

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.

v1.1 Requirements

INGEST — Datenquellen

  • INGEST-01: Das System ruft Ausschreibungen zeitgesteuert über die DÖE OpenData-API (oeffentlichevergabe.de, eForms/OCDS, auth-frei) ab.
  • INGEST-02: Das System importiert Ausschreibungen von Administration-Intelligence-NetServer-Portalen (lhs-vpbw, tender24, vergabe.landbw) über einen konfigurierbaren Adapter.
  • INGEST-03: Das System importiert Ausschreibungen vom cosinex-Vergabemarktplatz (DTVP) über einen Adapter.
  • INGEST-04: Das System importiert Ausschreibungen aus RSS-Feeds (subreport-elvis, service.bund.de).
  • INGEST-05: Das System liest Portal-Benachrichtigungs-E-Mails aus einem konfigurierten Postfach ein (nutzt bestehende DKV-Inbox-Infrastruktur) und extrahiert daraus Ausschreibungen.
  • 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).

SCHEMA — Normalisierung & Deduplizierung

  • 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.
  • SCHEMA-02: Das System erkennt Änderungen an bereits importierten Ausschreibungen (Fristverlängerung, Aufhebung) über einen Content-Hash und aktualisiert den Datensatz.
  • 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.

FILTER — Suche & Profile

  • FILTER-01: Nutzer kann per Volltext-Stichwort (Titel/Beschreibung) suchen.
  • FILTER-02: Nutzer kann nach Region / PLZ / Bundesland filtern.
  • FILTER-03: Nutzer kann nach CPV-Code / Branche filtern (hierarchische Auswahl mit Autocomplete).
  • FILTER-04: Nutzer kann nach Abgabefrist filtern, inkl. Option „nur noch offene".
  • 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.

UI — Anzeige & Triage

  • UI-01: Nutzer sieht eine durchsuchbare, sortierbare Trefferliste (Sortierung nach Frist, Wert, Veröffentlichungsdatum).
  • UI-02: Nutzer öffnet eine Detailansicht einer Ausschreibung mit Link zur Quelle und ggf. Dokument-URLs (keine lokale Spiegelung der Vergabeunterlagen).
  • UI-03: Nutzer kann Treffer als gelesen/ungelesen markieren (pro Nutzer).
  • 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.

NOTIFY — Benachrichtigung

  • NOTIFY-01: Nutzer erhält einen periodischen E-Mail-Digest passender Treffer; Intervall im Webinterface konfigurierbar.
  • NOTIFY-02: Nutzer erhält optional eine Sofort-E-Mail bei einem neuen Treffer eines aktiven Suchprofils; im Webinterface aktivierbar.
  • NOTIFY-03: Das System unterscheidet „getroffen" von „benachrichtigt" (kein Doppelversand Digest+Sofort; kein Rückstau-Massenversand beim Anlegen eines Suchprofils).
  • NOTIFY-04: Der E-Mail-Versand nutzt die mandantenspezifische SMTP-Konfiguration (bestehendes DKV-Mail-Muster).

CONFIG — Modul & Verwaltung

  • CONFIG-01: Das Modul ist im Marketplace registriert und pro Mandant aktivierbar (wie DKV-Fleet- und Cert-Manager-Modul).
  • CONFIG-02: Admin verwaltet Quellen-Poll-Konfiguration sowie das E-Mail-Ingestion-Postfach pro Mandant (Zugangsdaten verschlüsselt gespeichert).
  • CONFIG-03: Die gesamte Modul-UI ist mehrsprachig (Deutsch + Englisch, i18n).

Future Requirements (deferred)

  • TED API v3 (EU-weite Redundanz) — für DE-only weitgehend redundant zu DÖE.
  • Relevanz-/Ranking-Score innerhalb eines Suchprofils.
  • Dashboard-Widget „Ausschreibungen mit naher Frist" (nutzt Phase-8-Widget-Framework).
  • CSV/Excel-Export gefilterter Ergebnisse.
  • Team-/Kollaborationsfunktionen (Zuweisung, interne Notizen).

Out of Scope (explizit ausgeschlossen)

  • Direktes Scraping von vergabe24 & aumass — AGB-Verbot automatisierter Zugriffe; Oberschwellen-Daten kommen ohnehin über DÖE.
  • Generisches „beliebiges Portal scrapen"-Framework — zu fragil über inkompatible Portal-Familien, dauerhafter Wartungsaufwand.
  • 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.
  • KI-Zusammenfassungen / Bid-Fit-Scoring — verfrüht, eigener AI-SPEC-Phase vorbehalten.
  • Lokale Spiegelung/Hosting der Vergabeunterlagen — rechtlich unklar; nur Verlinkung zur Quelle.

Traceability

Requirement Phase Status
CONFIG-01 Phase 10 Complete
INGEST-01 Phase 10 Complete
INGEST-06 Phase 10 Complete
SCHEMA-01 Phase 10 Complete
SCHEMA-02 Phase 10 Complete
FILTER-01 Phase 11 Complete
FILTER-02 Phase 11 Complete
FILTER-03 Phase 11 Complete
FILTER-04 Phase 11 Complete
FILTER-05 Phase 11 Complete
FILTER-06 Phase 11 Complete
UI-01 Phase 11 Complete
UI-02 Phase 11 Complete
UI-03 Phase 11 Complete
UI-04 Phase 11 Complete
UI-05 Phase 11 Complete
NOTIFY-01 Phase 12 Complete
NOTIFY-02 Phase 12 Complete
NOTIFY-03 Phase 12 Complete
NOTIFY-04 Phase 12 Complete
INGEST-02 Phase 13 Complete
INGEST-03 Phase 13 Pending
INGEST-07 Phase 13 Complete
SCHEMA-03 Phase 13 Complete
INGEST-04 Phase 14 Pending
INGEST-05 Phase 14 Pending
CONFIG-02 Phase 14 Pending
CONFIG-03 Phase 14 Pending
UI-06 Phase 14 Pending

Coverage: 29/29 v1.1 requirements mapped — no orphans.