Lastenheft
Verbindliche Anforderungen an Linetra. IDs sind stabil und tauchen in der Roadmap wieder auf.
Stand: 2026-08-26 · Quelle: private/requirements/ANFORDERUNGEN.md · Status: nicht umgesetzt
Prioritäten
Muss steht in den Anforderungen. Soll ist nötig, damit ein Muss erfüllbar bleibt (ohne HOW vorzuschreiben). Kann ist ausdrücklich optional („evtl.“).
1. Ausgangslage
Heute ist PostGIS die SSOT (SRID 25832). Erfassung läuft in QGIS; das Web-CMS (Next.js + FastAPI) deckt Stammdaten, Berichte/PDF und eine nur lesende Karte ab.
Das reicht nicht für den operativen GIS-Workflow: Rohdaten des Auftraggebers, Normierung, abschnittsweise Aufträge mit eigenen Produkt-Geometrien, Versionierung nach Rücksprachen, kunden- und gemeindespezifische Berichte und eine Kundenoberfläche mit Kommentar, Chat und Tickets.
2. Ziele
- QGIS + Linetra-Plugin als Capture-UI: Schema anwenden, Import-Mapper, Projekt-/Layer-Hierarchie; Digitize im QGIS-Canvas (ADR-0030, ADR-0033). Das Plugin schreibt kein Schema.
- Linetra Web für Schema-CMS, Stammdaten (Zentrale + Kopien), Analyse, Verfahren (Planer und Behörden), Audit, Kunden-Anzeige — nicht für GIS-Erfassung.
- Feld-App für Bauleiter an genehmigten Abschnitten (später AR).
- Vertikale (Glasfaser, Verkehrszeichen, Tunnel, …) als Kind-Packs am gemeinsamen GIS-Stamm.
- Alles (Rohinput, Normierung, Produkte) versionierbar.
- Austausch mit GIS-Werkzeugen: QGIS-Export (und optional
.ltp). - PostGIS nicht im Internet; QGIS über Auth-Proxy mit Client-Zertifikaten, Apps nur über die API (ohne VPN-Zwang).
- Eine Datenbank pro Organisation (Ziel); Planer einer Org teilen die DB ohne Tabellenisolation.
3. Nicht-Ziele
Aus den Anforderungen nicht gefordert — deshalb kein Lieferumfang dieses Lastenhefts:
- Billing-Automatisierung, Rechnungsprogramm, Factura Directa
- Rechnungen werden abgelegt, nicht gebucht (Dokumente, §6.3)
- Keine Zwei-Wege-Synchronisation mit Cloud-Speichern (Linetra führt, Spiegel nur einseitig)
- Jira als Steuerzentrale (bestehender Betrieb, siehe Fachmodell)
- QGIS-Capture ohne Export-Pfad (Export bleibt Muss)
- Drittes Web-Framework neben Next.js (die Feld-App ist ein dritter Client, nicht eine zweite Webapp)
- Zweite Desktop-App neben QGIS für denselben Capture-Workflow (Tauri-Editor ist Legacy, nicht Primärpfad)
- Implementierungsdetails (Tabellennamen, Framework-APIs, Hosting)
4. Infrastruktur
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| INF-01 | Muss | Die Anwendung ist in Clients geteilt: QGIS + Linetra-Plugin, Linetra Web als Webapp, später Feld-App (Tauri-Editor Legacy). | Getrennte Oberflächen; gemeinsame SSOT. |
| INF-02 | Muss | Capture läuft als QGIS-Plugin (linetra-plugin/); Stack PyQGIS. Schema wird in Linetra Web geschrieben, das Plugin wendet es an. |
Plugin in QGIS installierbar; keine Kind-Anlage im Plugin; keine zweite Desktop-App für denselben Workflow. |
| INF-03 | Muss | Linetra Web ist Next.js mit FastAPI. | Browser-App spricht die FastAPI; kein GIS-Schreiben in der Webapp. Schema, Analyse und Stamm liegen dort. |
| INF-04 | Muss | PostGIS ist von außen nicht erreichbar. Editor und Web nutzen nur die API; GIS-Clients (QGIS) erreichen die DB ausschließlich über einen Auth-Proxy. VPN ist nicht Voraussetzung. | Kein öffentlicher Postgres-Port; ohne Proxy bzw. ohne API keine Session zur SSOT. |
| INF-05 | Muss | Zugang über den Proxy nur mit persönlichem oder gerätegebundenem Schlüssel: mTLS, X.509-Client-Zertifikat (widerrufbar). Kein geteiltes DB-Passwort über das Internet. | Client ohne gültiges Zertifikat wird abgewiesen; Entzug eines Zertifikats sperrt genau diesen Client. |
| INF-06 | Muss | Der Proxy prüft die Identität und leitet die Postgres-Verbindung intern an PostGIS weiter (Wire-Protocol, nicht HTTP). | QGIS verbindet gegen den Proxy mit TLS verify-full; PostGIS akzeptiert diese Clients nur aus dem internen Netz. |
| INF-07 | Soll | Die Feld-App (Android, Capacitor) spricht nur die FastAPI; kein zweites Backend. | Bauleiter sehen genehmigte Abschnitte ohne GIS-Write. |
Bestehender Web-Stack
FastAPI + Next.js existieren bereits. Das Lastenheft verlangt daraus Linetra Web (Schema-SSOT, Stamm, Analyse, Kunden und Behörden-Verfahren) — nicht eine zweite Webapp.
DB-Zugang ohne VPN
Live: Datenbankzugang. Client-Zertifikate statt API-Keys, weil QGIS das Postgres-Protokoll spricht.
5. Linetra Editor
5.1 Pipeline: Rohinput → Normierung → Auftrag/Produkt
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| ED-01 | Muss | Es gibt einen Rohinput des Auftraggebers (project_client), Typ Trasse, mit der kompletten Trasse. |
Pro Projekt ist die ungefilterte AG-Trasse als eigener Bestand abgelegt, getrennt von der Normierung. |
| ED-02 | Muss | Der Rohinput kommt als Dateien; Formate sind unterschiedlich (u. a. Shapefiles, PDFs). | Mindestens Datei-Import; unbekannte Formate als Datei speicherbar, nicht verworfen. |
| ED-03 | Soll | Inhalte, die nicht maschinell lesbar sind, lassen sich manuell in die Stufe Planung übertragen (heute QGIS / später Editor). | Planung kann ohne vollständigen Parser entstehen. |
| ED-04 | Muss | Rohinput wird in eine normierte Form überführt: überflüssige Daten entfallen, andere werden umformatiert. Ablauf: Skripte und manuelle Schritte. | Normierte Trasse ist vom Rohinput unterscheidbar; beide bleiben erhalten. |
| ED-05 | Muss | Ein Auftrag bearbeitet nur einen Abschnitt der normierten Trasse und erzeugt dabei Produkte. | Auftrag ist an einen Abschnitt gebunden, nicht zwingend an die ganze Trasse. |
| ED-06 | Muss | Beispielprodukte: Querungen (Genehmigungsart), Verkehrszeichen aufstellen, Verlängerungen der Genehmigung. | Jedes genannte Produkt ist als eigener Produkttyp anlegbar. |
| ED-07 | Muss | Produkte haben eigene Geometrie (nicht die Planungs-/Normierungslinie). | Produkt-Geometrie unabhängig speicher- und editierbar. |
| ED-08 | Muss | Produkte mit gemeinsamem Hauptprodukt und geteilten Feldern sind eigene Entities — mindestens TKG und VAO — und haben eigene Tabellen. | TKG und VAO sind getrennt modelliert, nicht nur ein Typ-Flag ohne Fachdaten. |
5.2 Versionierung
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| ED-09 | Muss | Rohinput, Normierung und Produkte sind versionierbar, wenn Rücksprachen zu Korrekturen führen. | Nach einer Korrektur bleibt die vorige Fassung nachvollziehbar; aktuelle Fassung ist eindeutig. |
5.3 Berichte
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| ED-10 | Muss | Ein Produkt lässt sich als Bericht darstellen, der die für Gemeinde und Kunden wichtigen Daten enthält. | Bericht aus Produktdaten erzeugbar. |
| ED-11 | Muss | Berichtsinhalte unterscheiden sich nach Gemeinde und Kunde; die Felder sind pro Kunde als Set zusammenstellbar. | Zwei Kunden können verschiedene Feld-Sets für denselben Produkttyp haben. |
| ED-12 | Kann | Berichtsfelder können aus einem Formular stammen und per API oder Scraper geholt werden. | Kein Blocker für ED-10/ED-11. |
5.4 Karteneditor
Eine Seite des Editors enthält den Karteneditor. Layer werden dort angelegt.
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| ED-13 | Muss | Drei umschaltbare Modi: Planung, Normierung, Produkt. | Genau ein aktiver Modus; Layer und Werkzeuge gehören zum Modus. |
| ED-14 | Muss | Pro Modus lassen sich Punkte, Linien und Flächen anlegen. | Alle drei Geometrietypen in jedem Modus erzeugbar. |
| ED-15 | Muss | Werkzeugkasten: Auswahl Punkt, Linie oder Fläche. | Aktives Zeichenwerkzeug ist sichtbar und umschaltbar. |
| ED-16 | Muss | Rechte Seite: Kontextfenster mit Tab Koordinaten und Tab Attribute. | Beide Tabs vorhanden; Koordinaten der aktuellen Geometrie, Attribute editierbar. |
| ED-17 | Muss | Pro Projekt und Geometrietyp lässt sich ein Klick-Popup aktivieren und konfigurieren, das gewählte Attributinformationen zeigt. | Popup an/aus und Attributauswahl speicherbar. |
| ED-18 | Muss | Import und Export des Projekts (alle Layer und Daten) im Format .ltp (Linetra Projekt Package). |
Roundtrip: Export → Import stellt Layer und Daten des Projekts wieder her. |
| ED-19 | Muss | .ltp-Dateiformat: ZIP-Container, Magic-Header z. B. LINETRA-PP\0, MIME-Type application/vnd.linetra.project+zip. |
Datei ist als .ltp erkennbar (Header + MIME); Inhalt ist ZIP. |
| ED-20 | Muss | Import externer GIS-Geolayer in den jeweils aktiven Modus. | Import landet in Planung, Normierung oder Produkt — nicht vermischt. |
flowchart TB
subgraph editor [Linetra Editor]
mode[Modus: Planung / Normierung / Produkt]
map[Karte + Layer]
tools[Werkzeugkasten: Punkt / Linie / Fläche]
ctx[Kontext: Koordinaten | Attribute]
popup[konfigurierbares Klick-Popup]
end
mode --> map
tools --> map
map --> ctx
map --> popup
6. Linetra Web
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| DASH-01 | Muss | Linetra Web schreibt keine GIS-Geometrie. Kunden: Anzeige und Analyse. Behörden: Verfahren (Status, Auflagen), nicht GIS-Edit. Schema-CMS und Stammdaten-Kopien liegen in der Webapp. | Keine GIS-Erfassung, keine Normierung, kein Rohinput-Editing im Browser. |
| DASH-02 | Muss | Kommentarfunktion an Produkten. | Kommentar ist einem Produkt zugeordnet und für den Kunden sichtbar. |
| DASH-03 | Muss | Chat. | Kunden können im Dashboard chatten (Kanal intern vs. Kunde: offen, siehe Klärung). |
| DASH-04 | Muss | Ticketsystem. | Kunde kann ein Ticket anlegen und den Status nachverfolgen. |
| DASH-05 | Muss | Genehmigungsantrag je Abschnitt mit Statuskette Entwurf → Eingereicht → Prüfung → genehmigt (mit/ohne Auflagen) / abgelehnt / Rückfrage. | Statuswechsel nur über die API; Audit-Event je Wechsel. |
| DASH-06 | Muss | Behörden-Nutzer sehen nur Anträge, deren Abschnittsgeometrie ihr Gebiet schneidet. | Räumlicher Filter; kein Zugriff auf fremde Gemeinden. |
| DASH-07 | Muss | Auflagen (Katalogtyp + Freitext) und Frist am Antrag. | Auflage ist dem Antrag zugeordnet; optional einem Produkt. |
| DASH-08 | Muss | Audit-Export der Verfahrensereignisse je Abschnitt oder Projekt. | Export nachvollziehbar (wer, wann, von→nach). |
6.2 Prozessmanagement (Betrieb)
Feldmitarbeiter ohne Web-Konto melden per WhatsApp; Jira bleibt Aufgaben-SSOT; Backoffice gibt KI-Entwürfe frei (ADR-0059–0062).
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| PM-01 | Muss | Issue-Tracker-Mirror (Jira): Aufgaben eines gemappten Projekts werden gelesen und in Linetra angezeigt. | Issues erscheinen unter Betrieb → Aufgaben; Webhook und Poll halten den Mirror aktuell. |
| PM-02 | Muss | WhatsApp 1:1 für Projektmitglieder mit Rolle Feld: Identität = Absendernummer, Opt-in Pflicht, kein Gruppen-Bot. | Unbekannte Nummern werden abgelehnt; ohne Opt-in kein Briefing. |
| PM-03 | Muss | Tages-Briefing je Projekt an die Mitglieder mit Rolle Feld, mit offenen zugewiesenen Aufgaben; das Briefing nennt das Projekt. | Briefing-Versand außerhalb des 24h-Fensters nur per Utility-Template. |
| PM-04 | Muss | Inbox je Projekt: Chatverlauf, Medien, manuelle Issue-Zuordnung. | Backoffice sieht und beantwortet Nachrichten im Web. |
| PM-05 | Muss | KI-Entwurf ordnet Rückmeldungen Issues zu; schreibt nicht ungeprüft. | Entwurf in Freigabe-Queue; Agent-Log nachvollziehbar. |
| PM-06 | Muss | Backoffice-Freigabe: genehmigen, anpassen, abweisen, zurückschicken. | Transition/Anhang erst nach Freigabe; Permission operations.review. |
| PM-07 | Soll | Nextcloud-Archiv und Tracker-Anhang nach Freigabe (Spiegel der Dokumentenablage: DMS-08). | Datei unter {kunde}/{projekt}/{issue}/…; Volume bleibt Primärablage. |
| PM-08 | Soll | Tagesbericht an Projekt-Manager mit Aggregation + KI-Einschätzung. | Zahlen aus der Aggregation; LLM nur Summary/Risiken. |
6.3 Dokumente (Dateiverwaltung)
Dokumenteneingang wie bei einer Buchhaltungs-Inbox, aber für Bauprojekte: Dokumente kommen an, ein Mensch ordnet zu und legt ab; abgelegt wird nach Projekt → Bauabschnitt → Kategorie. Linetra führt, Cloud-Speicher spiegeln später einseitig (ADR-0063, ADR-0065).
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| DMS-01 | Muss | Eingang aus allen Kanälen; nichts wird verworfen. | Upload im Web landet im Eingang (später WhatsApp, Cloud-Import); auch unbekannte Formate werden gespeichert. |
| DMS-02 | Muss | KI-Vorschlag plus menschliche Bestätigung; nie automatisch ablegen. | Ablage nur über „Bestätigen & ablegen“ durch eine Person; Vorschlag ist änderbar. |
| DMS-03 | Muss | Ablage Projekt → Bauabschnitt → Kategorie mit festem Ordnerschema. | Jedes abgelegte Dokument hat einen berechneten Pfad nach dem Schema; Umablegen ändert Pfad, nicht Inhalt. |
| DMS-04 | Muss | Volltext und Filter (Typ, Kategorie, Projekt, Bauabschnitt, Datum, Gültigkeit, Beteiligte). | Suche findet Text und Aktenzeichen (z. B. 32-1234/2026); Filter lassen sich kombinieren. |
| DMS-05 | Muss | Unveränderliche Versionen, Prüfsumme, Zeitstempel. | Neue Fassung überschreibt nichts; Prüfsumme und Verkettung sind in der Detailansicht prüfbar. |
| DMS-06 | Muss | Verknüpfungen mit Beteiligten, Verfahren, Aufträgen, Aufgaben und Geo-Objekten. | Verknüpfte Dokumente lassen sich vom jeweiligen Objekt aus filtern; Rolle der Beteiligten ist erfasst. |
| DMS-07 | Muss | Rechte je Projekt; Eingang nur mit Berechtigung; vertrauliche Typen geschützt. | Ohne Berechtigung kein Eingang; vertrauliche Typen nur für Berechtigte und Projekt-Owner/-Bearbeiter; Kunden sehen keine Dokumente. |
| DMS-08 | Soll | Nextcloud-Spiegel des Ordnerbaums (einseitig). | Ordnerbaum und Dateinamen in Nextcloud entsprechen der Ablage; Änderungen in Nextcloud wirken nicht zurück. |
| DMS-09 | Soll | SharePoint-/Drive-Spiegel, opt-in je Mandant, mit AV-Vertrag. | Ohne Aktivierung fließt nichts ab; Spiegel wie DMS-08. |
| DMS-10 | Soll | Cloud-Import bestehender Ordner in den Eingang. | Importierte Dateien erscheinen im Eingang und durchlaufen die Prüfung. |
| DMS-11 | Soll | Abruf per WhatsApp: genau ein sicherer Treffer geht an einen dafür erlaubten Projektkontakt, mehrere Treffer per Auswahl, Unsicheres und Vertrauliches über die Freigabe-Queue. | Vertrauliche Typen werden nie automatisch gesendet; Abruf ist im Verlauf nachvollziehbar. |
| DMS-12 | Soll | Export als CSV, JSON und ZIP mit Manifest. | Export eines Projekts enthält alle sichtbaren Dokumente mit Metadaten und Prüfsumme. |
| DMS-13 | Soll | Aufbewahrung, Löschung und Legal Hold. | Löschen nur nach Frist und ohne Legal Hold; Löschung ist protokolliert. |
| DMS-14 | Kann | GAEB-/REB-Auswertung (Leistungsverzeichnis, Aufmaß). | Positionen eines GAEB-/REB-Dokuments sind einsehbar. |
| DMS-15 | Kann | Nachtragsakte: Beweissicherung und Nachträge je Vorgang gebündelt. | Vorgang zeigt Anzeigen, Fotos und Vereinbarung chronologisch. |
6.1 Feld-App
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| FIELD-01 | Muss | Bauleiter sehen nur genehmigte Abschnitte im eigenen Gebiet. | Keine Entwürfe, keine Ablehnungen. |
| FIELD-02 | Muss | Auflagen aus dem Verfahren sind am Abschnitt lesbar. | Dieselben Auflagen wie im Dashboard. |
| FIELD-03 | Soll | Fortschritt und Foto-Nachweis, Offline-Zwischenspeicher mit Sync. | Nach Wiederverbindung landen Outbox-Einträge in der SSOT. |
| AR-01 | Kann | Kamera-Overlay (ARCore Geospatial + Passpunkte). ±30 cm erst mit RTK. | Overlay zeigt genehmigte Produktgeometrien; keine v1-Genauigkeitsgarantie. |
7. Integration
| ID | Prio | Anforderung | Abnahme |
|---|---|---|---|
| INT-01 | Muss | Aus Editor und Dashboard lassen sich Exporte für QGIS 3.4.4 LTS erzeugen, die für das Projekt alle wichtigen Layer und Daten enthalten. | Export aus beiden Clients; in QGIS ladbar; Layer + Attribute des Projekts enthalten. |
Klärungsbedarf INT-01
In den Anforderungen steht QGIS 3.4.4 LTS (Release 2019). Der heutige Betrieb nutzt QGIS 4.2. Vermutlich ist 3.40 LTR gemeint. Bis zur Klärung gilt der Wortlaut; die Roadmap plant den Export so, dass die Zielversion austauschbar bleibt.
8. Qualitätsanforderungen
| ID | Prio | Anforderung |
|---|---|---|
| Q-01 | Soll | Geo-SSOT bleibt PostGIS, Speicher-SRID 25832 (bestehender Standard, nicht neu erfunden). |
| Q-02 | Soll | Editor hält keine eigene Business-Datenbank; Fachdaten laufen über die FastAPI (Tauri-Stackregel). .ltp ist Austauschformat, kein zweites SSOT. |
| Q-03 | Soll | Kunden sehen im Dashboard nur Daten ihrer Organisation/Projekte. |
| Q-04 | Soll | Versionierung darf keine stille Überschreibung sein: Korrekturen erzeugen nachvollziehbare Fassungen (ED-09). |
| Q-05 | Soll | Transit zur SSOT: TLS 1.3 am Proxy bzw. intern nur Compose-Netz; hostnossl von außen abgelehnt. |
9. Offene Punkte (kein HOW, nur Klärung)
Diese Punkte ändern das Lastenheft erst nach Entscheidung:
- QGIS-Zielversion — 3.4.4 vs. 3.40 LTR vs. 4.2 (INT-01).
- Chat-Teilnehmer — nur Kunde↔Betreiber, oder auch intern?
- Tickets vs. bestehendes Jira — Dashboard-Tickets parallel (ADR-0007); Aufgaben-SSOT und Mirror: ADR-0059.
- Offline-Editor —
.ltplokal bearbeiten ohne API, dann synchronisieren? - Bericht-Sets — wer pflegt die Sets (intern im Editor, Admin im Dashboard)?
- PDF-Rohinput — nur Dateiablage in Planung, oder Geometrie-Digitalisierung Pflicht (ED-03)?
- Zertifikat → DB-Rolle — entschieden (ADR-0055): Mandanten-Paar
{slug}_edit/{slug}_readfür GRANTs + FastAPI; QGIS-Cert-CN = persönlicher LOGIN{slug}_u_{user_id_hex8}(Inherit). Shared-CN am Proxy ist tot. - VPN danach — abschalten oder als optionale zweite Hülle behalten?
- Dokumente und QGIS-Logins — persönliche QGIS-Logins von Mitarbeitern erben
{slug}_edit(ADR-0055) und können die Dokumenttabellen lesen, auch vertrauliche Typen (DMS-07). Akzeptiert für Phase 1a; zu klären, ob ein eigener Lesezugriff ohne Dokumente nötig ist.
10. Abnahme des Lastenhefts insgesamt
Das Lastenheft ist erfüllt, wenn alle Muss-IDs abgenommen sind. Soll darf die Abnahme nicht blockieren, wenn das Muss nachweisbar anders erfüllt ist. Kann (ED-12) ist kein Abnahme-Kriterium.
Nächster Schritt fachlich: Fachmodell. Nächster Schritt zeitlich: Roadmap.