MABEA/ergebnisse/01_anforderungsanalyse.md

Prompt 01 – Anforderungsanalyse

Projekt: Ressourcen- und Materialmanagement, Bereich Rettungsdienst/KatS als erster Anwendungsfall (11_systemumfang_ressourcenmanagement). Noch keine technische Umsetzung — reine fachliche Zusammenfassung.

1. Ausgangslage

Heute: Papierlisten pro Rucksack/Fahrzeug (Beispiele: Handball Rucksack, Rettungsrucksack, Rucksack PAX SEG). Mitarbeiter kontrolliert, zählt, tauscht abgelaufenes Material, trägt Abweichung ein, unterschreibt, Papier wird abgeheftet. Ziel: dies weitgehend digital ersetzen, ohne dass Fehlbestände vergessen werden können.

2. Funktionale Anforderungen

Muss

• Digitale Erfassung von Materialbeständen je Ressource (Rucksack, Fahrzeug, später weitere Objekttypen).
• Digitale Durchführung von Kontrollen: Ist-Menge je Position erfassen, Abweichungen sichtbar machen.
• Automatisches Anlegen eines Fehlbestand-Vorgangs bei jeder festgestellten Mindermenge — auch bei sofortiger Nachfüllung (Karte 07: entsteht + wird sofort erledigt, mit Historie).
• Fehlbestand bleibt als eigener, offener Vorgang bestehen, unabhängig vom Abschluss der Kontrolle.
• Besatzung kann fehlendes Material selbst aus dem Lager nachfüllen und dies dokumentieren.
• Fehlbestand gilt erst als erledigt, wenn tatsächlicher Bestand wieder vollständig ist (nicht durch bloße Genehmigung).
• Genehmigung von Mindermengen durch berechtigte Rollen (Materialverantwortlicher/Leitungsverantwortlicher), OHNE dass sich dadurch die tatsächliche Ist-Menge ändert (Karte 08: Genehmigung gilt automatisch bis zur nächsten Kontrolle).
• Materialverantwortlicher kann Sollmengen/Beladungsvorlagen ändern (Karte 03).
• Mitarbeiter meldet nur Ist-Menge, keine Stammdaten-Änderung (Karte 02).
• Administration verwaltet Ressourcen, Vorlagen, Materialstamm, Benutzer, Zuständigkeiten (Karte 04: Zuständigkeiten flexibel durch Admin einteilbar, n:m Verantwortlicher↔Standort/Objekt).
• Duplizieren von Ressourcen/Vorlagen als Grundlage für neue Objekte, mit anschließend voller Editierbarkeit; Zustandsdaten (Bestand, SN, Chargen, offene Fehlbestände, Historie) werden NICHT mitkopiert.
• Individuelle Abweichung eines konkreten Objekts von seiner Vorlage muss möglich und nachvollziehbar sein.
• Verantwortlichen-Dashboard mit offenen Fehlbeständen, genehmigten Mindermengen, Filtermöglichkeiten (Standort, Objekt, Material, Alter).
• Benachrichtigung bei neuem Fehlbestand: Dashboard + E-Mail (Karte 05).
• Vollständige Historie/Audit: wer, was, wann, alter/neuer Wert, Begründung.
• Echtes Benutzerkonto mit Login (Passwort/PIN) für alle Rollen (Karte 09).
• Bedienbarkeit sowohl auf PC als auch auf Smartphone/Tablet (Karte 06).
• Zuweisung von Kontrollverantwortung an Einzelperson oder Gruppe möglich, ohne dass dies andere Mitarbeiter von der Kontrolle ausschließt (Karte 01).

Soll

• Ablaufdaten/Chargen-Unterstützung inkl. Warnzeiträume (Prompt 14, später vertieft).
• Erweiterbarkeit des Materialstamms um Medikamente, Geräte mit Seriennummer, Chargen.
• Objekt- und Geräte-Code-Feld (ID für spätere QR/Barcode-Nutzung) bereits im Datenmodell vorsehen (Karte 10).
• Zeitstempel "Fehlbestand entstanden am" für spätere Eskalationslogik vorsehen (Karte 12).

Kann (spätere Ausbaustufen, nicht MVP)

• QR-/Barcode-Scan für Direktzugriff auf Objekt bzw. automatische SN-Erkennung (Roadmap, Karte 10).
• Automatische Eskalation offener Fehlbestände an Leitungsverantwortliche nach konfigurierbaren Fristen (Roadmap, Karte 12).
• Lagerverwaltung mit eigenen Lagerorten/Mindestbeständen, getrennt von Objektbestand (Prompt 15).
• Offline-fähige mobile Nutzung mit Synchronisierung (Prompt 17).
• Push-Benachrichtigungen (bewusst nicht in V1, Karte 05).
• Generische Ausweitung auf weitere Ressourcentypen (Zelte, Feldbetten, Stromerzeuger, Funkgeräte, Betreuungsmaterial) über bereits vorbereitete Bereichs-/Kategorie-Dimension (Karte 11).

3. Nichtfunktionale Anforderungen

