Pflichtenheft – Web-Anwendung zur Tourenplanung
Dieses Pflichtenheft beschreibt die technische und organisatorische Umsetzung der vom Logistikkunden beauftragten Web-Anwendung für 25 Disponenten. Die Lösung übernimmt Aufträge aus dem ERP, unterstützt die digitale Tourenplanung, bindet Fahrer-App und Fahrzeugtelematik an und wird in der EU betrieben.
1. Einleitung
Grundlage dieses Pflichtenhefts ist das Lastenheft des Auftraggebers für eine Individualsoftware zur Tourenplanung im Logistikbetrieb.
Das Dokument beschreibt aus Sicht des Auftragnehmers die vorgesehene Systemarchitektur, Umsetzung, Schnittstellen, Qualitätssicherung sowie den späteren Betrieb.
- Primäre Nutzergruppe: 25 Disponenten am Standort des Auftraggebers.
- Kernprozesse: Auftragsübernahme aus dem ERP, Tourenplanung, Übergabe an Fahrer, Lieferstatus, Unterschrift und Telematikabgleich.
- Hosting und Verarbeitung der produktiven Daten erfolgen innerhalb der Europäischen Union.
2. Lösungsüberblick und Systemarchitektur
Die Lösung wird als zentral betriebene Web-Anwendung mit rollenbasierter Anmeldung umgesetzt. Das Frontend läuft in aktuellen Versionen der marktüblichen Desktop-Browser; die Fahrer-App wird als mobile Anwendung für Android und iOS oder als installierbare Progressive Web App umgesetzt (Annahme).
Die Architektur besteht aus Web-Frontend, Backend-API, relationaler Datenbank, Datei- beziehungsweise Belegspeicher sowie separaten Integrationsadaptern für ERP und Telematik. Die Kommunikation erfolgt verschlüsselt über HTTPS; asynchrone Prozesse wie Imports, Statusübertragungen und Benachrichtigungen werden über eine Nachrichten- oder Jobwarteschlange verarbeitet (Annahme).
Die Anwendung wird in einer EU-Cloud mit getrennten Entwicklungs-, Test- und Produktionsumgebungen betrieben (Annahme).
- Frontend: responsives Disponentenportal mit Karten- und Tourenansicht.
- Backend: versionierte REST- oder gleichwertige JSON-API mit zentraler Geschäftslogik.
- Datenhaltung: relationale Datenbank für Aufträge, Touren, Benutzer, Status und Nachweise.
- Zugriffsschutz: Rollen für Disponenten, Fahrer, Administratoren und Supportpersonal.
- Integrationen: ERP-Adapter, Telematik-Adapter und App-Synchronisation.
3. Umsetzung der funktionalen Anforderungen
Die folgenden Anforderungen konkretisieren die im Lastenheft angenommenen funktionalen Anforderungen F-01 bis F-12. Die Nummerierung der Lastenheft-Anforderungen ist anhand der beschriebenen Kernfunktionen fortgeschrieben und muss bei der Detailabstimmung mit dem Auftraggeber bestätigt werden (Annahme).
Auftragsübernahme aus dem ERP
Ein Integrationsadapter übernimmt neue und geänderte Aufträge aus dem ERP automatisiert und stellt zusätzlich einen manuell auslösbaren Import bereit. Die Verarbeitung erfolgt idempotent anhand einer eindeutigen ERP-Auftragsnummer; fehlerhafte Datensätze werden mit Ursache protokolliert.
Abnahme: Ein Testauftrag wird im ERP angelegt, innerhalb des vereinbarten Importintervalls in der Anwendung angezeigt und bei wiederholter Übertragung nicht doppelt angelegt. Ein absichtlich fehlerhafter Datensatz erscheint im Fehlerprotokoll.
Auftragsübersicht und Suche
Disponenten erhalten eine filter- und sortierbare Übersicht der Aufträge mit mindestens Auftragsnummer, Empfänger, Adresse, Lieferdatum, Zeitfenster, Menge beziehungsweise Gewicht und aktuellem Bearbeitungsstatus. Die Suche unterstützt die ERP-Auftragsnummer und Empfängerangaben.
Abnahme: Mit einem vorbereiteten Datenbestand werden Aufträge nach Datum, Status und Auftragsnummer gefiltert. Die angezeigten Werte stimmen mit den importierten ERP-Daten überein.
Anlegen und Bearbeiten von Touren
Disponenten können Touren anlegen, bearbeiten, speichern und stornieren. Eine Tour enthält mindestens Tournummer, Datum, Fahrzeug, Fahrer, Stopps, geplante Reihenfolge und Status.
Abnahme: Ein berechtigter Disponent legt eine Tour an, ergänzt mindestens fünf Stopps, speichert sie und ändert Fahrzeug sowie Reihenfolge. Die Änderungen sind nach einer erneuten Anmeldung unverändert vorhanden.
Tourenplanung per Drag-and-drop
Nicht verplante Aufträge werden in einer Planungsansicht per Drag-and-drop einer Tour zugewiesen oder zwischen Touren verschoben. Das System prüft dabei Pflichtangaben sowie offensichtliche Konflikte bei Lieferdatum, Zeitfenster und Fahrzeugkapazität, sofern diese Daten im ERP verfügbar sind.
Abnahme: Ein Testauftrag wird per Drag-and-drop einer Tour zugewiesen und anschließend in eine zweite Tour verschoben. Ein Auftrag außerhalb seines Lieferdatums oder oberhalb der hinterlegten Kapazität wird mit einem verständlichen Hinweis abgewiesen oder als Konflikt markiert.
Routen- und Reihenfolgenunterstützung
Die Anwendung stellt die Stopps einer Tour auf einer Karte dar und berechnet auf Basis eines angebundenen Routingdienstes Strecke und voraussichtliche Fahrzeit (Annahme). Die Reihenfolge kann manuell angepasst werden; eine automatische Optimierung wird nur umgesetzt, wenn sie im beauftragten Routingumfang enthalten ist (Annahme).
Abnahme: Für eine Tour mit mindestens fünf gültigen Adressen werden Karte, Stoppfolge, Strecke und Fahrzeit angezeigt. Nach Änderung der Reihenfolge werden die berechneten Werte aktualisiert.
Fahrer- und Fahrzeugzuordnung
Disponenten ordnen einer Tour einen Fahrer und ein Fahrzeug aus den Stammdaten zu. Das System verhindert die gleichzeitige Zuordnung desselben Fahrers oder Fahrzeugs zu kollidierenden Touren, sofern Zeit und Status der Touren dies erkennen lassen.
Abnahme: Ein Fahrer und ein Fahrzeug werden einer Tour zugeordnet und anschließend in der Tourübersicht angezeigt. Eine kollidierende zweite Zuordnung erzeugt eine Fehlermeldung oder einen eindeutig sichtbaren Konflikthinweis.
Freigabe und Übermittlung an die Fahrer-App
Eine geplante Tour kann durch einen Disponenten freigegeben und an den zugeordneten Fahrer übermittelt werden. Nach der Freigabe werden Änderungen versioniert und als neue Aktualisierung an die App übertragen.
Abnahme: Eine Tour wird freigegeben und erscheint beim angemeldeten Fahrer. Eine nachträgliche Änderung wird mit neuer Version an die App übertragen; eine nicht freigegebene Tour bleibt für den Fahrer unsichtbar.
Lieferstatus in der Fahrer-App
Der Fahrer kann für jeden Auftrag mindestens die Zustände unterwegs, angekommen, zugestellt, nicht zugestellt und abgebrochen setzen. Statusänderungen werden mit Zeitstempel, Benutzerkennung und optionaler GPS-Position an das Backend übertragen; bei fehlender Verbindung werden sie zwischengespeichert (Annahme).
Abnahme: Mit einem Testkonto werden alle vorgesehenen Status gesetzt und im Disponentenportal angezeigt. Ein Offline-Test speichert eine Statusänderung lokal und überträgt sie nach Wiederherstellung der Verbindung genau einmal.
Digitale Unterschrift und Zustellnachweis
Die Fahrer-App erfasst für eine erfolgreiche Zustellung eine Unterschrift auf dem mobilen Endgerät und verknüpft sie mit Auftrag, Fahrer, Zeitstempel und Zustellstatus. Der Nachweis wird revisionsgeeignet gespeichert und im Disponentenportal angezeigt; die rechtliche Ausgestaltung der elektronischen Signatur wird mit dem Auftraggeber abgestimmt (Annahme).
Abnahme: Ein Testauftrag wird zugestellt, unterschrieben und synchronisiert. Der Disponent kann den Zustellnachweis einschließlich Unterschriftsbild und Zeitstempel abrufen; eine nachträgliche Änderung des gespeicherten Dokuments ist für Standardnutzer nicht möglich.
Anbindung der Fahrzeugtelematik
Ein Telematik-Adapter übernimmt Fahrzeugpositionen und die vom Anbieter bereitgestellten Fahrzeugstatus. Die Daten werden dem zugeordneten Fahrzeug beziehungsweise der Tour zugeordnet und mit Zeitstempel gespeichert; nicht verarbeitbare Nachrichten werden protokolliert.
Abnahme: Ein Testfahrzeug sendet mindestens eine Positions- und eine Statusmeldung. Beide Meldungen werden dem richtigen Fahrzeug zugeordnet und im Portal angezeigt; eine ungültige Nachricht erzeugt einen technischen Fehler im Integrationsprotokoll.
Abweichungen und Benachrichtigungen
Die Anwendung kennzeichnet nicht zugestellte Aufträge, verspätete Statusmeldungen, Tourkonflikte und fehlende Telematikdaten. Disponenten erhalten die Ereignisse in einer Aufgaben- oder Ereignisliste; E-Mail- oder Push-Benachrichtigungen werden nach Festlegung der Empfänger aktiviert (Annahme).
Abnahme: Für einen Testauftrag wird eine Nichtzustellung und für ein Testfahrzeug ein Kommunikationsausfall erzeugt. Beide Ereignisse erscheinen innerhalb des vereinbarten Zeitraums in der Ereignisliste und enthalten Ursache, Zeitpunkt und Bezug.
Historie, Protokollierung und Export
Das System führt für Aufträge und Touren eine Historie der wesentlichen Änderungen mit Benutzer, Zeitpunkt und altem beziehungsweise neuem Status. Berechtigte Disponenten können Tour- und Statusdaten für einen ausgewählten Zeitraum als CSV- oder XLSX-Datei exportieren (Annahme).
Abnahme: Eine Tour wird von zwei Benutzern geändert. Die Historie zeigt beide Änderungen korrekt. Ein Export für einen definierten Zeitraum enthält genau die im Filter angezeigten Touren und Statusdaten.
4. Umsetzung der nicht-funktionalen Anforderungen
Die folgenden Zielwerte gelten für den zunächst vorgesehenen Betrieb mit 25 Disponenten und einer noch zu bestätigenden Zahl aktiver Fahrer und Fahrzeuge. Die Werte mit dem Zusatz „(Annahme)“ sind im Rahmen der Detailkonzeption zu bestätigen.
Performance
Das System wird so dimensioniert, dass bei bis zu 25 gleichzeitig arbeitenden Disponenten und bis zu 100 gleichzeitig verbundenen Fahrer-Apps (Annahme) mindestens 95 Prozent der Standardabfragen innerhalb von zwei Sekunden beantwortet werden. Import- und Telematikverarbeitung erfolgt asynchron.
Abnahme: Ein Lasttest mit den genannten Nutzerzahlen und einem produktionsnahen Datenbestand misst die Antwortzeiten der definierten Standardvorgänge. Mindestens 95 Prozent liegen unter zwei Sekunden.
Verfügbarkeit
Für die produktive Anwendung wird eine monatliche Verfügbarkeit von mindestens 99,5 Prozent außerhalb angekündigter Wartungsfenster angestrebt (Annahme). Wartungsfenster werden mindestens 48 Stunden vorher angekündigt.
Abnahme: Die Verfügbarkeit wird über ein externes Monitoring und die Betriebsprotokolle eines Kalendermonats berechnet. Der vereinbarte Zielwert wird abzüglich freigegebener Wartungsfenster erreicht.
Authentifizierung und Berechtigungen
Jeder Benutzer erhält ein persönliches Konto. Die Anwendung setzt eine rollenbasierte Zugriffskontrolle um; administrative Funktionen, Zustellnachweise und Benutzerverwaltung sind auf berechtigte Rollen beschränkt. Eine Anbindung an den Identitätsdienst des Auftraggebers und Mehrfaktor-Authentifizierung werden vorgesehen (Annahme).
Abnahme: Mit Testkonten je Rolle wird geprüft, dass erlaubte Funktionen zugänglich und nicht erlaubte Funktionen technisch gesperrt sind. Ein nicht berechtigter Zugriff auf einen Zustellnachweis wird abgewiesen und protokolliert.
Verschlüsselung und Schutz der Daten
Datenübertragungen erfolgen ausschließlich über aktuelle TLS-Versionen. Datenbanken, Backups und gespeicherte Zustellnachweise werden verschlüsselt gespeichert; Schlüssel und Zugangsdaten werden getrennt von den Anwendungsdaten verwaltet.
Abnahme: Ein Sicherheitstest weist ausschließlich verschlüsselte externe Verbindungen nach. Eine Prüfung der Konfiguration bestätigt die Verschlüsselung der produktiven Datenbank, Backups und Belegdaten.
Datensicherung und Wiederherstellung
Produktive Daten werden mindestens täglich vollständig und zusätzlich regelmäßig inkrementell gesichert (Annahme). Als vorläufige Zielwerte gelten ein RPO von 24 Stunden und ein RTO von vier Stunden (Annahme).
Abnahme: Eine Sicherung wird in eine isolierte Umgebung eingespielt. Die Datenbank, ein Zustellnachweis und die zugehörige Tour werden innerhalb des Zielzeitraums wiederhergestellt.
Überwachung und Protokollierung
Anwendung, Datenbank, Schnittstellen, Hintergrundjobs und Systemressourcen werden überwacht. Fehler, Anmeldeversuche, Berechtigungsfehler, Importe und Statusänderungen werden mit Zeitstempel und technischer Korrelation protokolliert; personenbezogene Daten in Logdateien werden minimiert.
Abnahme: Für einen absichtlich fehlgeschlagenen ERP-Import, eine abgewiesene Anmeldung und einen API-Fehler werden Monitoring-Ereignisse und nachvollziehbare Logeinträge erzeugt. Die Logs enthalten keine vollständigen Unterschriftsbilder oder unnötigen personenbezogenen Inhalte.
Wartbarkeit und Erweiterbarkeit
Die Anwendung wird modular mit versionierten Schnittstellen, automatisierten Build- und Deployment-Prozessen sowie dokumentierten Konfigurationsparametern umgesetzt. Änderungen an ERP- und Telematikadaptern sollen ohne Änderung der zentralen Tourenlogik möglich sein.
Abnahme: Ein Deployment in die Testumgebung wird aus dem versionierten Quellcode reproduzierbar durchgeführt. Die Dokumentation beschreibt Konfiguration, Schnittstellen, Datenmodell und Rollback-Verfahren.
5. Schnittstellen und Migrationskonzept
Die konkrete technische Ausprägung der Schnittstellen wird nach Prüfung der Systeme des Auftraggebers festgelegt. Für das ERP wird eine REST- oder SOAP-Schnittstelle bevorzugt; falls keine geeignete API verfügbar ist, wird ein abgesicherter Dateiimport über SFTP als Ausweichlösung vorgesehen (Annahme).
Die Telematik wird über die vom Telematikanbieter bereitgestellte API oder einen abgesicherten Webhook angebunden (Annahme). Alle Adapter validieren eingehende Daten, ordnen externe IDs internen Objekten zu und stellen technische Fehler in einem Integrationsmonitor dar.
Die Fahrer-App kommuniziert ausschließlich über die Backend-API. Für Status, Unterschriften und sonstige Zustellnachweise werden eindeutige Nachrichten-IDs verwendet, damit Wiederholungen keine Duplikate erzeugen.
- ERP-Eingang: Auftragsnummer, Empfänger, Adresse, Lieferdatum, Zeitfenster, Mengen- und Kapazitätsdaten sowie Auftragsstatus, soweit im ERP vorhanden.
- Telematik-Eingang: Fahrzeug-ID, Zeitstempel, Position und verfügbare Fahrzeugstatus.
- Ausgang an ERP: Zustellstatus, Zustellzeitpunkt, Nichtzustellgrund und Verweis auf den Zustellnachweis, sofern vom Auftraggeber gewünscht (Annahme).
- Migration: Übernahme der Fahrer-, Fahrzeug- und Benutzerm Stammdaten sowie offener Aufträge; historische Touren und Nachweise werden zunächst nicht migriert (Annahme).
- Vor der Produktivsetzung werden Datenmapping, Dublettenregeln, Testdaten, fachliche Abnahme und ein Rückfallplan dokumentiert.
6. Datenschutz und IT-Sicherheit
Die Verarbeitung wird nach den Grundsätzen der DSGVO umgesetzt. Der Auftraggeber bleibt Verantwortlicher; der Auftragnehmer verarbeitet Daten ausschließlich im vereinbarten Auftrag und schließt mit den eingesetzten Hosting- und Unterauftragnehmern die erforderlichen Vereinbarungen zur Auftragsverarbeitung.
Personenbezogene Daten werden auf das für Tourenplanung, Zustellung, Nachweisführung und Support erforderliche Maß beschränkt. Fahrer- und Standortdaten werden nur für definierte Zwecke verarbeitet und nach Ablauf der festgelegten Aufbewahrungsfristen gelöscht oder anonymisiert.
Vor Produktivsetzung werden ein Verzeichnis der Verarbeitungstätigkeiten beziehungsweise die erforderlichen Verarbeitungsinformationen, eine Schutzbedarfsbewertung und, falls erforderlich, eine Datenschutz-Folgenabschätzung unterstützt.
- Hosting, Backups und Supportzugriffe erfolgen innerhalb der EU beziehungsweise des EWR; abweichende Übermittlungen werden nicht ohne Freigabe des Auftraggebers eingerichtet.
- Zugriffe werden nach dem Prinzip der geringsten Rechte vergeben und regelmäßig überprüft.
- Administrations- und Supportzugriffe werden personalisiert, zeitlich begrenzt oder freigegeben und protokolliert.
- Sicherheitsupdates für Betriebssysteme, Laufzeitumgebung und verwendete Bibliotheken werden nach einem dokumentierten Verfahren eingespielt.
- Zustellnachweise und Unterschriften werden gegen unberechtigte Änderung geschützt; Aufbewahrung und rechtliche Verbindlichkeit werden mit dem Auftraggeber festgelegt.
- Sicherheitsvorfälle werden bewertet, dokumentiert und gemäß den vereinbarten Meldewegen eskaliert.
7. Test- und Abnahmekonzept
Die Umsetzung wird durch automatisierte und manuelle Tests abgesichert. Testfälle werden aus den Anforderungen P-01 bis P-12 und Q-01 bis Q-07 abgeleitet und in einem Testmanagementsystem oder einer versionierten Testdokumentation geführt.
Die fachliche Abnahme erfolgt durch benannte Vertreter des Auftraggebers, insbesondere durch Disponenten sowie ausgewählte Fahrer im Pilotbetrieb (Annahme).
- Unit-Tests prüfen Geschäftsregeln, Statusübergänge, Berechtigungen und Datenvalidierungen.
- Integrationstests prüfen ERP, Telematik, App, Routingdienst und Benachrichtigungen mit Testsystemen.
- Systemtests prüfen vollständige Abläufe von der Auftragsübernahme bis zum Zustellnachweis.
- Sicherheits- und Berechtigungstests prüfen Authentifizierung, Rollen, API-Zugriffe, Eingabevalidierung und Protokollierung.
- Performance- und Wiederherstellungstests prüfen Q-01 und Q-05 in einer produktionsnahen Umgebung.
- Die Abnahme gilt als erreicht, wenn alle MUSS-Anforderungen bestanden, keine kritischen oder hohen Fehler offen und die vereinbarten Betriebs- und Sicherheitsdokumente übergeben sind.
8. Projektphasen, Rollen und Zeitplan
Für die Erstumsetzung wird ein Gesamtzeitraum von etwa 16 Kalenderwochen angenommen. Der Zeitplan setzt voraus, dass Testzugänge, Ansprechpartner, Schnittstellendokumentationen und fachliche Entscheidungen rechtzeitig bereitgestellt werden (Annahme).
Der Auftragnehmer führt die technische Umsetzung, Qualitätssicherung, Dokumentation und Koordination der Integrationen durch. Der Auftraggeber benennt einen Product Owner mit Entscheidungsbefugnis und stellt fachliche Tester aus Disposition und Fahrbetrieb bereit.
- Phase 1, Wochen 1–2: Detailaufnahme, Schnittstellenklärung, Datenschutz- und Sicherheitskonzept.
- Phase 2, Wochen 3–5: Architektur, Datenmodell, Benutzerverwaltung und Grundfunktionen der Auftragsverwaltung.
- Phase 3, Wochen 6–10: Tourenplanung, Karten- und Routingintegration, Fahrer-App und Zustellstatus.
- Phase 4, Wochen 11–12: ERP- und Telematikintegration, Unterschrift, Ereignisse und Exporte.
- Phase 5, Wochen 13–14: System-, Sicherheits-, Performance- und Migrationstests.
- Phase 6, Wochen 15–16: Pilotbetrieb, Fehlerkorrekturen, Abnahme, Schulung und Produktivsetzung.
- Rollen: Auftraggeber-Product-Owner, fachliche Key-User, Projektleitung, Backend- und Frontend-Entwicklung, Mobile-Entwicklung, Testmanagement, DevOps sowie Datenschutz- und Sicherheitsexpertise.
9. Betrieb, Support und Wartung
Der Auftragnehmer betreibt die Anwendung in einer überwachten EU-Hostingumgebung und stellt getrennte Umgebungen für Test und Produktion bereit. Produktivsetzungen werden geplant, dokumentiert und bei Bedarf über ein Rollback-Verfahren abgesichert.
Der Standard-Support erfolgt an Werktagen während der Geschäftszeiten des Auftraggebers (Annahme). Kritische Störungen werden über einen vereinbarten Bereitschafts- oder Eskalationsprozess behandelt, sofern dieser beauftragt wird.
- Störungsmeldungen werden über ein Ticketsystem mit Priorität, betroffenen Funktionen, Zeitstempel und Ansprechpartner erfasst.
- Priorität 1 gilt für einen vollständigen Produktionsausfall oder den Verlust der Zustellverarbeitung; Priorität 2 für wesentliche Einschränkungen eines Kernprozesses; Priorität 3 für sonstige Fehler und Änderungswünsche (Annahme).
- Backups, Monitoring, Zertifikate, Sicherheitsupdates und Speicherverbrauch werden regelmäßig geprüft.
- Regelmäßige Wartungen werden angekündigt und möglichst außerhalb der Dispositionszeiten durchgeführt.
- Die Betriebsdokumentation enthält Architektur, Schnittstellen, Benutzer- und Rollenmodell, Backup-Wiederherstellung, Monitoring, Eskalation und Notfallverfahren.
- Weiterentwicklungen, zusätzliche ERP- oder Telematikfunktionen sowie Änderungen an Aufbewahrungsfristen werden über ein separates Change-Verfahren beauftragt.
Vor der Verwendung klären
Diese Punkte und Annahmen sind im Beispiel offen — in deinem Vorhaben musst du sie festlegen.
- Welches ERP-System einschließlich Version, API- oder Dateischnittstelle, Datenfeldern, Importintervall und Rückmeldemechanismus wird eingesetzt?
- Welcher Telematikanbieter und welches Protokoll werden verwendet, welche Fahrzeuge werden angebunden und in welchem Übertragungsintervall stehen Positionsdaten zur Verfügung?
- Welche Anforderungen bestehen an automatische Routenoptimierung, Zeitfenster, Fahrzeugkapazitäten, Pausen, Maut- oder Umweltzonen und den Routingdienst?
- Für welche mobilen Betriebssysteme und Endgeräte wird die Fahrer-App benötigt, und muss sie offlinefähig sein?
- Welche Benutzerrollen, Identitätsdienste, Single-Sign-on- und Mehrfaktor-Anforderungen gelten für Disponenten, Fahrer, Administratoren und Support?
- Welche Zielmengen für Aufträge, Fahrzeuge, Fahrer und parallele App-Verbindungen sowie welche verbindlichen Werte für Verfügbarkeit, RPO und RTO sind festzulegen?
- Welche Aufbewahrungsfristen, Löschregeln, Anforderungen an elektronische Unterschriften, Rückmeldungen an das ERP und die Migration historischer Daten gelten?