Files
leistungsbilanz-ts/docs/anforderungs-abgleich.md
T
2026-05-03 19:15:46 +02:00

3.5 KiB
Raw Blame History

Anforderungs-Abgleich (Dokumentation vs. Code)

Dieses Dokument ergänzt die Hauptdokumentation und listet transparent auf:

  1. Was laut Anforderungen noch nicht vollständig umgesetzt ist.
  2. Was bereits im Code existiert, aber im ursprünglichen Requirements-Dokument nicht oder nur als offener Punkt erwähnt war.

Basisvergleich:

  • Anforderungen: docs/electrical-load-balance-requirements-context-dump.md
  • Ist-Stand: aktueller Code in src/

A) Anforderungen, die noch nicht vollständig umgesetzt sind

1) Bericht/Export/Print für Leistungsbilanzen

  • Erwartung: später nutzbarer Report-Export/Print.
  • Stand: Noch nicht umgesetzt.
  • Wirkung: Der Fokus liegt aktuell auf Erfassung, Bearbeitung und Berechnung im Web-UI.

2) „Keine Pflichtfelder“ vollständig im UI-Flow

  • Erwartung: Einträge sollen auch ohne zwingende Felder erfassbar sein.
  • Stand: Backend-seitig weitgehend erfüllt (optionale Felder + Defaults), UI-Schnellerfassung verlangt derzeit einen Namen.
  • Wirkung: Fachlich ist unvollständige Speicherung möglich, aber die Standard-UI bremst diesen speziellen Fall noch.

3) Einheitliche Textqualität (Mojibake-frei) im gesamten Frontend

  • Erwartung: saubere Umlaute/UTF-8.
  • Stand: In mehreren UI-Dateien sind weiterhin fehlerhafte Kodierungsreste vorhanden (z. B. „Gerät“).
  • Wirkung: Funktionalität ist gegeben, UX/Textqualität ist noch nachzuziehen.

B) Bereits umgesetzt, aber im ursprünglichen Requirements-Dokument nicht klar ausformuliert

1) Feste Domänen-Auswahllisten sind final definiert

  • Im Requirements-Dokument war das als „noch festzulegen“ markiert.
  • Im Code jetzt vorhanden:
    • src/shared/constants/consumer-option-lists.ts
    • Validierung in src/shared/validation/consumer.schemas.ts
    • Select-Felder in src/app/projects/[projectId]/circuit-lists/page.tsx

2) Sortieren, Filtern und Bulk-Edit sind bereits implementiert

  • Im Requirements-Dokument als mögliche Zusatzfunktion erwähnt.
  • Im Code umgesetzt in src/app/projects/[projectId]/circuit-lists/page.tsx.

3) Projekt-Spannungsstandards (1-phasig / 3-phasig) inkl. Berechnungsintegration

  • Im Requirements-Dokument nicht so detailliert als Projekt-Feature beschrieben.
  • Im Code umgesetzt:
    • Projekteinstellungen im Projekt-Detail
    • Verwendung in Berechnungslogik (effektive Spannung je Verbraucher)

4) 13 parallele Stromkreislisten mit responsiver Aufteilung

  • Im Requirements-Dokument nicht als konkrete UI-Regel spezifiziert.
  • Im Code umgesetzt in src/app/projects/[projectId]/circuit-lists/page.tsx.

5) Gerätekopie global ↔ projektbezogen in beide Richtungen

  • Fachlich erwähnt, aber technisch konkretisiert im API-Design:
    • POST /api/project-devices/projects/:projectId/import-global/:globalDeviceId
    • POST /api/global-devices/import-project/:projectId/:projectDeviceId

C) Offene fachliche Entscheidungen mit bereits getroffener Code-Interpretation

1) Verhalten beim Kopieren von Stromkreiseinträgen zwischen Listen

  • Offener Punkt in den Anforderungen: Link beibehalten oder trennen?
  • Aktuelle Code-Interpretation: Link-Information wird mitkopiert (projectDeviceId, isLinkedToDevice).
  • Relevanz: Sollte fachlich explizit bestätigt werden, damit spätere Änderungen keine Regression verursachen.

D) Empfehlung für nächste Dokumentationsrunde

  1. Das Requirements-Dokument um die inzwischen finalen Auswahllistenwerte ergänzen.
  2. Die Kopierlogik (Link beibehalten/trennen) fachlich eindeutig festschreiben.
  3. Einen eigenen Abschnitt für bekannte UX-/Textqualitätspunkte (Kodierung/Umlaute) ergänzen.