# 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? - Kann ein Objekt mehrere gleichzeitig zuständige Verantwortliche haben, und vererbt sich Zuständigkeit vom Standort automatisch auf alle dortigen Objekte (Karte 04)? - Wie granular soll der Objekttyp/Kategorie-Baum sein (Karte 11) — flache Liste (Rettungsdienst, Betreuung, Technik, ...) oder hierarchisch mit Unterkategorien? - Welche Kontrollintervalle/Fristen sind organisatorisch vorgesehen (täglich, wöchentlich, nach Einsatz)? — relevant für Prompt 02 und spätere Eskalation. ## 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]]