• Nachvollziehbarkeit/Auditierbarkeit hat hohe Priorität (Rettungsdienst-/KatS-Kontext, Verantwortlichkeit im Einsatzfall).
• Bedienung muss im Einsatzumfeld schnell und mit wenig Tipparbeit möglich sein (Prompt 11).
• System muss für mehrere Standorte/Wachen gleichzeitig nutzbar sein, mit flexibler, nicht starrer Organisationsstruktur (Karte 04).
• Erweiterbarkeit ohne Grundmodell-Umbau ist ausdrückliches Designziel (Medikamente, Geräte, Prüfungen, Lagerbestände, weitere Ressourcentypen).
• Datensicherheit: echte Authentifizierung, Rollen-/Rechtetrennung.
• Verfügbarkeit auf gängigen Endgeräten (PC, Smartphone, Tablet) ohne getrennte Codebasis-Pflicht.

4. Angenommene Rahmenbedingungen (Annahmen)

• Rettungsdienst/KatS ist der erste produktive Bereich, System aber von Anfang an bereichsoffen modelliert (Karte 11).
• Es gibt mehrere Standorte/Wachen mit potenziell unterschiedlichen Verantwortlichkeiten (Karte 04).
• Mengenangaben aus bestehenden Excel-Listen (Artikel, Menge, Artikelnummer, teils Seriennummer) bilden den fachlichen Ausgangsdatensatz für Materialstamm und Vorlagen.
• Netzabdeckung im Einsatzumfeld ist nicht durchgängig gesichert (Offline-Frage bleibt in Prompt 17 vertiefend zu klären).

5. Risiken

• Vermischung von "genehmigter Mindermenge" und "tatsächlichem Bestand" wäre fachlich falsch und sicherheitskritisch (ausdrücklich zu verhindern, siehe reihenfolge.md) — hohe Sorgfalt bei Statusmodell in Prompt 03/04 nötig.
• Zu frühes technisches Design (Datenbank/UI) vor Abschluss 01–05 kann zu Fehlannahmen führen, die teuren Umbau erfordern (deswegen strikte Reihenfolge).
• Generischer Ressourcenansatz (Karte 11) kann Komplexität erhöhen, wenn nicht sauber von MVP-Umfang (Prompt 18) getrennt.
• Fehlende/inkonsistente Netzabdeckung im Einsatz kann Datenverlust oder Doppelerfassung verursachen, falls Offline-Konzept (Prompt 17) nicht sauber gelöst wird.
• Kein Push in V1 (Karte 05) kann bei zeitkritischen Fehlbeständen zu Verzögerung führen, falls Verantwortlicher E-Mail/Dashboard nicht zeitnah prüft — als bekanntes Risiko für Roadmap (Eskalation, Karte 12) vermerkt.

6. Offene Fragen (vor Prompt 02–05 weiter zu klären)

• Muss zugewiesene Kontrollverantwortung (Karte 01) eine Pflichtkontrolle erzwingen, oder bleibt sie reine Sichtbarkeits-/Priorisierungshilfe? Geklärt: reine Sichtbarkeits-/Priorisierungshilfe, kein Zwang. Schutzmechanismus gegen Doppelarbeit ist die Objekt-Sperre (Prompt 02.8), nicht die Zuweisung.
• Kann ein Objekt mehrere gleichzeitig zuständige Verantwortliche haben, und vererbt sich Zuständigkeit vom Standort automatisch auf alle dortigen Objekte (Karte 04)? Geklärt: ja, mehrere Verantwortliche gleichzeitig möglich (n:m). Standort-Zuordnung vererbt sich automatisch auf alle Objekte an diesem Standort; zusätzliche objektspezifische Zuordnung ist eine feinere Ergänzung, kein Widerspruch.
• Wie granular soll der Objekttyp/Kategorie-Baum sein (Karte 11) — flache Liste (Rettungsdienst, Betreuung, Technik, ...) oder hierarchisch mit Unterkategorien? (weiterhin offen, unkritisch für Schema — Kategorie hat bereits optionale Selbstreferenz für Hierarchie, Prompt 20)
• Welche Kontrollintervalle/Fristen sind organisatorisch vorgesehen (täglich, wöchentlich, nach Einsatz)? Geklärt: V1 hat KEINE eigene Kontrollintervall-/Fälligkeitslogik. Einzige System-getriebene Aufforderung zur Kontrolle ist der bereits bestehende Ablaufdatum-Mechanismus (Prompt 14: bald ablaufend/abgelaufen). Reguläre Kontrollintervalle bleiben rein organisatorisch (Dienstplan/Anweisung), vom System nur dokumentiert (Zeitpunkt letzte Kontrolle sichtbar), nicht berechnet oder erzwungen.

Referenzen

Arbeitskarten: 01_rollen_zuordnung, 02_rechte_stammdaten, 03_sollmengen_recht, 04_organisationsstruktur, 05_benachrichtigungen, 06_geraet_pc_mobil, 07_sofort_nachfuellung, 08_mindermenge_gueltigkeit, 09_authentifizierung, 10_qr_barcode, 11_systemumfang_ressourcenmanagement, 12_eskalation