2026-00256_Lastenheftentwurf.pdf

[Seite 1]

Dresdner Verkehrsbetriebe AG

Vergabenummer: 2026_00256

Förderkennzeichen: EFRE 14 D 12 P 207 N

LASTENHEFT

für die Konzeption, Realisierung und Betreuung einer

barrierefreien, geräteübergreifenden Web-Plattform mit

nativer App-User-Experience

für die Dresdner Verkehrsbetriebe AG (DVB) im Rahmen des

Projekts MIKT (Modernisierung der Informations- und Kommu-

nikationstechnologien)

Status: Entwurf

[Seite 2]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Inhaltsverzeichnis

1. Einführung .............................................................................................................. 9 1.1 Inhalt des Gesamtprojekts MIKT ...................................................................................9 1.2 Ausgangssituation für das Teilprojekt ..........................................................................10 1.3 Motivation und Zielstellung für das Teilprojekt .............................................................11 1.3.1 Visuelles Erlebnis und Nutzungszentrierung .........................................................11 1.3.2 Konsolidierung von Inhalten und Interaktion .........................................................12 1.3.3 Funktionale Schwerpunkte und Mobilitätsservices ................................................12 1.3.4 Architektur und Infrastruktur .................................................................................13 1.4 Zielgruppen und Nutzungskontexte .............................................................................13 1.4.1 Pendelnde und regelmäßige Kundschaft ..............................................................14 1.4.2 Gelegenheitsfahrende, Besuchende und touristisch Reisende .............................14
2. Projektorganisation ............................................................................................... 15 2.1 Projektphasen und Meilensteine .................................................................................15 2.2 Projektorganisation und Rahmenbedingungen ............................................................16 2.2.1 Allgemeine Rahmenbedingungen & Projektsprache .............................................16 2.2.2 Erwartete Projektorganisation des beauftragten Unternehmens ...........................17 2.2.3 Schnittstelle zur DVB ............................................................................................17 2.3 Kollaboration und Abstimmungsroutinen .....................................................................18 2.4 Begleitende Marktforschung, UX-Forschung und Testings ..........................................18 2.4.1 Ausgangslage & Zielsetzung ................................................................................18 2.4.2 Marktforschung während der Designphase...........................................................19 2.4.3 Optional: Marktforschung nach Freigabe der neuen Website................................22 2.4.4 Allgemeine Marktforschungsanforderungen..........................................................23
3. Systemarchitektur & technische Infrastruktur ....................................................... 25

3.1 Zielarchitektur .............................................................................................................25 3.2 Schnittstellen-Übersicht ..............................................................................................26 3.3 Hosting- und Betriebsumgebung .................................................................................29 3.3.1 Infrastruktur & Bereitstellungsmodell ........................................................................29 3.3.2 Skalierbarkeit, Performance & Redundanz ...............................................................30 3.3.3 IT-Sicherheit & Datenschutz .....................................................................................30 3.3.4 DevOps, Wartung & Monitoring ................................................................................30 4. Übergreifende funktionale und strategische Anforderungen ................................. 32 4.1 Design, UX/UI-Vorgaben und Frontend-Prinzipien ......................................................32 4.1.1 Kernvorgaben des Corporate Designs (Faktenblatt) .............................................32 4.1.2 Digitales Design-System und Token-Architektur ...................................................33 4.1.3 Flexible Anzeige-Modi ..........................................................................................33

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 2 von 111

[Seite 3]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.1.4 Konzeptionelle Gestaltungs- und Interaktionsprinzipien ........................................33 4.2 Übergreifende Anforderungen Content-Management-System (CMS) ..........................34 4.2.1 Redaktionsworkflow und Redaktionsumgebung ...................................................34 4.2.2 Digital-Asset-Management und Bildverarbeitung ..................................................35 4.2.3 KI-gestützte Mehrsprachigkeit und Sprachvarianten .............................................36 4.2.4 URL-, Weiterleitungs- und Shortlink-Management ................................................37 4.2.5 Flexibles Formular- und Datenstruktur-Management ............................................37 4.2.6 Systemumgebungen, Qualitätssicherung und Staging ..........................................38 4.2.7 Globale Plattform-Konfiguration, Feedback-Engine & Echtzeit-Daten ...................38 4.2.8 Redaktionelle Suchmaschinenoptimierung (SEO-Werkzeuge) .............................39 4.3 Rahmenlayout und Navigation ....................................................................................39 4.3.1 Navigations- und Menü-Strukturen .......................................................................40 4.3.2 Globaler Header und zentrale Funktionselemente ................................................40 4.3.3 Globaler Footer ....................................................................................................41 4.4. Startseite....................................................................................................................41 4.4.1 Funktionale Anforderungen an die Startseite und Inhaltssteuerung ......................42 4.4.2 Führung der Nutzenden und strategische Einstiege auf der Startseite ..................43 4.5 Newsroom (Content Hub) ...........................................................................................43 4.5.1 Systemarchitektur und funktionale Grundlagen ....................................................44 4.5.2 Content-Aggregation und Drittanbieter-Schnittstellen ...........................................44 4.5.3 Redaktionelle Inhaltssteuerung und Teaser-Logiken ............................................45 4.5.4 Presse-Services und geschütztes Medienmanagement........................................46 4.6 Archiv-Bereiche und historische Daten .......................................................................46 4.6.1 Funktionale Anforderungen an das globale Archivierungsmodul...........................46 4.7 Blog-Modul und interaktives Fotobuch ........................................................................47 4.7.1 Systemintegration, Navigation und Blog-Startseite ...............................................48 4.7.2 Redaktionelle Verwaltung und Beitragsstrukturen.................................................48 4.7.3 Kommentarfunktion, Authentifizierung und Drittsysteme .......................................49 4.7.4 Das Fotobuch-Modul (Soll-Anforderung) ..............................................................50 4.8 Karriere-Portal und Stellenmarkt .................................................................................51 4.8.1 Migration, Navigation und Design .........................................................................51 4.8.2 API-Integration des Bewerbermanagementsystems .............................................51 4.8.3 Redaktionelle Konfiguration und Daten-Mapping im CMS ....................................52 4.9 Fachspezifische Formulare für Kundenanliegen und Kundengarantien .......................52 4.10 Beschaffung und Integration eines intelligenten Chatbot-Assistenten .......................53 4.10.1 Kernfunktionen und Systemarchitektur ...............................................................54 4.10.2 Erweiterte Interaktions- und Servicefunktionen ...................................................55

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 3 von 111

[Seite 4]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.11 Einbindung von Drittplattformen ................................................................................55 4.11.1 Technische Layout- und Datenschutzvorgaben ..................................................55 4.11.2 Integration von interaktiven Komoot-Widgets ......................................................56 4.11.3 Anbindung des Vergabeportals ...........................................................................56 4.11.4 Flexibilität und Erweiterbarkeit für zukünftige Drittsysteme .................................56 4.12 Optionale Funktionsmodule.......................................................................................57 4.12.1 Digitales Terminbuchungssystem (Option) .........................................................57 4.12.2 Umfragen- und Gewinnspielmodul (Option) ........................................................57 4.13 Gamification (Soll-Anforderung) ................................................................................58 4.13.1 Systemarchitektur und API-Schnittstellen ...........................................................58 4.13.2 Funktionale und rechtliche Vorgaben..................................................................59 4.14 Multimodale und barrierefreie Verbindungsauskunft..................................................59 4.14.1 Intelligente Ortssuche und Eingabelogik .............................................................60 4.14.2 Intermodale Routenberechnung und Komfortfilter...............................................60 4.14.3 Ergebnisanzeige und Fahrgastinformation..........................................................62 4.14.4 Interaktive Detailansicht und Komfort-Features ..................................................63 4.14.5 Kartografische Unterstützung .............................................................................65 4.14.6 Integrierte Haltestellenauskunft (Abfahrtsmonitor) ..............................................65 4.14.7 Kauf aus der Verbindungsauskunft .....................................................................66 4.14.8 Integration der alita-Buchung ..............................................................................66 4.14.9 Optionale innovative Erweiterungsvorschläge ....................................................67 4.15 Reisebegleitung „Schutzengelfunktion“ .....................................................................67 4.15.1 Systemintegration und technisches Verhalten ....................................................68 4.15.2 Kernfunktionen der Reiseüberwachung ..............................................................68 4.15.3 Benutzeroberfläche und Benachrichtigungen .....................................................69 4.15.4 Verknüpfung DVB-Account, Historisierung und Migration ...................................69 4.16 Zentrale Linienänderungen, Störungsinformationen und Großraummeldungen .........70 4.16.1 Zentrale Übersichts- und Filterseite ....................................................................70 4.16.2 Strukturierte Detailansicht und Infomedien .........................................................71 4.16.3 Abonnement-Infrastruktur und Verknüpfung DVB-Account .................................72 4.16.4 Systemweite Integration .....................................................................................72 4.17 Interaktive Karte ........................................................................................................73 4.17.1 Modulare Layer-Architektur und Interaktionssteuerung .......................................73 4.17.2 Live-Fahrzeugvisualisierung und RBL-Integration...............................................74 4.17.3 Multimodale MOBIpunkt-Karte mit Echtzeitdaten ................................................75 4.17.4 Geografische Darstellung von Linienänderungen ...............................................75 4.17.5 Modulare Verknüpfung mit redaktionellen Inhalten (Option) ...............................75

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 4 von 111

[Seite 5]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.17.6 Barrierefreiheit und Systemintegration (UI/UX) ...................................................76 4.18 Digitaler Abfahrtsmonitor (WebDFI) ..........................................................................76 4.18.1 Web-Konfigurator ...............................................................................................76 4.18.2 URL-Generierung und bildschirmunabhängiger Anzeigemodus ..........................77 4.18.3 Technische Datenversorgung .............................................................................77 4.19 DVB-Account (Profilbereich) .....................................................................................78 4.19.1 Systemarchitektur, Authentifizierungs-Schnittstelle und Datenhaltung ................78 4.19.2 Systemintegrationen und Drittanbieter-Schnittstellen (Commerce & Services) ...79 Hinweis für die Kapitel 4.20 bis 4.25: .............................................................................81 4.20 Interoperabler DVB-Onlineshop in der Vertriebslandschaft (Architektur) und weitere einzubindende Systeme ....................................................................................................81 4.20.1 Apps/Frontends (neu) .........................................................................................81 4.20.2 VVO-Tarifrechner ...............................................................................................81 4.20.3 Integration des CiCo-Tarifs per SDK (z.Z. Fairtiq)...............................................81 4.20.4 VVO-Barcode-Service ........................................................................................81 4.20.5 Vertriebshintergrundsystem (neu) .......................................................................81 4.20.6 Warenwirtschaftssystem (neu) ............................................................................81 4.20.7 Finanzdienstleister (z.Z. Logpay) ........................................................................81 4.20.8 Wallet-Dienstleister .............................................................................................81 4.20.9 Identity Provider (neu) ........................................................................................81 4.20.10 Kundenservice-Portal (neu) ..............................................................................81 4.20.11 BI-Analyse (neu) ...............................................................................................81 4.20.12 Technologien und Standards ............................................................................81 4.20.13 Best Practices ..................................................................................................81 4.20.14 Weiterentwicklungen.........................................................................................81 4.21 Identitätsprovider mit Single Sign-On ........................................................................82 4.21.1 Betriebsmodelle ..................................................................................................82 4.21.2 Schnittstellen & Integration .................................................................................82 4.21.3 Integration und Interoperabilität ..........................................................................82 4.21.4 Performance .......................................................................................................82 4.21.5 Integration und Migration von Keycload und MENTZ IDP ...................................82 4.21.6 Identitätsmanagement / Zentrale Nutzergruppenverwaltung (B2C, B2B, Mitarbeiter, Partner) ......................................................................................................82 4.21.7 Authentifizierung .................................................................................................82 4.21.8 User Journey - nahtlose Integration ....................................................................82 4.21.9 Content-Management .........................................................................................82 4.21.10 Technologien und Standards ............................................................................82 4.21.11 Best Practices ..................................................................................................82

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 5 von 111

[Seite 6]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.21.12 Weiterentwicklungen.........................................................................................82 4.22 DVB-Onlineshop inkl. Ticketshop ..............................................................................83 4.22.1 Integration und Interoperabilität ..........................................................................83 4.22.1 Identitätsmanagement & Authentifizierung über IDP (B2C, B2B, Mitarbeiter, Partner) .........................................................................................................................83 4.22.1 Authentifizierung .................................................................................................83 4.22.2 Produktkatalog (B2C, B2B, Mitarbeiter, Partner).................................................83 4.22.3 Verlinkung Abo-Shop ..........................................................................................83 4.22.4 Handling Tarifupdate ..........................................................................................83 4.22.5 Bereitstellung Content-Management-System ......................................................83 4.22.6 Verkauf und Transaktion .....................................................................................83 4.22.7 Ticketbereitstellung über alle Kanäle ..................................................................83 4.22.8 User Journey - Design des Kaufprozesses .........................................................83 4.22.9 Bereitstellung Content-Management-System ......................................................83 4.22.10 BI/Analyse ........................................................................................................83 4.22.11 Technologien und Standards ............................................................................83 4.22.12 Best Practices ..................................................................................................83 4.22.13 Weiterentwicklungen.........................................................................................83 4.23 Kundenservice-Ökosystem aus Kunden- und Ticketsystem ......................................84 4.23.1 Integration und Interoperabilität ..........................................................................84 4.23.2 Identitätsmanagement & Authentifizierung über IDP ...........................................84 4.23.3 Verwaltungsoberfläche .......................................................................................84 4.23.4 Zentrale Verwaltung von Kunden- und Fahrscheindaten ....................................84 4.23.5 Ticketsystem ......................................................................................................84 4.23.6 Zusammenspiel beider Systeme (Kundenverwaltung und Ticketsystem) ............84 4.23.7 Übergreifende Funktionen ..................................................................................84 4.23.8 Usability - Intuitive Bedienung und schnelle Informationsfindung ........................84 4.23.9 Plattformfähigkeit ................................................................................................84 4.23.10 BI/Analyse ........................................................................................................84 4.23.11 Technologien und Standards ............................................................................84 4.23.12 Best Practices ..................................................................................................84 4.23.13 Weiterentwicklungen.........................................................................................84 4.24 Reporting & Analyse .................................................................................................85 4.24.1 Interoperabilität und Verarbeitung von Daten aus anderen Systemen der Vertriebslandschaft ........................................................................................................85 4.24.2 Datenformate ......................................................................................................85 4.24.3 Datenaktualisierung ............................................................................................85 4.25 Mandantenfähigkeit (Optional) ..................................................................................85

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 6 von 111

[Seite 7]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.25.1 Zentrale Mandantenverwaltung ..........................................................................85 4.25.2 Mandantenbezogene Konfigurationen ................................................................85 4.25.3 Mandantenspezifisches Reporting und Controlling .............................................85 4.25.4 Mandantenspezifischen Konfiguration von Prozessen und Geschäftsregeln ......85 4.25.5 Mandantenanbindung - Unterstützung unterschiedlicher Betriebs- und Einführungsmodelle .......................................................................................................85 4.25.6 Weiterentwicklung und Zukunftsfähigkeit ............................................................85 4.25.7 Roadmap für die Weiterentwicklung der Software ..............................................85 4.25.8 DevOps-Prozess / DevOps-Setup ......................................................................85 4.25.9 Innovationsfähigkeit - Offenheit gegenüber neuen Trends/Technologien ............85 4.25.10 Partizipation des Auftraggebers ........................................................................85 5. Übergreifende nicht-funktionale Anforderungen & Rahmenbedingungen ............. 86

5.1 Performance, Lastgrenzen & Verfügbarkeit .................................................................86 5.1.1 Laststabilität und Skalierbarkeit bei Großevents ...................................................86 5.1.2 System-Performance und Reaktionszeiten ...........................................................87 5.1.3 Kapazitätssteuerung und Frühwarnsysteme .........................................................87 5.1.4 Verfügbarkeit und Fehlertoleranz ..........................................................................87 5.2 Benutzbarkeit, Responsive Design & Barrierefreiheit ..................................................89 5.2.1 Durchgängige Konsistenz, Systemstatus und mobile Fehlertoleranz ....................89 5.2.2 Responsive & adaptive Darstellung ......................................................................89 5.2.3 Barrierefreiheitsgrundsatz und rechtliche Rahmenbedingungen ...........................90 5.2.4 Spezifische Barrierefreiheitskriterien.....................................................................91 5.2.5 Anforderungen an den Kontrastmodus und den Design-Switch ............................92 5.2.6 Bereitstellung von Inhalten in einfacher oder leichter Sprache ..............................92 5.2.7 Barrierefreie Downloads und Dokumentenstandards ............................................93 5.2.8 Anforderungen an barrierefreie und mobile Formulare .........................................93 5.2.9 Anforderungen an barrierefreie und responsive Tabellen .....................................94 5.2.10 Barrierefreie Medienwiedergabe und Steuerung des Content-Management- System Players .............................................................................................................94 5.2.11 Integrierte Vorlesefunktion (Text-to-Speech) ......................................................94 5.2.12 Videos in Gebärdensprache durch künstliche Intelligenz ....................................95 5.3 Datenschutz (DSGVO) & IT-Sicherheit .......................................................................95 5.3.1 Sicheres Coding und Anwendungssicherheit ........................................................95 5.3.2 Identitäts- und Berechtigungsmanagement...........................................................96 5.3.3 Datenschutzkonformität, Datensparsamkeit und Löschkonzepte ..........................96 5.3.4 Schwachstellenmanagement und Penetrationstests .............................................97 5.4 SEO, GEO & Analytics ................................................................................................97 5.4.1 Technische Suchmaschinenoptimierung und Headless-Architektur ......................97

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 7 von 111

[Seite 8]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

5.4.2 Maschinenlesbarkeit und Optimierung für KI-Systeme..........................................98 5.4.3 Analytics, Tracking und datenschutzkonformes Monitoring ...................................98 6. Datenmigration, Testing & Go-live .......................................................................100 6.1 Migrationskonzept ..................................................................................................... 100 6.1.1 Technische Ausgangslage und Systemanalyse .................................................. 100 6.1.2 Migrationsanforderungen .................................................................................... 100 6.2 Abnahme- & Testverfahren ....................................................................................... 101 6.2.1 Systematische Qualitätssicherung und Teststufen.............................................. 102 6.2.2 Browser- und Geräteübersicht sowie Barrierefreiheitsprüfung ............................ 102 6.2.3 Fehlerklassifizierung und Fehlermanagement .................................................... 103 6.2.4 User Acceptance Testing und formelle Abnahme ............................................... 103 6.3 Rollout- und Go-live-Szenario ................................................................................... 104 6.3.1 Rollout-Planung und Umstellungsvorbereitung ................................................... 104 6.3.2 Durchführung der Systemumstellung .................................................................. 105 6.3.3 Fallback-Strategie und Rollback-Szenario .......................................................... 105 6.3.4 Hypercare-Phase und Stabilisierung................................................................... 105 6.4 Schulung, Dokumentation und Know-how-Transfer .................................................. 106 6.4.1 Zielgruppenspezifisches Schulungskonzept ....................................................... 106 6.4.2 Durchführung und Rahmenbedingungen ............................................................ 106 6.4.3 System- und Betriebsdokumentation .................................................................. 107 7. Betrieb, Support und Wartung nach Go-live ........................................................108 7.1 Service-Level-Agreement .......................................................................................... 108 7.2 Weiterentwicklung und Lifecycle-Management.......................................................... 108 8. Glossar und Begriffsdefinitionen ..........................................................................110

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 8 von 111

[Seite 9]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

1. Einführung

Das vorliegende Dokument beschreibt die im Teilprojekt „Relaunch der Website www.dvb.de zur barrierefreien, geräteübergreifenden Web-Plattform mit nativer App-User-Experience“ (nachfolgend „Teilprojekt“) vom Auftragnehmer zu erbringenden Leistungen. Das Teilprojekt ist ein Bestandteil des Gesamtprojekts zur „Modernisierung der Informations- und Kommuni- kationstechnologien“ (MIKT) für eine nachhaltige Mobilität in Dresden, in dem die DVB ein Maßnahmenbündel zur Stärkung der nachhaltigen Mobilitätssysteme in der Landeshauptstadt Dresden umsetzen. Der Projektablaufplan sieht eine Umsetzung des Gesamtprojekts bis De- zember 2028 vor.

1.1 Inhalt des Gesamtprojekts MIKT

Die qualitative Verbesserung des Öffentlichen Personennahverkehrs (ÖPNV) ist ein wesentli- ches Handlungsfeld zur Erreichung der Klimaschutzziele auf europäischer, nationaler, födera- ler und kommunaler Ebene.

Neben den klassischen Investitionen in ÖPNV-Fahrzeuge und Verkehrsinfrastruktur rücken zunehmend verkehrstelematische Anwendungen der intelligenten Verkehrssysteme in den Vordergrund, welche auf Basis innovativer Technologien eine effiziente, sichere und komfor- tablere Mobilität im Umweltverbund mittels Digitalisierung und Vernetzung ermöglichen.

Mit Fördermitteln der Europäischen Union, des BMDV und des Freistaats Sachsens führt die DVB bereits seit mehreren Jahren schrittweise und zielgerichtet verkehrstelematische Anwen- dungen ein, welche einen signifikanten Beitrag zur Steigerung von Verlässlichkeit, Reisege- schwindigkeit und Energieeffizienz im ÖPNV sowie zur Erhöhung der Qualität und Konsistenz von Fahrgastinformationen leisten (siehe Abbildung 1). Diese Maßnahmen führen bereits zu einer modalen Verkehrsverlagerung zum Umweltverbund, woraus eine deutliche Reduktion der verkehrsbedingten Schadstoffemissionen und bei der DVB eine Rekordnachfrage von über 180 Millionen ÖPNV-Fahrgästen im Jahr 2024 resultiert.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 9 von 111

[Seite 10]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Abbildung 1: Technische Maßnahmen der DVB zur Qualitätsverbesserung im ÖPNV

Die fortschreitende Digitalisierung und Vernetzung zwischen Verkehrsteilnehmenden, Fahr- zeugen, Infrastruktur und Verkehrsleitsystemen ermöglichen zukünftig die Einführung von C- ITS-Anwendungen (Cooperative Intelligent Transportation Systems), welche weitere Potenzi- ale zur Verbesserung der Leistungsfähigkeit und Verlässlichkeit des ÖPNV, zur Steigerung der Qualität individueller, verlässlicher und konsistenter Verkehrsinformationen sowie zur Er- höhung der Verkehrssicherheit erschließen.

Diese Vernetzung im Verkehr stellt allerdings hohe funktionale und qualitative Anforderungen an die Kommunikationstechnik und -infrastruktur der Verkehrsunternehmen. Darüber hinaus erfordert der Einsatz innovativer Technologien auch die Inbetriebnahme neuer Hard- und Soft- warekomponenten in den Fahrzeugen, in der Verkehrstechnik, in den Verkehrsleitsystemen und im allgemeinen Verkehrsdatenmanagement.

Damit die DVB auch zukünftig ökologisch nachhaltige und attraktive Mobilitätsangebote in Ein- klang mit gesetzlichen Vorgaben anbieten kann, ist der Einsatz innovativer Technologien auf allen Ebenen des Verkehrsmanagements erforderlich.

Im Rahmen des Gesamtprojekts werden daher kurz- und mittelfristig wirksame Maßnahmen zur Steigerung der Qualität des ÖPNV und Stärkung der emissionsarmen und kommunalver- träglichen Mobilität umgesetzt, welche vorrangig

a) attraktive Reisezeiten über eine verlässliche ÖPNV-Bevorrechtigung an Lichtsignalan- lagen (LSA) über 2038 hinaus sicherstellen, b) eine hohe Verkehrsdatenverfügbarkeit und -qualität in lokalen und zentralen Systemen des städtischen und interkommunalen Verkehrsmanagements erlauben, c) räumliche ÖPNV-Angebotserweiterungen ermöglichen, d) auf die Verbesserung von Fahrgastinformation im Störungsfall abzielen, e) die Betroffenheit von Fahrgästen in Störfällen reduzieren, f) die Minimierung digitaler Barrieren für Nutzende mit speziellen Bedürfnissen fokussie- ren und g) die Systemresilienz erhöhen.

Des Weiteren werden die technischen Voraussetzungen geschaffen, damit die DVB als Be- treiberin einer kritischen Infrastruktur zukünftig die Hochverfügbarkeit von öffentlichen Ver- kehrsdienstleistungen sicherstellen und gleichzeitig von den mittel- bis langfristigen qualitati- ven Weiterentwicklungen im ÖPNV auf Basis der fortschreitenden Digitalisierung und Ver- kehrsvernetzung partizipieren kann.

1.2 Ausgangssituation für das Teilprojekt

Die Website www.dvb.de bildet die zentrale digitale Schnittstelle in der Kommunikation mit der Kundschaft der DVB. Sie fungiert als primärer Informationsknotenpunkt für Fahrgäste und bün- delt essenzielle Services wie die Verbindungsauskunft mit Echtzeitdaten und Störungsmel- dungen. Die bestehende technische Infrastruktur und Architektur der Website basieren jedoch auf einem technologischen Stand von vor rund zehn Jahren und stellen ein historisch gewach- senes, stark ineinander verwobenes System dar. Diese monolithische und eng gekoppelte Struktur schränkt den Erfolg digitaler Kampagnen massiv ein und stößt zunehmend an ihre technologischen, funktionalen und wirtschaftlichen Grenzen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 10 von 111

[Seite 11]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Ein wesentliches Defizit der aktuellen Ausgangslage ist die ausgeprägte Fragmentierung der digitalen Angebote: Spezialisierte Portale wie die Karrierewelt (karriere.dvb.de), die Mobilitäts- marke MOBI (mobi-dresden.de) und der DVB-Blog bewegt! (blog.dvb.de) müssen als isolierte Einzellösungen betrieben werden. Da zudem die mobile Website (m.dvb.de) sowie die daraus resultierende HybridApp „DVB mobil“ parallel existieren, entstehen für die Nutzenden spürbare Medienbrüche in der User Experience, während auf administrativer Seite ein immenser redak- tioneller Pflegeaufwand durch redundante Datenhaltungen im Tagesgeschäft bewältigt wer- den muss.

Im Bereich des digitalen Vertriebs zeigt sich eine historisch gewachsene, heterogene System- landschaft. Die systemseitige Backend-Infrastruktur verteilt sich aktuell auf mehrere separate Ticketshops, die über unterschiedliche Tarifdatenversorgungen gespeist und von isolierten Ti- cketgeneratoren gestützt werden. Auf der öffentlichen Website selbst ist derzeit kein integrier- ter Ticketshop für den direkten Erwerb von Einzel- und Tageskarten vorhanden. Es existiert lediglich eine Weiterleitung zum Onlineportal „Mein Abo“, über das ausschließlich Zeitkarten verwaltet und erworben werden können. Ein durchgängiger, moderner Buchungsprozess di- rekt aus der Verbindungsauskunft heraus ist somit nicht gegeben. Diese zersplitterte Struktur führt zu einem hohen administrativen Aufwand und schränkt den Nutzungskomfort für die Kundschaft ein.

Darüber hinaus entspricht die jetzige Website nicht den modernen, gesetzlichen Anforderun- gen an die Barrierefreiheit, was eine digitale Barriere für Personen mit Einschränkungen dar- stellt. Technisch wird die Plattform derzeit über ein klassisches On-Premise-Hosting betrieben. Diese Infrastruktur schränkt die notwendige Flexibilität, Skalierbarkeit und Resilienz bei unvor- hergesehenen Lastspitzen stark ein. Um die Plattform zukunftsfähig aufzustellen und tief in das Gesamtprojekt MIKT zu integrieren, wird eine sukzessive Ablösung der betroffenen Alt- systeme sowie eine grundlegende architektonische Entflechtung angestrebt.

1.3 Motivation und Zielstellung für das Teilprojekt

Die Motivation für das umfassende Teilprojekt leitet sich aus der strategischen Notwendigkeit ab, die zentrale digitale Schnittstelle der DVB zu entflechten, grundlegend zu modernisieren und an gesetzliche Vorgaben sowie veränderte Nutzungserwartungen anzupassen. Das Teil- projekt setzt auf eine zukunftsfähige, modulare Systemarchitektur. Durch den angestrebten Einsatz standardisierter Schnittstellen und offener Webstandards wird eine maximale techno- logische Flexibilität und Interoperabilität gewährleistet. Ziel ist eine nachhaltige Plattform, die sich agil an zukünftige Anforderungen anpassen lässt und eine langfristige Unabhängigkeit in der technologischen Weiterentwicklung sichert.

Die im Folgenden skizzierten strategischen Schwerpunkte beschreiben das angestrebte Ziel- bild und stehen exemplarisch für die wesentlichen Fokusbereiche des Vorhabens, ohne den Anspruch auf eine abschließende Aufzählung aller funktionalen Detailziele zu erheben:

1.3.1 Visuelles Erlebnis und Nutzungszentrierung

1. Fokus auf Barrierefreiheit Die lückenlose und rechtssichere Umsetzung der gesetzlichen Vorgaben gemäß BITV 2.0 und WCAG (mindestens Version 2.2, Level AA) steht im Mittelpunkt des Vorhabens. Allen Nutzenden muss ein diskriminierungsfreier, intuitiver und uneingeschränkter Zu- gang zu sämtlichen Informationen und Services gewährt werden. Dies gilt explizit sowohl für die öffentlichen Frontends als auch für die redaktionellen Administrations- und Edito- renoberflächen des zu beschaffenden CMS.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 11 von 111

[Seite 12]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Geräteübergreifende Web-Plattform mit nativer App-User-Experience Das Frontend wird konsequent nach dem Mobile-First-Prinzip konzipiert. Ziel ist eine ge- räteübergreifende Plattform, die auf allen Endgeräten (Desktop, Tablet, Smartphone) per- formant agiert und den Nutzenden das intuitive Look-and-Feel sowie die flüssige Interak- tionsqualität einer nativen Applikation bietet. Dabei soll die etablierte visuelle Identität der DVB im Sinne einer modernen Markenführung gewahrt und ein hoher digitaler Wiederer- kennungswert sichergestellt werden.

3. Nutzungszentrierte Designvalidierung durch begleitende Marktforschung Um ein optimales Nutzungserlebnis, maximale Barrierefreiheit und eine hohe Akzeptanz bei den Nutzenden sicherzustellen, wird in der Konzeptionsphase ein konsequent nut- zungszentrierter Ansatz verfolgt. Ziel ist es, das neu zu entwickelnde visuelle Gestal- tungs- und Layoutkonzept im Rahmen einer begleiteten Marktforschung direkt mit den Zielgruppen zu erproben. Die daraus gewonnenen Erkenntnisse und Rückmeldungen der Testpersonen sollen unmittelbar in die finale funktionale und visuelle Ausgestaltung der Benutzeroberfläche einfließen.

1.3.2 Konsolidierung von Inhalten und Interaktion

1. Konsolidierung und Reduktion des redaktionellen Aufwands Das Zielbild fokussiert die vollständige Auflösung der bisherigen inhaltlichen und techni- schen Fragmentierung. Die ehemals isolierten Satelliten-Portale (Karrierewelt, MOBI- Plattform, DVB-Blog) sowie die mobilen Web-Infrastrukturen sollen in einer einzigen, kon- sistenten Plattform aufgehen. Durch die konsequente Etablierung einer „Single Source of Truth“ wird angestrebt, Medienbrüche für die Nutzenden vollständig zu beseitigen und re- dundante Datenhaltungen auf administrativer Seite aufzuheben, um den täglichen redak- tionellen Aufwand nachhaltig zu minimieren.

2. Zentraler, modularer Content-Hub Unabhängig von der strukturellen Zusammenführung wird die Etablierung eines moder- nen Newsrooms angestrebt, der als zentraler Content-Hub sämtliche Kommunikationska- näle der DVB in einer optisch konsistenten und funktionalen Einheit bündelt. Die Vision ist eine hochflexibel gestaltete Informationsarchitektur, die u. a. klassische Newsmeldun- gen, Pressemitteilungen, politische Kommunikation und Social-Media-Beiträge harmo- nisch nebeneinander abbildet. Dadurch soll sichergestellt werden, dass die unterschiedli- chen Bedürfnisse der verschiedenen Zielgruppen intuitiv, barrierefrei und mit minimalem Suchaufwand abgedeckt werden.

3. Kreative Interaktion durch spielerische Elemente (Gamification) Es wird die punktuelle Integration von spielerischen Ansätzen angestrebt, um die Interak- tion mit den digitalen Medien der DVB zu steigern und komplexe Mobilitätsthemen unter- haltsam sowie niederschwellig zu vermitteln. Das Vorhaben ist bewusst ideen- und tech- nologieoffen gestaltet, um innovative Akzente im digitalen Gesamterlebnis zu setzen.

1.3.3 Funktionale Schwerpunkte und Mobilitätsservices

1. Multimodale Verbindungsauskunft Ein wesentliches Ziel des Teilprojekts ist die Entwicklung einer multimodalen Verbin- dungsauskunft. Neben dem regulären ÖPNV-Angebot sollen alternative Mobilitätsformen flexibel abgebildet werden, um der Kundschaft eine ganzheitliche Reisekette aufzuzei- gen. Die Verbindungsauskunft ist dabei technologisch so vorzubereiten und an Schnitt- stellen anzubinden, dass eine direkte Buchung der jeweiligen Sharing-Angebote ermög- licht wird.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 12 von 111

[Seite 13]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Vollintegrierte Vertriebs- und Servicefunktionalitäten Die strategische Ausrichtung fokussiert eine spürbare Steigerung des digitalen Nutzungs- komforts durch das Zusammenführen von Fahrgastinformation und direktem Ticketkauf. Während das bestehende Onlineportal „Mein Abo“ zur Verwaltung von Zeitkarten weiter- hin als bewährter Absprung erreichbar bleibt, wird für den Erwerb von Einzel- und Tages- karten die direkte Integration eines nutzungsfreundlichen Ticketshops in die Website an- gestrebt. Der neue Ticketshop soll konzeptionell als White-Label-Lösung vorbereitet wer- den, um das Vertriebsmodul zu einem späteren Zeitpunkt flexibel in andere Frontends einbinden zu können. Die nachgelagerte Integration in andere Frontends ist ausdrücklich nicht Bestandteil dieses Teilprojekts. Die Abwicklung aller Kaufprozesse soll dabei naht- los über ein zentrales Identitätsmanagement (Single Sign-On) erfolgen.

3. Zentraler, personalisierter DVB-Account Die strategische Ausrichtung fokussiert die Schaffung eines passwortgeschützten, zent- ralen Benutzerbereichs, der als persönlicher Hub für alle digitalen Interaktionen zwischen den Nutzenden und der DVB fungiert. Ziel ist eine massive Reduktion der Komplexität durch die Bündelung bislang fragmentierter Dienste unter einer einheitlichen, intuitiven Oberfläche. Eingeloggte Fahrgäste sollen hierüber persönliche Profileinstellungen, Favo- riten und Benachrichtigungsservices (z. B. die „Schutzengelfunktion“) geräteübergreifend in Echtzeit synchronisieren sowie ihre vertrieblichen Daten einsehen können. Die techno- logische Grundlage soll über ein sicheres Identitätsmanagement realisiert werden, das höchste Standards an die IT-Sicherheit und die DSGVO-Konformität erfüllt.

1.3.4 Architektur und Infrastruktur

1. Architektonische Entflechtung mittels Headless-Ansatz Die historisch gewachsenen, komplex verwobenen Strukturen werden zielgerichtet auf- gebrochen und entflochten. Durch den verbindlichen Einsatz einer modernen Headless- Architektur wird die Content-Verwaltung strikt vom Frontend entkoppelt. Dies gewährleis- tet eine schlanke, agile Datenstruktur, erleichtert die Systemwartung und sichert eine langfristige technologische Flexibilität.

2. Modernisierung der Hosting-Infrastruktur Als strategische Ausrichtung wird eine Abkehr vom klassischen On-Premise-Hosting an- gestrebt, um den Weg für eine hochverfügbare, ausfallsichere und elastisch skalierbare Hosting-Umgebung zu ebnen, die auch bei extremen Lastspitzen stabil bleibt. Die end- gültige Umsetzung dieses Wechsels steht unter dem Vorbehalt der wirtschaftlichen und technischen Machbarkeit im Rahmen der eingehenden Angebote. Die technologische Ar- chitektur soll daher so flexibel konzipiert werden, dass sie zukunftsfähige Betriebsmo- delle ermöglicht und gleichzeitig harmonisch auf die spezifischen rechtlichen und admi- nistrativen Rahmenbedingungen der Förderinstitutionen angepasst werden kann.

1.4 Zielgruppen und Nutzungskontexte

Die digitale Web-Plattform der DVB bedient eine vielschichtige und diverse Nutzerschaft mit vollkommen unterschiedlichen digitalen Vorkenntnissen, technischen Endgeräten und Erwar- tungshaltungen. Um den in Kapitel 1.3.1 verankerten, nutzungszentrierten Ansatz erfolgreich zu realisieren, muss die Plattform flexibel auf die spezifischen Nutzungssituationen reagieren. Strategisch wird hierbei zwischen vier zentralen Zielgruppen unterschieden:

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 13 von 111

[Seite 14]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

1.4.1 Pendelnde und regelmäßige Kundschaft

Für diese Gruppe steht die Effizienz sowie die zeitliche Verlässlichkeit im Vordergrund, wes- halb der schnelle, barrierefreie Zugriff auf die Verbindungsauskunft, Echtzeitdaten, aktuelle Störungsmeldungen sowie die Verwaltung persönlicher Favoriten direkt über einen personali- sierten DVB-Account im Fokus liegt. Die Plattform muss für diese Nutzenden ein integriertes Mobility-as-a-Service-Erlebnis bieten, das Schnittstellen zu Sharing-Diensten nahtlos bündelt, Echtzeit-Verfügbarkeiten anzeigt und eine transparente Preisanzeige bei verkehrsmittelüber- greifenden Routen gewährleistet. Ein detailliertes Profil dieser digitalaffinen Personengruppe findet sich in Anhang „Persona_Jan_Jederzeit“.

1.4.2 Gelegenheitsfahrende, Besuchende und touristisch Reisende

Diese Gruppe benötigt eine intuitive, niederschwellige Orientierung mit dem Ziel einer einfa- chen verkehrsmittelübergreifenden Routenplanung, verständlichen Tarifinformationen sowie einem unkomplizierten, direkten Ticketkauf ohne langwierige Registrierungsprozesse. Zu den zentralen Anforderungen an das Web-Interface gehören daher die Bereitstellung einer vollum- fänglichen, fehlerfreien englischsprachigen Version sowie eine Point-to-Point-Navigation, die auch ohne Vorkenntnisse des lokalen Liniennetzes sofort verständlich ist. Zur Validierung die- ses Nutzungskontexts wird auf die Ausführungen in Anhang „Persona_George_Tourist“ ver- wiesen.

1.4.3 Personen mit Mobilitäts-, Seh- oder kognitiven Einschränkungen

Für eine uneingeschränkte gesellschaftliche Teilhabe ist diese Gruppe auf die lückenlose Ein- haltung der gesetzlichen Barrierefreiheitsstandards (BITV 2.0 / WCAG 2.2) angewiesen. Das Spektrum reicht von der optimierten Screenreader-Bedienbarkeit für blinde Menschen bis hin zu logischen, leicht verständlichen Bedienabläufen. Neben der Barrierefreiheit im Quellcode sind für die Reiseplanung visuelle und funktionale Hinweise zu Niederflurfahrzeugen, präzise Auslastungsprognosen sowie verlässliche Echtzeit-Meldungen zu Aufzugsstörungen an wich- tigen Umsteigeknoten essenziell. Als valides Fallbeispiel für diese situativen und physischen Einschränkungen dient Anhang „Persona_Thilo_Teilhabe“.

1.4.4 Generationenübergreifende Nutzerschaft

Die Plattform muss sowohl von digital nativen Generationen auf modernsten Smartphones als auch von älteren Menschen auf älteren Endgeräten problemlos bedienbar sein, was eine klare visuelle Hierarchie, ausreichend große Interaktionsflächen und den Verzicht auf überflüssige visuelle Komplexität erfordert. Bei unvorhergesehenen Störungen im Liniennetz müssen akute Fahrplanänderungen ohne tiefe Verschachtelungen so prominent kommuniziert werden, dass auch weniger digitalaffine Personen sofort eine alternative Route finden. Die spezifischen An- forderungen dieser im demografischen Übergang befindlichen Gruppe werden in Anhang „Per- sona_Veronika_Vital“ vertieft.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 14 von 111

[Seite 15]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Projektorganisation

Dieses Kapitel beschreibt den organisatorischen und zeitlichen Rahmen für die Umsetzung der neuen Web-Plattform der DVB. Aufgrund des straffen und anspruchsvollen Zeitplans bis zum geplanten Go-live ist eine effiziente Prozesssteuerung unerlässlich. Um eine terminge- rechte Realisierung und eine reibungslose Zusammenarbeit zwischen der DVB und dem be- auftragten Unternehmen zu gewährleisten, werden nachfolgend die Projektphasen, die Zu- ständigkeiten sowie die zeitkritischen Mitwirkungspflichten definiert.

2.1 Projektphasen und Meilensteine

Die Umsetzung des Teilprojekts gliedert sich ab April 2027 in fünf aufeinander aufbauende Projektphasen. Der April 2027 dient dabei primär dem organisatorischen und technischen Pro- jekt-Setup sowie dem gemeinsamen Kick-off mit dem beauftragten Unternehmen.

Das vorliegende Projekt wird im Rahmen des Förderprogramms EFRE (Europäischer Fonds für regionale Entwicklung) unter Inanspruchnahme von Fördermitteln der EU und des Freistaa- tes Sachsen umgesetzt. Dies bedingt zwingend die termingerechte Realisierung des Projekts. Aufgrund von Vorgaben der Fördermittelgeber und der Regulierungsbehörden ist die Realisierung des Projekts zeitkritisch. Die aktuellen Vorgaben machen einen Projektabschluss zum 30.06.2029 erforderlich.

1. Phase 1 - Spezifikation In dieser dreimonatigen Phase wird das vorliegende Lastenheft durch das beauftragte Unternehmen in enger Abstimmung mit der DVB in ein detailliertes technisches Pflichten- heft überführt. Dies bildet die verbindliche und finale vertragliche Grundlage für alle nach- folgenden Umsetzungsphasen.

Meilenstein - Finale Abnahme des Pflichtenhefts Anfang Juli 2027

2. Phase 2 - Marktforschung, Konzeption & UI-/UX-Gestaltung Diese Phase umfasst die fachliche Konzeption, die Definition der Informationsarchitektur

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 15 von 111

[Seite 16]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

sowie das gesamte UI-/UX-Design. Flankierend dazu setzt ab Mai 2027 die begleitende Marktforschung bzw. Durchführung von Tests ein. Dadurch wird sichergestellt, dass die gestalteten Klickpfade und Layouts direkt mit den Erwartungen der Fahrgäste und Ziel- gruppen abgeglichen und optimiert werden.

Meilenstein - Freigabe der UI-/UX-Designs und des interaktiven Prototyps Anfang No- vember 2027

3. Phase 3 - Technische Entwicklung & Implementierung Die technische Realisierung beinhaltet die Frontend- und Backend-Entwicklung, die barri- erefreie Umsetzung nach BITV 2.0 sowie die Integration aller Kernkomponenten. Um ei- nen nahtlosen technischen Handover zu gewährleisten, startet die Entwicklung bereits im Oktober 2027 parallel zum laufenden Designprozess. Ein integraler Bestandteil ist die CMS-Befüllung und Content-Migration durch die DVB-Redaktion, welche im laufenden System über ein sechsmonatiges Fenster erfolgt.

Meilenstein - Erreichung des „Feature-Complete“-Status

4. Phase 4 - Qualitätssicherung & Testing Diese Phase dient der vollumfänglichen Absicherung der neuen Plattform. Sie startet pa- rallel zur Endphase der Entwicklung mit der allgemeinen Qualitätssicherung inklusive U- ser Acceptance Testing durch die DVB und offiziellen Barrierefreiheits-Audits. Das Ende dieser Phase ist als dedizierter Bugfixing-Sprint reserviert, um alle dokumentierten Rest- fehler und Optimierungen vor dem Launch effizient abzuarbeiten.

Meilenstein - Technische Abnahme der Plattform

5. Phase 5 - Launch & Go-live Nach der erfolgreichen technischen Abnahme erfolgt die finale Rollout-Phase. Diese be- inhaltet die finale Migration aller Daten, das Deployment auf die produktive Infrastruktur sowie notwendige DNS-Umstellungen. Die Phase schließt mit dem offiziellen Go-live ab.

Meilenstein - Offizieller Launch der neuen Web-Plattform

2.2 Projektorganisation und Rahmenbedingungen

2.2.1 Allgemeine Rahmenbedingungen & Projektsprache

Um eine reibungslose Zusammenarbeit und eine rechtssichere Abnahme zu gewährleisten, werden folgende grundlegende Rahmenbedingungen für das Projekt definiert:

1. Projektsprache Die verbindliche Projektsprache für alle Termine, Workshops und Absprachen ist Deutsch.

2. Dokumentation Alle zu erstellenden Dokumente wie das Pflichtenheft, technische Konzepte, API-Doku- mentationen und Schulungsunterlagen sind zwingend in deutscher Sprache zu verfas- sen.

3. System- und Backend-Sprache Das CMS muss im Administrationsbereich vollständig auf Deutsch bedienbar sein, um der DVB-Redaktion eine barrierefreie Pflege zu ermöglichen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 16 von 111

[Seite 17]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4. Ort der Zusammenarbeit und Termine Die Zusammenarbeit erfolgt primär digital über Videokonferenzen und die definierten Kol- laborationswerkzeuge. Für strategisch kritische Termine behält sich die DVB vor, diese als Präsenztermine am Hauptsitz der DVB in Dresden durchzuführen. Die Reisekosten sind vom bietenden Unternehmen in die Gesamtkalkulation einzupreisen.

2.2.2 Erwartete Projektorganisation des beauftragten Unternehmens

Vom bietenden Unternehmen wird die Bereitstellung einer stabilen und kompetenten Projekt- organisation erwartet. Im Angebot sind für die gesamte Projektlaufzeit namentlich feste Per- sonen für folgende Schlüsselrollen zu benennen:

1. Projektleitung Verantwortlich für die operative Steuerung, das Meilenstein-Controlling und das regelmä- ßige Reporting an die DVB.

2. Lead UI-/UX-Design Verantwortlich für die Konzeption, Gestaltung und die Durchführung der Nutzungstests.

3. Technische Leitung/Software-Architektur Verantwortlich für die technische Infrastruktur, die Code-Qualität und die sichere Anbin- dung der Schnittstellen.

4. Lead Qualitätsmanagement & Barrierefreiheit Verantwortlich für die kontinuierliche Qualitätssicherung sowie die strikte Einhaltung der gesetzlichen Vorgaben nach BITV 2.0 in Abstimmung mit den jeweils aktuellen WCAG- Richtlinien.

Hinweis zur Personalkontinuität: Für den gemeinsamen Projekterfolg und eine effiziente Zusammenarbeit ist eine hohe Konstanz innerhalb der Schlüsselrollen von zentraler Bedeu- tung. Vom bietenden Unternehmen wird daher erwartet das Projektteam über die gesamte Laufzeit hinweg so stabil wie möglich zu halten. Sollte ein personeller Wechsel, insbesondere in der Projektleitung, im Ausnahmefall unumgänglich sein, ist die DVB hierüber frühzeitig zu informieren. In diesem Fall stellt das Unternehmen eigenverantwortlich eine gleichwertige Qualifikation der nachfolgenden Personen sowie eine strukturierte und reibungslose Übergabe sicher.

Auf die verbindlichen Regelungen zur Sicherstellung der Personalkontinuität gem. Ziffer 7.2 und 7.3 des Vertrages wird im Zuge dieses Absatzes besonders hingewiesen. Diese sind zwin- gend einzuhalten.

2.2.3 Schnittstelle zur DVB

Auf Seiten der DVB wird für die gesamte Projektlaufzeit in eine operativ-technische und eine kommerzielle Gesamtverantwortung unterteilt, um eine effiziente Projektdurchführung zu ge- währleisten:

1. Projektleitung (technisch & organisatorisch) Fungiert als primäre, bevollmächtigte Schnittstelle und zentrale Ansprechperson für das beauftragte Unternehmen im operativen Projektgeschäft. Sie verantwortet die übergeord- nete Projektsteuerung, die Termin- und Meilensteinplanung sowie die fachliche Freigabe von Systemarchitekturen und technischen Konzepten. Zudem koordiniert sie die Einbin- dung der internen Fachbereiche (u. a. IT, Vertrieb und Redaktion) entsprechend den An- forderungen der jeweiligen Projektphasen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 17 von 111

[Seite 18]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Kommerzielle Projektleitung Zeichnet hauptverantwortlich für sämtliche vertragliche Angelegenheiten, das Nachtrags- management, die Budgetüberwachung sowie die kaufmännischen Abnahmen.

2.3 Kollaboration und Abstimmungsroutinen

Für eine transparente und effiziente Zusammenarbeit im Projektalltag werden feste Kommu- nikationswege und Werkzeuge definiert. Das bietende Unternehmen hat die Aufwände für diese Routinen in die Gesamtkalkulation einzupreisen.

1. Operativer Jour fixe Zwischen den Projektleitungen beider Seiten findet ein regelmäßiger Austausch, z. B. alle 14 Tage virtuell via Videokonferenz, statt. Ziel ist der Abgleich des Projektfortschritts, das Risikomanagement sowie die Klärung offener operativer Fragen.

2. Fachliche Workshops Zu spezifischen Meilensteinen, wie Design-Reviews, Schnittstellen-Architektur und BITV- Audits, werden durch das beauftragte Unternehmen gezielte Fachworkshops mit den je- weils beteiligten Personen der DVB organisiert und moderiert.

3. Projekt-Werkzeuge Die operative Aufgabensteuerung soll über ein gemeinsames, durch das beauftragte Un- ternehmen bereitzustellendes Ticket-System erfolgen. Für die zentrale Dokumentation ist ein kollaboratives Wiki zu nutzen, zu dem das Projektteam der DVB vollumfänglichen Lese- und Schreibzugriff erhält.

2.4 Begleitende Marktforschung, UX-Forschung und Testings

Um ein rundum barrierefreies, mobiles und nutzungszentriertes Gesamtsystem zu garantie- ren, ist die kontinuierliche Einbindung der Endnutzenden ein integraler Bestandteil des Pro- jekts. Der Auftragnehmer ist verpflichtet, eine methodisch fundierte, iterative UX- und Markt- forschung durchzuführen, welche die Konzeptions-, Design- und Freigabephase des Gesamt- systems begleitet. Basis hierfür bilden die Erkenntnisse der DVB-Nullmessung aus dem Jahr 2025.

2.4.1 Ausgangslage & Zielsetzung

Innerhalb des Projektes besteht die grundlegende Anforderung, Design und Funktionalität bar- rierefrei und nutzungsfreundlich zu entwickeln. Die Website ist eine wichtige Informations- quelle für die Kundschaft. 60 Prozent der Kundschaft informieren sich vor der ÖPNV-Nutzung im Internet und 70 Prozent nutzen mobil ihr Smartphone. Tendenzen der digitalen und mobilen Information im ÖPNV sind steigend. Unterwegs nutzen mehr als 60 Prozent die App DVB mo- bil. Nur zehn Prozent greifen bisher unterwegs auf die bestehende Website zu, die nicht responsiv ist.

Der Relaunch der Website www.dvb.de zur barrierefreien, geräteübergreifenden Web-Platt- form mit nativer App-User-Experience zielt maßgeblich darauf ab, die UX zu verbessern und die mobile Nutzung zu optimieren. Dafür wurde bereits eine Online-Befragung durchgeführt, welche die Nutzung, aber auch Einstellungen und Painpoints der Befragten aufzeigte. An- schließend daran ist während der Designphase die UX zu testen, mit dem Ziel, bisherige Pain- points zu beheben, die Nutzungsfreundlichkeit zu erhöhen und Barrierefreiheit herzustellen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 18 von 111

[Seite 19]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Getestet wird dabei die Customer Journey auf der gesamten Website anhand von Prototypen im Designprozess und abschließend die finale Version, ausgegeben über verschiedene End- geräte.

2.4.2 Marktforschung während der Designphase

2.4.2.1 Obligatorisch: UX – Zentrale Funktionen

Ziel der UX-Forschung ist die systematische, iterative Verbesserung der verschiedenen Web- site-Versionen im Verlauf des Design-Prozesses. Die Erkenntnisse dienen als fundierte Grundlage für die nutzungszentrierte Weiterentwicklung hin zur finalen Website.

Die bereits 2025 durchgeführte Befragung der Nutzenden der Website verdeutlichte die fol- genden Handlungsschwerpunkte, welche maßgeblich durch die UX-Forschung betrachtet wer- den sollen:

1. Optimierung der Hauptnutzungsszenarien:

a) Verbindungssuche

b) Informationen bei Störungen

c) Informationen bei Baumaßnahmen

2. Optimierung der mobilen Nutzung

3. Bewahren bewährter Formate und des Wiedererkennungswertes bei gleichzeitiger inhalt- licher und visueller Schärfung und ggf. Neuausrichtung

Das Ergebnis der UX-Forschung soll die Gewährleistung einer reibungslosen User-Journey insgesamt auf der Website und den Weg über diese zu anderen Kanälen der DVB sein. Die Navigation auf der Website allgemein muss auch bei unterschiedlicher Systemkenntnis leicht und intuitiv für Nutzende sein.

Neue Features (z. B. E-Commerce) und die Integration bestehender sekundärer Webseiten der DVB sowie der Absprung zum System Abo-Online sind zu testen. Dafür sind u. a. Test- käufe zu tätigen.

Auch eine Abgrenzung der Website zu anderen Informationskanälen aus Perspektive der Nut- zenden ist zu betrachten, mit dem Ziel, mehr Klarheit in die Informationsmedien der DVB für die Kundschaft zu bringen und diese für die Bewerbung der Web-Plattform nach dem Re- launch zu nutzen.

Die Ergebnisse der UX-Forschung dienen als Grundlage für die Konzeption und Umsetzung des nutzungszentrierten Vorhabens. Das beauftragte Unternehmen (nachfolgend Auftragneh- mer genannt) führt dafür eine umfassende UX-Forschung unter Bezugnahme auf die Erkennt- nisse der bereits durchgeführten Befragung 2025 durch. Die Ergebnisse der Befragung wer- den von der DVB bereitgestellt und können gemeinsam diskutiert werden.

Die folgenden Leistungen werden seitens der DVB vorgeschlagen und sind zu kalkulieren. Diese können vom Auftragnehmer noch mit eigenen Vorstellungen untersetzt und ergänzende Methoden wie bspw. Eye-Tracking u. Ä. dürfen optional empfohlen werden.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 19 von 111

[Seite 20]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

UX-Forschung zur Identifikation tatsächlicher Nutzungsprobleme vor und während der Designphase:

Reale Anwendungsfälle der Testpersonen sind innerhalb der Designphase der Website zu testen. In die UX-Tests der Website sind auch systemfremde Nutzende einzubeziehen, d. h. Personen, die die bisherige Website der DVB nicht kennen, sowie Personen, die bisher nicht im ÖPNV in Dresden unterwegs sind. Überwiegend Einwohnende Dresdens, aber auch ein- zelne Reisende sind einzubeziehen. Auch die Mehrsprachigkeit der Website ist zu testen, so- dass deutsch-, englisch- sowie polnisch-, tschechisch- und spanischsprachige Personen ein- zubeziehen sind. Die Personas Jan Jederzeit, Veronika Vital, Thilo Teilhabe und Georg Tourist im Anhang verdeutlichen die zu beachtenden, unterschiedlichen Bedürfnisse (potenziell) Nut- zender.

Es wird ein persönlicher oder digitaler iterativer Prozess angestrebt. Die Testpersonen testen vor Freigabe das finale Design am Bildschirm über verschiedene Ausgabemedien. Die Test- personen werden zuvor zu geeigneter Zeit im Rahmen eines UX-Tests verschiedener Mockup- Versionen in den Designprozess integriert. Ein Thinking-Aloud-Ansatz ist dabei zu verfolgen, oder es sind andere geeignete Begleitmethoden durch den Auftragnehmer zu beschreiben. Die Tests können Remote oder vor Ort in einem Teststudio durchgeführt werden. Die Ergeb- nisse der Tests werden zur Weiterentwicklung des Designs und zur Schärfung der Nutzungs- freundlichkeit berücksichtigt. Sie sind Grundlage der finalen Freigabe.

Für die kaufmännische Bewertung sind Preise für folgende Optionen anzubieten:

1. Zweifacher UX-Test - Einmal im Designprozess und vor Freigabe: a) Option 1: 10 Stück b) Option 2: 15 Stück c) Option 3: 20 Stück
2. Dreifacher UX-Test - Zweimal im Designprozess und vor Freigabe: a) Option 1: 10 Stück b) Option 2: 15 Stück c) Option 3: 20 Stück

Eine Dokumentation aller identifizierten Barrieren und Usability-Probleme, aufgeschlüsselt nach Alters- und Nutzungsgruppen, sowie eine priorisierte Maßnahmenliste mit Handlungs- empfehlungen ist für den weiteren Designprozess nach jedem Testzyklus abzustimmen und bereitzustellen.

Die Rekrutierung einer angemessenen Anzahl von geeigneten Testpersonen ist durch das beauftragte Dienstleistungsunternehmen sicherzustellen. Die DVB kann bei der Rekrutierung ggf. unterstützen. Dies ist bei Auftragsübernahme abzustimmen. Die Kosten für die Rekrutie- rung sind daher optional aufzuführen.

2.4.2.2 Obligatorisch: UX – Barrierefreiheit

Ziel der UX-Forschung mit Schwerpunkt Barrierefreiheit ist die systematische Identifikation von Nutzungsbarrieren sowie Optimierungspotenzialen der bestehenden Website unter besonde- rer Berücksichtigung der Anforderungen an die digitale Barrierefreiheit.

Die Ergebnisse dienen als Grundlage für die Konzeption und Umsetzung der barrierefreien auf der bereits bestehenden und zeitlich absehbaren rechtlichen Grundlage der Barrierefreie-In- formationstechnik-Verordnung (BITV 2.0). Der Auftragnehmer führt dafür eine umfassende Bestandsanalyse sowie UX-Forschung durch.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 20 von 111

[Seite 21]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Die folgenden Leistungen werden seitens der DVB angedacht und sind zu kalkulieren. Diese können vom Auftragnehmer noch mit eigenen Vorstellungen untersetzt werden; ergänzende Methoden dürfen optional empfohlen werden.

Bestandsanalyse durch systematische Identifikation aller Usability- und Accessibility- Probleme als Grundlage der UX-Forschung:

Identifikation von Barrieren in den Bereichen:

1. Wahrnehmbarkeit (z. B. Kontraste, Alternativtexte)
2. Bedienbarkeit (z. B. Tastatursteuerung, Fokusführung)
3. Verständlichkeit (z. B. Sprache, Struktur)
4. Robustheit (z. B. Kompatibilität mit assistiven Technologien)
5. Bereitstellung einer priorisierten Maßnahmenliste.

Inklusive UX-Forschung zur Barrierefreiheit: Tiefeninterviews sind mit Nutzenden unterschiedlicher assistiver Technologien vor der Design- phase durchzuführen (u. a. Screenreader, Sprachausgabe, kognitive Unterstützungsmittel), um alltägliche Hürden bei der Nutzung der bestehenden Website aufzudecken sowie reale Anwendungsfälle für anschließende UX-Tests aufzunehmen. Die Befragten sind Fahrgäste der DVB und haben mindestens einmal versucht, sich zur DVB und den Verkehrsangeboten zu informieren. Ihnen sind bestehende Barrieren für Menschen mit Behinderungen bewusst und sie können dazu Auskunft geben. Die Persona Thilo Teilhabe im Anhang verdeutlicht die zu beachtenden Anforderungen an barrierefreie Fahrgastinformationen.

Es sind Preise für die folgenden Optionen zu kalkulieren:

1. Barrierefreie Tiefeninterviews je 45 Minuten: a) 10 Stück b) 15 Stück c) 20 Stück
2. Barrierefreie Tiefeninterviews je 60 Minuten: a) 10 Stück b) 15 Stück c) 20 Stück

Die priorisierten, realen Anwendungsfälle der Testpersonen sind innerhalb der Designphase der Website gemeinsam mit den Testpersonen zu testen. Es wird ein iterativer Prozess vor- geschlagen. Die Testpersonen testen in jedem Fall vor Freigabe das finale Design und die Einfache Sprache der Website. Die Testpersonen werden zuvor bereits zu geeigneter Zeit im Rahmen eines UX-Tests von Mockup-Versionen in den Designprozess integriert. Die Ergeb- nisse der Tests werden zur Weiterentwicklung des Designs und der finalen Freigabe berück- sichtigt.

Es sind Preise für die folgenden Optionen anzubieten:

1. Zweifacher UX-Test: Einmal im Designprozess und vor Freigabe a) Option 1: 8 Stück b) Option 2: 10 Stück
2. Dreifacher UX-Test: Zweimal im Designprozess und vor Freigabe a) Option 1: 8 Stück b) Option 2: 10 Stück

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 21 von 111

[Seite 22]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Verbindlicher technischer Barrierefreiheitstest

1. Anforderung Die Methodik für den abschließenden technischen Test ist durch den Auftragnehmer zu empfehlen (z. B. ein zertifizierter, automatisierter und manueller WCAG/BITV-Check).

2. Relevanz Dieser technische Test dient als zwingende Basis für die finale Freigabe und Gesamtab- nahme der Website.

3. Liefergegenstände Eine lückenlose Dokumentation der Testergebnisse sowie die offizielle technische Frei- gabe sind durch den Auftragnehmer zwingend bereitzustellen.

Rekrutierung für den Schwerpunkt Barrierefreiheit: Die Rekrutierung einer angemessenen Anzahl von geeigneten Testpersonen für den Schwer- punkt Barrierefreiheit ist durch das beauftragte Dienstleistungsunternehmen sicherzustellen. Die DVB kann bei der Rekrutierung ggf. unterstützen. Dies ist bei Auftragsübernahme abzu- stimmen. Die Kosten für die Rekrutierung sind daher optional aufzuführen.

2.4.3 Optional: Marktforschung nach Freigabe der neuen Website

2.4.3.1 Einstellungen der Nutzenden gegenüber der Website

Die Einstellungen gegenüber den einzelnen Aspekten der Website sind im Durchschnitt posi- tiv, wie eine Nullmessung im Herbst 2025 gezeigt hat. Maßnahmen sollen darauf abzielen, langfristig Verbesserungen der Einstellungen gegenüber der Website herbeizuführen. Dafür ist eine Nachmessung der Einstellungen gegenüber der Website durchzuführen.

Die Nutzenden empfinden die Informationen, die die Website bietet, derzeit als hilfreich und verlässlich. Begriffe, Texte und Darstellungen werden als verständlich wahrgenommen. Etwas geringer ist die Zustimmung in Bezug auf den Umfang und die Aktualität von Informationen, die Übersichtlichkeit und Struktur, die visuell zeitgemäße Ansprache und die Schnelligkeit bei der Informationssuche.

Die Nachmessung 1 sollte direkt nach Freigabe der neuen Website im Internet erfolgen. Dabei sind die gleichen Items wie bei der Nullmessung zu verwenden. Die Bewertungsskala ist bei- zubehalten. Da die Kundschaft sich an Änderungen erst gewöhnen und die Website kennen- lernen muss, ist eine zweite Nachmessung nach sechs bis zwölf Monaten durchzuführen. Auch die langfristige Wahrnehmung der Website ist zu erfassen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 22 von 111

[Seite 23]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Ich kann mich auf die Informationen auf der… 1,8 Die Website bietet mir Wenn ich auf der alles was ich brauche.2,1 2,2Website etwas suche,…

Auf der Website finde Die Website ist 2 2,1 ich umfangreiche,… übersichtlich und…

Die Informationen au1f,7 2,2Die Website ist visuell der Website sind… ansprechend und… 1,8 Die Begriffe, Texte und 1 = stimme voll und ganz Darstellungen auf der… zu 2 = stimme eher zu 3= teils, teils

Abbildung 2 – Einstellungen gegenüber der Website, Nullmessung 2025

2.4.3.2 Zufriedenheit und Weiterempfehlungsbereitschaft

Zum Zeitpunkt der Nullmessung 2025 lag der Customer Satisfaction Score (CSAT) mit der Website bei 60 Prozent. Ergänzend dazu würden 46 Prozent die Website weiterempfehlen. Der Net Promoter Score (NPS) lag bei 20 Punkten. Maßnahmen sollen darauf abzielen, lang- fristig Verbesserungen der Zufriedenheit und eine Erhöhung der Weiterempfehlungsbereit- schaft herbeizuführen. Dafür ist eine Nachmessung dieser Key Performance Indicators (KPIs) durchzuführen.

Die Nachmessung 1 sollte direkt nach Freigabe der neuen Website im Internet erfolgen. Dabei sind die gleichen Items wie bei der Nullmessung zu verwenden. Die Bewertungsskala ist bei- zubehalten. Da die Kundschaft sich an Änderungen erst gewöhnen und die Website kennen- lernen muss, ist eine zweite Nachmessung nach sechs bis zwölf Monaten durchzuführen.

Auch die langfristige Wahrnehmung der Website ist zu erfassen. Das Item ist dafür standard- mäßig im jährlichen Kundenbarometer inkludiert. Die Zufriedenheit mit der Website lag 2025 bei 47 Prozent (Top-Two) und einem Mittelwert von 2,4 (abweichende Bewertungsskala zur Nullmessung 2025).

2.4.4 Allgemeine Marktforschungsanforderungen

Die Nutzenden unserer Website sind vielfältig. Einen guten Einblick bieten dafür die Personas der DVB im Anhang. Diese Vielfältigkeit ist bei der Auswahl geeigneter Testpersonen zu be- rücksichtigen.

Qualitative Forschungsdesigns im Rahmen des Projektverlaufs müssen Testpersonen mit un- terschiedlichem Nutzungsverhalten hinsichtlich der vorherigen Website, des Internets zur In- formationsbeschaffung sowie des Smartphones einbeziehen.

Es sollen Stammnutzende (DVB- und/oder Website-Nutzung mind. an 3 Tagen pro Woche), Gelegenheitsnutzende (DVB- und/oder Website-Nutzung mind. einmal pro Monat) sowie

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 23 von 111

[Seite 24]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Nichtnutzende berücksichtigt werden. Die Altersverteilung sollte zu vergleichbaren Teilen die Altersgruppen bis 29 Jahre, 30–44 Jahre, 45–59 Jahre bzw. 60 Jahre und älter umfassen.

In optionalen quantitativen Befragungen sind Stichproben so zu wählen, dass repräsentative Ergebnisse nach Altersgruppen und ÖPNV-Nutzungsverhalten vorliegen. Dafür können beste- hende Kennzahlen der DVB sowie der Stadt Dresden zur Gewichtung hinzugezogen werden. Grundsätzlich ist eine geeignete Zusammensetzung der Stichproben/Testpersonen vonseiten des Auftragnehmers vorzuschlagen.

In Bezug auf die oben ausgeführten und zu kalkulierenden Leistungen sind die folgenden Leis- tungen, wenn zutreffend, einzeln auszuweisen:

1. Entwicklung und Abstimmung von Test- und Interviewleitfäden
2. Rekrutierung und Incentivierung der Teilnehmenden
3. Moderation und Aufzeichnung von Tests bzw. Führen der Interviews
4. Auswertung und Berichtslegung (Ergebnisbericht nur in digitaler Form)
5. Studiomiete
6. Reisekosten
7. Optional: Präsentation der Ergebnisse beim Auftraggebenden

Weitere anfallende Kosten sind anzugeben.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 24 von 111

[Seite 25]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

3. Systemarchitektur & technische Infrastruktur

Dieses Kapitel beschreibt die technologische Grundlage der neuen Systemlandschaft. Im Fo- kus steht die Ablösung monolithischer Strukturen durch eine modulare, zukunftssichere und hochgradig vernetzte Architektur, die den Anforderungen an Echtzeit-Datenverarbeitung, digi- talen Vertrieb und ein modernes, plattformunabhängiges Nutzungserlebnis gerecht wird.

3.1 Zielarchitektur

Die Zielarchitektur der neuen digitalen Plattform bricht mit klassischen, monolithischen Ansät- zen und setzt konsequent auf ein modulares Headless-Modell. Das CMS agiert hierbei als Inhaltslieferant, während das Frontend vollständig entkoppelt als eigenständiger Client betrie- ben wird. Die funktionalen Module kommunizieren ausschließlich über standardisierte Pro- grammierschnittstellen.

1. Zentrale, plattformunabhängige Frontend-Basis Das Frontend wird auf Basis moderner, offener Webstandards entwickelt. Die Codebasis ist architektonisch so flexibel zu konzipieren, dass sie einen dualen Bereitstellungsweg ohne parallele Entwicklungsstränge nativ unterstützt:

a) Browserbasierte Nutzung und App-Store-unabhängige Installation: Nutzende können die Anwendung direkt im Webbrowser aufrufen und ohne den Zwang eines App- Stores als anwendungsähnliches Icon auf dem Startbildschirm mobiler Endgeräte oder Desktops hinterlegen.

b) App-Store-Distribution: Die technologische Basis der Frontends muss so aufgebaut sein, dass sie auch für die Veröffentlichung in den gängigen App Stores genutzt wer- den kann. Die Architektur hat die notwendigen Voraussetzungen zu erfüllen, um eine App-Store-konforme Bereitstellung und reibungslose Updates zu gewährleisten.

2. Offline-First-Fähigkeiten und lokale Datenhaltung Das Frontend muss über intelligente, clientseitige Caching- und Speicherungsmechanis- men verfügen. Dadurch ist sicherzustellen, dass kritische Kernbereiche, wie bereits gela- dene digitale Tickets im Onlineshop, persönliche Profildaten oder statische Liniennetz- pläne, auch bei einem temporären Verbindungsabriss einsatzbereit sind.

3. Strikte Logiktrennung Das Frontend ist als reine Darstellungs- und Interaktionsschicht konzipiert. Komplexe Be- rechnungen, dauerhafte Überwachungsprozesse oder datenintensive Verarbeitungen dürfen nicht auf den Endgeräten der Nutzenden stattfinden. Solche Prozesse sind zwin- gend in spezialisierte Hintergrunddienste auszulagern. Das Frontend fragt lediglich die fertigen Zustandsdaten über standardisierte Schnittstellen ab oder übergibt Eingaben an das jeweilige Backend.

4. CMS als reine Inhaltsbasis Das CMS konzentriert sich ausschließlich auf die Verwaltung und strukturierte API-Aus- gabe redaktioneller Inhalte. Es enthält bewusst keine Logik für die Auswertung von Fahr- plandaten, das Kundenmanagement oder Vertriebsprozesse.

5. Modulare E-Commerce-Integration Der neue digitale Onlineshop wird als eigenständiges, mandantenfähiges Vertriebsmodul

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 25 von 111

[Seite 26]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

via API nahtlos in das Frontend eingebunden. Er verknüpft Produktkataloge und Ticket- verkäufe direkt mit der Benutzeroberfläche, agiert datentechnisch jedoch vollkommen un- abhängig vom CMS.

6. Identitäts- und Autorisierungsmanagement Ein zentraler Identitätsprovider übernimmt die Authentifizierung via Single Sign-on für alle Systemmodule. Die Kundschaft erhält über einen zentralen Account einen konsolidierten Zugriff auf alle persönlichen Daten, Abonnements und digitalen Aktivitäten, was als tech- nisches Fundament für zukünftiges Account-based Ticketing und Mobilitätsbudgets dient.

7. Abstraktion der Fahrgastinfrastruktur Für das bietende Unternehmen wird der Umgang mit den ÖPNV-Daten stark vereinfacht. Es muss sich nicht mit komplexen Rohdatenströmen direkt aus dem Fahrbetrieb befas- sen. Diese Daten werden bereits auf vorgelagerten Plattformen gesammelt und aufberei- tet. Das Frontend ruft diese fertigen Datenpakete über zentrale Schnittstellen ab, sodass keine direkte technische Anbindung an die operativen Hintergrundsysteme auf Website- Ebene nötig ist.

3.2 Schnittstellen-Übersicht

Durch den konsequenten Headless-Ansatz sind die Schnittstellen die zentrale Verbindung, über die das Frontend sämtliche Daten mit den Backend-Systemen austauscht. Der Daten- fluss zwischen dem Frontend und den Backend-Systemen ist grundlegend als bidirektionaler Dialog ausgelegt, bei dem Daten sowohl aktiv abgefragt als auch ereignisgesteuert an das Frontend übermittelt werden.

Hinweis zur Vollständigkeit: Die nachfolgende Übersicht beschreibt die architektonischen Kernschnittstellen zur Veranschaulichung der Systemlandschaft. Diese Aufzählung erhebt kei- nen Anspruch auf abschließende Vollständigkeit. Die finale Spezifikation, Detailanalyse und Ausgestaltung aller für den Gesamtbetrieb notwendigen Schnittstellen und Datenstrukturen sind vom beauftragten Unternehmen und der DVB gemeinsam im Rahmen der Konzeptions- phase zu erarbeiten und zu vervollständigen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 26 von 111

[Seite 27]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 27 von 111

[Seite 28]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 28 von 111

[Seite 29]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

3.3 Hosting- und Betriebsumgebung

Für den zuverlässigen, hochverfügbaren und performanten Betrieb der neuen, entkoppelten Plattformarchitektur ist eine moderne und zukunftssichere Hosting-Infrastruktur erforderlich. Da das Frontend und das CMS technologisch getrennt betrieben werden, ergeben sich spezi- fische Anforderungen an die Systembereitstellung, die Laststabilität bei unvorhersehbaren Zu- griffsspitzen sowie die Datensicherheit.

Die Zielarchitektur orientiert sich an einem flexiblen Cloud-First-Ansatz. Dieser stellt sicher, dass das System agil skaliert werden kann, während gleichzeitig eine strikte Hersteller- und Betriebsmodellunabhängigkeit gewahrt bleibt, um sämtlichen Anforderungen, insbesondere in Bezug auf die Fördermittelkonformität sowie auf die Vorgaben des Informationssicherheitsma- nagementsystems (ISMS) der DVB, gerecht zu werden.

3.3.1 Infrastruktur & Bereitstellungsmodell

1. Cloud-First & dynamische Skalierbarkeit Die gesamte Plattform ist für den hochverfügbaren, dynamisch skalierbaren Betrieb in ei- ner modernen Cloud-Infrastruktur zu konzipieren. Der Betrieb auf starren, nicht-elasti- schen On-Premise-Infrastrukturen oder internen Servern ohne automatische Skalierungs- möglichkeit ist explizit ausgeschlossen. Das System muss Lastspitzen bei Großereignis- sen oder Störungslagen automatisch und unterbrechungsfrei ausgleichen können.

2. Technologiestandard & Containerisierung Unabhängig vom finalen Betriebsmodell muss die Anwendungsbereitstellung plattformun- abhängig und entkoppelt auf Basis moderner Container-Standards erfolgen. Dies stellt sicher, dass die Plattform herstellerneutral betrieben, portiert und gewartet werden kann.

3. Betriebsmodell-Flexibilität Um eine optimale Anpassung an künftige Fördermittelrahmenbedingungen (CAPEX vs. OPEX) sowie die IT-Strategie der DVB zu gewährleisten, muss die Systemarchitektur of- fen für unterschiedliche Betriebsmodelle konzipiert sein. Die DVB behält sich vor, im Rahmen der Vergabeentscheidung zwischen folgenden Optionen zu wählen:

a) Option A (Managed Service / SaaS): Der Betrieb der Plattform oder einzelner Sys- temkomponenten (z. B. des Headless CMS) erfolgt als verwalteter Dienst / SaaS durch das bietende Unternehmen oder einen spezialisierten Drittanbieter.

b) Option B (Eigenverantwortlicher Cloud-Betrieb): Bereitstellung und vollautomatisches Deployment aller Systemkomponenten innerhalb einer dedizierten Cloud-Subscrip- tion der DVB.

c) Option C (Hybrides Modell): Betrieb des Headless CMS als SaaS-Lösung bei gleich- zeitigem Betrieb der Anwendungs- und Schnittstellen-Backends in der Cloud-Sub- scription der DVB.

Das bietende Unternehmen hat im Angebot aufzuzeigen, wie die vorgeschlagene Archi- tektur diese Flexibilität unterstützt, und die preislichen Auswirkungen der jeweiligen Mo- delle transparent darzustellen.

4. KRITIS- & Cloud-Compliance Da die DVB als Betreiberin kritischer Infrastrukturen agiert, muss der Einsatz von Cloud- Diensten strengen Sicherheitsrichtlinien genügen. Das bietende Unternehmen muss

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 29 von 111

[Seite 30]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

nachweisen, dass die vorgeschlagene Cloud-Umgebung einschlägig zertifiziert ist (z. B. BSI C5-Zertifizierung/Azure Sovereign Cloud). Jedes Cloud-Konzept ist im Vorfeld zwin- gend mit der IT-Sicherheit der DVB abzustimmen.

3.3.2 Skalierbarkeit, Performance & Redundanz

1. Elastische Skalierung Nutzung von Cloud-Ressourcen zur automatischen Skalierung bei unvorhersehbaren Lastspitzen.

2. Edge-Caching & CDN Verpflichtender Einsatz von Content Delivery Networks (CDN) und Edge-Caching zur glo- balen/regionalen Entlastung der Backend-Systeme und für minimale Ladezeiten im Frontend.

3. Infrastruktur-Redundanz Alle informationsverarbeitenden Einrichtungen, virtuellen Infrastrukturen und Administrati- onswerkzeuge müssen durch geeignete Redundanzen (z. B. hochverfügbare SAN-Lö- sungen) gegen Ausfälle geschützt sein. Die Einhaltung der vertraglich vereinbarten Ver- fügbarkeit ist vom Auftragnehmer regelmäßig zu überwachen und nachzuweisen.

3.3.3 IT-Sicherheit & Datenschutz

1. Souveräne Cloud, Serverstandort Bei der Nutzung von Cloud-Infrastrukturen ist die Datenhaltung zwingend auf Deutsch- land oder die Europäische Union (EU) zu beschränken.

2. Strikte Umgebungstrennung Es ist eine konsequente logische und physische Trennung zwischen Entwicklungs-, Prüf- und Produktionsumgebungen zu gewährleisten. Test- und Entwicklungsumgebungen dürfen nicht auf denselben Virtualisierungsservern betrieben werden wie produktive Sys- teme. In der Testumgebung dürfen grundsätzlich keine echten Produktionsdaten verwen- det werden.

3. Sicherheitsstandards Einhaltung der BSI-Grundschutz-Empfehlungen für Cloud-Dienste sowie durchgängige Transportverschlüsselung (TLS 1.3) aller internen und externen Datenströme.

3.3.4 DevOps, Wartung & Monitoring

1. System-Deployment Einrichtung von CI/CD-Pipelines für unterbrechungsfreie Zero-Downtime-Updates direkt in die Cloud-Umgebung.

2. Zentrales Monitoring & Logging Integration eines einheitlichen IT-Monitorings zur proaktiven Überwachung aller relevan- ten Systemkomponenten inklusive automatischer Alarmierung bei Schwellenwertüber- schreitungen. Administrative Ereignisse, Bedienhandlungen und sicherheitsrelevante

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 30 von 111

[Seite 31]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Vorfälle müssen dauerhaft und manipulationsgeschützt protokolliert werden. Die Platt- form muss die technische Möglichkeit bieten, diese Logs an eine zentrale Protokollie- rungsinfrastruktur (z. B. SIEM/SOC des Auftraggebers) weiterzuleiten.

3. Uhrzeitsynchronisation Die Systemzeit aller protokollierenden und verwalteten Komponenten der IT-Infrastruktur muss zwingend synchron laufen. Der Liefergegenstand muss die Möglichkeit bieten, sich über alle Standorte hinweg mit einem zentralen Zeitserver zu synchronisieren, um ein- heitliche Datums- und Zeitformate in den Protokollen zu garantieren.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 31 von 111

[Seite 32]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4. Übergreifende funktionale und strategische Anforderungen

Sämtliche nachfolgend beschriebenen technischen und funktionalen Anforderungen dienen der informationstechnischen Realisierung des strategischen Zielbildes der DVB. Die verbind- liche inhaltliche, fachliche und gestalterische Grundlage für ausgewählte Module bildet das Dokument „Konzeptanforderungen“ (siehe Anhang konzeptanforderungen.pdf).

Das beauftragte Unternehmen hat bei der Umsetzung aller funktionalen Anforderungen zwin- gend die dort definierten Fokusbereiche architektonisch und konzeptionell zu berücksichtigen. Eventuelle Widersprüche zwischen der technischen Umsetzung und den strategischen Vorga- ben der Anlage konzeptanforderungen.pdf sind im Rahmen der vorgelagerten Konzeptions- phase proaktiv durch das beauftragte Unternehmen aufzudecken und aufzulösen.

4.1 Design, UX/UI-Vorgaben und Frontend-Prinzipien

Die Anforderungen in diesem Kapitel gelten vollumfänglich für alle im Rahmen dieser Aus- schreibung neu zu entwickelnden Systeme, Module, Anwendungen und deren Benutzerober- flächen. Die gesamte visuelle und interaktive Gestaltung muss dem Corporate Design der DVB entsprechen.

Für integrierte Drittanwendungen, Widgets oder externe Subsysteme, auf deren technische Architektur und Quellcode das beauftragte Unternehmen keinen direkten Einfluss hat, gilt die gestalterische Vorgabe im Rahmen der technischen Konfigurationsmöglichkeiten des jeweili- gen Drittsystems. Das beauftragte Unternehmen hat hierbei eine bestmögliche optische An- gleichung an das DVB-Corporate-Design sowie die Gewährleistung einer barrierefreien In- tegration anzustreben.

Als verbindliche grafische Grundlage für die Identitätsmerkmale gilt das aktuelle Corporate- Design-Faktenblatt siehe Anhang „DVB_CD-Faktenblatt“ (Stand: Februar 2019).

Da dieses Faktenblatt primär analoge Grundelemente definiert, hat das beauftragte Unterneh- men den notwendigen kreativen und konzeptionellen Gestaltungsspielraum, um diese Vorga- ben in eine moderne, weboptimierte und funktionale digitale UX zu überführen. Diese ist der DVB zur Freigabe vorzulegen und hat nach folgenden Prinzipien zu erfolgen:

4.1.1 Kernvorgaben des Corporate Designs (Faktenblatt)

1. Logo-Verwendung Das offizielle DVB-Logo ist unverändert zu nutzen. Der definierte Mindestschutzraum ist im Layout einzuhalten. Das Logo darf nicht in Sonderformen oder künstlichen Rahmen platziert werden. Bei der Platzierung auf Fotos oder farbigen Hintergründen sind aus- schließlich die Logofarbe Gelb, Schwarz oder Weiß zulässig, wobei stets ein normge- rechtes Kontrastverhältnis zu gewährleisten ist.

2. Primärfarben Die visuelle Identität baut auf den Primärfarben der DVB auf:

a) DVB-Gelb: Hex-Farbwert #FFCC00 (RGB 255 | 204 | 0)

b) DVB-Schwarz: Hex-Farbwert #000000 (RGB 0 | 10 | 0 / verkehrsschwarz)

3. Typografie Die technische Architektur der Plattform muss so flexibel konzipiert sein, dass globale

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 32 von 111

[Seite 33]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

WebFonts ohne strukturellen Programmieraufwand ausgetauscht oder angepasst werden können. Zum Zeitpunkt der Ausschreibung gilt die Helvetica Neue als primäre Hausschrift der DVB. Die visuelle Ausarbeitung hat so zu erfolgen, dass eine etwaige Änderung oder Neudefinition der Hausschrift im Projektverlauf systemseitig problemlos, flexibel und lay- outkonform übernommen werden kann. Um eine optimale digitale Performance und Li- zenzsicherheit im Web zu garantieren, ist die Nutzung von weboptimierten äquivalenten Systemschriftart-Fallbacks im Frontend-Code in Abstimmung mit der DVB zulässig.

4.1.2 Digitales Design-System und Token-Architektur

1. Zentrales Design-System und gemeinsame Arbeitsumgebung Alle UI-Elemente, Layouts und Seitentypen sind in einem erweiterbaren Design-System zu verwalten. Die Design-Architektur soll vorzugsweise konsequent auf Design Tokens oder einem nachweislich gleichwertigen, industriestandardisierten Ansatz zur zentralen Variablensteuerung basieren. Um eine kontinuierliche, partnerschaftliche Zusammenar- beit zwischen der DVB und dem beauftragten Unternehmen auch über den Go-live hin- aus zu gewährleisten, kann die Bereitstellung der Arbeitsumgebung flexibel entweder auf der Infrastruktur des beauftragten Unternehmens oder direkt bei der DVB erfolgen. Das System ist so aufzusetzen, dass die DVB entweder von Beginn an als Inhaberin der pri- mären Arbeitsumgebung agiert oder eine vollständige, struktur- und verlustfreie Übertra- gung der gesamten Design-Umgebung auf eine eigene Arbeitsumgebung der DVB zu je- dem Zeitpunkt technisch und rechtlich garantiert ist. Sämtliche Eigentums-, Urheber- und uneingeschränkten Nutzungsrechte an den Arbeitsergebnissen gehen spätestens mit der Bereitstellung bzw. Abnahme vollständig, ohne zeitliche Beschränkung und exklusiv auf die DVB über. Eine flexible, gemeinsame Nutzung sowie eine uneingeschränkte interne Weiternutzung und Weiterentwicklung muss möglich sein.

2. Modulare, komponentenbasierte Gestaltung In enger Verzahnung mit den CMS-Anforderungen an ein flexibles Komponenten-Layout müssen alle UI-Elemente als in sich geschlossene, wiederverwendbare Design-Bau- steine nach einem strukturierten, modularen Prinzip entwickelt werden. Das visuelle De- sign muss garantieren, dass diese Elemente in der redaktionellen Praxis flexibel mitei- nander kombiniert werden können, ohne das Gesamtlayout oder die visuelle Hierarchie der jeweiligen Seite zu brechen.

4.1.3 Flexible Anzeige-Modi

1. Unterstützung von Light- und Darkmode Die Plattform muss sowohl in einer hellen Darstellung (Lightmode) als auch in einer dunklen Darstellung (Darkmode) bereitgestellt werden. Alle UI-Komponenten, Farb-To- kens und Layout-Templates sind im Design-System (in der Design-Arbeitsumgebung so- wie im Frontend-Code) für beide Modi vollständig auszuarbeiten. In beiden Darstellungs- modi ist die Einhaltung normgerechter Kontrastverhältnisse gemäß den Barrierefreiheits- anforderungen in Kapitel 5.2 zwingend zu gewährleisten. Die funktionale Umschaltung des Darstellungsmodus erfolgt zentral im globalen Header gemäß Kapitel 4.3.2.

4.1.4 Konzeptionelle Gestaltungs- und Interaktionsprinzipien

1. Mobile-First-Ansatz Da die Plattform primär mobil im ÖPNV-Kontext genutzt wird, hat die gestalterische Kon- zeption der UI/UX konsequent nach dem Mobile-First-Ansatz zu erfolgen. Für alle zentra- len Inhaltstypen und Fachmodule sind primär mobile Layouts zu entwerfen, bevor die Skalierung auf größere Viewports erfolgt. Die intuitive Bedienbarkeit per Touch-Gesten ist im Design bereits über ausreichende Klickflächen, gemäß den Kriterien in Kapitel 5.2.4, sicherzustellen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 33 von 111

[Seite 34]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Berücksichtigung der Barrierefreiheit im Design Das visuelle Design muss die technischen und rechtlichen Anforderungen an die Barrie- refreiheit aus Kapitel 5.2 bereits auf Layoutebene zwingend vorbereiten. Dies umfasst insbesondere die Einhaltung normgerechter Kontrastverhältnisse bei der Farbwahl, ge- mäß Kapitel 5.2.4, und die gestalterische Definition von deutlichen Fokus-Zuständen für die Tastaturnavigation.

3. Vollständiges Zustandsdesign Für alle interaktiven Elemente, Schaltflächen und Formulare sind sämtliche im Projekt- verlauf erforderlichen Bedien- und Systemzustände, inklusive der Lade- und Fehlersze- narien, visuell in den Designdateien auszuarbeiten. Das Design hat damit alle funktiona- len Varianten so vollständig abzubilden, dass eine lückenlose und fehlerfreie technische Umsetzung gemäß den Anforderungen in Kapitel 5.2.1 und 5.2.8 direkt möglich ist.

4.2 Übergreifende Anforderungen Content-Management-System (CMS)

Das einzuführende Content-Management-System (CMS) dient als zentrale technologische Basis für alle redaktionellen Prozesse der Plattform. Das System muss modular aufgebaut sein und den Redaktionsalltag durch Automatisierungen und Schnittstellen optimal unterstüt- zen, ohne eine spezifische technische Architektur des Anbieters zwingend vorzugeben.

4.2.1 Redaktionsworkflow und Redaktionsumgebung

Für die Ausgestaltung der Redaktionsumgebung und zur Gewährleistung effizienter, abtei- lungsübergreifender Arbeitsabläufe muss die angebotene Lösung folgende funktionale Krite- rien erfüllen:

1. Rollen- und Rechtemanagement Das System muss ein feingranulares, mandantenfähiges Rollen- und Rechtesystem be- reitstellen, um Redaktionsmitarbeitenden exakt jene Inhaltsbereiche und Funktionen zu- zuweisen, für die sie eine fachliche Freigabe besitzen.

2. Onboarding-Unterstützung bei seltener Systemnutzung Um Personen, die das System selten nutzen, das fehlerfreie Anlegen von Inhalten zu er- leichtern, soll das Backend über konfigurierbare Inhalts-Templates, geführte Workflows sowie kontextsensitive Hilfetexte in deutscher Sprache verfügen.

3. Flexibles Komponenten-Layout Die Erstellung von Inhaltsseiten sowie temporären Kampagnen- und Landingpages muss über ein flexibles System aus wiederverwendbaren, in sich geschlossenen Inhaltskompo- nenten erfolgen. Redaktionsmitarbeitende müssen in der Lage sein, diese Komponenten pro Seite frei auszuwählen, in beliebiger Reihenfolge modular miteinander zu kombinie- ren und bestehende Elemente flexibel im Backend zu verschieben. Das System muss diese strukturelle Reihenfolge strikt als strukturierte Daten an das Frontend übergeben, welches die visuelle und responsive Darstellung der Komponenten übernimmt.

4. API-basierte Echtzeit-Vorschau Da Backend und Frontend technologisch entkoppelt sind, muss das CMS eine dedizierte Vorschau-Schnittstelle bereitstellen. Das System muss es ermöglichen, für verschiedene Inhaltstypen dynamische Vorschau-URLs zu konfigurieren, die bei Aktivierung durch die Redaktion einen sicheren Authentifizierungs-Token sowie die Inhalts-ID an das externe Frontend übergeben. Das System muss sicherstellen, dass die Redaktion so eine präzise visuelle Live-Vorschau von unveröffentlichten Entwurfsständen direkt aus dem Backend

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 34 von 111

[Seite 35]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

heraus aufrufen können. Diese Vorschau-Links müssen optional mit einem temporären Token versehen werden können, damit sie auch von externen Stakeholdern ohne CMS- Benutzerkonto aufgerufen und gegengelesen werden können.

5. Zeitgesteuerte Veröffentlichung und Archivierung Das System muss für sämtliche Dateien sowie Inhaltsseiten insbesondere für News, Pressemitteilungen und Baumaßnahmen eine minutengenaue Terminierung für die Ver- öffentlichung sowie für die automatisierte Depublikation bzw. Archivierung bereitstellen. Das API-Framework muss sicherstellen, dass abgelaufene Inhalte ohne manuellen Ein- griff sofort aus den produktiven Endpunkten entfernt werden.

6. Versionierung, Audit-Trail und Rollback-Funktionalität Alle Änderungen an Inhalten und Datenstrukturen müssen lückenlos historisiert werden. Das System muss einen Audit-Trail bereitstellen, der nachvollziehbar macht, welcher Mit- arbeitende zu welchem Zeitpunkt Änderungen vorgenommen hat. Redaktionsmitarbei- tende müssen in der Lage sein, ältere Inhaltsversionen im Backend einzusehen und per „Knopfdruck“ vollständig wiederherzustellen.

7. Strukturiertes und barrierefreies Tabellen-Modul Um komplexe Daten wie Tarifstrukturen oder Taktzeiten darzustellen, muss das System eine strukturierte Tabellenerfassung bereitstellen. Das Modul darf kein unstrukturiertes Freiform-HTML erlauben, sondern muss Daten zeilen- und spaltenweise als reines JSON-Array speichern. Es muss redaktionell zwingend die Definition von Kopfzeilen und Barrierefreiheits-Metadaten einfordern, damit das Frontend die Tabellen sowohl für Scre- enreader optimiert als auch vollumfänglich responsiv rendern kann.

8. Headless-konforme Video- und Streaming-Komponente Für die Einbindung von Bewegtbildmedien (z. B. Erklärvideos „So geht MOBI“) muss das System ein dediziertes Datenmodell bereitstellen. Dieses muss sowohl die Verknüpfung externer Streaming-Plattformen (z. B. YouTube, Vimeo) über reine ID-Felder als auch die Hinterlegung lokaler, barrierefreier Zusatzressourcen, wie z. B. VTT-Dateien für Untertitel und Audiodeskriptionen unterstützen. Die API muss diese Daten so bereitstellen, dass das Frontend Videos datenschutzkonform ausspielen kann.

4.2.2 Digital-Asset-Management und Bildverarbeitung

Die Verwaltung und Verarbeitung von Medienressourcen innerhalb des CMS muss medien- bruchfrei und automatisiert erfolgen, wofür das System die folgenden Funktionen bereitzustel- len hat:

1. Direkte Schnittstelle zur zentralen Mediendatenbank Das System muss über eine standardisierte Schnittstelle vollständig an die zentrale Me- diendatenbank Canto angebunden werden. Redaktionsmitarbeitende müssen Medienres- sourcen direkt aus der CMS-Bearbeitungsmaske suchen, auswählen und ohne lokalen Zwischen-Download einbinden können. Durch die standardisierte Schnittstelle soll sicher- gestellt werden, dass der zukünftige Wechsel der Mediendatenbank flexibel umgesetzt werden kann.

2. Automatisiertes Metadaten-Mapping für Barrierefreiheit Bei der Übernahme eines Mediums aus der Mediendatenbank müssen die dort hinterleg- ten Metadaten, wie Alternativtexte und Bildbeschreibungen, automatisch ausgelesen und über die API bereitgestellt werden, um Suchmaschinenoptimierung und Barrierefreiheit systemseitig abzusichern.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 35 von 111

[Seite 36]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

3. Intelligente und automatisierte Bildanpassung Medienressourcen müssen von der Redaktion nur einmal im Original bereitgestellt wer- den. Das System muss die automatische Skalierung, Komprimierung und Konvertierung in moderne, performante Web-Formate für alle im Frontend benötigten responsiven Aus- gabegrößen übernehmen und über die API passend anbieten.

4. Definition eines visuellen Bildfokus Die Bildverarbeitungskomponente muss es der Redaktion erlauben, einen visuellen Fo- kuspunkt auf dem Originalbild zu definieren. Das System muss technisch sicherstellen, dass dieser Kernbereich bei automatischen Bildbeschneidungen auf mobilen Endgeräten im Frontend niemals weggeschnitten wird.

5. Integrierte Medienbearbeitung im Backend Für schnelle Korrekturen direkt in der Bearbeitungsmaske muss das System grundle- gende Bearbeitungswerkzeuge wie Zuschneiden, Schärfen oder einfache Farbkorrektu- ren nativ bereitstellen.

6. Sicherheits-Validierung für Vektorgrafiken Beim Upload von Vektorgrafiken, beispielsweise für Liniennetz-Icons oder Piktogramme, muss das System einen automatisierten Sicherheits-Scan durchführen. Potenziell schäd- liche Skripte innerhalb der XML-Struktur der SVG-Datei müssen systemseitig isoliert und unschädlich gemacht werden, bevor die Datei über die API bereitgestellt wird.

7. Modul für visuelle Kennzeichnungen Das System muss ein Modul bereitstellen, um definierte Piktogramme oder kleine Grafi- ken als ergänzende Kennzeichnung flexibel mit hochgeladenen Medienressourcen zu verknüpfen, beispielsweise zur Signalisierung von Projekt- oder Inhaltsstati.

a) Zentrale Verwaltung: Die zugehörigen Grafiken und Piktogramme müssen zentral im System verwaltet und gepflegt werden können.

b) Redaktionelle Platzierung: Redaktionsmitarbeitende müssen das gewünschte Ele- ment im Editor auswählen und dessen relative Positionierung auf dem Hauptmedium (z. B. oben rechts, mittig) über eine einfache Auswahlmaske bestimmen können.

4.2.3 KI-gestützte Mehrsprachigkeit und Sprachvarianten

Um eine internationale, barrierefreie und zielgruppenspezifische Ansprache der Fahrgäste si- cherzustellen, muss das System über ein flexibles Mehrsprachigkeitskonzept verfügen, das folgende Kriterien erfüllt:

1. Hybride Umsetzung von Mehrsprachigkeit Das System muss ein hybrides Konzept unterstützen, das sowohl die statische, redaktio- nelle Pflege strategisch wichtiger Hauptsprachen im Backend als auch die dynamische, automatisierte Übersetzung über externe Übersetzungsschnittstellen für das erweiterte Sprachangebot ermöglicht. Die deutsche und englische Sprachversion sind als feste, re- daktionell gepflegte Sprachen vorzusehen.

2. KI-gestützte schnittstellenbasierte Übersetzungsprozesse Zur effizienten Pflege der Hauptsprachen muss das CMS über eine integrierte Schnitt- stelle zu professionellen Übersetzungs-Diensten verfügen. Redaktionsmitarbeitende müssen in der Lage sein, automatisierte Übersetzungen direkt im CMS-Backend zu ge- nerieren, diese manuell zu korrigieren und freizugeben.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 36 von 111

[Seite 37]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

3. Architektur für dynamische Frontend-Übersetzung Die Bereitstellung der Inhaltsdaten über die API muss so strukturiert und semantisch sau- ber erfolgen, dass das Frontend externe KI-Übersetzungsmodelle integrieren kann, um nicht statisch gepflegte Sprachen für Nutzende in Echtzeit und ohne Layout-Verzerrun- gen direkt im Browser zu übersetzen.

4. Bereitstellung sprachlich vereinfachter Inhaltsversionen Ergänzend zu den Fremdsprachen muss das System die Pflege und systemseitige Zu- ordnung von Textversionen in einfacher oder leichter Sprache unterstützen, wobei die Generierung dieser Texte durch die Anbindung eines automatisierten Textassistenzsys- tems unterstützt werden soll.

4.2.4 URL-, Weiterleitungs- und Shortlink-Management

Für die Durchführung von Marketingmaßnahmen sowie für die nahtlose Migration bestehender Plattformen und Subdomains, wie blog.dvb.de, mobi-dresden.de und karriere.dvb.de, ist ein zentrales Steuerungswerkzeug für URLs erforderlich, welches folgende Anforderungen abbil- det:

1. Erstellung von sprechenden URLs und Alias Das System muss beim Erstellen einer Inhaltsseite automatisch eine lesbare, suchma- schinenoptimierte URL-Struktur generieren. Redaktionsmitarbeitende müssen in der Lage sein, diese URL manuell anzupassen oder zusätzliche Alias für dieselbe Ressource zu definieren, ohne dass identischer Inhalt entsteht.

2. Zentrales Weiterleitungsmanagement im Backend Zur Vermeidung von fehlerhaften Aufrufen (404-Fehlern) nach Inhaltsstrukturänderungen oder Systemmigrationen muss das System ein zentrales Werkzeug zur Einrichtung von dauerhaften (301) und temporären (302) Weiterleitungen bereitstellen.

3. Generierung und Verwaltung von Shortlinks Die Redaktion muss zum Beispiel für Kampagnen oder gedruckte Informationsmateria- lien kurze, einprägsame URLs definieren können, die intern flexibel auf tiefer liegende In- haltsdaten oder Module der Plattform verweisen. Diese URLs müssen mit dem von der DVB verwendeten Analyse-Tool Matomo getrackt werden können.

4.2.5 Flexibles Formular- und Datenstruktur-Management

Um der Redaktion die Möglichkeit zu geben, eigenständig Kontaktformulare, Feedback-Abfra- gen oder einfache Registrierungsmasken zu erstellen, muss das System folgende Kriterien erfüllen:

1. Struktureller Formular-Konfigurator Das System muss ein Werkzeug bereitstellen, mit dem die Redaktion Formularfelder fle- xibel definieren, als Pflicht- oder Freiwilligenfeld markieren und in ihrer Reihenfolge an- ordnen können.

2. Datenbasierte Bereitstellung Das System darf für diese Formulare keinen fertigen HTML-Code generieren. Stattdes- sen muss die Formularstruktur als rein maschinenlesbare Beschreibung über die API be- reitgestellt werden. Das Frontend übernimmt die visuelle, barrierefreie Darstellung und das Styling.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 37 von 111

[Seite 38]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

3. Sichere API-gestützte Datenrückführung Wenn ein Nutzer im Frontend ein Formular absendet, müssen die Daten über eine si- chere API-Schnittstelle an das Backend, oder einen dafür definierten Drittdienst, übertra- gen, dort verschlüsselt gespeichert und für die Redaktion im System zugänglich gemacht werden.

4. API-basierter Spam-Schutz Das Formular- und API-System muss Mechanismen zur automatisierten Spam-Abwehr, z. B. per Honeypot-Verfahren oder über eine rein API-gestützte Validierung von Sicher- heits-Tokens, unterstützen. Die Einbindung darf nicht auf dem Injizieren von fertigem Frontend-Code basieren, sondern muss rein logisch über die Schnittstelle erfolgen.

5. DSGVO-konformes Daten- und Löschmanagement: Für alle über Formulare erfassten personenbezogenen Daten muss das Backend admi- nistrative Werkzeuge bereitstellen. Dazu gehören konfigurierbare, automatisierte Lösch- fristen sowie eine Exportfunktion für die Redaktion in Standardformaten (CSV/XLSX) zur internen Weiterverarbeitung unter Einhaltung des Datenschutzes.

4.2.6 Systemumgebungen, Qualitätssicherung und Staging

Zur Gewährleistung eines sicheren und fehlerfreien Betriebs im redaktionellen Alltag muss die Systemarchitektur folgende prozessuale Anforderungen unterstützen:

1. Mehrstufige Systemumgebung Es muss eine strikte Trennung zwischen einer produktiven Live-Umgebung und mindes- tens einer davon entkoppelten Test- bzw. Qualitätssicherungs-Umgebung gegeben sein. Redaktionsmitarbeitende müssen neue Inhaltsstrukturen, größere Textänderungen oder komplexe Baukasten-Komponenten gefahrlos auf der Testumgebung erproben können.

2. Synchronisation von Datenstrukturen Das System muss Mechanismen unterstützen, um neu definierte Datenmodelle, Inhalts- typen oder globale Konfigurationen kontrolliert und konsistent von der Testumgebung auf die Live-Umgebung zu übertragen, ohne dass es zu Datenverlusten oder Systemausfäl- len kommt.

3. Abwärtskompatibilität und API-Versionierung Bei der Übertragung von strukturellen Änderungen vom Staging- auf das Live-System muss das CMS eine strikte Versionierung der API unterstützen. Es muss technisch aus- geschlossen sein, dass eine Änderung im Backend das aktuell produktive Frontend un- brauchbar macht oder zu Systemabstürzen führt, solange das Frontend nicht explizit an die neue API-Version angepasst wurde.

4.2.7 Globale Plattform-Konfiguration, Feedback-Engine & Echtzeit-Daten

Um übergreifende Funktionen und Drittsysteme zentral steuern zu können, ohne Codeände- rungen am Frontend vornehmen zu müssen, hat das CMS folgende Integrationsdatenmodelle bereitzustellen:

1. Eilmeldungs-Modul/Live-Ticker Für hochpriorisierte Krisenkommunikation, wie sie z. B. im Fall von Bombenfunden erfor- derlich wird, muss ein Inhaltsmodul existieren. Sobald eine Eilmeldung aktiviert wird, muss das System diese Daten per Echtzeit-Schnittstelle verzögerungsfrei an das Front- end pushen, damit dieses sofort einen globalen Live-Ticker oder Warnhinweis einblenden kann, ohne das CMS durch permanente Anfragen der Nutzenden zu belasten.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 38 von 111

[Seite 39]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Konfigurierbares Feedback- und Bewertungssystem Das CMS muss Datenstrukturen bereitstellen, um die Logik des plattformweiten Feed- back-Tools zu steuern. Die Redaktion muss im Backend konfigurieren können, an wel- chen Triggerpunkten im Frontend, z. B. nach einem erfolgreichen Ticketkauf, innerhalb der Verbindungsauskunft oder nach dem Aufruf bestimmter FAQ-Bereiche, Feedback- Abfragen ausgespielt werden. Diese Konfigurationsdaten müssen als strukturiertes JSON an das Frontend übergeben werden, welches die Logik z. B. als In-App-Feedback oder Weiterleitung zu Store-Bewertungen autonom ausführt.

3. Zentrale Drittdienst- und Asset-Token-Verwaltung Zur Einbindung globaler Services, wie des Chatbot-Assistenten oder von Social-Media- Walls, darf kein JavaScript-Code im CMS-Editor hinterlegt werden. Das CMS muss statt- dessen dedizierte Konfigurationsfelder bereitstellen, in denen die Redaktion API-Schlüs- sel, Service-IDs oder vergleichbares hinterlegen. Das Frontend liest diese Felder aus und initialisiert die Dienste datenschutzkonform.

4.2.8 Redaktionelle Suchmaschinen- und Antwort-Optimierung (SEO-, GEO- & AEO- Werkzeuge)

Um die Sichtbarkeit der DVB sowohl in klassischen Suchmaschinen als auch in KI-basierten Antwort-Infrastrukturen nachhaltig zu sichern, muss das System höchsten technologischen Standards entsprechen:

1. SEO-Pflegemaske Bereitstellung dedizierter Eingabefelder bzw. Steuerungselementen pro Seite und In- haltstyp für Title-Tags, Meta-Descriptions, Open-Graph-Tags, Canonical-Tags sowie Ro- bots-Meta-Tags.

2. Redaktionelle Hilfesysteme Echtzeit-Zeichenzählung und optische Warnungen bei Unter-/Überschreitung von Stan- dardlängen für Title und Description sowie optionale, KI-gestützte Vorschläge für opti- mierte Teaser-Texte.

3. Semantische Textarchitektur Das CMS muss die Redaktion durch eine intuitive Benutzerführung z. B. durch Pflichtfel- der oder logische Validierungen aktiv dabei unterstützen, eine strikt hierarchische HTML- Struktur fehlerfrei und ohne visuelles Rauschen einzuhalten.

4. Redaktionelle AEO-Unterstützung und FAQ-Strukturierung Das CMS muss Werkzeuge zur strukturierten Erfassung von Frage-Antwort-Formaten bereitstellen. Das System muss die Redaktion dabei unterstützen, prägnante Antwort- Snippets zu formulieren und diese automatisch mit strukturierten Mikrodaten für direkte Antwort-Engines aufzubereiten.

4.3 Rahmenlayout und Navigation

Das Frontend umschließt sämtliche über die API gelieferten Inhaltsdaten und Fachmodule der Plattform mit einem globalen, konsistenten Rahmenlayout. Dieses Framework muss geräte- übergreifend auf allen Unterseiten identisch ausgespielt werden und den Nutzenden jederzeit Zugriff auf zentrale Systemfunktionen wie z. B. die Suche, Login zum DVB-Account, Sprach- auswahl und die Hauptnavigation ermöglichen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 39 von 111

[Seite 40]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.3.1 Navigations- und Menü-Strukturen

Da das System auf einer entkoppelten (Headless-)Architektur basiert, muss das Content-Ma- nagement-System die Menüstrukturen rein datenbasiert verwalten und für das Frontend be- reitstellen:

1. API-gesteuerte Navigation Die gesamte Menüstruktur u. a. Hauptnavigation, Footer-Verlinkungen und Meta-Naviga- tion darf nicht fest im Frontend programmiert sein. Sie muss durch die Redaktion im CMS flexibel verwaltet, hierarchisch strukturiert und umsortiert werden können. Das CMS muss diese Menübäume als leichtgewichtiges, verschachteltes Datenmodell über eine API bereitstellen.

2. Performance-Optimierung für App-ähnliche Seitenwechsel Um bei der Navigation zwischen den Seiten eine flüssige, verzögerungsfreie Interaktion ohne spürbare Ladezeiten der Menüstrukturen zu garantieren, muss die Navigations-API so hoch performant ausgelegt sein, dass das Frontend die Menüdaten verzögerungsfrei verarbeiten kann.

3. Visuelle Navigationshilfen und Metadaten Die Navigations-API muss die Erweiterung von Menüpunkten um optionale Metadaten im Content-Management-System unterstützen. Dazu gehören die Zuordnung von spezifi- schen Icons oder Piktogrammen sowie optionale Badge-Texte um die kognitive Erfass- barkeit der Menüstruktur für die Nutzenden zu beschleunigen.

4. Eindeutige URL-Referenzierung bei Mehrfachverlinkungen Wenn Inhaltsseiten aus redaktionellen Gründen an mehreren Stellen der Navigations- struktur verlinkt werden, muss das Content-Management-System technisch sicherstellen, dass die Ressource datenseitig unter einer einzigen primären Standard-URL erreichbar bleibt, um Suchmaschinen-Nachteile durch doppelte Inhalte zu verhindern.

4.3.2 Globaler Header und zentrale Funktionselemente

Der globale Header bildet den oberen Abschluss jeder Seite und muss die wichtigsten Ab- sprungpunkte und Werkzeuge für die Nutzenden bündeln:

1. Plattformweite Suche Der Header muss ein dauerhaft präsentes und von den Nutzenden intuitiv erreichbares Sucheinstiegsfeld bereitstellen. Bei der Eingabe ab dem dritten Zeichen muss eine feh- lertolerante Echtzeit-Vorschau von passenden Inhalten ausgespielt werden, die nach Re- levanz und Inhaltstypen (z. B. „Häufige Fragen“, „Aktuelle Meldungen“, „Tickets“) grup- piert vorgeschlagen werden.

2. Schnittstellenbasierte Such-Indexierung Das CMS muss bei jeder Veröffentlichung, Änderung oder Depublikation von Inhalten au- tomatisierte Signale an einen externen Suchindex-Dienst senden, um den Suchindex in Echtzeit mit den strukturierten Inhaltsdaten synchron zu halten. Eine zeitverzögerte Inde- xierung oder das Durchschleusen von Suchanfragen als Proxy durch das Content-Ma- nagement-System ist unzulässig, um Serverüberlastungen zu vermeiden.

3. Erweiterte Barrierefreiheits- und Komforteinstellungen Im globalen Header müssen direkt zugängliche Bedienelemente für barrierefreie Ein- stiege und Komfortfunktionen platziert werden. Dazu gehören direkte Absprünge zu den

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 40 von 111

[Seite 41]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

gesetzlich geforderten Inhalten in einfacher Sprache sowie ein zentrales, leicht zugängli- ches manuelles Steuerungselement für den Darstellungsmodus wie Hell-/Dunkelmodus und Kontrastmodus. Für die intelligente, nutzungszentrierte Steuerung dieses Darstel- lungsmodus gelten folgende Anforderungen:

a) Automatische Erkennung: Standardmäßig ist eine automatische Erkennung und An- passung an die Systemeinstellungen des Endgeräts der Nutzenden.

b) Manuelle Übersteuerung: Eine manuell über das Steuerungselement getroffene Aus- wahl der Nutzenden muss die automatische Erkennung dauerhaft übersteuern.

c) Sitzungsübergreifende Speicherung: Die manuell getroffene Auswahl muss für Folge- sitzungen sitzungsübergreifend gespeichert werden.

d) Globaler Gültigkeitsbereich: Diese Einstellungen müssen global wirken und dürfen beim Wechsel von Unterseiten nicht verloren gehen.

4. Sprachumschaltung Der Header muss ein Element zur Sprachumschaltung (mindestens Deutsch/Englisch) enthalten. Das Content-Management-System muss bei einem Sprachwechsel das ent- sprechende lokalisierte Navigations- und Inhaltsdatenmodell an das Frontend übergeben.

5. Einstieg zum persönlichen Account-Login Im Header muss ein prominenter, konfigurierbarer Platzhalter für den DVB-Account-Login integriert sein. Das Content-Management-System liefert hierfür lediglich die strukturellen Rahmenbedingungen und Icons, während die eigentliche Authentifizierung und Statusan- zeige über die Schnittstellen des Identitäts-Management-Systems der DVB im Frontend gelöst wird.

4.3.3 Globaler Footer

Der Footer bildet den unteren Abschluss der Plattform und bietet Nutzenden Zugang zu wei- terführenden Informationen. Folgendes muss gewährleistet sein:

1. Mehrspaltiges, flexibles Layout Der Footer muss im Content-Management-System als globale Komponente editierbar sein. Redaktionsmitarbeitende müssen in der Lage sein, mehrere Spalten mit Texten, Linklisten, Logos und Social-Media-Verknüpfungen flexibel zu konfigurieren.

2. Rechtliche Pflichtlinks Der Footer muss eine dedizierte Zone für rechtlich vorgeschriebene Inhalte wie Impres- sum, Datenschutz, Barrierefreiheitserklärung und Cookie-Einstellungen enthalten. Diese Links müssen auf jeder Unterseite für die Nutzenden mit einem Klick erreichbar sein.

4.4. Startseite

Die Startseite bildet das funktionale und strategische Rückgrat der gesamten Plattform. Sie muss als zentraler, intuitiver Einstiegspunkt dienen, welcher die Komplexität der verschiede- nen digitalen Angebote reduziert, fragmentierte Einstiege bündelt und eine konsistente, barri- erefreie Orientierung direkt ab dem ersten Aufruf der Plattform, über alle Endgeräte hinweg, sicherstellt.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 41 von 111

[Seite 42]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.4.1 Funktionale Anforderungen an die Startseite und Inhaltssteuerung

Für die Ausgestaltung der Startseite als primäre Anlaufstelle für sämtliche digitalen Bedürf- nisse unserer Kundschaft muss die vorgeschlagene Lösung folgende Kriterien und Integrati- onsmechanismen erfüllen:

1. Verpflichtende Umsetzung des Startseitenkonzepts Die technische Bereitstellung der Startseite und ihrer Komponenten durch das CMS muss die vollständige, barrierefreie und performante Umsetzung des vom Bieterunter- nehmen einzureichenden Fachkonzepts auf Basis der Vorgaben aus Anhang konzeptan- forderungen.pdf (Konzeptanforderung 1 „Startseite“) ermöglichen.

2. Anforderungen an das Bieterunternehmen Das Bieterunternehmen hat im Rahmen seines Angebots detailliert zu beschreiben, wie das angebotene CMS und die vorgeschlagene Frontend-Architektur, die in Konzeptanfor- derung 1 „Startseite“ geforderte Reduktion von Komplexität und die visuelle Bündelung der Angebote auf der Startseite technologisch abgebildet werden.

3. Harmonische Integration von Kernfunktionen Die Startseite muss so konzipiert sein, dass sie sowohl zeitkritische Transaktionsfunktio- nen, wie die Verbindungsauskunft oder aktuelle Abfahrtsdaten, als auch Inhalte, wie ak- tuelle Top-Themen aus dem Newsroom oder Kampagnen-Teaser, auf einer gemeinsa- men Oberfläche vereint.

4. Abkoppelung operativer Echtzeit-Widgets Für hochdynamische Elemente auf der Startseite, wie die Verbindungsauskunft, Stö- rungsmeldungen oder den Abfahrtsmonitor, darf das CMS keinen Code generieren. Das System muss stattdessen in der Lage sein, diese Elemente als eigenständige „Widget- Platzhalter“ im Komponenten-Baukasten bereitzustellen. Die Redaktion steuert im Ba- ckend lediglich die Platzierung, Überschriften oder begleitende Texte. Die eigentliche technische Ausführung und Datenabfrage erfolgt autark direkt im Frontend.

5. Dynamische Anzeige betrieblicher Großraummeldungen Das Frontend muss in der Lage sein, hochpriorisierte betriebliche Störungsmeldungen und Informationen zu Großereignissen, die über die externe VVO-WebAPI bereitgestellt werden, im obersten, sofort sichtbaren Bereich der Startseite dynamisch und mit maxi- maler visueller Priorität auszusteuern. Das CMS liefert hierfür lediglich die strukturellen Rahmenbedingungen oder Platzhalter zur Positionierung, während die Datenabfrage und visuelle Aufbereitung vollkommen autark und performant direkt im Frontend erfolgt.

6. Redaktionelle Steuerung von plattformspezifischen Systemhinweisen Für rein anwendungsbezogene Mitteilungen (z. B. geplante Wartungsfenster, temporäre Hinweise zu Fehlern im Ticketshop oder Informationen zu neuen Anwendungsupdates) muss das CMS eine flexible, rein redaktionelle Inhaltskomponente bereitstellen, die von der Redaktion je nach Dringlichkeit pro Hinweis flexibel gewählt werden kann. Um ein in- teraktives (App-)Nutzungserlebnis im Frontend zu gewährleisten, muss das System die gewählte Eskalationsstufe als strukturiertes Daten-Flag über die API übergeben. Das Frontend übernimmt die autonome visuelle Aussteuerung und das Rendering der ent- sprechenden UI-Komponenten. Die Eskalationsstufen sind im Laufe des Projekts zu defi- nieren. Das könnten zum Beispiel sein:

a) Eskalationsstufe 1 (informativ): Prominente, aber nicht-blockierende Inline-Banner im direkt sichtbaren Bereich.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 42 von 111

[Seite 43]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

b) Eskalationsstufe 2 (kritisch/dringend): Vollständig barrierefreie, modale Overlays, wel- che die Interaktion mit der Plattform temporär überlagern, bis sie von den Nutzenden aktiv akzeptiert oder geschlossen werden.

Die Redaktion muss im Backend in der Lage sein, diese Hinweise manuell zu pflegen, die passende Eskalationsstufe zu wählen und die Ausspielung zeitgesteuert oder per Knopfdruck flexibel zu aktivieren oder zu deaktivieren.

7. Unterstützung personalisierter Startseitenansicht Um den Komfort für die Stammkundschaft zu erhöhen, muss die Startseiten-Struktur die Integration einer persönlichen Startseitenansicht unterstützen. Das CMS stellt hierfür die strukturellen Rahmenbedingungen und Standard-Konfigurationen bereit, während das Frontend in der Lage sein muss, individuelle Favoriten der Nutzenden datenschutzkon- form und dynamisch in diese Startseitenbereiche einzubetten.

8. Konsequenter Mobile-First- und App-First-Ansatz Die Struktur der Startseite muss primär für die Touch-Bedienung auf mobilen Endgeräten optimiert sein. Interaktive Elemente und Teaser-Komponenten müssen so strukturiert an die API übergeben werden, dass die Frontend-Applikation eine flüssige, app-ähnliche Be- dienung ohne Informationsverlust garantieren kann.

4.4.2 Führung der Nutzenden und strategische Einstiege auf der Startseite

Um Fahrgästen, Bewerbenden und Partnerunternehmen direkt beim Einstieg eine schnelle Orientierung und einen flexiblen Wechsel zwischen den Angeboten zu ermöglichen, muss die Startseite folgende Anforderungen an die User Experience abbilden:

1. Thematische Flexibilität im UX-Fluss Die Anordnung der Elemente auf der Startseite muss so aufgebaut sein, dass ein schnel- ler, direkter Wechsel zwischen den Kernthemen möglich ist. Fahrgäste müssen von der Startseite aus kontextbezogen zu den für sie relevanten Inhalten springen können, ohne lange suchen zu müssen.

2. Einstiegsoptimierung für strategische Teilbereiche Die strategisch wichtigen Inhaltsbereiche, wie u. a. Karriere, Vertrieb und MOBI, sowie spezielle Einstiege für Fokus-Zielgruppen (z. B. Reisende oder Studierende) dürfen auf der Startseite nicht versteckt sein. Das CMS muss flexible Teaser-Strukturen oder Ein- stiegs-Kacheln bereitstellen, damit die Redaktion diese strategischen Ziele und zielgrup- penspezifischen Inhalte im direkt sichtbaren Bereich mit minimalem Klickaufwand zu- gänglich machen kann.

4.5 Newsroom (Content Hub)

Der Newsroom fungiert als zentraler, modularer Content-Hub der DVB. Er führt sämtliche in- terne und externe Kommunikationskanäle in einer optisch konsistenten und funktionalen Ein- heit zusammen. Die Informationsarchitektur muss so flexibel gestaltet sein, dass die unter- schiedlichen Bedürfnisse der verschiedenen Zielgruppen (wie Fahrgäste, Pressevertretende, politische Stakeholder oder Social-Media-Interessierte) intuitiv, barrierefrei, datenschutzkon- form und mit minimalem Suchaufwand abgedeckt werden.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 43 von 111

[Seite 44]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Dieses Kapitel bildet die funktionale und technische Grundlage für die Umsetzung der Kon- zeptanforderung 2 – „Newsroom (Content-Hub)“. Die Systemarchitektur ist zwingend headless und technologieunabhängig zu konzipieren, um eine vollständige Entkopplung zwischen der redaktionellen Inhaltspflege im CMS und der Ausspielung über die Programmierschnittstellen an das Frontend zu gewährleisten.

4.5.1 Systemarchitektur und funktionale Grundlagen

Für die Ausgestaltung des Newsrooms als entkoppelter Content-Hub muss die angebotene Lösung folgende Kriterien erfüllen:

1. Verpflichtende Umsetzung des Newsroom-Konzepts Das CMS und die API-Schichten müssen die vollständige, barrierefreie und performante Umsetzung des vom Bieterunternehmen einzureichenden Fachkonzepts auf Basis der Vorgaben aus der Konzeptanforderung 2 – „Newsroom (Content-Hub)“ vollumfänglich unterstützen.

2. Technologieunabhängige Bündelung von Inhaltsformen Das CMS muss in der Lage sein, strukturierte Datensätze für heterogene Beitragsformen (darunter klassische News, Pressemeldungen, politische Kommunikation und Blog-Bei- träge) modular zu verwalten. Die Inhaltstypen müssen über die API so bereitgestellt wer- den, dass das Frontend eine klare visuelle Hierarchie ohne Informationsüberlastung der Nutzenden abbilden kann.

3. API-gestützte Verlinkungs- und Interaktionslogik Das System muss Teaser-Datenstrukturen semantisch differenziert an die API überge- ben. Bei internen Inhalten verweist die Datenstruktur auf die jeweilige Inhalts-ID der eige- nen Plattform. Bei externen Inhalten (z. B. Social-Media-Inhalten) muss die Ziel-URL di- rekt im Datensatz übermittelt werden, um dem Frontend eine direkte Weiterleitung zum Originalbeitrag ohne layerbasierte Zwischenschritte oder Overlays zu ermöglichen.

4. Modularität und Omnichannel-Fähigkeit Die Inhaltsstrukturen des Newsrooms müssen vollständig losgelöst von Layout-Vorgaben als strukturierte Rohdaten bereitgestellt werden, um eine künftige Erweiterung um zu- sätzliche digitale Touchpoints oder Ausgabekanäle ohne architektonische Anpassungen zu garantieren.

4.5.2 Content-Aggregation und Drittanbieter-Schnittstellen

Die Integration externer Datenströme und die Bereitstellung standardisierter Feeds muss au- tomatisiert, performant und datenschutzkonform erfolgen:

1. Serverseitige Social-Media-Aggregation Um die Übertragung von personenbezogenen Daten der Nutzenden an Drittplattformen ohne blockierende Consent-Layer im Frontend zu verhindern, muss die Aggregation offi- zieller Social-Media-Kanäle (mindestens Instagram, Facebook, WhatsApp, LinkedIn und YouTube) zwingend im Backend bzw. auf Server-Ebene erfolgen. Im Frontend dürfen keine direkten Skripte oder Tracker der Drittanbieter eingebunden werden.

2. Performanceoptimierung durch Mengenbegrenzung Die automatisierte Abfrage und Zwischenspeicherung externer Social-Media-Beiträge muss im Backend mengenmäßig präzise eingegrenzt werden (z. B. durch eine konfigu- rierbare Deckelung auf die jeweils letzten 10 Beiträge), um Latenzen beim API-Aufruf durch das Frontend effektiv auszuschließen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 44 von 111

[Seite 45]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

3. Automatisierte Bereitstellung standardisierter Feeds Das System muss bei der Veröffentlichung von News-, Presse- oder Blog-Inhalten auto- matisch valide, maschinenlesbare Feeds (z. B. RSS/XML-Strukturen) generieren und über zweckbestimmte Endpunkte plattformweit abrufbar zur Verfügung stellen. Für die Ausgabe wie u. a. des News-Feeds muss die API zudem Datenstrukturen bereitstellen, die im Frontend eine chronologische Darstellung sowie eine performante Paginierung oder „Load More“-Funktion ermöglichen.

4.5.3 Redaktionelle Inhaltssteuerung und Teaser-Logiken

Die Inhaltsverwaltung im Backend muss der Redaktion maximale Flexibilität bei der Steue- rung der Frontend-Ausgaben bieten:

1. Strukturierte Teaser-Datensätze Jedes Teaser-Element muss als eigenständiges Objekt über die API übergeben werden und mindestens ein Bild, den Titel, das Veröffentlichungsdatum, Kategorie-Tags sowie einen Kurztext enthalten. Das CMS darf im Backend keine starren Zeichenbeschränkun- gen für Titel und Texte erzwingen. Um ein Aufbrechen des Layouts im Frontend zu ver- hindern, hat die visuelle Kürzung dynamisch im Frontend-Code zu erfolgen.

2. Dynamische Startseiten-Steuerung Die Redaktion muss im Backend pro Beitrag über ein einfaches Steuerungselement (z. B. eine Checkbox) festlegen können, ob der Datensatz für den Newsbereich der Start- seite freigegeben wird. Das Veröffentlichen ist als Standard zu definieren. Die API muss diese Daten so übergeben, dass der Newsbereich im Frontend auf Desktop- und Mobil- geräten in der ersten Scrolltiefe ausgespielt werden kann und ein prominenter Call-to-Ac- tion direkt auf den vollständigen Newsroom verweist.

3. Zeitliche Inhaltssteuerung und Terminierung Das System muss Funktionen zur manuellen Überschreibung des Veröffentlichungsda- tums sowie zur minutengenauen zeitversetzten Veröffentlichung in der Zukunft bereitstel- len. Das Frontend muss diese Daten über die API chronologisch korrekt einordnen.

4. Priorisierung und API-gestütztes Anpinnen Es ist eine Steuerungslogik zu implementieren, mit der Beiträge als „priorisiert“ markiert werden können. Die API muss diese Markierung als Flag übergeben, sodass das Front- end diese Inhalte unabhängig von der chronologischen Sortierung im obersten Bereich fixieren und optisch hervorheben kann.

5. Klassifizierung und kombinierte Filterung Das CMS muss eine flexible Zuordnung von Beiträgen zu einer unbegrenzten Anzahl an Kategorien unterstützen, wobei ein Beitrag auch ohne Kategoriezuordnung veröffentli- chungsfähig sein muss. Die API muss die Kategoriestruktur so abbilden, dass im Front- end eine performante, kombinierte Filterung nach mehreren Kriterien gleichzeitig reali- siert werden kann.

6. Direkte interne und externe Teaser-Verlinkung Redakteure müssen Beiträge so konfigurieren können, dass der Teaser über die API di- rekt mit einer externen Ziel-URL oder einer bestehenden internen CMS-Inhaltsseite ver- knüpft wird. Bei Klick auf den Teaser im Frontend muss eine direkte Weiterleitung ohne Zwischenschritte erfolgen. Für externe Absprünge muss die API ein entsprechendes Flag übergeben, damit das Frontend den Teaser automatisch mit einem dezenten visuellen Icon als externen Link kennzeichnen kann.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 45 von 111

[Seite 46]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.5.4 Presse-Services und geschütztes Medienmanagement

Zur gezielten Bedienung von Medienvertretenden sind spezifische Workflows und geschützte Datenstrukturen zu etablieren:

1. Funktionale Gleichheit für den Presse-Feed Der Feed für Pressemitteilungen muss architektonisch und funktional identisch zum regu- lären News-Feed aufgebaut sein und dieselben Mechanismen für Filterung, Suche, Kate- gorisierung und Terminierung bereitstellen.

2. Registrierungs-Workflow für den Presseverteiler Es ist eine barrierefreie Formular-Schnittstelle zur Erfassung von Kontaktdaten und einer Presseausweisnummer bereitzustellen. Nach erfolgreichem Double-Opt-In müssen diese Daten strukturiert an das System der Pressestelle übergeben werden.

3. Schnittstellenbasierte Kontaktsynchronisation Das System soll einen datenschutzkonformen Workflow (z. B. über automatisierte Datei- Importe oder direkte API-Anbindungen) bereitstellen, um externe Adressverteiler effizient abzugleichen und Dubletten selbstständig zu bereinigen.

4. Mobiler Medienimport für die Redaktion Die Eingabemasken des CMS müssen vollständig responsiv gestaltet sein, um der Pres- sestelle den unkomplizierten Upload von Pressefotos direkt vor Ort über mobile Endge- räte zu ermöglichen.

5. Anbindung an das vorhandene Medienportal Canto Die Bereitstellung hochauflösenden Pressematerials (Bilder, Logos, Videos) sowie deren gezielte Freigabe an einen von der Redaktion definierbaren und authentifizierten Kreis von Nutzenden soll nicht als Eigenentwicklung im CMS umgesetzt werden. Diese ge- schützte, rollenbasierte Speicherstruktur ist zwingend über eine API-basierte Integration des bei der DVB vorhandenen Medienportals Canto abzudecken. Das Gesamtsystem muss gewährleisten, dass die autorisierten Assets aus Canto über die Programmier- schnittstelle performant und rechtekonform an das Frontend übergeben und dort für die berechtigte Zielgruppe zum Download angeboten werden.

4.6 Archiv-Bereiche und historische Daten

In diesem Abschnitt werden die plattformweiten, übergreifenden Anforderungen an die Archi- vierung und den Lebenszyklus von Inhalten definiert. Die Archivierung ist als globale, modul- unabhängige Systemfunktion zu verstehen, die für unterschiedliche Inhaltstypen (darunter News, Pressemitteilungen und Baumaßnahmen) eine konsistente Logik zur Verfügung stellt. Ziel ist es, historische Daten kontrolliert bereitzustellen, die Systemperformance zu sichern und die Auffindbarkeit im Frontend geräteübergreifend zu gewährleisten.

4.6.1 Funktionale Anforderungen an das globale Archivierungsmodul

1. Strukturelle Bereitstellung und visuelle Kennzeichnung Das CMS muss für definierte Inhaltstypen eigenständige Archiv-Datenbereiche bereitstel- len. Die API muss archivierte Datensätze mit einem eindeutigen Status-Flag an das

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 46 von 111

[Seite 47]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Frontend übergeben, damit dieses die entsprechenden Inhalte auf der Plattform ausspie- len und für die Nutzenden unmissverständlich und visuell eindeutig als „archiviert“ kenn- zeichnen kann.

2. Statusbasiertes Archiv-Management und Workflows Das System muss einen Workflow bereitstellen, um aktive Inhaltsseiten in den Status „ar- chiviert“ zu versetzen. Sobald dieser Status aktiv ist, muss der Inhalt datenseitig automa- tisch aus der primären Navigation sowie aus den regulären, aktuellen Feeds entfernt und in den zugehörigen Archiv-Bereich überführt werden. Für die Archivsteuerung müssen der Redaktion folgende Veröffentlichungsoptionen zur Verfügung stehen:

a) Befristete Veröffentlichung: Der Beitrag ist im Archiv-Bereich im definierten Zeitraum von/bis sichtbar, danach nicht publiziert.

b) Dauerhaft: Der Beitrag wird ab einem definierten Zeitpunkt X unbefristet im Archiv- Bereich bereitgestellt.

c) Nicht publiziert: Der Beitrag wird mit sofortiger Wirkung aus allen produktiven API- Endpunkten des Archivs entfernt.

3. Rollenbasiertes Berechtigungsmodell für Archivstrukturen Das CMS muss beim Verwalten von Archiven strikt zwischen der Strukturadministration und der Inhaltszuweisung trennen. Das Anlegen, Umbenennen oder Löschen von Archiv- Bereichen oder Verzeichnissen darf ausschließlich administrativen Rollen sowie der Chef-Redaktion vorbehalten sein.

4. API-gestützte Archiv-Suche und kombinierte Filterung: Die API muss für die Archiv-Endpunkte Datenstrukturen bereitstellen, die im Frontend eine performante Filterung nach den zentralen Kategorien sowie nach spezifischen Da- tumsangaben, speziell gruppiert nach Jahr und Monat, ermöglichen. Zudem müssen die Archiv-Inhalte über eine performante Volltextsuche flexibel abfragbar sein.

5. Suchmaschinenoptimierung und Indexierungs-Steuerung Um zu verhindern, dass historische Archiv-Inhalte die Suchmaschinen-Rankings aktueller Meldungen negativ beeinflussen, müssen archivierte Seiten im CMS automatisch mit ei- nem noindex-Tag versehen werden, welches über die API an das Frontend übermittelt wird. Archivierte Inhalte dürfen zudem nicht über die reguläre XML-Sitemap an Suchma- schinen übermittelt werden. Das System muss, sofern möglich, jedoch technisch sicher- stellen, dass archivierte Beiträge ihre ursprüngliche URL-Struktur beibehalten, um beste- hende externe Verlinkungen nicht zu beschädigen.

6. Interne Archivierung zur Wiederverwendung von Daten Das CMS muss die Möglichkeit bieten, Inhalte rein systemintern zu archivieren, ohne sie über einen öffentlichen Archivbereich auf der Website auszuspielen. Diese Funktion dient der internen Dokumentation, der Historisierung sowie der späteren Wiederverwendung von Inhaltsstrukturen durch die Redaktion.

4.7 Blog-Modul und interaktives Fotobuch

Das bereitzustellende Blog-Modul sowie die integrierte Fotobuch-Komponente erweitern die Plattform um flexible, redaktionelle Inhaltsformen. Die technische Bereitstellung dieser Module

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 47 von 111

[Seite 48]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

muss vollständig konform zur Headless-Architektur erfolgen. Das Content-Management-Sys- tem hat die Inhaltsdaten ausschließlich als strukturierte, layoutfreie Rohdaten über die Schnitt- stelle zu übergeben, während das Frontend die performante, responsive und barrierefreie Aus- spielung autonom übernimmt.

Dieses Kapitel bildet die funktionale und technische Grundlage zur informationstechnischen Umsetzung der entsprechenden Vorgaben aus dem Absatz „Konzeptanforderung 3 – Foto- buch im Bereich Blog“ des Anhang konzeptanforderungen.pdf.

4.7.1 Systemintegration, Navigation und Blog-Startseite

Für die strukturelle Einbettung des Blogs in die Gesamtplattform muss die angebotene Lösung folgende Kriterien erfüllen:

1. Eigenständige Blog-Navigation Das CMS muss ein separat editierbares Navigationsmenü für den Header-Bereich des Blogs bereitstellen. Dieses Menü muss die flexible Verwaltung von mindestens fünf Navi- gationspunkten über die API erlauben und darf nicht fest im Frontend programmiert sein.

2. Spezifisches Blog-Branding Im Datenmodell der Blog-Navigation muss ein dediziertes Feld zur Integration eines spe- zifischen Blog-Logos existieren. Das Frontend muss dieses Logo auslesen und zwingend mit der Startseite des Blogs verlinken.

3. Volltextsuche mit Ergebnisseite Das System muss eine fehlertolerante Volltextsuche bereitstellen, die exklusiv alle Blog- Inhalte indexiert. Die Suchmaske muss auf jeder Blog-Unterseite direkt bedienbar sein. Die API muss die Suchergebnisse so strukturiert und paginiert ausgeben, dass das Frontend eine eigenständige Suchergebnisseite rendern kann.

4. Schlagwort-Navigation/Tag-Cloud im Footer Das CMS muss eine aggregierte Datenstruktur aller im Blog genutzten Schlagworte/Tags bereitstellen. Das Frontend nutzt diese Daten, um im Footer-Bereich des Blogs eine dy- namische Schlagwort-Navigation bereitzustellen, über die Nutzende direkt zu den ent- sprechenden Kategorie- oder Schlagwort-Ergebnisseiten springen können.

5. Visueller Themenüberblick auf der Blog-Startseite Die übergeordnete Startseite des Blogs muss ein flexibles, visuelles Element unterstüt- zen, das einen strukturierten Überblick über alle aktiven Themenwelten bietet. Das Da- tenmodell muss so skalierbar konzipiert sein, dass auch eine große Anzahl an Themen- kacheln abgebildet werden kann. Das Redaktionsteam muss in der Lage sein, diese Übersichtselemente auf der Blog-Startseite flexibel hinzuzufügen, zu editieren oder zu entfernen.

4.7.2 Redaktionelle Verwaltung und Beitragsstrukturen

Für die Erstellung und den Export von Blog-Inhalten gelten folgende funktionale Anforderun- gen:

1. Strukturierte Inhaltspflege für Blogbeiträge Das CMS muss einen dedizierten Inhaltstyp „Blogbeitrag“ bereitstellen. Neben den Stan- dard-Metadaten wie z. B. die Zuweisung der erstellenden Person und Veröffentlichungs-

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 48 von 111

[Seite 49]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

datum, muss die flexible Inhaltserstellung über das in Kapitel 4.2.1 definierte Komponen- ten-System erfolgen. Das System muss eine intuitive Bearbeitung sowie eine minutenge- naue, zeitgesteuerte Veröffentlichung unterstützen.

2. Themen-Übersichtsseiten Die API muss Blog-Metadaten chronologisch sortiert (neueste Beiträge zuerst) für pagi- nierte Übersichtsseiten im Frontend bereitstellen. Ein Teaser-Datensatz muss zwingend das Titelbild, das Veröffentlichungsdatum, den Teaser-Text sowie die aktuelle Anzahl der Kommentare und Likes umfassen.

3. Detailansicht von Blogbeiträgen Für die Darstellung der Beitrags-Detailseite muss die API alle erfassten Inhaltskompo- nenten sowie die zugehörigen Metadaten wie Veröffentlichungsdatum und Themen-Kate- gorien, vollständig bereitstellen. Die Datenstruktur muss so aufgebaut sein, dass das Frontend daraus die Beitragsseite sowie die dynamischen Verlinkungen zu den jeweili- gen Themenbereichen autonom generieren kann.

4. Validierte Like-Funktion Das System muss eine Interaktions-API für Reaktionen (z. B. Like-Button) am Beitrags- ende bereitstellen. Um Mehrfachstimmabgaben pro Nutzungssitzung oder Person effektiv zu unterbinden, sind systemseitig geeignete Validierungsmechanismen zu implementie- ren.

5. Datenschutzkonformes Social-Sharing Am Beitragsende ist eine leicht zugängliche Teilen-Funktion für digitale Kanäle wie E- Mail, direkter Link, WhatsApp sowie über alle relevanten Social-Media-Plattformen zu in- tegrieren. Hierbei sind mindestens jene anzubinden, auf denen die DVB nach aktuellem Stand selbst vertreten ist. Die Bereitstellung über die API muss so erfolgen, dass das Frontend die Funktion vollständig datenschutzkonform, ohne das automatische Laden von Drittanbieter-Skripten oder Trackern, ausführen kann.

6. Automatisierte Veröffentlichung über Web-Feeds Bei der Veröffentlichung eines Blogbeitrags muss das System automatisch einen validen Blog-RSS- bzw. Atom-Feed über einen dedizierten API-Endpunkt aktualisieren, inklusive Titel, Teaser, Datum und Link, damit externe Inhaltsverwerter die Inhalte zeitverzugslos auslesen können.

7. Bereitstellung für barrierefreien Dokumenten-Export Das System soll die strukturierte Beitrags-Datenstruktur so vollständig über die API be- reitstellen, dass das Frontend eine Funktion zum Download des Blogbeitrags als barrie- refreies PDF-Dokument generieren kann. Die gelieferten Daten müssen alle notwendigen semantischen Tags und Hierarchien enthalten, damit das Frontend den PDF/UA-Stan- dard client- oder serverseitig lückenlos erfüllen kann. Der Fokus liegt hierbei auf dem rei- nen Inhalt unter Ausschluss von Navigationselementen oder Kommentaren.

4.7.3 Kommentarfunktion, Authentifizierung und Drittsysteme

Um den direkten, sicheren Dialog mit den Nutzenden zu ermöglichen, ist folgende Kommentar- Infrastruktur zu etablieren:

1. Differenzierte Kommentarfunktion & DVB-Account-Anbindung Redaktionsmitarbeitende müssen die Kommentarfunktion pro Beitrag individuell aktivie- ren oder deaktivieren können. Für nicht-authentifizierte Nutzende ist eine Eingabemaske bereitzustellen. Bei authentifizierten Nutzenden, die via DVB-Account eingeloggt sind,

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 49 von 111

[Seite 50]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

muss das System, sofern im persönlichen Bereich eingewilligt wurde, automatisch den hinterlegten Vornamen und den Avatar über die Schnittstelle einspeisen.

2. Barrierefreier Spam-Schutz Zur Abwehr automatisierter Spam-Angriffe bei der Kommentar-Übermittlung darf kein vi- suelles oder unzugängliches Captcha-Verfahren eingesetzt werden, das Barrieren für Screenreader erzeugt. Das System muss zwingend auf API-basierte, barrierefreie Ver- fahren setzen.

3. Moderation durch Drittsystem Das CMS muss über eine offene Programmierschnittstelle verfügen, die eine Anbindung an das externe Social-Media-Management-Tool (derzeit hat die DVB Social Hub in Ver- wendung) ermöglicht. Eingehende Blog-Kommentare müssen über diese Schnittstelle an das Drittsystem übergeben werden können, sodass die Moderation, Beantwortung, Frei- gabe und Löschung medienbruchfrei im externen Tool erfolgen und in Echtzeit an das CMS zurückübertragen werden kann.

4. E-Mail-Abonnement Für die Bindung der Lesenden muss eine Option für ein E-Mail-Abonnement bei neuen Beiträgen integriert werden. Das CMS stellt hierfür entweder die Datenstrukturen für ein internes Snippet bereit, inklusive nativem Double-Opt-In-Workflow im CMS, oder übergibt die Registrierungsdaten via verschlüsseltem Webhook DSGVO-konform an das zentrale Newsletter-Tool der DVB.

4.7.4 Das Fotobuch-Modul (Soll-Anforderung)

Sofern das Bieterunternehmen die funktionale Umsetzung eines interaktiven Fotobuchs, auf Basis von Konzeptanforderung 3, technologisch realisieren kann, muss dieses Modul nach den folgenden Kriterien umgesetzt werden:

1. Exklusive Bildspeicherung im Medienportal Canto Zur Vermeidung von redundanten Datenhaltungen dürfen die für das Fotobuch genutzten Bildressourcen nicht lokal im CMS gespeichert werden. Das Modul muss zwingend auf der in Kapitel 4.2.2 definierten Direktschnittstelle zum vorhandenen Medienportal Canto aufsetzen. Sämtliche Bild-Assets werden ausschließlich in Canto vorgehalten und über die API rechtekonform und performant an das Frontend übergeben.

2. Rechtssicherer Upload-Prozess, Einwilligung & Dokumentation Das Frontend muss einen Upload-Mechanismus für Nutzende bereitstellen. Diesem Pro- zess muss eine verbindliche Bestätigungsmaske zur Übertragung der erforderlichen Nut- zungsrechte an den hochgeladenen Bildern vorgeschaltet sein. Diese Einwilligung muss zwingend mit dem persönlichen DVB-Account der hochladenden Person verknüpft und dort verwaltet werden. Das CMS muss am jeweiligen Datensatz dauerhaft, revisionssi- cher und unveränderlich protokollieren, welche Person das Bild wann hochgeladen und welcher Rechteübertragung zugestimmt wurde. Das CMS muss hierfür einen entspre- chenden Inhaltstyp bereitstellen, sodass eingehende Einreichungen automatisiert über die Management-API als unveröffentlichte Datensätze angelegt werden können. Die übermittelten Metadaten und die verknüpfte Bildressource müssen für die Redaktion in der Redaktionsumgebung zur Moderation und Freigabe jederzeit einsehbar und editier- bar sein.

3. Pflichtfeld für Urheberkennung Das CMS-Datenmodell für Fotobuch-Assets muss ein spezifisches Pflichtfeld für den Na-

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 50 von 111

[Seite 51]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

men der urhebenden Person bereitstellen. Das Frontend liest dieses Feld aus und gene- riert bei der Veröffentlichung automatisch ein barrierefreies Copyright-Label direkt am Bild.

4. KI-Unterstützung und Barrierefreiheit Für jedes Bild müssen Alternativtexte vorliegen. Das System soll Redaktionsmitarbei- tende bei der Pflege unterstützen, indem es Alternativtexte entweder manuell oder mittels eines KI-Vorschlags pflegbar macht. Fehlt ein Alternativtext, muss das System einen Warnhinweis in der Redaktionsumgebung ausgeben. Bleibt das entsprechende Feld den- noch leer, muss ein automatischer System-Eintrag mit dem Inhalt „Kein Alt-Text vorhan- den“ erfolgen, um Screenreader-Nutzende explizit zu informieren.

5. Interaktive Frontend-Galerie & Bild-Reaktionen Das Frontend muss die via API gelieferten Bild-Arrays als flüssiges, für Touch-Gesten optimiertes Galerie-Element ausgeben. Nutzende müssen die Möglichkeit haben, auf ein- zelne Bilder mit vordefinierten Reaktionen (z. B. Emojis) zu reagieren. Die Aggregation und Speicherung dieser Bild-Reaktionen erfolgt vollständig datenschutzkonform.

4.8 Karriere-Portal und Stellenmarkt

Die aktuell eigenständige Webpräsenz karriere.dvb.de soll vollständig in die Hauptplattform integriert und technologisch sowie inhaltlich unter der neuen Verzeichnisstruktur z. B. dvb.de/karriere konsolidiert werden. Ziel ist die Schaffung eines nahtlosen, performanten Be- werbungserlebnisses unter Wahrung des spezifischen Employer-Branding-Designs der DVB.

Für die technische Umsetzung und die Anbindung von Drittsystemen gelten folgende Anfor- derungen:

4.8.1 Migration, Navigation und Design

1. SEO-erhaltende Migration Um Reichweitenverluste nach dem Umzug der Domain zu verhindern, hat das System ein lückenloses 301-Redirect-Konzept zu unterstützen. Sämtliche bestehenden URLs der alten Subdomain müssen dauerhaft auf die neuen, korrespondierenden Zielseiten unter dvb.de/karriere umgeleitet werden.

2. Einstiegs-Optimierung Die Architektur des globalen Frontends muss sicherstellen, dass das Karriere-Portal von jedem Punkt der Hauptseite für externe Bewerbende intuitiv und mit maximal einem Klick erreichbar ist.

3. Visuelle Identität durch Employer Branding Das Frontend muss das spezifische Employer Branding Design der DVB harmonisch in das Gesamt-UI der neuen Plattform einbetten. Die visuelle Eigenständigkeit der Arbeitge- bermarke muss dabei gewahrt bleiben.

4.8.2 API-Integration des Bewerbermanagementsystems

Die Bereitstellung und Verarbeitung von Stellenanzeigen und Bewerbungsdaten erfolgt über eine direkte, bidirektionale Anbindung an die REST-API des bestehenden Systems Concludis:

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 51 von 111

[Seite 52]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

1. Echtzeit-Import von Stellenangeboten Das System muss offene Stellenangebote automatisiert und in Echtzeit über die Conclu- dis-API abrufen. Die erhaltenen Rohdaten müssen im Frontend dynamisch, barrierefrei und responsiv gerendert werden.

2. Intelligente Job-Filterung und Freitextsuche Für Stellensuchende ist im Frontend eine Echtzeit-Filterung sowie eine performante Voll- textsuche bereitzustellen. Die Filterkriterien müssen sich dynamisch aus den von Conclu- dis gelieferten Datenfeldern generieren, ohne dass ein Neuladen der Seite erforderlich ist.

3. Dynamische und individuelle Bewerbungsmasken Das System muss in der Lage sein, die Bewerbungsformulare je nach Stellenangebot in- dividuell auszugestalten. Das Backend muss die von Concludis vorgegebenen Pflicht- und Optionalfragen für die jeweilige Stelle interpretieren und fehlerfrei an das Frontend übergeben.

4. Sichere, datenschutzkonforme Datenrückführung Sämtliche durch Bewerbende eingegebenen Daten sowie Dateianhänge müssen über eine verschlüsselte und gesicherte API-Verbindung direkt an Concludis übermittelt wer- den. Eine dauerhafte Speicherung dieser sensiblen Bewerbungsdaten im CMS-Backend ist aus Datenschutzgründen auszuschließen.

5. Job-Newsletter-Abonnement Im Stellenmarkt ist eine Funktion zu integrieren, über die interessierte Personen einen automatisierten Job-Newsletter abonnieren können. Nutzende müssen hierbei spezifi- sche Jobkategorien auswählen können, um bei passenden Neueinträgen gezielt benach- richtigt zu werden.

4.8.3 Redaktionelle Konfiguration und Daten-Mapping im CMS

Da die Stellenanzeigen primär aus einem externen System stammen, muss das CMS spezifi- sche Konfigurations- und Mapping-Optionen bereitstellen, um die über die API bereitgestellten Datenstrukturen redaktionell zu steuern:

1. Flexible Strukturanordnung der Stelleninhalte In Ergänzung zum globalen Komponenten-System (siehe Kapitel 4.2.1) müssen Redakti- onsmitarbeitende die strukturelle Reihenfolge der aus Concludis importierten Inhaltsblö- cke pro Stellentyp oder Anzeige flexibel verschieben können. Das CMS muss diese Sor- tierung als strukturierte Meta-Informationen über die API an das Frontend übergeben, welches die visuelle Anordnung autonom übernimmt.

2. Hierarchische Fallback-Logik für Medieninhalte Für die Ausspielung von Header- oder Teaserbildern im Stellenmarkt ist eine logische Weiche zu implementieren. Das System muss primär das in Concludis hinterlegte Bild abrufen. Ist dort kein Medien-Asset definiert, muss das Frontend automatisiert auf ein im CMS hinterlegtes Fallback-Bild zurückgreifen. Die Verarbeitung der CMS-Bilder hat hier- bei konform zu den Vorgaben aus Kapitel 4.2.2 zu erfolgen.

4.9 Fachspezifische Formulare für Kundenanliegen und Kundengarantien

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 52 von 111

[Seite 53]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Für die digitale Kundenkommunikation und das Beschwerdemanagement sind auf der Platt- form zwei technisch getrennte, jedoch auf der Formularentwicklungs-Infrastruktur dem Formu- larmodul des CMS (siehe Kapitel 4.2.5) basierende Anwendungen zu integrieren. Das sind das Kundenanliegenformular für Lob, Kritik, allgemeine Anfragen, und das Kundengarantie- formular für Erstattungsansprüche im Rahmen von Servicegarantien:

1. Logische Trennung und dynamische Nutzerführung Beide Formulare müssen über eigenständige URLs und dedizierte Einstiegspunkte auf der Plattform erreichbar sein. Je nach vom Nutzenden ausgewählter Kategorie müssen sich die nachgelagerten Eingabefelder dynamisch und barrierefrei anpassen, um nur die jeweils relevanten Daten abzufragen.

2. Technische Integration Die Formulare basieren auf der Infrastruktur des ELMA-Systems des Verkehrsverbundes Oberelbe (VVO). Um eine nahtlose Nutzerführung ohne Wechsel der Hauptdomain zu gewährleisten, müssen die Formulare clientseitig direkt innerhalb der jeweiligen In- haltsseite der Plattform integriert werden.

a) Headless-Datenübergabe: Das CMS übergibt über die Schnittstelle ausschließlich die notwendigen Konfigurationsparameter.

b) Frontend-Ausführung: Das Frontend-Framework muss so konzipiert sein, dass es das Resource-Injection-Verfahren des Public Wizards autonom unterstützt. Die client- seitige Einbindung und das Laden der externen JavaScript-Ressourcenlader des Fremdsystems über spezifische Container-Elemente werden vollständig vom Front- end gesteuert.

3. Nahtlose visuelle Anpassung Die eingebetteten Formulare dürfen für die Nutzenden keinen visuellen Medienbruch dar- stellen. Sämtliche Formularelemente, Eingabefelder, Auswahllisten und Buttons müssen über das globale Design-System vollständig und konsistent im Corporate Design der DVB gestaltet werden.

4. Barrierefreie Validierung Beide Formularstrecken müssen vollumfänglich den Kriterien der WCAG 2.2 (Level AA) entsprechen. Fehlerhafte oder unvollständige Eingaben müssen in Echtzeit über standar- disierte, barrierefreie Fehlerzustände am jeweiligen Feld signalisiert werden, wie es die API-Validierung vorgibt. Um eine hohe Nutzerfreundlichkeit zu gewährleisten, ist tech- nisch sicherzustellen, dass bereits eingegebene Formulardaten bei einer Fehlervalidie- rung oder einem unbeabsichtigten Neuladen der Seite im Formular erhalten bleiben.

4.10 Beschaffung und Integration eines intelligenten Chatbot-Assistenten

Um Fahrgästen einen schnellen, zeitgemäßen und barrierefreien digitalen Service zu bieten, wird ein zentraler, auf künstlicher Intelligenz basierter Chatbot eingeführt. Die gesuchte Lö- sung umfasst sowohl das sofort einsatzbereite Gesamtsystem bestehend aus Software, KI- Infrastruktur und Hosting als auch die technische und visuelle Einbindung in die neue Platt- form-Architektur.

Für die technische Umsetzung und die Anbindung von Drittsystemen gelten folgende Anfor- derungen:

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 53 von 111

[Seite 54]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.10.1 Kernfunktionen und Systemarchitektur

1. Anforderungen an das Betriebsmodell und die Bereitstellung Das Bieterunternehmen muss im Angebot sein vorgeschlagenes Hosting- und Betriebs- konzept detailliert beschreiben und begründen. Unabhängig vom gewählten Modell muss die Lösung über eine vollständig dokumentierte REST-API verfügen, über die alle Chat- Inhalte, Konfigurationen und Dialog-Steuerungen als strukturiertes JSON ausgegeben werden können.

2. Anforderungen an das Redaktions-Backend und Trainings-Interface Es ist eine übersichtliche Benutzeroberfläche bereitzustellen, damit Redaktionsmitarbei- tende ohne Programmierkenntnisse neue Frage-Antwort-Paare einpflegen, Dialogbäume konfigurieren und den Bot kontinuierlich trainieren können.

3. Zentrale Frontend-Komponente Der Chatbot dient als primärer Erstkontaktpunkt für Nutzende und muss systemübergrei- fend auf allen Unterseiten der Plattform präsent ausgeführt sein. Das Tool hat proaktiv bei der Navigation, Informationssuche und Prozessabwicklung zu unterstützen. Die tech- nische Einbindung im Frontend erfolgt performant.

4. Zuverlässige Wissensbasis Das System muss Antworten basierend auf zwei Datenquellen generieren. Die erste Quelle bildet ein automatisiertes Auslesen der öffentlichen Website für tagesaktuelle In- formationen. Die zweite Quelle ist eine separat pflegbare Wissensdatenbank für die Hin- terlegung rechtssicherer Dokumente wie Allgemeine Geschäftsbedingungen oder Tarif- bestimmungen. Das System muss sicherstellen, dass Falschinformationen zuverlässig verhindert werden und Daten aus der Wissensdatenbank im Konfliktfall vorrangig behan- delt werden.

5. Human-Handover-Logik mit Verfügbarkeitsprüfung Kann das System ein Anliegen nach mehreren Versuchen nicht autonom lösen, muss eine automatische Übergabe an das menschliche Service-Team angeboten werden. Diese Option darf im Frontend nur dann sichtbar sein, wenn Service-Mitarbeitende aktu- ell verfügbar sind. Außerhalb dieser Zeiten oder bei Überlastung des Teams müssen au- tomatisch alternative Kontaktwege wie ein Rückrufservice oder ein Kontaktformular ange- boten werden.

6. Barrierefreiheit nach gesetzlichen Standards Die Benutzeroberfläche des Bots muss vollständig barrierefrei gestaltet sein und mindes- tens den Standard WCAG 2.2 Level AA sowie die BITV 2.0 erfüllen. Dies umfasst unter anderem eine integrierte Spracheingabe, eine Vorlesefunktion für die ausgegebenen Ant- worten sowie die lückenlose Bedienbarkeit über Tastaturbefehle und Screenreader. Im Rahmen eines Prüfauftrags sollen die Bietenden im Angebot kurz beschreiben, wie das System Antworten zusätzlich in einfacher Sprache ausgeben kann.

7. Mehrsprachigkeit Das System muss fremdsprachige Anfragen unter anderem in den Sprachen Englisch, Polnisch und Tschechisch nativ verarbeiten können. Das System muss den Kontext die- ser Anfragen verstehen, auf Basis der deutschen Quelltexte korrekte Antworten generie- ren und diese fachlich präzise in der jeweiligen Nutzersprache ausgeben.

8. Datenschutzkonformes Hosting Das Gesamtsystem muss höchsten Datenschutzstandards entsprechen. Da Fahrgäste im Chatverlauf sensible Daten wie Abonnement-Nummern eingeben können, muss das

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 54 von 111

[Seite 55]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Hosting der KI-Modelle und Datenstrukturen nachweislich auf Servern innerhalb der Eu- ropäischen Union erfolgen. Die Einhaltung aller Vorgaben der DSGVO ist durch das bie- tende Unternehmen nachzuweisen.

9. Architektonische Entkopplung im Headless-Setup Entsprechend den Vorgaben aus Kapitel 4.1.7 darf die Integration des Chatbots im Front- end nicht über das direkte Injizieren von unkontrolliertem Drittanbieter-JavaScript-Code im CMS-Editor erfolgen. Das CMS stellt lediglich die notwendigen Konfigurationsdaten wie API-Schlüssel oder Service-IDs als strukturiertes JSON bereit. Das Frontend liest diese Daten aus und initialisiert die Chatbot-Schnittstelle über die API des Chatbot-Sys- tems autonom.

4.10.2 Erweiterte Interaktions- und Servicefunktionen

1. Interaktive Bedienführung Der Assistent soll Nutzende aktiv auf der Website navigieren können. Bei Fragen zu be- stimmten Prozessen soll das System nicht nur Text-Links ausgeben, sondern Elemente im Frontend visuell hervorheben oder direkt in den gesuchten Prozess überleiten.

2. Dokumentenbereitstellung im Chat Erkennt das System im Rahmen einer Suchanfrage passende Dokumente wie Formu- lare, Tarifblätter oder Liniennetzpläne, soll es diese direkt als klickbare Download-Res- source innerhalb des Chat-Fensters anbieten.

3. Formular-Vorbefüllung Bei der Weiterleitung an ein spezifisches Kontaktformular sollen die bereits im Chatver- lauf erfassten Daten und Informationen automatisch in die entsprechenden Formularfel- der des Frontends übertragen werden.

4.11 Einbindung von Drittplattformen

Zur Erweiterung des redaktionellen und serviceorientierten Angebots sind verschiedene spe- zialisierte Drittplattformen nahtlos in die Gesamtarchitektur der Plattform zu integrieren. Um Sicherheitsrisiken zu minimieren, erfolgt die Konfiguration dieser Dienste ausschließlich über die im CMS definierte tokenbasierte Drittdienst-Verwaltung (siehe Kapitel 4.2.7).

4.11.1 Technische Layout- und Datenschutzvorgaben

Für die technische Einbindung jeglicher externer Plattformen sind folgende Kriterien zwin- gend einzuhalten:

1. Responsives Verhalten Alle Widgets, Karten und Iframes müssen vollständig responsiv umgesetzt werden und sich flexibel an die jeweilige Bildschirmgröße des Endgeräts anpassen. Ein horizontales Scrollen der Hauptseite oder das Abschneiden von Inhalten auf mobilen Endgeräten ist technisch möglichst auszuschließen.

2. Datenschutzkonformes Laden Externe Skripte, Iframes oder Widgets dürfen erst dann clientseitig geladen und Daten an Drittserver übertragen werden, wenn die Nutzenden hierzu eine explizite Einwilligung über das zentrale Consent-Management erteilt haben.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 55 von 111

[Seite 56]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.11.2 Integration von interaktiven Komoot-Widgets

Zur Bewerbung von Ausflugs- und Freizeitangeboten im Einzugsgebiet der DVB ist die Ein- bindung von interaktiven Widgets der Plattform Komoot zu ermöglichen.

1. Das CMS verwaltet hierzu lediglich die strukturierten Tour-Konfigurationen wie z. B. Tour- IDs.

2. Das Frontend-Framework muss diese Daten empfangen und die standardisierten Wid- gets von Komoot selbstständig und sauber innerhalb von redaktionellen Inhaltskompo- nenten rendern.

3. Die Widgets müssen performant nachgeladen werden, um die initiale Ladezeit der Haupt- seiten nicht negativ zu beeinflussen.

4.11.3 Anbindung des Vergabeportals

Für den Geschäftskundenbereich der DVB ist das offizielle Vergabeportal anzubinden, um aktuelle Ausschreibungen transparent darzustellen. Da sich das zu nutzende Vergabeportal zum aktuellen Zeitpunkt selbst in der Vergabe befindet, steht das konkrete Zielsystem noch nicht fest.

1. Die Integration hat als direkte, strukturierte und datenbasierte Einbindung auf der Web- site über die vom Zielsystem bereitgestellte API zu erfolgen.

2. Das System muss in der Lage sein, die vom zukünftigen Vergabeportal bereitgestellten strukturierten Daten automatisiert abzurufen und über die plattformeigenen Design-Kom- ponenten nativ, konsistent und barrierefrei im Frontend zu rendern.

3. Die Integrationslogik im Backend muss so flexibel und modular aufgebaut werden, dass das Daten-Mapping an die finale API-Struktur des neuen Vergabeportals angepasst wer- den kann, sobald dieses feststeht.

4.11.4 Flexibilität und Erweiterbarkeit für zukünftige Drittsysteme

Um eine langfristige Zukunftssicherheit der Plattform zu gewährleisten, muss die Architektur von Frontend und Backend so flexibel und modular konzipiert sein, dass jederzeit neue, heute noch nicht definierte Drittplattformen und externe Services integriert werden können.

1. Autonomie für die Redaktion Um dem Redaktionsteam ein hohes Maß an Autonomie zu bieten, soll die Integration neuer Dienste im Alltag ohne zusätzlichen Programmieraufwand möglich sein. Die Re- daktion wird hierzu durch übersichtliche Eingabemasken im CMS unterstützt, in denen lediglich die relevanten Service-IDs oder API-Tokens hinterlegt werden müssen.

2. Datenbasierte Frontend-Initialisierung Entsprechend der Headless-Architektur (siehe Kapitel 4.2.7) übergibt das CMS für neue Dienste ausschließlich strukturierte Konfigurationsdaten, wie Service-Typ und API-Token, über die Schnittstelle. Das Frontend-Framework muss so aufgebaut sein, dass es diese Parameter autonom interpretieren kann, die zugehörigen Skripte blockiert, bis eine Frei- gabe im Consent-Management vorliegt, und die Einbindung über native Frontend-Kom- ponenten steuert.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 56 von 111

[Seite 57]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.12 Optionale Funktionsmodule

Zur optionalen Erweiterung der Plattform sind die nachfolgenden Funktionsmodule architekto- nisch so vorzuhalten, dass sie nahtlos in die Headless-Struktur integriert werden können. So- fern die Realisierung dieser Module im Leistungsspektrum vom bietenden Unternehmen liegt und angeboten werden kann, sind diese im Angebot zwingend separat auszuweisen und ein- zeln zu bepreisen.

4.12.1 Digitales Terminbuchungssystem (Option)

Dieses Modul ermöglicht das Anbieten und vollständige Abwickeln von Online-Terminbu- chungen direkt über die Plattform.

1. Backend-Konfiguration Das Redaktionsteam muss im Backend in der Lage sein, Terminslots flexibel zu erstellen und zu verwalten. Hierzu zählen die Definition von Metadaten, wie Titel, Beschreibung, Ort/digitaler Raum, die Zuweisung zu Fachbereichen, die Festlegung von Dauer, Puffer- zeiten sowie maximalen Teilnehmendenzahlen pro Termin.

2. Datenbasierte Frontend-Architektur Die Bereitstellung freier Terminslots erfolgt dynamisch via API. Das Frontend baut daraus eine intuitive, mehrstufige Buchungsstrecke auf, die mit minimalen Klicks auskommt.

3. Automatisierte Workflows Nach erfolgreicher Buchung muss das System vollautomatisch eine Bestätigung per E- Mail an die buchende Person versenden. Diese Nachricht muss eine standardisierte Ka- lenderdatei enthalten.

4. Self-Service für Nutzende Die Bestätigungs-E-Mail muss einen personalisierten, sicheren Token-Link enthalten. Über diesen Link können Nutzende ihren Termin ohne Anmeldung und ohne manuellen Aufwand für die Redaktion selbstständig verschieben oder stornieren. Der Slot wird im selben Moment im System wieder als „frei“ markiert.

5. Schnittstellen & Synchronisation Das System muss optional in der Lage sein, gebuchte Termine über standardisierte Pro- tokolle (z. B. REST-API oder gängige Kalender-Schnittstellen) direkt in die Kalendersys- teme der jeweiligen Fachabteilungen zu übertragen.

6. Buchungs-Analyse Für die interne Ressourcenplanung ist im Backend ein Dashboard bereitzustellen, das Auslastungsquoten, Buchungszahlen und beliebte Terminarten übersichtlich visualisiert.

7. Automatisiertes Löschkonzept Personenbezogene Daten der Buchenden müssen nach Abschluss des Termins oder nach einer im Backend definierten Frist automatisch und unwiderruflich gelöscht oder vollständig anonymisiert werden.

4.12.2 Umfragen- und Gewinnspielmodul (Option)

Dieses Modul ermöglicht es dem Redaktionsteam, interaktive Umfragen und Gewinnspiele unkompliziert auf der Plattform bereitzustellen, um direktes Feedback einzuholen und digitale Marketingaktionen umzusetzen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 57 von 111

[Seite 58]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

1. Strukturierte Inhaltspflege Das Erstellen von Umfragen und Gewinnspielen muss für die Redaktion ohne Program- mierkenntnisse über flexible Inhaltselemente im CMS möglich sein. Fragen werden als rein strukturierte Datenmodelle angelegt.

2. Teilnahme-Logik und Spamschutz Zur Sicherung valider Ergebnisse muss das Modul Mechanismen zur Reduzierung von Mehrfachteilnahmen bereitstellen. Das Redaktionsteam kann diese Schutzfunktion pro Kampagne flexibel aktivieren oder deaktivieren.

3. Auswertung und Datenexport Die über das Frontend per Schnittstelle übermittelten Teilnahmedaten müssen im Ba- ckend sicher zusammengeführt werden. Für die interne Auswertung ist ein integriertes Dashboard im geschützten Backend-Bereich gefordert, das diese Ergebnisse in Echtzeit grafisch aufbereitet. Für vertiefende Analysen müssen die Rohdaten in gängigen Stan- dardformaten exportierbar sein.

4. Kampagnenbezogene Datenlöschung Da bei Gewinnspielen sensible personenbezogene Daten erhoben werden, muss das Modul konfigurierbare Fristen unterstützen, die alle Daten von Teilnehmenden nach Be- endigung des Gewinnspiels und Ablauf gesetzlicher Aufbewahrungsfristen automatisch oder manuell und sicher löschen.

4.13 Gamification (Soll-Anforderung)

Zur Steigerung der Interaktion, Erhöhung der Verweildauer und spielerischen Vermittlung von Mobilitätsthemen soll die Plattform um Gamification-Elemente erweitert werden. Da dieser Be- reich als offenes Ideenkonzept ausgeschrieben ist, bildet die Grundlage hierfür das durch das Bieterunternehmen einzureichende Konzept auf Basis der Konzeptanforderung 5 – „Gamifica- tion“ im Anhang konzeptanforderungen.pdf.

Für die informationstechnische und architektonische Einbindung dieses Konzepts gelten die nachfolgenden funktionalen und technischen Rahmenbedingungen, die erfüllt sein müssen:

4.13.1 Systemarchitektur und API-Schnittstellen

Die technische Umsetzung der spielerischen Elemente muss sich nahtlos in die entkoppelte Systemlandschaft der DVB einfügen:

1. Architektonische Flexibilität Das System muss entweder eine native Umsetzung innerhalb des CMS-Komponenten- systems oder die API-basierte Anbindung einer spezialisierten, externen Gamification- Engine unterstützen.

2. Headless-Datenbereitstellung Sämtliche für die Gamification-Elemente notwendigen Daten müssen durch das Backend ausschließlich als strukturierte, layoutfreie Rohdaten via API an das Frontend übergeben werden.

3. Optionale Verknüpfung mit dem DVB-Account Das System muss darauf vorbereitet sein, erzielte Spielstände, virtuelle Abzeichen oder Meilensteine optional und dauerhaft an das Profil der jeweiligen nutzenden Person im

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 58 von 111

[Seite 59]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

zentralen DVB-Account zu koppeln und über entsprechende Schnittstellen zu synchroni- sieren.

4.13.2 Funktionale und rechtliche Vorgaben

Unabhängig von den vorgeschlagenen Spielmechaniken muss die angebotene Lösung fol- gende Kernkriterien zwingend erfüllen:

1. Spezifische Barrierefreiheit für interaktive Elemente Die Umsetzung aller spielerischen Ansätze hat zwingend konform zu den globalen Vor- gaben aus Kapitel 5.2 zu erfolgen. Komplexe Interaktionen (z. B. Quiz-Auswahlen oder zeitbasierte Spiele) dürfen Menschen mit Einschränkungen nicht ausschließen. Sie müs- sen vollständig per Tastatur bedienbar sowie für Screenreader-Nutzende barrierefrei auf- bereitet sein.

2. Hürdenfreie Nutzung Das System muss technisch gewährleisten, dass sämtliche Gamification-Angebote zu- mindest in ihren Grundfunktionen auch ohne vorherigen Login oder Registrierung für alle nutzbar sind. Weiterführende Funktionen, wie z. B. das dauerhafte Speichern von Spiel- ständen, dürfen an den DVB-Account gekoppelt werden.

3. Performance-Schutz Da die Gamification-Elemente voraussichtlich primär auf mobilen Endgeräten genutzt werden, darf die Einbindung interaktiver Skripte oder Assets keine negativen Auswirkun- gen auf die Seitenladezeiten oder die Client-Performance der Gesamtplattform haben.

4. DSGVO-konforme Datenminimierung Die Nutzung spielerischer Elemente ist für alle Webseiten-Besuchenden rein optional. Das Tracking von temporären Spielständen (z. B. innerhalb einer Nutzungssitzung) muss ohne die unnötige Erhebung oder Speicherung personenbezogener Daten realisiert wer- den.

4.14 Multimodale und barrierefreie Verbindungsauskunft

Die Verbindungsauskunft ist das zentrale Informationselement für Fahrgäste bei der Reisepla- nung auf der neuen Plattform der DVB. Sie hilft Fahrgästen dabei, schnell und unkompliziert die beste Route von Start bis Ziel zu finden. Dabei verknüpft die Verbindungsauskunft klassi- sche Verkehrsmittel wie Straßenbahn und Bus flexibel mit neuen Angeboten wie Bike- oder Carsharing. Damit alle Auskünfte und Berechnungen immer auf dem neuesten Stand sind, führt das System im Hintergrund Daten aus verschiedenen Quellen zusammen. Hierzu gehö- ren u. a. die Fahrplandaten, Echtzeitinformationen und Betriebsdaten wie die Besetztgradin- formation, welche durch die DVB über den Verkehrsverbund Oberelbe zur Verfügung gestellt werden sowie die direkten Schnittstellen der beteiligten Mobilitätspartner.

Hinweis zur Innovationsöffnung: Die nachfolgend beschriebenen Kriterien definieren den funktionalen und technischen Mindestleistungsumfang der neuen Verbindungsauskunft. Da sich Technologien, Datenstandards und Nutzungsgewohnheiten im Bereich der digitalen Mo- bilitätsinformationen fortlaufend weiterentwickeln, versteht die DVB dieses Anforderungsprofil nicht als abschließend. Bieterunternehmen sind ausdrücklich dazu eingeladen, innovative Konzepte, modernste UI/UX-Ansätze sowie optionale technologische Erweiterungsvorschläge einzubringen, wie eine zukunftsweisende und nutzungsfreundliche Verbindungsauskunft heute optimal gestaltet werden kann.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 59 von 111

[Seite 60]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Für die funktionale und technische Umsetzung der Verbindungsauskunft gelten die folgenden Kriterien:

4.14.1 Intelligente Ortssuche und Eingabelogik

1. Automatische Vervollständigung mit Relevanzgewichtung Das Suchformular muss bereits während des Tippens der ersten Buchstaben eine perfor- mante Liste mit Vorschlägen liefern. Bei der Sortierung dieser Vorschläge müssen der aktuelle geografische Standort, sofern freigegeben, der nutzenden Person über das glo- bale Positionsbestimmungssystem sowie ältere Suchanfragen einfließen. Stationen und Adressen im direkten Einzugsgebiet der DVB sind gegenüber weit entfernten, namens- gleichen Orten in anderen Regionen bevorzugt anzuzeigen.

2. Verlauf und Schnellwahl Direkt im Eingabebereich müssen die am häufigsten genutzten Ziele sowie die letzten Suchanfragen der nutzenden Person als Schnellwahloptionen übersichtlich angeboten werden.

3. Fehlertoleranz bei der Suche Die Ortssuche muss bei allen Eingaben, egal ob Haltestelle, Adresse oder POI, eine hohe Toleranz gegenüber Tippfehlern, Buchstabendrehern, doppelten Leerzeichen oder unvollständigen Wörtern aufweisen. Das System muss auch bei fehlerhafter Eingabe zielsicher die logisch wahrscheinlichsten Ergebnisse ausspielen.

4. Erkennung von Haltestellenkürzel und Abkürzungen Das System muss in der Lage sein, bekannte Haltestellenkürzel sowie gängige Abkür- zungen von Stationen, Plätzen und Straßen, wie z. B. „Hbf“, „Pl.“, „Str.“, verlässlich zu in- terpretieren und zuzuordnen.

5. Verarbeitung von Sonderzielen Neben offiziellen Haltestellennamen muss die Eingabelogik auch konkrete Straßenadres- sen, Kreuzungen sowie markante Punkte von allgemeinem Interesse wie Sehenswürdig- keiten, Behörden, Krankenhäuser oder Freizeiteinrichtungen fehlerfrei verarbeiten und in geografische Start- und Zielpunkte für die Routenberechnung übersetzen.

6. Eingabe von Zwischenhaltestellen Die Eingabemaske für die Verbindungsauskunft muss eine Funktion enthalten, mit der Fahrgäste eine gezielte Haltestelle oder ein bestimmtes Zwischenziel für den gewünsch- ten Fahrtverlauf definieren können.

7. Reisenden- und Mitnahme-Konfigurator Direkt in der Eingabemaske muss die Anzahl der reisenden Personen flexibel eingestellt werden können. Fahrgäste müssen zudem die Möglichkeit haben, ermäßigungsberech- tigte Personen wie Kinder oder Schüler hinzuzufügen sowie die geplante Mitnahme von Fahrrädern oder Hunden zu aktivieren, da diese Faktoren maßgeblich für die spätere Ta- rifermittlung sind. Als Referenz für die Gestaltung und Funktionalität des Konfigurators kann der Reisenden- und Mitnahme-Konfigurator der Deutschen Bahn herangezogen werden. Die konkrete Umsetzung hat jedoch die projektspezifischen Anforderungen zu berücksichtigen.

4.14.2 Intermodale Routenberechnung und Komfortfilter

1. Kombination der Verkehrsmittel Die Routenberechnung muss klassische Nahverkehrsszenarien mit Bussen, Straßenbah-

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 60 von 111

[Seite 61]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

nen, Bergbahnen und Fähren sowie den Regionalverkehr des VVO flexibel mit alternati- ven Mobilitätsformen verknüpfen. Zu den einbeziehbaren Optionen gehören Fußwege, Bike- sowie Carsharing. Das System muss architektonisch so konzipiert sein, dass es problemlos für weitere Mobilitätsformen erweitert werden kann.

2. Steuerung multimodaler Streckenabschnitte im gesamten Reiseverlauf Die Benutzeroberfläche und die Routenberechnung müssen die gezielte Anpassung ein- zelner Abschnitte innerhalb einer berechneten Reisekette ermöglichen:

a) Standard-Verhalten: Trifft die nutzende Person vor oder während der Suche keine gezielte Auswahl, berechnet das System die Reisekette standardmäßig mit klassi- schen Fußwegen für die Startetappe, die Zieletappe sowie alle Zwischenetappen.

b) Segment-spezifische Anpassung: Nutzende müssen flexibel und intuitiv festlegen können, wie sie einzelne Etappen überbrücken möchten. Das System muss diese Abschnitte auf Wunsch mit alternativen Mobilitätsformen neu berechnen.

c) UI/UX-Anforderung: Die Benutzeroberfläche muss hierfür eine intuitive, barrierefreie Bedienlogik umsetzen, die diese Anpassung ermöglicht, ohne die Einstiegshürde für Gelegenheitsnutzende zu erhöhen.

3. Vergleichsrouting mit Individualverkehr Das System muss in der Lage sein, neben den multimodalen Verbindungsvorschlägen parallele Routen für den privaten Pkw, für reguläre Taxidienste sowie für die vollständige Bewältigung der Strecke mit dem eigenen Fahrrad zu berechnen. Diese Optionen dienen zum Beispiel dem direkten Reisezeit-, CO - und Komfortvergleich mit den Verkehrsmit- 2 teln des ÖPNV. Zudem muss die Pkw-Option kombinierte Reiseketten über Park-and- Ride-Parkplätze (P+R) und die Fahrrad-Option kombinierte Reiseketten über Bike-and- Ride-Anlagen (B+R) mit anschließendem Umstieg in den Linienverkehr unterstützen.

4. Verkehrsmittelfilter Es muss die Möglichkeit bereitgestellt werden, bestimmte Verkehrsmittel gezielt von der Routenberechnung auszuschließen oder einzuschränken, um beispielsweise reine Bus- oder Straßenbahnverbindungen zu erzwingen.

5. Anpassung von Gehgeschwindigkeit und Fußwegen Es müssen Optionen zur individuellen Anpassung von Fußwegen angeboten werden. Nutzende müssen ihre Gehgeschwindigkeit in mehreren Stufen von sehr langsam bis sehr schnell sowie die maximale Dauer des Fußwegs zur Haltestelle festlegen können. Zudem muss die Option bestehen, nahegelegene Alternativhaltestellen bewusst vom Routing auszuschließen.

6. Regulierung der Umsteigehäufigkeit Die Benutzeroberfläche muss einen Filter bereitstellen, mit dem die maximale Anzahl der Umstiege im Fahrtverlauf begrenzt werden kann, bis hin zur ausschließlichen Suche nach Direktverbindungen.

7. Echtzeitinformationen und Prognose-Integration Die Routenberechnung bezieht aktuelle Echtzeit- und Prognosedaten wie u. a. Ver- spätungen, Verfrühungen oder Fahrtausfälle ein, sofern diese von der VVO-Web-API für die jeweilige Fahrt zur Verfügung gestellt werden. Das System nutzt diese Daten, um die prognostizierten Abfahrts- und Ankunftszeiten entlang der Reisekette fortzuschreiben und die Durchführbarkeit von Umstiegen realitätsnah zu bewerten. Liegen für Teilstrecken keine Ist- oder Prognosedaten vor, greift das System automatisch auf die regulären Soll- Fahrplandaten zurück.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 61 von 111

[Seite 62]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

8. Individuelle Barrierefreiheits- und Mobilitätsfilter In den Filteroptionen müssen differenzierte, barrierefreie Einstellungen zur individuellen Reiseplanung bereitgestellt werden. Das System hat hierfür vordefinierte Schnellauswah- len für verschiedene Mobilitätsprofile sowie eine detaillierte Filterauswahl zur Feinjustie- rung spezifischer Kriterien anzubieten. Die konkrete Ausgestaltung und Benennung der Filter im UI ist im Laufe des Projekts zu präzisieren. Die folgenden Kriterien sind hierbei als exemplarische Mindestanforderungen zu verstehen:

a) Beispiele für vordefinierte Schnellauswahlen: Profile für Rollstuhlnutzende, Personen mit Rollatoren, Fahrgäste mit Kinderwagen oder Reisende mit schwerem Gepäck.

b) Beispiele für detaillierte Filterkriterien: Ausschluss von Treppen/Stufen, Bevorzugung von Rampen und Aufzügen, Vorgabe maximaler Einstiegshöhen an Haltestellen oder die Berücksichtigung von Mindestumsteigezeiten für mobilitätseingeschränkte Perso- nen.

4.14.3 Ergebnisanzeige und Fahrgastinformation

1. Visuelle Übersichtlichkeit Die vorgeschlagenen Verbindungen müssen auf einen Blick alle wesentlichen Kerninfor- mationen strukturiert abbilden. Die Übersicht muss mindestens u. a. verständliche Sym- bole für die genutzten Verkehrsmittel, die Liniennummern, die Echtzeit-Abfahrts- und An- kunftszeiten, die Gesamtreisedauer, die Anzahl der Umstiege sowie eine erste indikative Preisauskunft beinhalten.

2. Integration von Echtzeitinformationen In der Fahrtenübersicht sowie in den Fahrtdetails muss die aktuelle Verkehrssituation exakt gespiegelt werden. Das System hat für die visuelle Aufbereitung von Zeitdaten eine klare dreistufige Logik anzuwenden, um Fahrgästen maximale Datentransparenz zu bie- ten:

a) Bei Abweichungen (Verspätung/Verfrühung): Besteht eine tatsächliche Abweichung vom Soll-Fahrplan, ist die Differenz im Format „+X/-X“ prominent anzuzeigen und die neu prognostizierte Ankunfts- bzw. Abfahrtszeit einzublenden.

b) Bei Pünktlichkeit: Liegen Echtzeitinformationen für die Fahrt an und das Fahrzeug ist exakt fahrplankonform unterwegs, muss diese verifizierte Pünktlichkeit für die Fahr- gäste aktiv und unmissverständlich visualisiert werden. Dies dient der bewussten Ab- grenzung zu Fahrten ohne Echtzeit-Verbindung.

c) Bei fehlenden Echtzeitdaten (Soll-Fahrplan): Liegen für einen Fahrtabschnitt tempo- rär keine Ist- oder Prognosedaten vor, blendet das System die regulären Soll-Fahr- plandaten ein. Diese sind optisch neutral und ohne jegliche Minuten- oder Pünktlich- keitskennzeichnung darzustellen, damit für den Fahrgast sofort erkennbar ist, dass es sich um eine reine Fahrplanzeit handelt.

3. Logik für gefährdete Anschlüsse Beträgt die berechnete Übergangszeit an einem Umstiegspunkt im aktuellen Verkehrsge- schehen weniger als 1 Minute, muss das System eine visuelle Warnung als explizite Un- terbrechung der Fahrtdetails einbauen. Diese muss unmissverständlich darauf hinwei- sen, dass die Fahrt nicht wie geplant stattfinden kann und der Anschluss voraussichtlich nicht erreichbar ist.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 62 von 111

[Seite 63]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4. Visualisierung von Haltestellen- und Fahrtausfällen Fällt eine Haltestelle im Fahrtverlauf aus, muss direkt an der betroffenen Station ein Aus- fallhinweis geschaltet werden, ergänzt um eine allgemeine Warnung zur Fahrt. Fällt eine Fahrt vollständig aus, ist ein allgemeiner Warnhinweis auszugeben und eine unüberseh- bare Kennzeichnung in den Fahrtdetails sowie in der Fahrtenübersicht zu verankern.

5. Anzeige des Besetztgrades Für jeden Fahrtabschnitt, sofern Besetztgradinformationen vorhanden sind, muss dem Nutzer ein intuitiver, grafischer Hinweis zur erwarteten Fahrzeugauslastung gespiegelt werden. Für die visuelle Ausgabe sind die von der DVB gelieferten Icons einzubinden, wobei textuell und symbolisch zwischen vier Stufen unterschieden werden muss: „Ge- ringe Auslastung erwartet“, „Mittlere Auslastung erwartet“, „Hohe Auslastung erwartet“ und „Keine Angabe möglich“.

6. Hinweise zu geplanten Linienänderungen und Störungsmeldungen Liegt auf einer vorgeschlagenen Route eine geplante Linienänderung oder Ad-hoc Stö- rung vor, muss ein entsprechender Warnhinweis direkt am betroffenen Fahrtabschnitt an- gezeigt werden. Dabei müssen sich die verschiedenen Störungstypen visuell voneinan- der unterscheiden. Beim Klick auf diesen Störungstext müssen die über die VVO-Web- API gelieferten Detailinformationen für die Nutzenden aufgerufen werden.

7. Anzeige von Großraummeldungen Liegt eine Großraummeldung vor, die das Gesamtnetz oder weite Teile des Bedienungs- gebietes betrifft (z. B. Streik, extreme Witterung oder Großveranstaltungen), muss diese global und unübersehbar in der Ergebnisseite der Verbindungsauskunft platziert werden. Diese Großraummeldungen sind nach aktuellem Stand rein informativer Natur. Um eine sofortige, barrierefreie Wahrnehmung zu garantieren, müssen sie optisch besonders stark hervorgehoben werden.

8. Automatische Aktualisierung (Soll-Anforderung) Bleibt eine berechnete Verbindung in der Anwendung geöffnet, sollte das System plötzli- che Betriebsausfälle, Verspätungsänderungen oder Gleis- und Steigwechsel automatisch und ohne manuelles Neuladen der Seite in der Benutzeroberfläche aktualisieren. Die technische Umsetzung ist vom bietenden Unternehmen so zu konzipieren, dass die Ba- ckend-Infrastruktur auch bei hoher Last stabil bleibt.

4.14.4 Interaktive Detailansicht und Komfort-Features

1. Detaillierter Fahrtverlauf mit Zwischenhalten Beim Aufklappen oder Erweitern einer Verbindung muss das System den Linienverlauf mit allen dazwischenliegenden Haltestellen in der korrekten Reihenfolge anzeigen. Für Zwischenhalte müssen die Abfahrtszeit sowie die aktuellen Echtzeit-Abweichungen und eventuelle Gleis- oder Steigänderungen übersichtlich ablesbar sein. Das System muss ein klares Interaktionselement bereitstellen, über welches die Zwischenhalte standardmä- ßig platzsparend eingeklappt sind, jedoch durch die nutzende Person stufenlos ein- und wieder ausgeblendet werden können.

2. Linienband in den Fahrtdetails: Beim Erweitern einer Verbindung muss der detaillierte Fahrtverlauf im Frontend als verti- kales Linienband dargestellt werden.

a) Farbcodierung: Das Linienband muss die offizielle Kennfarbe der jeweiligen Linie bzw. des Verkehrsmittels als durchgehende Achse aufgreifen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 63 von 111

[Seite 64]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

b) Haltestellen-Hierarchie: Einstiegs-, Umstiegs- und Ausstiegshaltestellen müssen als primäre Knotenpunkte visuell hervorgehoben und immer volltextlich eingeblendet werden. Die dazwischenliegenden Haltestellen sind standardmäßig platzsparend ein- zuklappen, müssen jedoch über ein klares Interaktionselement ausgeklappt werden können.

3. Favoritenfunktion für Verbindungen und Haltestellen Innerhalb der Verbindungsauskunft muss ein intuitives Element platziert werden, mit dem die nutzende Person sowohl eine gewählte Verbindung als auch eine spezifisch ausge- wählte Haltestelle als Favorit abspeichern kann, um diese bei zukünftigen Suchen direkt aufrufen zu können.

4. Direktes Linien-Abonnement im Fahrtverlauf: In der Detailansicht einer Verbindung bzw. einer spezifischen Linie innerhalb des Fahrt- verlaufs muss eine intuitive Funktion integriert werden, die es Fahrgästen ermöglicht hier- über, mit wenigen Klicks gezielte RSS-Feeds oder Push-Notifications für die ausgewählte Linie zu aktivieren. Die vollständige technische Abwicklung des Abonnements, die Bereit- stellung der Kanäle sowie die differenzierten Funktionsumfänge für Gäste und registrierte Nutzende erfolgen zentral nach den plattformweiten Vorgaben aus Kapitel 4.16.3.

5. Absprung zur Reisebegleitung „Schutzengel“ An jeder berechneten Verbindung ist ein gut sichtbares Interaktionselement zu platzieren, das es den Nutzenden ermöglicht, die gewählte Fahrt über die „Schutzengel“-Funktion zu überwachen. Bei Klick auf dieses Element müssen die Nutzenden in einen geführten Workflow geleitet werden, über den die Fahrt entweder einmalig oder als regelmäßiges Abonnement zur automatischen Überwachung eingerichtet werden kann. Hierbei sind die im Kapitel 4.15 definierten Anforderungen vollständig zu berücksichtigen.

6. Direktaufruf des Linienfahrplans durch ISOLI-Integration Direkt an den jeweiligen Haltestellen innerhalb des detaillierten Fahrtverlaufs muss ein Interaktionselement integriert sein, das den direkten Aufruf und barrierefreien Download des haltestellenspezifischen PDF-Linienfahrplans ermöglicht.

7. Kalender-Export und Sharing-Funktion Jede gefundene Verbindung muss über leicht zugängliche Werkzeuge nahtlos in den All- tag des Fahrgasts integriert werden können:

a) Komfort-Sharing: Bereitstellung einer Ein-Klick-Funktion zum Teilen der Verbindung. Dies umfasst die Generierung eines persistenten Deeplinks sowie die direkte Anbin- dung an gängige Messenger-Dienste und die Nutzung der nativen Web-Share-API des Endgeräts.

b) Kalender-Export: Integration einer Funktion zum direkten Export der Reisedaten im standardisierten ICS-Format. Das System muss eine fehlerfreie Datei generieren, die Abfahrts- und Ankunftszeiten, Liniennummern und die Haltestellennamen in den per- sönlichen Kalender des Nutzers übernimmt.

c) Optimierte Druckansicht: Für Fahrgäste, die ihre Verbindung ausdrucken möchten, muss eine integrierte Druckfunktion bereitgestellt werden. Bei Aktivierung dieser Funktion müssen alle für den Ausdruck nicht relevanten Seitenelemente ausgeblen- det werden. Es ist ein übersichtliches, strukturiertes und tintensparendes Layout zu generieren, das die wesentlichen Informationen der Reisekette optimal für den analo- gen Ausdruck aufbereitet. Die technische Umsetzung hat sich an modernen, barriere- freien Web-Standards zu orientieren.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 64 von 111

[Seite 65]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.14.5 Kartografische Unterstützung

1. Interaktive Kartendarstellung Jeder berechneten Verbindung muss eine interaktive, performante Kartenansicht zuge- ordnet werden. Die Karte muss den gesamten Routenverlauf geografisch exakt abbilden.

a) Visuelle Trennung: Die einzelnen Fahrtabschnitte sind auf der Karte in der Linien- farbe des jeweiligen Verkehrsmittels darzustellen. Fußwege, Start- und Umstiegs- punkte müssen visuell deutlich von liniengebundenen Fahrten abgegrenzt werden.

b) Interaktion: Startpunkte, Umstiegsknoten (inkl. Steig-Wechsel) und Zielpunkte müs- sen mit eindeutigen Icons markiert sein. Bei Klick auf ein Verkehrsmittel oder eine Haltestelle auf der Karte müssen die entsprechenden Detailinformationen z. B. in ei- nem Popup/Tooltip geliefert werden. Der Kartenausschnitt muss sich bei Auswahl ei- ner Verbindung automatisch optimal anpassen.

2. Detaillierte Wegeleitung für Fußwege Bei Fußweg-Etappen, insbesondere bei komplexen Umstiegen an großen Knotenpunk- ten, reicht die bloße Anzeige der Gehzeit nicht aus. Das System muss eine präzise, barri- erefreie Schritt-für-Schritt-Wegeleitung in Textform generieren. Diese Wegeleitung muss sowohl in den textuellen Fahrtdetails als auch visuell auf der Karte präzise nachvollzieh- bar sein.

3. Anzeige von Umleitungswegen Das System muss im Fall von betrieblichen Störungen oder geplanten Linienänderungen den konkreten Verkehrsstörungsstandort, bezogen auf den betroffenen Streckenab- schnitt bzw. die digitale Netzkante, auf der Karte visualisieren. Der tatsächliche Umlei- tungsweg der betroffenen Linie muss geometrisch exakt und farblich deutlich abgehoben auf der interaktiven Karte dargestellt werden.

4.14.6 Integrierte Haltestellenauskunft (Abfahrtsmonitor)

Die Übersicht bereitet alle aktuellen Abfahrten der Haltestelle fahrgastfreundlich auf und infor- miert auf einen Blick über anstehende Fahrten, Verfrühungen/Verspätungen, aktuelle Linien- änderungen sowie Ad-hoc Störungen.

Grundsatz zur technologischen Umsetzung: Für die Anzeige von Echtzeitdaten, die visuelle Darstellung von Störungen, Linienbändern und Auslastungen sowie für alle Komfort-Features gelten eins zu eins die identischen funktionalen und visuellen Anforderungen der Verbindungs- auskunft (Kapitel 4.14.2 bis 4.14.5).

Ergänzend und spezifisch für die Haltestellenauskunft müssen folgende Kriterien umgesetzt werden:

1. Integrierte Suchumschaltung Innerhalb der zentralen Ortssuche (siehe 4.14.1) muss eine intuitive Wechselmöglichkeit bereitgestellt werden, um direkt nach einer Haltestelle und deren Abfahrten zu suchen, anstatt eine Start-Ziel-Route zu berechnen.

2. Chronologische Abfahrtsliste Die Darstellung der Fahrten erfolgt als chronologisch sortierte Liste aller anstehenden Abfahrten dieser spezifischen Station, gefüttert aus der VVO-WebAPI. Nutzende müssen die Liste über granulare Filteroptionen nach Datum, Uhrzeit sowie spezifischen Verkehrs- mitteln einschränken können.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 65 von 111

[Seite 66]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

3. Zugriff auf Aushangfahrpläne Direkt in der Haltestellenansicht ist eine nach Verkehrsmitteln sortierte Übersicht aller dort verkehrenden Linien zu integrieren. Über diese muss der direkte, barrierefreie Down- load der offiziellen, statischen PDF-Linienfahrpläne ermöglicht werden, wobei die zeitge- steuerte Gültigkeitsprüfung im Hintergrund über die entsprechende Schnittstelle erfolgt.

4.14.7 Kauf aus der Verbindungsauskunft

1. Kauf aus der Verbindungsauskunft An jeder berechneten Verbindung muss ein prominentes Interaktionselement für den Ti- cketkauf platziert werden. Dieses Element zeigt den berechneten Gesamtpreis für die in der Eingabemaske gewählte Personenanzahl und den passenden Tarif an. Bei Klick auf dieses Element wird die Person an den Ticketshop übergeben, wobei die Reisedaten, die Tarifzonen und die ausgewählte Ticketart als strukturierte Daten im Hintergrund mitgelie- fert werden, um einen schnellen Bezahlprozess zu ermöglichen.

2. Fallback-Regelung bei fehlender Preisauskunft Kann für eine Verbindung keine konkrete Preisauskunft ermittelt werden, muss das Inter- aktionselement in einen neutralen Status versetzt werden. Um Fehlkäufe zu vermeiden und das Nutzererlebnis beim Ticketkauf positiv zu gestalten ist ein Workflow zu erarbei- ten der z. B. die Preisanzeige ausblendet und die Beschriftung in eine neutrale Formulie- rung zu ändern und bei Klick erfolgt eine sichere Weiterleitung auf die manuelle Ticke- tauswahl des Ticketshops.

3. Absprung zur Buchung von Bike- und Carsharing Beinhaltet eine vorgeschlagene Verbindung Abschnitte mit Sharing-Angeboten, muss ein direktes Interaktionselement integriert werden. Sofern es die technische Schnittstelle des jeweiligen Mobilitätsanbieters zulässt, ist die Reservierung und anschließende Buchung des Sharing-Angebots so nahtlos wie möglich direkt im Frontend einzubinden. Ein exter- ner Absprung der nutzenden Person soll nach Möglichkeit verhindert werden. Sollte eine native Integration in die digitale Anwendung schnittstellenseitig nachweislich nicht reali- sierbar sein, dient das Element als direkter Absprung zur Buchung oder Reservierung auf der Plattform des Mobilitätspartners. Auch in diesem Fall sind relevante Buchungsdaten automatisch im Hintergrund zu übergeben, um den Prozess für die Nutzenden so medi- enbruchfrei wie möglich zu gestalten.

4.14.8 Integration der alita-Buchung

1. Visuelle Kennzeichnung im Suchergebnis Wenn eine berechnete Route einen Fahrtabschnitt enthält, welcher von einem Anruflini- entaxi (alita) abgedeckt wird, muss dieser im Frontend unmissverständlich als Bedarfs- verkehr gekennzeichnet werden. Das System muss ein spezifisches alita-Symbol anzei- gen und einen unübersehbaren Hinweis auf die einzuhaltende Voranmeldefrist von min- destens zwanzig Minuten vor der planmäßigen Abfahrt ausgeben.

2. Direktes Interaktionselement zur Bestellung Direkt an der betroffenen Verbindung muss ein prominenter Button mit der Beschriftung zur alita-Buchung platziert werden.

3. Buchungsprozess Die Buchung einer alita-Fahrt muss vollständig über ein integriertes, barrierefreies Formu- lar abgewickelt werden. Eine Weiterleitung auf externe Buchungsplattformen ist unzuläs- sig. Das Formular muss alle für die Disposition notwendigen Angaben dynamisch erfassen und validieren:

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 66 von 111

[Seite 67]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

a) Fahrgast-Zuordnung: Option zur Angabe eines abweichenden Fahrgastnamens (falls die buchende Person nicht selbst fährt).

b) Kapazitätsrelevante Merkmale: Abfrage der Anzahl der reisenden Personen, getrennt nach Erwachsenen und Kindern, sowie spezifischer Mobilitäts- und Mitnahmerkmale wie u. a. klappbarer Rollstuhl, Rollator, erleichterter Einstieg, Kinderwagen, Gepäck- stücke, Fahrrad oder die Mitnahme von Tieren.

c) Automatisierte Datenübergabe: Die fahrtspezifischen Kerndaten, wie Start- und Ziel- haltestelle, Liniennummer und planmäßige Abfahrtszeit, müssen automatisch aus der gewählten Verbindung im Hintergrund mitgeführt werden.

4. Schnittstellen-Kommunikation und Antwort-Logik Die Übermittlung der Buchungsdaten erfolgt verschlüsselt über eine Echtzeit-Program- mierschnittstelle an die übergeordnete Verkehrsdatenplattform der DVB. Das System muss eine asynchrone Kommunikationslogik mit einer angemessenen Timeout-Schwelle (maximal 30 Sekunden) implementieren. Bleibt eine Antwort der Plattform innerhalb die- ser Frist aus, ist ein automatisierter Wiederholungsversuch einzuleiten oder der nutzen- den Person eine verständliche Fehlermeldung anzuzeigen.

5. Dynamische Anzeige des Bestellstatus Das Frontend muss in der Lage sein, verschiedene Rückmeldungen der Schnittstelle, wie „übermittelt“, „bestätigt/vermittelt“ oder „nicht verfügbar“, live zu verarbeiten und in der Benutzeroberfläche visuell ansprechend zu spiegeln. Bei einer erfolgreichen Vermittlung sind dem Fahrgast die eindeutige Buchungsnummer sowie, sofern über die Schnittstelle bereitgestellt, fahrzeugspezifische Erkennungsmerkmale und telefonische Kontaktmög- lichkeiten zum Fahrpersonal des Taxis barrierefrei anzuzeigen.

6. Kopplung mit DVB-Account und Stornierungs-Infrastruktur Ist die buchende Person in ihrem DVB-Account eingeloggt, sind Profilname und Kontakt- daten im Formular vorauszufüllen. Bestätigte Buchungen müssen sofort im persönlichen Dashboard des Accounts hinterlegt werden. Das Frontend muss dort eine native Funk- tion zur Stornierung der Fahrt inklusive der optionalen Angabe eines Stornierungsgrun- des bereitstellen, welche den Auftrag direkt an die Schnittstelle übermittelt, sofern die geltende Frist (bis zu 20 Minuten vor der Abfahrt) eingehalten wird.

4.14.9 Optionale innovative Erweiterungsvorschläge

1. Einreichung von Mehrwertfunktionen Über die oben genannten Mindestanforderungen hinaus wird das Bieterunternehmen ausdrücklich dazu eingeladen, innovative Konzepte und technologische Erweiterungsvor- schläge für die Verbindungsauskunft einzureichen.

4.15 Reisebegleitung „Schutzengelfunktion“

Als ergänzender digitaler Service ermöglicht die kontinuierliche Reisebegleitung „Schutzen- gelfunktion“ die aktive Überwachung einer bereits ausgewählten Verbindung. Das System ver- knüpft hierzu im Hintergrund die geplante Reisekette über den bestehenden Schutzengel-Ser- ver mit den Echtzeitdaten des laufenden Betriebs, um Nutzende automatisiert über relevante Änderungen auf der gewählten Route zu informieren. Für die funktionale und visuelle Umset- zung dieses Moduls gelten die folgenden Kriterien:

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 67 von 111

[Seite 68]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.15.1 Systemintegration und technisches Verhalten

1. Integration der Schutzengel-Library Für die clientseitige Kommunikation mit der Server-Infrastruktur muss die bereitgestellte Schutzengel-Library nahtlos in die Web-Applikation integriert werden. Das bietende Un- ternehmen ist dafür verantwortlich, die Schnittstellen der Library im Frontend anzuspre- chen, um Datenpakete sauber zu übergeben und serverseitige Statusmeldungen perfor- mant zu verarbeiten.

2. Push-Notifications Da die Reisebegleitung auch bei gesperrtem Bildschirm oder im Hintergrundbetrieb des Endgeräts zuverlässig funktionieren muss, ist die Signalisierung als systemseitige Push- Notification umzusetzen. Für den Versand dieser Benachrichtigungen stellt die DVB eine bereits eingerichtete Infrastruktur auf Basis von Firebase Cloud Messaging (FCM) zur Verfügung. Das bietende Unternehmen ist dafür verantwortlich, die Web-Applikation im Frontend so zu konzipieren, dass diese FCM-Infrastruktur über standardisierte, browser- basierte Hintergrunddienste performant angesprochen wird. Eingehende Statusmeldun- gen des Schutzengel-Servers müssen auf Basis etablierter Web-Standards ohne spür- bare Verzögerung direkt auf dem Endgerät bzw. dem Sperrbildschirm der Nutzenden ausgegeben werden.

3. Robustes UI-Verhalten bei Netzunterbrechungen Das Frontend muss so konzipiert sein, dass ein temporärer Signalverlust zu einem tole- ranten Systemzustand führt. Der zuletzt geladene Überwachungsstatus bleibt lesbar und wird optisch unaufdringlich als historischer Stand gekennzeichnet. Sobald die Netzwerk- verbindung wiederhergestellt ist, reaktiviert das System die Datenaktualisierung im Hin- tergrund selbstständig.

4.15.2 Kernfunktionen der Reiseüberwachung

1. Episodenbasierte Fahrtenüberwachung via Schutzengel-Server Das System muss es ermöglichen, eine von den Nutzenden ausgewählte Verbindung an den bestehenden Schutzengel-Server zu übergeben, um diese aktiv zu verfolgen. Die Reisekette ist dabei intern in Abschnitte „Episoden“ zu unterteilen. Eine Episode definiert sich jeweils durch den Zustieg, die Fahrt in einem spezifischen Fahrzeug, den Ausstieg sowie die dazwischenliegenden Fußwege (z. B. Start-, Umstiegs- und Zielabschnitte).

2. Periodische Fortschritts- und Positionsberechnung Für aktiv überwachte Verbindungen muss das System in regelmäßigen Intervallen eine automatisierte Fortschrittsberechnung über den Schutzengel-Server anstoßen. Das Frontend muss in der Lage sein, den prozentualen Fortschritt der Gesamtfahrt sowie eine vom System geschätzte geografische Position der reisenden Personen entlang des Lini- enverlaufs visuell und dynamisch aufbereitet darzustellen.

3. Alternativfahrten bei Fahrtgefährdung Erkennt das System über den Schutzengel-Server eine Gefährdung der Reisekette, muss den Nutzenden innerhalb der Benachrichtigungsmaske ein direktes Steuerungsele- ment zur Suche nach Alternativen bereitgestellt werden.

a) Anzeige und Auswahl: Nach Interaktion ist eine Liste mit aktuellen, alternativen Fahrt- möglichkeiten auszugeben. Wird eine dieser Alternativen durch die reisende Person ausgewählt, muss diese als neu zu begleitende Fahrt übernommen werden können und die ursprünglich aktive Fahrt im Überwachungsfokus ablösen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 68 von 111

[Seite 69]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

b) Vergleichende Darstellung in der Übersicht: Nach der Übernahme einer Alternative muss die Benutzeroberfläche des Moduls so aufgebaut sein, dass sowohl die ur- sprünglich geplante Fahrt (für die Nachvollziehbarkeit visuell dezent), als auch die neu gewählte, aktive Alternative parallel in der Maske abgebildet werden.

c) Interaktiver Detailwechsel: Nutzende müssen innerhalb dieser Ansicht flexibel zwi- schen den Detailansichten der ursprünglichen Fahrt, mit fortlaufend aktualisierter Auskunftsabfrage, und den Details der gewählten Alternative wechseln können.

4.15.3 Benutzeroberfläche und Benachrichtigungen

1. Zentrale Übersicht zur Reisebegleitung Das Modul muss über eine zentrale, konsistente Benutzeroberfläche gesteuert werden. Diese Übersicht dient als Anlaufpunkt für alle Schutzengel-Funktionen und muss eine strukturierte Übersicht über aktive, geplante sowie inaktive Verbindungen bereitstellen.

2. Individuell konfigurierbare Benachrichtigungstypen Die Alarmierungsoptionen müssen für jeden Überwachungsplan separat und feingranular angepasst werden können. Das System muss dedizierte Steuerungselemente bereitstel- len, um Benachrichtigungen unabhängig voneinander ein- oder auszuschalten. Nach ak- tuellem Stand sind das folgende Benachrichtigungstypen:

a) (vor) Beginn: Benachrichtigungen zur Fahrt bis zu 60 Minuten im Voraus

b) Umstieg: Benachrichtigungen bei Umstiegen mit Haltestellen und Steigangabe

c) bei Problem: Benachrichtigung bei Störungen, Verfrühungen oder Verspätungen, An- schlussverlusten, Fahrtausfall, etc.

3. Direkteinstieg aus Benachrichtigungen (Deeplink) Die Interaktion mit einer systemseitig empfangenen Benachrichtigung auf dem Endgerät darf nicht lediglich die Einstiegsseite der Web-Applikation aufrufen. Das System muss so konzipiert sein, dass Nutzende über den Klick oder Tipp direkt in die entsprechende De- tailansicht, der zentralen Übersicht zur Reisebegleitung oder, im Fall einer Fahrtgefähr- dung, unmittelbar in die Maske zur Alternativensuche geleitet werden.

4.15.4 Verknüpfung DVB-Account, Historisierung und Migration

1. Funktionsumfänge für Gäste und registrierte Nutzende Für die Aktivierung der Reisebegleitung gelten je nach Authentifizierungsstatus der Nut- zenden differenzierte Funktionsumfänge:

a) Unangemeldeter Zustand: Die Überwachung ist ausschließlich für einmalige Reisebe- gleitungen zulässig. Nach Beendigung oder Abbruch der Fahrt wird der aktive Über- wachungsplan beendet, die Daten müssen jedoch im lokalen Speicher des Endgeräts erhalten bleiben und in der Historie einsehbar sein.

b) Angemeldeter Zustand: Eingeloggte Personen können Fahrten über den DVB-Ac- count, zusätzlich zur einmaligen Begleitung, auch als wiederkehrende, regelmäßige Reisebegleitung einrichten. In diesem Zustand ist die Anzahl der gleichzeitig angeleg- ten Überwachungspläne im Frontend auf maximal 5 Fahrten zu begrenzen.

2. Historie begleiteter Fahrten Das System muss für jede angelegte oder abonnierte Verbindung eine nachvollziehbare

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 69 von 111

[Seite 70]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Historie der in der Vergangenheit bereits durchgeführten und aktiv begleiteten Fahrten bereitstellen.

a) Integrierte Bereitstellung: Diese Historie ist direkt innerhalb der Übersicht zur Reise- begleitung im Bereich für letzte Fahrten darzustellen.

b) Datenhaltung: Bei registrierten Nutzenden werden die historischen Fahrtdaten dauer- haft serverseitig mit dem DVB-Account synchronisiert. Bei anonymen Gästen erfolgt die Speicherung ausschließlich lokal im Speicher des Endgeräts, sodass die Historie in der Übersicht fortlaufend erhalten bleibt, solange die Browserdaten nicht gelöscht werden.

c) Inhalt: Die Historie muss eine Übersicht über die stattgefundenen Episoden sowie die zugehörigen, vom Schutzengel-Server empfangenen Benachrichtigungen und Status- meldungen enthalten.

3. Migration bei nachträglicher Anmeldung am DVB-Account Führt eine Person, die im Rahmen einer anonymen Gästenutzung eine einmalige Reise- begleitung gestartet hat, zu einem späteren Zeitpunkt eine Registrierung durch oder mel- det sich im zentralen DVB-Account an, müssen der aktuell laufende Überwachungsplan sowie die lokale Fahrtenhistorie im Hintergrund und verlustfrei über den Schutzengel- Server in den zentralen DVB-Account zusammengeführt werden.

4.16 Zentrale Linienänderungen, Störungsinformationen und Großraummeldun- gen

Dieses Modul bündelt alle geplanten Linienänderungen, Ad-hoc Störungen sowie Großraum- meldungen und stellt diese konsistent auf der gesamten Plattform bereit. Die Datenbasis speist sich dynamisch aus der VVO-WebAPI und der Vehrkehrsdatenplattform (VDP) der DVB. Die zugrundeliegenden Störungstexte werden hierbei automatisiert über das FGI-Tool generiert und über die VVO-WebAPI zur Verfügung gestellt.

Für die funktionale und technische Umsetzung gelten folgende Kriterien:

4.16.1 Zentrale Übersichts- und Filterseite

Das System muss eine dedizierte, performante Übersichtsseite für Linienänderungen, Störun- gen und Großraummeldungen bereitstellen, welche plattformweit als Anlaufpunkt dient. Diese Seite muss folgende Funktionen abbilden:

1. Priorisierte Platzierung von Großraummeldungen Netzweite oder linienübergreifende Großraummeldungen müssen im dedizierten Bereich als oberste, gestalterisch hervorgehobene Ebene implementiert werden. Sie stehen visu- ell über den regulären Linien- und Ad-hoc-Störungsmeldungen, um eine sofortige Wahr- nehmung bei Aufruf des Bereichs zu erzwingen.

2. Visuelle Markierung von neuen Meldungen Für Nutzende muss auf den ersten Blick intuitiv erkennbar sein, wenn eine neue, bisher ungelesene Meldung vorliegt.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 70 von 111

[Seite 71]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

3. Einsatz spezifischer Icons pro Meldungstyp Um trotz der gleichrangigen Priorisierung in der Ausgabeliste eine sofortige Orientierung zu ermöglichen, müssen geplante Linienänderungen und Ad-hoc-Störungen über eindeu- tige, prägnante Icons visuell unmissverständlich voneinander unterscheidbar sein.

4. Zeitliche Filterung Das System muss intuitive Filter- und Bedienstrukturen bereitstellen, die es Nutzenden erlauben, die Meldungen flexibel nach ihrem Gültigkeitszeitraum bzw. ihrer zeitlichen Re- levanz zu segmentieren. Großraummeldungen können von dieser zeitlichen Filterung ausgenommen oder als dauerhaft aktiv gekennzeichnet werden, sofern die Schnittstelle dies vorgibt.

5. Linienbezogene Suche Für Fahrgäste muss es möglich sein, die Anzeige nach dem gewünschten Geltungsbe- reich einzugrenzen. Das System hat hierfür flexible Auswahlfunktionen bereitzustellen, die folgende Filterungen erlauben:

a) gezielte Beschränkung rein auf Linien und Meldungen der DVB

b) Auswahl großräumiger, verbundweiter Linien und Änderungen im gesamten Bereich des VVO

c) direkte Suche oder Schnellauswahl einer oder mehrerer spezifischer Liniennummern

6. Inhaltliche Filterung nach Verkehrsmitteln Ergänzend muss die Übersicht einfache Auswahlmöglichkeiten nach Verkehrsmitteltypen beinhalten.

4.16.2 Strukturierte Detailansicht und Infomedien

Beim Aufruf einer spezifischen Großraummeldung, Linienänderung oder Ad-hoc-Störung ge- neriert das System eine barrierefreie Detailansicht, die modular aufgebaut ist und folgende Elemente nahtlos zusammenführt:

1. Beschreibung und Umleitungsgrafiken Neben dem automatisiert über das FGI-Tool generierten und via VVO-WebAPI bereitge- stellten Beschreibungstext müssen der Meldung zugeordnete Umleitungskarten oder In- fografiken zugänglich gemacht werden. Das Frontend hat diese Grafiken responsiv und stufenlos zoombar darzustellen. Diese Umleitungsgrafiken sind vom System automati- siert und performant vom zentralen VDP-Fileserver abzurufen und der jeweiligen Mel- dung zuzuordnen.

2. Integration von Begleitmedien Handelt es sich um eine geplante Linienänderung, muss das System die Verknüpfung und den direkten Download von Informationsmedien wie z. B. Flyer zu Baumaßnahmen, sofern diese vorliegen, unterstützen.

3. Fahrplan-Synchronisations-Status In der Detailansicht muss für den Fahrgast ein unmissverständlicher, visueller Hinweis ausgespielt werden, ob die vorliegende Änderung bereits vollständig in den regulären Fahrplandaten berücksichtigt ist oder ob es sich um eine kurzfristige Abweichung han- delt.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 71 von 111

[Seite 72]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.16.3 Abonnement-Infrastruktur und Verknüpfung DVB-Account

Um eine flexible, zeitnahe und proaktive Information der Fahrgäste zu gewährleisten, sind die folgenden Kanäle vollumfänglich und modular zu realisieren:

1. Bereitstellung von RSS-Feeds Für alle Meldungstypen ist ein dynamischer RSS-Feed über eine persistente URL bereit- zustellen, den Nutzende barrierefrei abonnieren können. Der Feed hat strukturell das DVB-Logo, den Titel und alle zugehörigen Änderungseinträge zu beinhalten.

2. Infrastruktur für Push-Notifications Es ist eine datenschutzkonforme Push-Infrastruktur zu implementieren, welche die von der DVB bereitgestellte zentrale Firebase-Cloud-Messaging-Infrastruktur (FCM) als tech- nisches Backend nutzt. Fahrgäste müssen die Möglichkeit haben, direkte Echtzeit-Be- nachrichtigungen über das Frontend zu aktivieren, um bei Großraummeldungen, relevan- ten Linienänderungen oder Störungen der abonnierten Linie(n) informiert zu werden. Die technische Umsetzung des Frontends hat auf etablierten, offenen Web-Standards zu ba- sieren und die FCM-Schnittstellen über Hintergrunddienste sauber anzusprechen. Die Ar- chitektur ist dabei so zu konzipieren, dass das System modular aufgebaut und technolo- gisch offen für eine spätere Erweiterung auf zusätzliche clientseitige Endpunkte ist, ohne dass ein Wechsel der zugrundeliegenden Firebase-Infrastruktur erforderlich wird.

3. E-Mail-Abonnement (Option) Als optionale und separat im Angebot auszuweisende Leistung hat das Bieterunterneh- men einen konkreten technischen Lösungsvorschlag einschließlich eines Realisierungs- angebots für ein E-Mail-Abonnement von Linienänderungen anzubieten. Sollte diese Op- tion durch die DVB beauftragt werden, muss sich der Versand nahtlos in die bestehende Systemlandschaft integrieren. Die Konfiguration und Verwaltung dieses E-Mail-Abonne- ments für registrierte Nutzende muss in diesem Fall ebenfalls vollständig über das zent- rale Dashboard des DVB-Accounts abgebildet werden.

4. Funktionsumfang für Gäste und registrierende Nutzende Für die Aktivierung von Linienänderungs- und Störungsinformations-Abonnements gelten je nach Authentifizierungsstatus der Nutzenden differenzierte Funktionsumfänge:

a) Unangemeldeter Zustand: Die Einrichtung von Push-Benachrichtigungen für Linien ist auch ohne Registrierung direkt zulässig. Die Konfiguration sowie die Verknüpfung des browserbasierten Benachrichtigungs-Tokens müssen im lokalen Speicher des Endgeräts erhalten bleiben und in der Übersicht fortlaufend einsehbar sein.

b) Angemeldeter Zustand: Eingeloggte Personen können Linien-Abonnements über den DVB-Account einrichten. In diesem Zustand werden die abonnierten Linien dauerhaft serverseitig mit dem DVB-Account synchronisiert. Nutzende müssen ihre Abonne- ments flexibel im zentralen Dashboard innerhalb ihres DVB-Accounts verwalten, z. B. einsehen, bearbeiten und löschen, können.

4.16.4 Systemweite Integration

Die Störungs- und Änderungsinformationen dürfen kein Silo sein, sondern müssen an allen relevanten Touchpoints der Plattform einfließen:

1. Startseite Hochpriorisierte Großraummeldungen werden gemäß Kapitel 4.4.1 direkt im obersten Sichtbereich der Startseite ausgespielt.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 72 von 111

[Seite 73]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Verbindungsauskunft Liegt auf einer berechneten Route eine Störung oder Änderung vor, ist diese gemäß Ka- pitel 4.14.3 direkt am betroffenen Fahrtabschnitt visuell zu kennzeichnen und mit der De- tailansicht dieses Moduls zu verlinken.

3. Haltestellenauskunft (Abfahrtsmonitor) Bei der Abfrage spezifischer Haltestellendaten müssen dort anliegende Linienänderun- gen oder Störungen, welche die an dieser Station verkehrenden Linien betreffen, unüber- sehbar eingeblendet werden. Auch hier ist ein direkter Absprung zur entsprechenden De- tailansicht zu realisieren.

4.17 Interaktive Karte

Dieses Kapitel umfasst die Konzeption und technische Bereitstellung einer zentralen, hoch- performanten und interaktiven Kartenkomponente, die als geografisches Fundament für die gesamte Plattform dient. Die Komponente ist architektonisch so zu konzipieren, dass sie so- wohl als eigenständige, vollwertige Ansicht über einen dedizierten Menüpunkt in der Hauptna- vigation zur Verfügung steht, als auch als modular wiederverwendbares Element nahtlos und kontextbezogen in andere Services und Detailseiten (z. B. Haltestellendetails, Verbindungs- auskunft, Baustellenberichte) eingebettet werden kann.

Das System muss eine flexible, herstellerunabhängige und auf offenen Datenstandards basie- rende Kartengrundlage nutzen, die standardisierte Kacheldienste unterstützt. Die Kartenkom- ponente muss vollständig über performante APIs gesteuert werden und clientseitig so optimiert sein, dass sie auch auf mobilen Endgeräten bei minimalem Datenverbrauch flüssig und ver- zögerungsfrei funktioniert.

Hinweis zur Innovationsöffnung: Die nachfolgend beschriebenen Kriterien definieren den funktionalen und technischen Mindestleistungsumfang für die interaktive Kartenkomponente. Da sich kartenbasierte Technologien, Web-Rendering-Verfahren und die Integration intermo- daler Mobilitätsangebote fortlaufend weiterentwickeln, versteht die DVB dieses Anforderungs- profil nicht als abschließend. Bieterunternehmen sind ausdrücklich dazu eingeladen, innova- tive Konzepte, modernste UI/UX-Ansätze sowie optionale technologische Erweiterungsvor- schläge einzubringen, wie geografische Informationen für Fahrgäste noch intuitiver und barri- erefreier erlebbar gemacht werden können.

Für die funktionale und technische Umsetzung gelten die folgenden Kriterien:

4.17.1 Modulare Layer-Architektur und Interaktionssteuerung

Die Kartenkomponente muss standardmäßig ein dynamisches und erweiterbares Layer-Sys- tem unterstützen, sowohl in der Vollansicht als auch in den eingebetteten Kontexten. Nutzende müssen in der Lage sein, unterschiedliche Informationsebenen nach ihren individuellen Infor- mationsbedürfnissen flexibel ein- und auszublenden.

1. Steuerung der Informationsebenen Das System muss intuitive Steuerungselemente bereitstellen, über die mindestens die Ebenen für Haltestellen, multimodale Mobilitätspunkte (MOBIpunkte), Park-and-Ride-An- lagen (P+R), Bike-and-Ride-Anlagen (B+R), E-Ladesäulen (Stromtankstellen), Echtzeit- Fahrzeugpositionen sowie betriebliche Linienänderungen unabhängig voneinander ge- schaltet werden können.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 73 von 111

[Seite 74]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Objektbasierte Interaktion in Echtzeit Bei der Interaktion mit einem Kartenelement, z. B. einer Haltestelle, einem Fahrzeug oder einem POI, müssen dem Fahrgast direkt spezifische Detailinformationen in Echtzeit zur Verfügung gestellt werden. Dazu gehören je nach Elementtyp Informationen wie aktuelle Abfahrtszeiten, Fahrzeugdetails, Linienverläufe oder die Verfügbarkeit von Sharing-Ange- boten.

3. High-Density-Performance Da im städtischen Raum eine sehr hohe Dichte an Echtzeit-Icons und geografischen Da- tenpunkten parallel dargestellt werden muss, hat das Bieterunternehmen geeignete, mo- dernste Rendering-Technologien einzusetzen. Ein flüssiges Zoomen und Verschieben der Karte muss auch bei maximaler Layer-Auslastung gewährleistet bleiben.

4.17.2 Live-Fahrzeugvisualisierung und RBL-Integration

Das System muss eine interaktive Live-Kartenansicht abbilden, welche die aktuellen Standorte aller im Liniennetz aktiv befindlichen Fahrzeuge visuell wiedergibt.

1. Echtzeit-Datenbezug via VDP (MQTT) Die Positions- und Bewegungsdaten werden über die zentrale VDP der DVB bereitge- stellt. Das System muss hierzu einen Datenstream über den MQTT-Broker der VDP auf das spezifische Topic vehicle Data abonnieren und die Daten latenzfrei im Frontend ver- arbeiten.

2. Fahrzeugabdeckung und funktionale Ausnahmen Die Visualisierung umfasst grundsätzlich alle im System angemeldeten Fahrzeuge des Linienverkehrs. Nach aktuellem Stand sind von der Darstellung auf der interaktiven Karte Taxis, Fähren sowie Bergbahnen ausgenommen. Die DVB prüft derzeit die Einbindung dieser Fahrzeugtypen.

3. Fahrzeugspezifische Detailtiefe Bei Auswahl eines Fahrzeugs auf der Karte sind dem Nutzenden die übertragenen Attri- bute dynamisch anzuzeigen. Hierzu gehören zwingend:

a) Fahrzeugtyp und Fahrzeugnummer

b) aktueller geografischer Standort

c) aktuelle Linie und Fahrtziel

d) aktueller Besetztgrad des Fahrzeugs (zur Unterstützung der Fahrgastkomfort-Infor- mation)

4. Verbindungsbezogene Integration Die Kartenkomponente muss technologisch in der Lage sein, diese Live-Fahrzeugdaten auch verbindungsbezogen auszusteuern. Wird eine konkrete Route aufgerufen, soll das dazugehörige Fahrzeug direkt auf seinem prognostizierten Fahrtverlauf live visualisiert werden können.

5. Zukünftige und flexible Filtermöglichkeiten Für die Anzeige der Fahrzeuge auf der Karte sind sinnvolle Filtermöglichkeiten wie z. B. nach Fahrzeugtyp oder Linie vorzusehen. Da die exakten Kriterien und Parameter erst im weiteren Projektverlauf gemeinsam definiert werden, muss die technische Architektur der Filterlogik von Beginn an flexibel, offen und erweiterbar gestaltet sein.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 74 von 111

[Seite 75]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.17.3 Multimodale MOBIpunkt-Karte mit Echtzeitdaten

Zur Förderung der intermodalen Mobilität ist eine dezidierte Funktion zur Visualisierung aller physischen MOBIpunkte der DVB zu implementieren.

1. Datenbezug über die VDP Die geografischen Standorte und statischen Stammdaten aller MOBIpunkte sowie weite- rer Infrastrukturelemente, wie P+R, B+R und Stromtankstellen, werden über die VDP be- zogen. Das System hat diese Daten direkt über die entsprechenden Schnittstellen abzu- rufen.

2. P+R und B+R mit Live-Auslastung Die Karte muss alle offiziellen P+R- und B+R-Anlagen verorten. Es ist eine Funktion zu implementieren, welche aktuelle Stellplatzkapazitäten, die Gesamtzahl der Plätze sowie den aktuellen Belegungsgrad in Echtzeit direkt über die Detailansicht des jeweiligen Ob- jekts für die Nutzenden einsehbar macht. Die dafür notwendigen dynamischen Daten sind aus der VDP zu beziehen.

3. nutzungszentrierte Standort-Lokalisierung Es ist eine datenschutzkonforme Lokalisierungsfunktion zu integrieren. Stimmen Nut- zende der Standortermittlung zu, hat sich der Kartenausschnitt automatisch auf die aktu- elle Position zu zentrieren und nahegelegene Haltestellen sowie MOBIpunkte priorisiert sichtbar zu machen.

4.17.4 Geografische Darstellung von Linienänderungen

Betriebliche Abweichungen und geänderte Linienführungen müssen für Fahrgäste geogra- fisch eindeutig und intuitiv auf der Karte verortet werden.

1. Datenbasis aus der VDP Die Daten zu den aktiven Linienänderungen, Umleitungsstrecken und temporären Halte- stellenverlegungen werden vollständig über die entsprechende Schnittstelle der VDP be- reitgestellt.

2. Geografische Visualisierung von Umleitungen Eine aktive Linienänderung muss auf der Karte geometrisch präzise dargestellt werden. Das System darf sich nicht auf eine rein textliche Information beschränken, sondern muss Umleitungsstrecken visuell eindeutig im Kartenbild kennzeichnen.

3. Temporäre Haltestellenänderungen Entfallende bzw. nicht bediente Haltestellen sowie temporär eingerichtete Ersatzhalte- stellen müssen auf der Karte klar symbolisiert und mit den Detailinformationen der jewei- ligen Linienänderung verknüpft sein.

4.17.5 Modulare Verknüpfung mit redaktionellen Inhalten (Option)

Es soll die Möglichkeit geschaffen werden, die interaktive Kartenkomponente flexibel mit re- daktionellen Inhalten z. B. Bauprojekten, Netzentwicklungen oder Statusberichten aus dem CMS zu verknüpfen.

1. Schnittstellen- und Architektur-Offenheit Die Kartenkomponente und das CMS müssen architektonisch so konzipiert sein, dass im Projektverlauf definierte redaktionelle Inhalte wie Projektphasen, Zeitstrahle oder Status-

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 75 von 111

[Seite 76]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Piktogramme geografisch auf der Karte verortet oder die Karte modular in diese Inhalts- seiten eingebettet werden können. Das exakte funktionale Zusammenspiel wird im Rah- men der Konzeptionsphase final definiert.

4.17.6 Barrierefreiheit und Systemintegration (UI/UX)

1. Ergänzende Anforderungen zur barrierefreien Karteninteraktion In Ergänzung zu den globalen Vorgaben zur Barrierefreiheit (siehe Kapitel 5.2) muss die Kartenkomponente den gängigen Richtlinien gemäß BITV 2.0 und WCAG 2.2 Level AA vollumfänglich entsprechen. Dies erfordert zwingend, dass alle wesentlichen Kartenfunk- tionen und die Filtersteuerung auch per Tastatur bedienbar sein müssen. Für Screenrea- der ist eine strukturierte, listenbasierte Darstellung als funktionaler Fallback bereitzustel- len.

2. Visuelle Integration und Adaption Die Kartenelemente und -hintergründe müssen sich gestalterisch nahtlos an das Ge- samtdesign der Plattform anpassen. Das System muss hierzu eine dynamische Um- schaltung unterstützen, um beispielsweise bei einem aktiven Dark Mode oder bei kon- trastreichen Ansichten für sehbehinderte Menschen eine optimierte, gut lesbare Karten- darstellung auszusteuern.

4.18 Digitaler Abfahrtsmonitor (WebDFI)

Der digitale Abfahrtsmonitor (WebDFI) ermöglicht es externen Nutzenden, z. B. Unternehmen, Bildungseinrichtungen, Smart-Mirror-Betreibern oder Privatpersonen, eine flexibel skalierbare Abfahrtsanzeige im Design der physischen DVB-Anzeiger auf beliebigen Endgeräten zu nut- zen. Die gesamte Anwendung ist als rein clientseitiges, zustandsloses Frontend-Modul zu re- alisieren. Eine serverseitige Speicherung von Monitor-Profilen oder Benutzerkonten durch die DVB ist explizit nicht vorgesehen.

4.18.1 Web-Konfigurator

Auf einer regulären Unterseite der Website wird ein Konfigurationstool bereitgestellt, das aus- schließlich im Browser der nutzenden Person operiert. Alle Eingaben werden rein clientseitig und in Echtzeit direkt in URL-Parameter übersetzt:

1. Haltestellen- und Liniensteuerung Für die datenseitige Steuerung der Anzeige werden im Konfigurator folgende browserba- sierte Auswahlmöglichkeiten bereitgestellt:

a) Multi-Station-Support: Kombination von bis zu 3 Haltestellen in einer gemeinsamen Anzeige

b) Einstellbarkeit pro Haltestelle: freier Anzeigename, Verkehrsmittelfilter und eine steig- bezogene Eingrenzung

c) Anzeigeumfang und Vorlaufzeit: Festlegung der Zeilen- und Spaltenanzahl der aus- zugebenden Abfahrten sowie die Definition einer Vorlaufzeit (in Minuten), ab wel- chem zukünftigen Zeitpunkt die Abfahrten auf dem Monitor berücksichtigt werden sol- len

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 76 von 111

[Seite 77]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Design- und Corporate-Identity-Engine Zur optischen Anpassung an das Erscheinungsbild der DVB umfasst die Design-Engine folgende konfigurierbare Parameter:

a) Umschalter für horizontales/vertikales Layout

b) Farbanpassung im DVB-Design: Steuerung der visuellen Farbwerte für Haltestellen- text, Tabellenkopf, Hintergrund, wechselnde Zeilenfarben, Steig-Anzeigen, Rahmen und Uhrzeit. Die Auswahl ist hierbei strikt auf vordefinierte, zulässige Farbvarianten des offiziellen DVB-Corporate-Designs einzuschränken. Die freie Eingabe beliebiger Farbcodes ist technisch auszuschließen.

c) Permanentes Branding: Das offizielle DVB-Logo ist fester und unveränderlicher Be- standteil der Anzeigeoberfläche. Es muss auf jedem konfigurierten Monitor dauerhaft und gut sichtbar eingeblendet werden. Eine Option zum Ausblenden des Brandings oder zum Hochladen von Drittlogos ist nicht zulässig.

d) Typografie & Laufschrift: stufenlose Anpassung der Schriftgrößen für eine optimale Lesbarkeit auf unterschiedlichen Displaygrößen sowie Option zur Aktivierung und Konfiguration einer dynamischen Laufschrift

3. Aktualisierungsverhalten Um eine permanente Aktualität der Anzeige auf dem Endgerät zu gewährleisten, wird eine clientseitig gesteuerte Logik für die kontinuierliche, automatische Aktualisierung der Anzeigeoberfläche ohne Neuladen der Seite integriert, was die fortlaufende Versorgung des Monitors mit aktuellen Echtzeitdaten garantiert.

4.18.2 URL-Generierung und bildschirmunabhängiger Anzeigemodus

Die Ausgabe der konfigurierten Monitore erfolgt vollständig zustandslos über dynamische Hy- perlinks, welche eine maximale Flexibilität bei der Darstellung auf unterschiedlichen Endgerä- ten garantieren:

1. Zustandsloser Permalink Das Tool speichert keine Konfigurationsdaten in der zentralen Plattform-Infrastruktur. Nach der Konfiguration wird ein dynamischer Link generiert, der sämtliche Konfigurati- ons- und Designparameter vollständig als URL-Parameter mitführt.

2. Nutzerseitige Verwaltung Die Verantwortung für das Speichern und Verwalten der Links liegt vollständig bei den Nutzenden z. B. durch Abspeichern als Browser-Lesezeichen.

3. Clean UI Wird eine solche generierte URL aufgerufen, rendert das Frontend eine cleane, respon- sive Ansicht ohne jegliche Website-Elemente. Das Design passt sich automatisch und flüssig an die jeweilige Auflösung und Bildschirmgröße des aufrufenden Endgeräts an.

4.18.3 Technische Datenversorgung

Um die zentrale Web-Infrastruktur im Dauerbetrieb zu entlasten, basiert die Datenversorgung der Anzeigeoberfläche auf einer direkten und entkoppelten Kommunikation zwischen dem Endgerät und der hauseigenen Datenplattform:

1. Direkte API-Abfrage im Browser Das Laden der Fahrplandaten erfolgt entkoppelt von der zentralen Plattform-Infrastruktur

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 77 von 111

[Seite 78]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

der DVB. Der Browser des Endgeräts interpretiert die Haltestellen-IDs aus der URL und sendet die Datenanfragen direkt vom Endgerät des Nutzenden an die öffentliche API der zentralen Verkehrsdatenplattform (VDP) der DVB.

2. Lastminimierung Durch diese Client-zu-API-Architektur entsteht beim dauerhaften Betrieb von WebDFI- Abfahrtsmonitoren z. B. im 24/7-Dauerbetrieb keinerlei Performance- oder Traffic-Last auf der Infrastruktur der Hauptwebsite.

4.19 DVB-Account (Profilbereich)

Der DVB-Account fungiert als zentraler, passwortgeschützter Benutzerbereich und personali- sierter Hub für alle digitalen Interaktionen zwischen den Nutzenden und der DVB. Ziel ist eine konsequente Reduktion der Komplexität durch die Bündelung fragmentierter Dienste, wie per- sönliche Plattform-Einstellungen, Favoriten, Benachrichtigungen, Tickets und Feedback, unter einer einheitlichen, intuitiven und barrierefreien Benutzeroberfläche auf Basis eines Mobile- First-Ansatzes. Dieses Kapitel bildet die funktionale und technische Grundlage für die Umset- zung der Konzeptanforderung 4 – „DVB-Account (Profilbereich)“ im Anhang konzeptanforde- rungen.pdf. Die angebotene Lösung muss sowohl die datenbankseitigen Strukturen im Web- Backend als auch die Frontend-Logiken umfassen, um alle im Konzept verankerten Persona- lisierungs- und Servicefunktionen vollumfänglich bereitzustellen. Die zugrundeliegenden Stan- dards für das zentrale Identity Management (IdP) und Single Sign-On (SSO) werden in den dafür vorgesehenen Kapiteln dieser Ausschreibung spezifiziert und sind als fundamentale Schnittstelle in dieses Modul zu integrieren.

4.19.1 Systemarchitektur, Authentifizierungs-Schnittstelle und Datenhaltung

Für die Bereitstellung des geschützten Profilbereichs und der lokalen Datenstrukturen muss die angebotene Lösung folgende Kriterien erfüllen:

1. Verpflichtende Umsetzung des Account-Konzepts Die technische Bereitstellung des DVB-Accounts, inklusive Frontend, Backend-Logiken und lokaler Datenbanken, muss die vollständige, barrierefreie und performante Umset- zung des vom Bieterunternehmen einzureichenden Fachkonzepts auf Basis der Vorga- ben aus Anhang konzeptanforderungen.pdf (Konzeptanforderung 4 „DVB-Account (Profil- bereich)“) vollumfänglich ermöglichen.

2. Übergreifende Frontend-Logik und Dashboard-Struktur Der Profilbereich muss von jeder (Unter-)Seite der Plattform aus prominent, konsistent und barrierefrei erreichbar sein. Nach erfolgreicher Authentifizierung ist den Nutzenden eine intuitive Übersicht und Verwaltungsoberfläche für ihre wichtigsten Daten und Dienste bereitzustellen. Hierzu zählen u. a. die Konfiguration der persönlichen Startseite, Push-Benachrichtigungen, der Schutzengel-Dienst, aktive Abonnements sowie die Ti- ckethistorie.

3. Integration des zentralen Identity Managements (IdP / SSO) Die Plattform muss die Authentifizierungsprozesse gegen den zentralen Identity Provider nahtlos unterstützen. Die detaillierten technischen Anforderungen an den IdP und das Single Sign-On werden in den dafür vorgesehenen Kapiteln geregelt. Die hier angebo- tene Lösung muss diese Vorgaben im Profilbereich funktional und visuell vollständig adaptieren und die bereitgestellte User-ID als Primärschlüssel für alle verknüpften Dienste nutzen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 78 von 111

[Seite 79]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4. Account-Lifecycle und Passwort-Management Das System muss im Profilbereich sowie den zugehörigen Login-/Registrierungsmasken die vollständigen Workflows für das Benutzermanagement abbilden. Dies umfasst zwin- gend die Funktionen „Passwort ändern“, „Passwort vergessen/zurücksetzen“ sowie „Ac- count löschen“. Bei Ausführung der Funktion „Account löschen“ muss das Backend den Löschprozess im zentralen IdP anstoßen und gleichzeitig alle plattformseitig in der Pro- jektdatenbank gespeicherten Daten der Nutzenden automatisiert, unwiderruflich und DSGVO-konform bereinigen.

5. Zentrale Backend-Datenhaltung & API-Synchronisation Um eine geräteübergreifende Synchronisation in Echtzeit zu gewährleisten, muss die an- gebotene Lösung eine performante, backendseitige Datenhaltung bereitstellen. Das Sys- tem muss mindestens die Daten zu folgenden Funktionen eigenständig, dauerhaft und datenschutzkonform speichern und verwalten:

a) Consent-Management

b) persönliche Favoriten (wie Linien, Haltestellen, Verbindungen)

c) allgemeine Plattform-Präferenzen (u. a. Sprache oder Anzeigemodus)

d) individuelle Layout-Konfigurationen zur persönlichen Startseite

e) Nutzerdefinierte Push-Benachrichtigungen zu z. B. Linienänderungen und Schutzen- gelfunktion

6. Nutzerseitige Inhaltssteuerung der persönlichen Startseite Das System muss die strukturellen Rahmenbedingungen bereitstellen, damit Nutzende im eingeloggten Zustand Module der Startseite, wie die Verbindungsauskunft, Abfahrtsta- feln, News-Feeds, aktuelle Meldungen und die Ticketübersicht, eigenständig priorisieren, anordnen oder ausblenden können.

7. Performance-Optimierung und Schnittstellen-Resilienz Aufgrund der Vielzahl anzubindender Drittsysteme dürfen API-Abfragen das Laden des initialen Dashboards unter keinen Umständen blockieren. Nicht zeitkritische Daten sind zwingend asynchron nachzuladen. Um die Last auf den Umsystemen zu minimieren, ist ein intelligentes Caching für statische oder langlebige Profildaten zu implementieren. Sollte ein Drittsystem temporär nicht erreichbar sein, muss der Rest des Profilbereichs vollumfänglich funktionsfähig bleiben und den Teilausfall im UI transparent anzeigen.

4.19.2 Systemintegrationen und Drittanbieter-Schnittstellen (Commerce & Services)

Die Bündelung der Dienste im Profilbereich erfordert die tiefe funktionale Integration externer Datenströme über standardisierte APIs:

1. Commerce-Integration Der Profilbereich ist vollumfänglich mit dem Ticketshop-Backend zu synchronisieren. Hierbei gelten mindestens folgende spezifische Anforderungen:

a) Eingabe und Validierung der Abonnement-Nummer: Im Profilbereich muss ein barrie- refreies Eingabefeld bereitgestellt werden, in dem Nutzende ihre persönliche Abo- Nummer hinterlegen können. Das Backend der Plattform muss die eingegebene Nummer über eine bereitzustellende Schnittstelle gegen eine externe Datenquelle (Datenbank/Abgleichdatei) automatisiert auf Korrektheit und Vorhandensein prüfen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 79 von 111

[Seite 80]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

b) Datenbereitstellung für den Ticketshop: Nach erfolgreicher Validierung ist der verifi- zierte Abonnement-Status permanent im Profilbereich des Nutzenden zu speichern. Die Plattform muss diesen verifizierten Status über eine standardisierte API so für den Ticketshop bereitstellen, dass dieser bei nachfolgenden Ticketkäufen im Kauf- prozess automatisiert berücksichtigt und für die Rabattierung bzw. korrekte Preisbe- rechnung herangezogen werden kann.

c) Stammdaten und Historie: Neben der Abo-Verknüpfung muss die Integration die Ver- waltung von Vertragsdaten via automatisierter Synchronisation sowie die Anzeige der Kaufhistorie, aktiver Tickets und den direkten Rechnungs-Download umfassen.

2. Reisebegleitung „Schutzengel“ Über eine Schnittstelle zum IVI-System sind die Funktionen des Schutzengels im Profil- bereich zu aggregieren. Dies umfasst die Anzeige aktiv begleiteter Fahrten, die Integra- tion einer Historie begleiteter Fahrten, die Konfiguration der Begleitfrequenz sowie die automatisierte Ausspielung von Push-Benachrichtigungen via Google Firebase Cloud.

3. Push-Abonnement für Linienänderungen und Störungsinformationen Im Profilbereich muss eine zentrale, intuitive Verwaltung für die von den Nutzenden abonnierten Linien und gespeicherten Favoriten bereitgestellt werden. Nutzende müssen für jede Linie eigenständig konfigurieren können, ob sie proaktive Benachrichtigungen er- halten möchten. Der technische Versand dieser Benachrichtigungen wird über die von der DVB bereitgestellte Firebase-Cloud-Messaging-Infrastruktur abgewickelt.

4. Newsletter Opt-in/Opt-out Über die Benutzeroberfläche des Accounts müssen Nutzende den Newsletter-Versand für von der DVB zur Verfügung gestellte Medien (z. B. den Blog) jederzeit eigenständig abonnieren und deabonnieren können.

5. Nutzer-Self-Service für integrierte Sub-Konzepte Entsprechend den übergreifenden Anforderungen für das Blog-Fotobuch ist ein transpa- renter Self-Service-Bereich innerhalb des DVB-Accounts zu integrieren, über den Nut- zende erteilte Einwilligungen und Bildrechte einsehen und via Klick direkt widerrufen kön- nen, was einen Löschprozess im CMS anstoßen muss. Ebenso ist eine optionale Schnitt- stelle zur dauerhaften Speicherung spielerischer Fortschritte aus dem Gamification-Kon- zept architektonisch vorzubereiten.

6. Konzeptioneller Digitaler Notfallknopf Vom Bieterunternehmen wird im Rahmen des Angebots ein konkreter funktionaler und technischer Umsetzungsvorschlag für einen digitalen Notfallknopf im Account/Dashboard erwartet. Der Button muss in Notsituationen sofort auffindbar, jedoch durch Bestätigungs- mechanismen gegen versehentliches Auslösen geschützt sein. Das Konzept muss detail- liert darlegen, wie im Moment des Auslösens eine präzise Standortermittlung erfolgt, wie diese Geodaten datenschutzkonform übertragen und eine zuverlässige Alarmierungs- kette in Echtzeit sowie technische Voraussetzungen zur Missbrauchsprävention im Sys- tem vorbereitet werden.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 80 von 111

[Seite 81]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Hinweis für die Kapitel 4.20 bis 4.25:

Die nachfolgende Gliederung spiegelt den aktuellen Planungsstand der funktionalen und tech- nischen Anforderungen wider. Im Zuge der weiteren Finalisierung des Lastenhefts können sich aus Gründen der redaktionellen Übersichtlichkeit und Systematik rein organisatorische Anpas- sungen der Kapitelstruktur oder der Zuordnung von Unterpunkten ergeben. Der fachliche Leis- tungsumfang sowie die zugrundeliegenden inhaltlichen Anforderungen bleiben hiervon unbe- rührt.

4.20 Interoperabler DVB-Onlineshop in der Vertriebslandschaft (Architektur) und weitere einzubindende Systeme

Dieses Kapitel beschreibt die architektonischen Rahmenbedingungen für die Integration des neuen Onlineshops (inkl. Ticketshop) als interoperable, modulare Kernkomponente innerhalb der DVB-Vertriebsinfrastruktur. Ziel ist der Aufbau einer zukunftsfähigen Systemlandschaft, die Punkt-zu-Punkt-Verbindungen minimiert und auf einer flexiblen API-First-Architektur ba- siert. Das anbietende Unternehmen hat darzulegen, wie die nachfolgend aufgeführten Ba- ckend-, Dritt- und Verbundsysteme funktional sowie datenseitig nahtlos eingebunden werden, um klare Systemgrenzen und medienbruchfreie Datenflüsse zu gewährleisten.

4.20.1 Apps/Frontends (neu)

4.20.2 VVO-Tarifrechner

4.20.3 Integration des CiCo-Tarifs per SDK (z.Z. Fairtiq)

4.20.4 VVO-Barcode-Service

4.20.5 Vertriebshintergrundsystem (neu)

4.20.6 Warenwirtschaftssystem (neu)

4.20.7 Finanzdienstleister (z.Z. Logpay)

4.20.8 Wallet-Dienstleister

4.20.9 Identity Provider (neu)

4.20.10 Kundenservice-Portal (neu)

4.20.11 BI-Analyse (neu)

4.20.12 Technologien und Standards

4.20.13 Best Practices

4.20.14 Weiterentwicklungen

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 81 von 111

[Seite 82]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.21 Identitätsprovider mit Single Sign-On

Zur Schaffung eines zentralen, sicheren und benutzerfreundlichen Zugangs plant die DVB die Implementierung eines zentralen Identity Providers (IdP) mit Single Sign-On (SSO) für alle digitalen Kanäle (z. B. Web-Plattform, Ticketshop, DVB-Account). Die Lösung muss ein dem Stand der Technik entsprechendes Identitäts- und Berechtigungsmanagement für B2C- und B2B-Nutzungskontexte abbilden. Das Bieterunternehmen hat in den folgenden Unterpunkten das technische Konzept zu den geforderten Schnittstellen, Sicherheitsstandards, den Authen- tifizierungsverfahren inkl. MFA sowie die Migrationsstrategie für bestehende Identitätssysteme (Keycloak/MENTZ IDP) detailliert darzustellen.

4.21.1 Betriebsmodelle

4.21.2 Schnittstellen & Integration

4.21.3 Integration und Interoperabilität

4.21.4 Performance

4.21.5 Integration und Migration von Keycload und MENTZ IDP

4.21.6 Identitätsmanagement / Zentrale Nutzergruppenverwaltung (B2C, B2B, Mitarbei- ter, Partner)

4.21.7 Authentifizierung

4.21.8 User Journey - nahtlose Integration

4.21.9 Content-Management

4.21.10 Technologien und Standards

4.21.11 Best Practices

4.21.12 Weiterentwicklungen

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 82 von 111

[Seite 83]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.22 DVB-Onlineshop inkl. Ticketshop

Der zu realisierende DVB-Onlineshop dient als zentrales Verkaufsorgan für das gesamte Ti- cketsortiment sowie optionale Nebensortimente (z. B. Souvenirs) im B2C- und B2B-Kontext. Die Anforderung umfasst die Bereitstellung hochgradig intuitiver Kaufprozesse, sowohl aus einer Verbindungsauskunft heraus als auch als Direktkauf. In den nachfolgenden Abschnitten hat das anbietende Unternehmen zu beschreiben, wie die Lösung die funktionale Trennung von Verkaufslogik und Frontend realisiert, Tarifupdates verarbeitet, persistente Warenkörbe führt sowie flexible Rabattierungs- und Ticketausgabemechanismen bereitstellt.

4.22.1 Integration und Interoperabilität

4.22.1 Identitätsmanagement & Authentifizierung über IDP (B2C, B2B, Mitarbeiter, Partner)

4.22.1 Authentifizierung

4.22.2 Produktkatalog (B2C, B2B, Mitarbeiter, Partner)

4.22.3 Verlinkung Abo-Shop

4.22.4 Handling Tarifupdate

4.22.5 Bereitstellung Content-Management-System

4.22.6 Verkauf und Transaktion

4.22.7 Ticketbereitstellung über alle Kanäle

4.22.8 User Journey - Design des Kaufprozesses

4.22.9 Bereitstellung Content-Management-System

4.22.10 BI/Analyse

4.22.11 Technologien und Standards

4.22.12 Best Practices

4.22.13 Weiterentwicklungen

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 83 von 111

[Seite 84]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.23 Kundenservice-Ökosystem aus Kunden- und Ticketsystem

Um Kundenanliegen für den Onlineshop effizient, strukturiert und nachvollziehbar zu bearbei- ten, fordert die DVB den Aufbau eines integrierten Kundenservice-Ökosystems. Dieses setzt sich aus einem zentralen Ticketsystem zur Vorgangsbearbeitung sowie einer webbasierten Verwaltungs- und Supportoberfläche für Kunden- und Fahrscheindaten zusammen. Das Bie- terunternehmen hat darzulegen, wie durch eine tiefe Systemintegration ein medienbruchfreier Arbeitsplatz für die Kundenservice-Fachkräfte geschaffen wird. Dieser muss eine vollständige Einsicht in die Profile der Nutzenden und Transaktionshistorien gewähren sowie administrative Aktionen, wie die Bearbeitung von Fehlkäufen, Sperrungen, Stornierungen und Erstattungen, direkt im System ermöglichen.

4.23.1 Integration und Interoperabilität

4.23.2 Identitätsmanagement & Authentifizierung über IDP

4.23.3 Verwaltungsoberfläche

4.23.4 Zentrale Verwaltung von Kunden- und Fahrscheindaten

4.23.5 Ticketsystem

4.23.6 Zusammenspiel beider Systeme (Kundenverwaltung und Ticketsystem)

4.23.7 Übergreifende Funktionen

4.23.8 Usability - Intuitive Bedienung und schnelle Informationsfindung

4.23.9 Plattformfähigkeit

4.23.10 BI/Analyse

4.23.11 Technologien und Standards

4.23.12 Best Practices

4.23.13 Weiterentwicklungen

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 84 von 111

[Seite 85]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4.24 Reporting & Analyse

Zur datengestützten Steuerung, Vertriebsabrechnung und Prognose benötigt die DVB eine umfassende Datenbasis über alle Geschäftsvorfälle der Vertriebslandschaft. Die angebotene Lösung muss Verkaufs- und Nutzungsdaten automatisiert, revisionssicher und DSGVO-kon- form aufbereiten. Das Bieterunternehmen hat in diesem Abschnitt zu beschreiben, wie Daten- modelle strukturiert, standardisierte Exportformate bereitgestellt und automatisierte Schnitt- stellen zu nachgelagerten Systemen bedient werden.

4.24.1 Interoperabilität und Verarbeitung von Daten aus anderen Systemen der Ver- triebslandschaft

4.24.2 Datenformate

4.24.3 Datenaktualisierung

4.25 Mandantenfähigkeit (Optional)

Perspektivisch beabsichtigt die DVB, als Vertriebsdienstleister für externe Partner und Ver- kehrsunternehmen aufzutreten. Zu diesem Zweck soll die anzubietende Lösung als mandan- tenfähiges Gesamtsystem mit strikter logischer oder physischer Datentrennung bei gemeinsa- mer Plattformnutzung konzipiert werden. Das Bieterunternehmen hat darzustellen, wie diese Architektur realisiert wird und wie mandantenspezifische Konfigurationen effizient verwaltet und separat für die jeweiligen Partnerorganisationen ausgerollt werden können.

4.25.1 Zentrale Mandantenverwaltung

4.25.2 Mandantenbezogene Konfigurationen

4.25.3 Mandantenspezifisches Reporting und Controlling

4.25.4 Mandantenspezifischen Konfiguration von Prozessen und Geschäftsregeln

4.25.5 Mandantenanbindung - Unterstützung unterschiedlicher Betriebs- und Einfüh- rungsmodelle

4.25.6 Weiterentwicklung und Zukunftsfähigkeit

4.25.7 Roadmap für die Weiterentwicklung der Software

4.25.8 DevOps-Prozess / DevOps-Setup

4.25.9 Innovationsfähigkeit - Offenheit gegenüber neuen Trends/Technologien

4.25.10 Partizipation des Auftraggebers

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 85 von 111

[Seite 86]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

5. Übergreifende nicht-funktionale Anforderungen & Rahmenbedin-

gungen

Dieses Kapitel beschreibt die qualitativen Rahmenbedingungen. Da die DVB als zentraler Mo- bilitätsdienstleister und Betreiber kritischer Infrastrukturen (KRITIS) agiert, sind die Anforde- rungen an die Performance, die Barrierefreiheit sowie den Datenschutz von herausragender Bedeutung. Die nachfolgenden Vorgaben sind vom beauftragten Unternehmen zwingend ein- zuhalten und bilden das Fundament für einen stabilen, zukunftssicheren und gesetzeskonfor- men Betrieb der gesamten modularen Systemlandschaft.

5.1 Performance, Lastgrenzen & Verfügbarkeit

Der digitale Ticketverkauf und die Bereitstellung von Fahrgastinformationen in Echtzeit müs- sen auch unter extremen Rahmenbedingungen uneingeschränkt verlässlich funktionieren. Dieses Kapitel definiert die nicht-funktionalen Anforderungen an die Laststabilität, die System- geschwindigkeiten sowie die Ausfallsicherheit der gesamten Plattform, um insbesondere bei Großveranstaltungen oder unvorhersehbaren Ereignissen eine durchgehend hohe Perfor- mance zu garantieren.

Zur Gewährleistung der Vergleichbarkeit im Vergabeverfahren und als Basis für die spätere technische Abnahme werden folgende verbindliche Lastprofile für das Gesamtsystem festge- legt. Diese leiten sich aus den realen Nutzungshistorien der bestehenden Infrastrukturen der DVB unter Berücksichtigung von Zukunftswachstum und Sicherheitsaufschlägen ab:

5.1.1 Laststabilität und Skalierbarkeit bei Großevents

Um plötzliche und massive Zugriffswellen der Kundschaft ohne Performance-Verluste abzu- fangen, muss die Systemarchitektur hochgradig elastisch und belastbar konzipiert sein:

1. Bewältigung von Spitzenlasten Das Gesamtsystem muss so dimensioniert sein, dass es das definierte Spitzenlast-Sze- nario über einen Zeitraum von mindestens 60 Minuten ohne spürbare Verzögerungen und mit einer Fehlerrate von nachweislich unter 0,1 % verarbeitet. Für die Vertriebs- und E-Commerce-Module sowie für die Echtzeit-Verbindungsauskunft ist die laststabile Ver- arbeitung dieser Spitzen eine zwingende Mindestanforderung.

2. Elastische Ressourcenzuweisung Die Softwarearchitektur muss in der Lage sein, dynamisch und elastisch auf veränderte Lastanforderungen zu reagieren. Steigen die Zugriffszahlen über das Niveau des Nor- malbetriebs, müssen zusätzliche Rechen- und Speicherkapazitäten innerhalb der Infra- struktur vollautomatisch und ohne manuellen Eingriff hinzugeschaltet werden, um die Einhaltung der definierten Antwortzeiten auch im Peak-Szenario zu gewährleisten. Bei abfallender Last müssen sich die Ressourcen ebenso automatisiert wieder kostenopti- miert herunterskalieren.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 86 von 111

[Seite 87]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

5.1.2 System-Performance und Reaktionszeiten

Für eine optimale Nutzungsfreundlichkeit und barrierefreie Interaktion müssen alle Teilsys- teme kurze Antwortzeiten aufweisen. Das beauftragte Unternehmen hat sicherzustellen, dass unter normaler Volllast folgende Grenzwerte nach dem 95. Perzentil nicht überschritten wer- den. Im definierten Spitzenlast-Szenario dürfen sich diese Werte um maximal 50 % erhöhen:

1. Time to First Byte Die Antwortzeit des Servers/CDNs bis zum ersten Byte darf bei gecachten Inhalten 200 Millisekunden und bei dynamischen Anfragen 500 Millisekunden nicht überschreiten.

2. Frontend-Ladezeit Die optische Hauptladezeit der Anwendung im Browser der Nutzenden muss stabil unter 2,0 Sekunden liegen.

3. API-Antwortzeiten Schnittstellenabfragen für redaktionelle Inhalte müssen in unter 200 Millisekunden beant- wortet werden.

4. API-Antwortzeiten Komplexe Abfragen wie die Echtzeit-Fahrplanauskunft oder der Ticket-Bezahlvorgang müssen in unter 800 Millisekunden (maximal 1,0 Sekunde) verarbeitet sein.

5. Entkoppelte Datenverarbeitung Rechenintensive Prozesse oder Aktualisierungen im Hintergrund dürfen die Interaktion im Frontend zu keinem Zeitpunkt blockieren. Datenströme, wie hochfrequente Fahrzeug- Live-Standorte via MQTT, müssen asynchron verarbeitet werden, um flüssige Übergänge auf den Endgeräten zu gewährleisten.

5.1.3 Kapazitätssteuerung und Frühwarnsysteme

Zur proaktiven Vermeidung von Systemüberlastungen müssen integrierte Überwachungs- werkzeuge einen drohenden Ressourcenmangel frühzeitig und automatisiert signalisieren:

1. Automatisierte Warnmechanismen Das System muss über integrierte Warnmechanismen verfügen. Diese müssen drohende Kapazitätsengpässe, wie Engpässe bei CPU-/Speicherauslastung oder das Erreichen von API-Kontingenten, proaktiv erkennen und fehlerfrei an das zentrale Monitoring-Sys- tem melden.

2. Unterstützung des Supports Die Software muss entsprechende Metriken bereitstellen, die es dem beauftragten Unter- nehmen sowie den internen IT-Verantwortlichen ermöglichen, das kontinuierliche Nut- zungsverhalten zu analysieren und Kapazitäten vorausschauend anzupassen.

5.1.4 Verfügbarkeit und Fehlertoleranz

Das System muss so aufgebaut sein, dass der Teilausfall einzelner, nicht-kritischer Funktionen niemals zum Stillstand oder zur spürbaren Beeinträchtigung der kritischen Kernfunktionen der gesamten digitalen Plattform führt. Für die technische Umsetzung und die Bewertung der Sys- temarchitektur gelten folgende verbindliche Priorisierungen und spezifische Anforderungen an das Systemverhalten:

1. Kritische Kernfunktionen (Priorität 1 – Höchste Verfügbarkeit)

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 87 von 111

[Seite 88]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

a) Die Fahrplanauskunft und Echtzeit-Verbindungsauskunft (bezogen auf die Verarbei- tungs- und Darstellungsinfrastruktur der Plattform. Nachweisbare Ausfälle der zentra- len VVO-Hintergrundsysteme sind von der SLA-Berechnung ausgeschlossen.)

b) der digitale Vertrieb/E-Commerce-Module (Ticketkauf, Bezahlvorgang und Ticket-Ge- nerierung)

c) die bereitzustellende zentrale Authentifizierungsinfrastruktur (IDP) sowie das Single Sign-On

d) der persönliche Profilbereich (DVB-Account) zur Verwaltung von Kundendaten

e) die Anzeige und Verifizierung bereits lokal auf den Endgeräten geladener digitaler Ti- ckets (Gewährleistung der Offline-Fähigkeit)

f) das Eilmeldungs-Modul/der Live-Ticker für die hochpriorisierte Krisenkommunikation

2. Nicht-kritische Begleitfunktionen (Priorität 2 – Isolierbare Funktionen)

a) redaktionelle CMS-Inhaltsseiten (News, Blog, statische Informationsseiten)

b) die interaktive Kartenkomponente sowie deren Live-Daten-Layer (z. B. Live-Fahr- zeugvisualisierung oder Echtzeit-Auslastungsanzeigen von MOBIpunkten und P+R- Anlagen)

c) das konfigurierbare Feedback- und Bewertungssystem sowie die Einbindung von Drittdiensten (z. B. Chatbots)

3. Hohe Verfügbarkeitsraten Die Plattform, alle zugehörigen Teilsysteme sowie sämtliche geschäftskritischen Schnitt- stellen, insbesondere für den digitalen Vertrieb und die Echtzeit-Verbindungsauskunft, müssen eine durchgehende Hochverfügbarkeit von mindestens 99,9 % im Jahresdurch- schnitt aufweisen, um den digitalen Servicebetrieb rund um die Uhr zu gewährleisten. Für das redaktionelle CMS gilt eine Verfügbarkeit von mindestens 99,5 % im Jahresdurch- schnitt. Die Einhaltung der vertraglich vereinbarten Verfügbarkeit muss vom beauftragten Unternehmen fortlaufend überwacht und auf Nachfrage der DVB lückenlos dargelegt werden.

4. Fehlertolerantes Systemverhalten Sollten nachgelagerte Systeme oder externe Schnittstellen der Priorität 2 temporär aus- fallen, darf dies nicht zum Absturz oder zur Blockade der Funktionen in Priorität 1 führen.

5. Ausfall von externen Hintergrundsystemen Sollten externe Hintergrundsysteme, wie die Fahrplanberechnung des VVO, temporär ausfallen, darf dies ebenfalls nicht zum Absturz der gesamten Anwendung führen. Das System muss in einem solchen Fall eine nutzungsfreundliche Fehlermeldung ausgeben und alternative Funktionen weiterhin voll funktionsfähig halten.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 88 von 111

[Seite 89]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

5.2 Benutzbarkeit, Responsive Design & Barrierefreiheit

5.2.1 Durchgängige Konsistenz, Systemstatus und mobile Fehlertoleranz

Für eine durchgängig hohe Benutzbarkeit im mobilen und stationären Kontext müssen fol- gende Kriterien erfüllt werden:

1. Visuelle und strukturelle Konsistenz bei Drittsystemen Beim Wechsel zwischen der Kernplattform und integrierten Drittsystemen, externen Por- talen oder Whitelabel-Lösungen muss eine strikte visuelle und strukturelle Konsistenz ge- wahrt bleiben. Die globale Hauptnavigation sowie die grundlegenden Design- und Be- dienmuster müssen nahtlos übertragen werden, um Brüche in der Nutzungserfahrung zu verhindern.

2. Eindeutiges Feedback zum Systemstatus Bei allen zeitverzögerten Prozessen, insbesondere bei der Verbindungsauskunft, bei Ti- cket-Transaktionen oder bei der Datenverarbeitung im Kundenkonto, muss das System den aktuellen Status jederzeit transparent und barrierefrei anzeigen. Dies hat über visu- elle und für Screenreader optimierte Lade-Indikatoren zu erfolgen. Mehrfache Klicks auf Interaktionselemente während eines laufenden Ladevorgangs müssen systemseitig blo- ckiert werden, um Doppelbuchungen oder Systemfehler zu verhindern.

3. Fehlertoleranz bei Netzwerkunterbrechungen Da die Nutzung der Plattform primär im mobilen Raum und im öffentlichen Nahverkehr erfolgt, muss das System hochgradig fehlertolerant auf kurzzeitige Verbindungsabbrüche oder unvollständige Datenübertragungen reagieren. Bereits von Nutzenden eingegebene Formulardaten dürfen bei einem Signalverlust nicht serverseitig gelöscht werden, son- dern müssen lokal temporär gepuffert werden. Das System muss die Nutzenden über den Netzwerkstatus sowie über das konkrete weitere Vorgehen verständlich und barrie- refrei informieren.

5.2.2 Responsive & adaptive Darstellung

Die vorgeschlagene Lösung muss ein vollständig responsives und adaptives Layout aufwei- sen, um auf allen gängigen Endgeräten wie Desktop, Tablet, Smartphones sowie bei unter- schiedlichen Bildschirmauflösungen und Hoch- wie Querformat uneingeschränkt, barrierefrei und optimal nutzbar zu sein. Hierzu gelten folgende verbindliche Kriterien:

1. Layoutanpassung und Endgerätekompatibilität Inhalte, Navigation und interaktive Elemente müssen sich automatisch an die Bildschirm- größe von Desktop, Tablet und mobilen Endgeräten sowie an unterschiedliche Auflösun- gen anpassen, ohne dass ein Informationsverlust auftritt oder horizontal gescrollt werden muss.

2. Browser- und anwendungsübergreifende Ausführung Die fehlerfreie und responsive Darstellung muss sowohl bei der Nutzung über Standard- Webbrowser als auch bei der Ausführung als installierte Anwendung auf dem Endgerät vollumfänglich gewährleistet sein.

3. Unterstützung von Display-Orientierungen Die Anwendung muss sowohl im Hochformat als auch im Querformat uneingeschränkt nutzbar sein. Ein automatischer oder manueller Wechsel der Display-Orientierung durch

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 89 von 111

[Seite 90]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

die Nutzenden darf zu keinem Zeitpunkt zu einem Datenverlust in Formularen, zum Ab- bruch von Transaktionen oder zu einer fehlerhaften Verschiebung von Bedienelementen führen.

4. Stabilität des Layouts während des Ladevorgangs Zur Vermeidung von fehlerhaften Interaktionen auf mobilen Endgeräten muss das Layout während des asynchronen Nachladens von Inhalten, Skripten oder Werbeelementen vi- suell stabil bleiben. Unkontrollierte visuelle Sprünge von Textelementen oder Buttons während des Seitenaufbaus sind technisch vollständig auszuschließen.

5.2.3 Barrierefreiheitsgrundsatz und rechtliche Rahmenbedingungen

Die gesamte Plattform muss standardmäßig so konzipiert sein, dass eine barrierefreie Nutz- barkeit von Personen mit physischen, visuellen oder kognitiven Einschränkungen gewährleis- tet ist. Um dies rechtlich und qualitativ abzusichern, muss das System die Anforderungen der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) sowie die Web Content Accessibility Guidelines (WCAG) in der aktuell gültigen Version, mindestens jedoch Version 2.2, nach Level AA erfüllen.

Die Anforderungen an die Barrierefreiheit gelten ausdrücklich nicht nur für das öffentliche Frontend der Plattform, sondern auch für die im Zuge dieser Ausschreibung beauftragten Sys- teme, Oberflächen, Schnittstellen, funktionalen Konzepte und Zusatzfeatures. Alle Anforde- rungen gelten somit ausnahmslos für das Gesamtsystem.

Dies umfasst zwingend folgende Systeme/Komponenten:

1. Content-Management-System (CMS) Die Administrationsoberfläche und alle Editoren-Ansichten müssen für Redaktionsmitar- beitende mit Seheinschränkungen, speziell für die Nutzung mit Screenreadern und reiner Tastaturbedienung, vollständig barrierefrei bedienbar sein.

2. Verbindungsauskunft Die Eingabe von Start/Ziel, die Datumsauswahl sowie die Ausgabe der Fahrtübersichten und dynamischen Fahrpläne müssen semantisch korrekt und barrierefrei umgesetzt wer- den.

3. Ticketshop Sowohl die in das Frontend der Website eingebettete Variante als auch der Ticketshop als eigenständige (Whitelabel-)Lösung müssen den Barrierefreiheitsstandards lückenlos entsprechen.

4. Consent Management Die technisch integrierte Lösung zur Einholung von Nutzungs-Einwilligungen in Form ei- nes Consent Banners muss im Frontend vollständig barrierefrei umgesetzt werden. Der Banner muss zwingend vollumfänglich per Tastatur bedienbar und für die Nutzung mit Screenreadern optimiert sein, während gleichzeitig die getroffene Entscheidung der Nut- zenden rechtssicher im Hintergrund gespeichert wird.

5. Chatbot Das interaktive Assistenzsystem muss in seiner gesamten Bedienoberfläche im Frontend vollständig barrierefrei gestaltet sein. Die Umsetzung muss explizit die Unterstützung von Spracheingaben, eine integrierte Vorlesefunktion für die generierten Antworten sowie die uneingeschränkte und fehlerfreie Bedienbarkeit per Tastaturnavigation und Screenreader beinhalten.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 90 von 111

[Seite 91]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

6. Schnittstellen Alle bereitgestellten und genutzten Programmierschnittstellen müssen maschinenles- bare, semantische Rohdaten und standardisierte Fehlermeldungen liefern, um eine lü- ckenlos barrierefreie Weiterverarbeitung und Darstellung in den jeweiligen Frontends zu ermöglichen.

7. Funktionale Konzepte, Zusatzfeatures/-tools Die Kriterien der Barrierefreiheit gelten ausnahmslos für alle in diesem Lastenheft be- schriebenen funktionalen Konzepte, Module und interaktiven Features/Tools. Dies um- fasst ausdrücklich, aber nicht abschließend, das Kundenkonto (DVB-Account), Fotobuch, Oberflächen sowie alle zukünftigen funktionalen Erweiterungen, die im Rahmen des Pro- jekts umgesetzt werden.

5.2.4 Spezifische Barrierefreiheitskriterien

Für die Umsetzung gelten die folgenden verbindlichen Kriterien sowohl für die Desktop-Nut- zung im Browser als auch für die geräteübergreifende mobile Anwendung:

1. Konformitätsstufe Die Benutzeroberfläche muss die Kriterien der aktuellsten Version, mindestens aber Ver- sion 2.2, der WCAG Level AA erfüllen.

2. Tastaturbedienbarkeit und alternative Eingabe Alle interaktiven Elemente wie z. B. Menüs, Formulare und Buttons müssen vollständig und ohne Maus ausschließlich per Tastatur navigier- und bedienbar sein. Der Tastaturfo- kus muss jederzeit visuell deutlich erkennbar sein. Bei der Nutzung auf mobilen Endgerä- ten muss dies gleichermaßen für externe Tastaturen oder Braillezeilen gewährleistet sein. Komplexe Wischgesten dürfen nicht der einzige Weg sein, um eine Funktion auszu- führen.

3. Screenreader-Unterstützung Der Quellcode muss semantisch korrekt strukturiert sein, damit gängige Desktop-Screen- reader wie NVDA, JAWS oder vergleichbare sowie mobile Assistenztechnologien auf Smartphones wie Apple VoiceOver auf iOS, TalkBack auf Android oder vergleichbare die Inhalte fehlerfrei auslesen und interpretieren können.

4. Skalierbarkeit & Respektierung von Systemeinstellungen Die Inhalte müssen bei einer Zoom-Vergrößerung von bis zu 200 % ohne Verlust von Text oder Funktionalität lesbar sein. Ein horizontaler Scrollbalken ist dabei auf Standard- Bildschirmen zu vermeiden. Darüber hinaus muss die Anwendung responsiv auf die Ein- stellungen der Nutzenden reagieren. Wird im Browser oder im Betriebssystem des End- geräts ein Dunkelmodus oder eine systemseitige Textvergrößerung gewählt, muss sich die Darstellung automatisch und fehlerfrei anpassen.

5. Touch-Zielgrößen und Klickflächen Alle interaktiven Elemente wie z. B. Buttons, Links und Ticket-Auswahlelemente müssen eine ausreichende Mindestgröße aufweisen, um sowohl am Desktop per Maus als auch auf mobilen Displays per Fingertipp leicht und fehlerfrei bedienbar zu sein.

6. Kontraste und Farben Texte und grafische Bedienelemente müssen die geforderten Mindestkontrastverhält- nisse erfüllen. Farben dürfen niemals das einzige Mittel sein, um Informationen zu vermit- teln. Zum Beispiel müssen Fehlermeldungen zusätzlich durch Icons oder Textbausteine gekennzeichnet werden.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 91 von 111

[Seite 92]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

7. Alternativtexte Für alle nicht-textuellen Inhalte wie Bilder, Icons und Grafiken müssen äquivalente Alter- nativtexte bereitgestellt werden, es sei denn, es handelt sich um rein dekorative Elemente. Wird ein Inhaltselement als „dekorativ“ gekennzeichnet, muss das System automatisch sicherstellen, dass dieses Element im Frontend von assistierenden Technologien wie Screenreadern ignoriert wird.

5.2.5 Anforderungen an den Kontrastmodus und den Design-Switch

Die Plattform muss sowohl automatische Betriebssystem-Vorgaben als auch individuelle ma- nuelle Anpassungen der Darstellung durch die Nutzenden vollumfänglich unterstützen. Hierzu gelten die folgenden verbindlichen Kriterien:

1. Automatische Erkennung von Systemeinstellungen Das System muss systemseitige Einstellungen zur Barrierefreiheit der Nutzenden auto- matisch beim Aufruf der Seite erkennen und interpretieren. Dies betrifft vor allem Farb- umkehr- und Kontrasteinstellungen gängiger Betriebssysteme. Das System darf diese systemseitig erzwungenen Farben zu keinem Zeitpunkt durch eigene CSS-Vorgaben überschreiben, sondern muss das Kontrastverhältnis innerhalb dieses Modus im Front- end automatisch maximal erhöhen, um eine fehlerfreie Lesbarkeit zu garantieren.

2. Manueller Kontrastumschalter im Frontend Unabhängig von den jeweiligen Systemeinstellungen des Endgeräts muss für die Nut- zenden im sichtbaren Bereich des Frontends, bevorzugt im Header- oder Servicebereich, ein gut erkennbares und barrierefrei bedienbares Steuerelement bereitgestellt werden. Über dieses Element müssen Nutzende in der Lage sein, einen optimierten, kontrastrei- chen Darstellungsmodus jederzeit manuell zu aktivieren und zu deaktivieren.

3. Sitzungsübergreifende Speicherung der Präferenz Wird der Kontrastmodus von Nutzenden manuell im Frontend aktiviert oder deaktiviert, muss das System diese Entscheidung datenschutzkonform und sitzungsübergreifend speichern. Bei einem erneuten Aufruf der Plattform oder beim Navigieren zwischen ver- schiedenen Unterseiten und Modulen darf der Modus nicht zurückgesetzt werden, son- dern muss dauerhaft in der gewählten Einstellung aktiv bleiben, bis eine explizite Ände- rung durch die Nutzenden erfolgt. Eine notwendige Kopplung mit dem DVB-Account ist im Projektverlauf festzulegen.

5.2.6 Bereitstellung von Inhalten in einfacher oder leichter Sprache

Das Content-Management-System beziehungsweise die genutzte API muss die barrierefreie Bereitstellung sprachlich vereinfachter Inhalte nach folgenden Kriterien unterstützen:

1. Systemseitige Unterstützung und Mindestanforderung Das System muss die Generierung einer alternativen Textversion in einfacher oder leich- ter Sprache mittels eines integrierten KI-Tools oder einer entsprechenden Schnittstelle unterstützen, wobei die Umsetzung in einfacher Sprache die qualitative Mindestanforde- rung darstellt. Diese alternative Textversion muss für mindestens alle redaktionellen Hauptinhalte wie Nachrichten, komplexe Erklärtexte und zentrale Services bereitgestellt und redaktionell gepflegt werden können.

2. Globale Umschaltmöglichkeit im Frontend Für die Nutzenden muss im Headerbereich der Plattform eine eindeutige, intuitive und barrierefrei bedienbare Umschaltmöglichkeit zwischen dem Originaltext und der Version in einfacher beziehungsweise leichter Sprache global zur Verfügung stehen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 92 von 111

[Seite 93]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

5.2.7 Barrierefreie Downloads und Dokumentenstandards

Beim Verlinken von bereitgestellten Dokumenten müssen folgende Kriterien erfüllt werden:

1. Transparenz bei Dateiinformationen Beim Verlinken eines Download-Dokuments im Frontend muss das System automatisch die exakte Dateigröße sowie den jeweiligen Dateityp ermitteln und ausgeben, um die Nutzenden vorab transparent über die benötigte Bandbreite sowie die erforderliche Soft- ware zu informieren.

2. Barrierefreiheitsstatus und PDF/UA-Standard Für PDF-Dokumente muss im CMS ein separates Kennzeichnungsfeld bereitgestellt wer- den, über welches redaktionell hinterlegt werden kann, ob das entsprechende Dokument barrierefrei erstellt wurde. Diese Information bezüglich des Barrierefreiheitsstatus muss im Frontend verarbeitet und für die Nutzenden klar ersichtlich dargestellt werden. Bereit- gestellte barrierefreie Dokumente müssen hierbei vollumfänglich den Anforderungen des internationalen PDF/UA-Standards entsprechen.

5.2.8 Anforderungen an barrierefreie und mobile Formulare

Die auf der Plattform bereitgestellten Formulare müssen sowohl mobil optimiert als auch voll- ständig barrierefrei umgesetzt werden. Hierzu gelten die folgenden verbindlichen Kriterien:

1. Mobile Optimierung und Tastaturanpassung Die Formularfelder und zugehörigen Texte müssen sich automatisch an die jeweilige Bildschirmgröße anpassen, sodass alle Elemente stets vollständig sichtbar bleiben und ein horizontales Scrollen konsequent vermieden wird. Um eine fehlerfreie Touch-Bedie- nung mit dem Finger zu garantieren, müssen alle interaktiven Bedienelemente eine aus- reichende Mindestgröße aufweisen. Bei der Fokussierung von Feldern zur Eingabe spe- zifischer Daten, wie beispielsweise E-Mail-Adressen oder Telefonnummern, muss das System die virtuelle Tastatur des Mobilgeräts automatisch auf das jeweils passende Ein- gabeformat umstellen, um den Prozess für die Nutzenden zu beschleunigen.

2. Semantische Struktur und Screenreader-Reihenfolge Formularfelder und Beschriftungen müssen im Quellcode semantisch korrekt verknüpft sein. Dies stellt sicher, dass Screenreader und andere assistierende Technologien die Formularelemente in einer logischen, der visuellen Anordnung entsprechenden Reihen- folge von oben nach unten und zeilenweise von links nach rechts fehlerfrei vorlesen und ansteuern können. Für Checkboxen und Radio-Buttons bedeutet dies eine strikte pro- grammtechnische Verknüpfung der Beschriftung mit dem Steuerelement, damit Screen- reader die gesamte Information aus Label und Funktion in einem einzigen Schritt ausge- ben können, ohne dass zusätzliche Interaktionen durch die Nutzenden erforderlich sind. Zudem muss der visuelle Kontrast von Checkboxen und Radio-Buttons im aktivierten Zu- stand deutlich erhöht dargestellt werden.

3. Barrierefreie Validierung und Fehlermanagement Meldungen bei einer fehlerhaften Dateneingabe in Formularen müssen präzise, leicht verständlich und für Assistenztechnologien sofort erfassbar ausgegeben werden. Das be- troffene Formularfeld muss nach der Validierung automatisch direkt fokussiert werden, um eine schnelle und unkomplizierte Korrektur zu ermöglichen, ohne dass Nutzende das gesamte Formular manuell nach dem Fehler absuchen müssen.

4. Barrierefreier Spam-Schutz Zur Vermeidung von Barrieren dürfen keine rein visuellen Captchas wie komplexe Re- chenaufgaben oder Bilderrätsel als einzige Sicherheitsmaßnahme eingesetzt werden. Als

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 93 von 111

[Seite 94]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Spam-Schutz müssen barrierefreie, im Hintergrund laufende Alternativen wie Honeypot- Felder oder zeitbasierte Validierungsverfahren zum Einsatz kommen, die den barriere- freien Abschluss des Formulars zu keinem Zeitpunkt beeinträchtigen.

5. Unterstützung von Spracheingaben Den Nutzenden muss die Möglichkeit geboten werden, Formularfelder über eine Speech- to-Text-Funktion mittels Spracheingabe auszufüllen. Die standardmäßig in modernen Be- triebssystemen und Browsern integrierten Spracheingabefunktionen müssen vom Sys- tem vollumfänglich unterstützt und dürfen an keiner Stelle blockiert oder beeinträchtigt werden.

5.2.9 Anforderungen an barrierefreie und responsive Tabellen

Alle über das Content-Management-System erstellten Tabellen müssen im Frontend vollstän- dig responsiv dargestellt werden und die gesetzlichen Kriterien der Barrierefreiheit erfüllen. Hierzu gelten die folgenden verbindlichen Kriterien:

1. Flexible Darstellung auf mobilen Endgeräten Auf kleinen Endgeräten muss eine nutzungsfreundliche Darstellung der Tabellendaten vollumfänglich gewährleistet sein. Das System muss hierbei zwei verschiedene Anzeige- optionen unterstützen: das klassische horizontale Scrollen der Tabelle oder das automa- tische Umwandeln in eine gestapelte Listenansicht. Redaktionsmitarbeitende müssen im Zuge der Inhaltspflege im CMS pro Tabelle flexibel zwischen diesen beiden Darstellungs- arten für Mobilgeräte wählen können.

2. Semantische Kennzeichnung und Editor-Validierung Um die Anforderungen der WCAG zu erfüllen, muss der Editor im CMS die korrekte Strukturierung zwingend vorschreiben. Das System muss die Pflege eines expliziten Ta- bellentitels sowie die semantische Kennzeichnung von Kopfzeilen und/oder Kopfspalten technisch erzwingen, bevor eine Tabelle gespeichert oder veröffentlicht werden kann. Dies stellt sicher, dass assistierende Technologien wie Screenreader die Tabelleninhalte im Frontend fehlerfrei auslesen und logisch in Bezug setzen können.

5.2.10 Barrierefreie Medienwiedergabe und Steuerung des Content-Management-Sys- tem Players

Bei der direkten Einbindung von Video- und Audioinhalten über das CMS muss der genutzte Player eine vollständige und barrierefreie Steuerung im Frontend ermöglichen.

Nutzende müssen in der Lage sein, alle wesentlichen Funktionen des Players uneingeschränkt sowohl über die Maus als auch vollständig über die Tastatur anzusteuern. Dies betrifft insbe- sondere die Befehle für Wiedergabe und Pause, die Lautstärkeregelung, das Aktivieren des Vollbildmodus, das Ein- und Ausschalten von Untertiteln sowie das Umschalten zwischen ver- schiedenen angebotenen Sprachversionen oder Audiospuren für die Mehrsprachigkeit.

5.2.11 Integrierte Vorlesefunktion (Text-to-Speech)

Über das Frontend soll eine integrierte Vorlesefunktion bereitgestellt werden, die folgende Kri- terien erfüllt:

1. Integration und Barrierefreiheit Die Funktion muss barrierefrei und unaufdringlich in das Frontend integriert werden und darf keine zusätzlichen, unnötigen akustischen Signale oder störende visuelle Overlays erzeugen. Die parallele Nutzung von externen Screenreadern darf durch diese integrierte Funktion nicht beeinträchtigt werden.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 94 von 111

[Seite 95]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Steuerung und Sprachausgabe Die zugehörigen Steuerelemente für Wiedergabe, Pause und Stopp müssen dauerhaft sichtbar und barrierefrei bedienbar sein. Die Funktion muss es Nutzenden ermöglichen, alle primären redaktionellen Inhalte verbal vorgetragen zu bekommen, wobei die Sprach- ausgabe die korrekte Aussprache der jeweiligen Sprache unterstützen muss.

5.2.12 Videos in Gebärdensprache durch künstliche Intelligenz

Das CMS beziehungsweise die genutzte API soll die automatisierte Generierung von Videos oder Video-Overlays in Gebärdensprache, wie beispielsweise der Deutschen Gebärdenspra- che, aus den redaktionellen Textinhalten mittels eines integrierten KI-Services unterstützen.

Die auf diese Weise erzeugten Gebärdensprach-Videos müssen auf der jeweiligen Seite bar- rierefrei und nahtlos als visuelle Ergänzung zum bestehenden Text eingebettet werden kön- nen.

5.3 Datenschutz (DSGVO) & IT-Sicherheit

Als Betreiber kritischer Infrastrukturen (KRITIS) und im Sinne einer lückenlosen Einhaltung der Datenschutz-Grundverordnung legt die DVB höchsten Wert auf die technologische Sicherheit des neuen Gesamtsystems. Dieses Kapitel definiert die verbindlichen, nicht-funktionalen An- forderungen an die Anwendungssicherheit, die Absicherung administrativer Zugänge, den Schutz personenbezogener Daten sowie die Verpflichtung zu regelmäßigen Sicherheitsüber- prüfungen während des gesamten Lebenszyklus.

5.3.1 Sicheres Coding und Anwendungssicherheit

Um die Plattform nachhaltig gegen externe Angriffe abzusichern und einen reibungslosen Da- tenaustausch zu gewährleisten, müssen bei der Softwareentwicklung etablierte und geprüfte Schutzmechanismen implementiert werden:

1. Entwicklung nach dem Stand der Technik Das beauftragte Unternehmen verpflichtet sich zu einer Softwareentwicklung nach nach- weisbar sicheren Design-Prinzipien. Die Anwendung muss nativ gegen die typischen Si- cherheitsrisiken geschützt sein, insbesondere gegen die aktuellen OWASP Top 10.

2. Schutz von Transaktionen und Datenströmen Alle Informationen, die über öffentliche Netzwerke übertragen werden, müssen lückenlos vor unbefugter Offenlegung, Veränderung oder Fehlleitung geschützt werden. Dies ist durch den Einsatz moderner Verschlüsselungsstandards sowie durch eine strikte Validie- rung aller Eingaben im Frontend und Backend sicherzustellen.

3. Schutz gegen Schadsoftware Alle Schnittstellen, über die Daten oder Dateien an die Systemlandschaft übermittelt wer- den (z. B. Formulare, Medien-Uploads), müssen über automatisierte Prüfmechanismen verfügen, um das Einschleusen von Schadsoftware effektiv zu verhindern.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 95 von 111

[Seite 96]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

5.3.2 Identitäts- und Berechtigungsmanagement

Die Vergabe von Zugriffsrechten innerhalb der gesamten bereitgestellten Systemlandschaft folgt strengen organisatorischen sowie technischen Vorgaben, um unbefugte administrative Zugriffe konsequent zu verhindern:

1. feingranulares Rollenkonzept Sämtliche im Rahmen des Projekts gelieferten Anwendungen, Werkzeuge und Administ- rations-Oberflächen, wie des CMS, der Vertriebs- und E-Commerce-Module sowie nach- gelagerter Systeme, müssen ein detailliertes Rollen- und Rechtemanagement unterstüt- zen, das auf dem Prinzip der minimalen Rechtevergabe basiert.

2. Trennung von Administrationsrollen Die reine fachliche Nutzung der jeweiligen Systeme, wie die redaktionelle Arbeit oder die Produktpflege im Shop, und administrative Betriebsaufgaben müssen technisch strikt voneinander getrennt sein. Privilegierte Administrationsrollen dürfen nur für spezifische IT-Betriebsaufgaben vergeben werden.

3. starke Authentifizierung Der Zugriff auf administrative Bereiche, Backends und Konfigurations-Schnittstellen aller Systemkomponenten ist über dem Schutzbedarf angemessene Authentifizierungsmecha- nismen abzusichern. Das beauftragte Unternehmen muss eine native Unterstützung für starke Authentifizierungsverfahren wie eine Multi-Faktor-Authentifizierung über alle admi- nistrierten Werkzeuge hinweg bereitstellen.

5.3.3 Datenschutzkonformität, Datensparsamkeit und Löschkonzepte

Der Schutz personenbezogener Daten und die Einhaltung datenschutzrechtlicher Prinzipien müssen tief in der Architektur aller bereitgestellten Teilsysteme verankert sein:

1. Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellun- gen Die gesamte Systemarchitektur und alle Softwarekomponenten müssen bereits im Ent- wurf so konzipiert sein, dass der Schutz der Privatsphäre technisch verankert ist. Alle Systeme müssen im Auslieferungszustand standardmäßig so konfiguriert sein, dass die Verarbeitung personenbezogener Daten auf das absolut notwendige Mindestmaß be- schränkt wird (Grundsatz der Datenminimierung).

2. Grundsatz der Datensparsamkeit Die Erhebung und Speicherung von personenbezogenen Daten ist auf das für den Be- trieb zwingend erforderliche Minimum zu reduzieren. Eine dauerhafte Speicherung sen- sibler Daten auf vorgelagerten Systemen oder im Frontend ist auszuschließen.

3. Funktionen zur Datenlöschung Das System muss über dokumentierte und zuverlässige Funktionen verfügen, um perso- nenbezogene Daten nach Ablauf von Aufbewahrungsfristen oder auf Anfrage der Nut- zenden DSGVO-konform und unwiderruflich zu löschen.

Zusätzlich zu den hier definierten Regelungen wird zwischen den Parteien eine Auftragsver- arbeitungsvereinbarung (AVV) zum Umgang mit personenbezogenen Daten, die im Rahmen der Leistungserbringung für den Auftraggeber verarbeitet werden, geschlossen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 96 von 111

[Seite 97]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

5.3.4 Schwachstellenmanagement und Penetrationstests

Zur langfristigen Aufrechterhaltung des Sicherheitsniveaus und zur präventiven Erkennung potenzieller Einfallstore sind fortlaufende Prüf-, Update- und Test-Prozesse zwingend erfor- derlich:

1. kontinuierliche Änderungs- und Patchsteuerung Das beauftragte Unternehmen muss ein dokumentiertes Konzept für das Patch- und Än- derungsmanagement vorlegen. Sicherheitsrelevante Updates und Fehlerbehebungen von Drittanbieter-Bibliotheken müssen zeitnah eingespielt werden können.

2. verpflichtende Penetrationstests Vor der finalen Produktivname und dem Go-live des Gesamtsystems ist die Plattform ei- ner unabhängigen Sicherheitsüberprüfung zu unterziehen. Das beauftragte Unternehmen ist verpflichtet, alle dabei identifizierten Sicherheitsrisiken und Schwachstellen vor dem offiziellen Systemstart auf eigene Kosten vollständig zu beheben.

5.4 SEO, GEO, AEO & Analytics

Die Auffindbarkeit von Informationen sowie die datenschutzkonforme Analyse des Nutzungs- verhaltens sind essenziell für die kontinuierliche Optimierung des digitalen Angebots. Dieses Kapitel definiert die Anforderungen an die technische Suchmaschinen- und Antwortoptimie- rung (SEO, GEO & AEO), die Strukturierung von Daten für künstliche Intelligenz sowie die Rahmenbedingungen für ein datenschutzkonformes Tracking auf Basis der gesetzten Syste- marchitektur.

5.4.1 Technische Suchmaschinenoptimierung und Headless-Architektur

Die Plattform muss technisch so optimiert sein, dass alle öffentlichen Inhalte von Suchmaschi- nen-Crawlern effizient indexiert und in den Suchergebnissen optimal dargestellt werden kön- nen:

1. Server-Side-Rendering, Headless-SEO Da das Gesamtsystem auf einer technologisch entkoppelten Headless-Architektur ba- siert, muss das Frontend zwingend Server-Side Rendering oder Static Site Generation unterstützen. Reine Client-Side-Rendering-Verfahren sind für öffentlich indexierbare In- halte vollständig auszuschließen. Es muss technisch sichergestellt sein, dass der voll- ständige Textinhalt und alle Metadaten bereits im initialen HTML-Dokument ohne die Ausführung von clientseitigem JavaScript für Bots und Scraper lesbar sind.

2. standardkonforme Metadaten Das Frontend muss die im CMS gepflegten, SEO-relevanten Metadaten fehlerfrei im HTML-Header ausgeben. Dies umfasst pro Einzelseite und Inhaltstyp zwingend Title- Tags, Meta-Descriptions, Open-Graph-Tags für Social Media, Canonical-Tags sowie Ro- bots-Meta-Tags.

3. automatische Sitemap-Generierung Das System muss XML-Sitemaps vollautomatisch generieren und bei Inhaltsänderungen in Echtzeit aktualisieren, um eine lückenlose Indexierung zu garantieren. Die Sitemaps müssen den offiziellen, standardisierten Sitemap-Protokollen entsprechen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 97 von 111

[Seite 98]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

4. sprechende URLs Alle URLs müssen automatisch logisch, hierarchisch und lesbar generiert werden. Das beauftragte Unternehmen hat zudem ein automatisiertes Weiterleitungsmanagement (301- und 302-Redirects) bei Strukturänderungen oder Migrationen technisch im Gesamt- system zu implementieren.

5.4.2 Maschinenlesbarkeit und Optimierung für KI-Systeme

Um sicherzustellen, dass KI-Schnittstellen, Sprachassistenten und generative Suchmaschinen die Inhalte der Plattform fehlerfrei interpretieren und korrekt wiedergeben können, müssen die Daten in einer hochgradig strukturierten Form bereitgestellt werden:

1. strukturierte Daten nach Industriestandards Alle öffentlichen Inhalte, Seiten und bereitgestellte Datenstrukturen der Plattform müssen vollautomatisiert mit strukturierten Daten auf Basis der Spezifikationen von Schema.org semantisch angereichert werden. Hierbei ist zwingend das JSON-LD-Format zu verwen- den. Die Validität der Ausgabe muss über gängige Testwerkzeuge fehler- und warnungs- frei nachweisbar sein.

2. semantisches HTML5-Markup Der vom Frontend generierte Quelltext muss eine strikte, logische und barrierefreie Hie- rarchie aufweisen. Standard-Inhaltselemente müssen über semantische HTML5-Tags ausgezeichnet werden, damit KI-Systeme und Suchmaschinen die inhaltlichen Zusam- menhänge ohne visuelles Rauschen maschinell auslesen können.

3. gezielte Steuerung von KI-Crawlern Über die zentrale Konfigurationsdatei muss eine feingranulare Steuerung von KI-Craw- lern und LLM-Scrapern möglich sein. Dadurch muss die DVB in der Lage sein, öffentliche Service-Daten gezielt für KI-Systeme freizugeben, während interne, geschützte oder irre- levante Bereiche konsequent für diese Bots ausgeschlossen werden.

4. Answer Engine Optimization (AEO) für direkte Antwort-Systeme Die Plattform muss technisch und inhaltlich darauf ausgelegt sein, dass direkte Antwort- Engines und Conversational-AI-Systeme präzise Informationen extrahieren können. Sämtliche öffentlich zugänglichen Service- und Tarifinformationen, Störungsmeldungen sowie FAQ-Bereiche sind in klar gegliederten, semantisch eindeutigen Frage-Antwort- Formaten aufzubereiten. Die Datenarchitektur muss sicherstellen, dass Antworten auf häufig gestellte Fragen eindeutig den jeweiligen Entitäten (z. B. Haltestellen, Linien, Ti- cketarten, Tarifzonen) zugeordnet und direkt maschinell verarbeitbar sind.

5.4.3 Analytics, Tracking und datenschutzkonformes Monitoring

Zur datenschutzkonformen Analyse der Nutzung und zur kontinuierlichen Optimierung des di- gitalen Angebots setzt die DVB den Matomo Tag Manager ein. Die Anforderungen in diesem Kapitel gelten ausdrücklich für das Gesamtsystem, bestehend aus dem CMS, dem integrierten Ticketshop sowie allen direkt verbundenen Subsystemen. Dieses Gesamtsystem muss sich nativ, übergreifend und vollständig in die gesetzte Analyse-Infrastruktur integrieren:

1. native Integration des Matomo Tag Managers Das System muss die Einbindung des Matomo Tag Managers vollumfänglich ermögli- chen. Um wichtige Interaktionselemente ohne zusätzlichen Programmieraufwand als Events messbar zu machen, müssen diese im Frontend über eindeutige, dokumentierte CSS-Klassen oder Daten-IDs verfügen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 98 von 111

[Seite 99]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. datenschutzkonforme MTM-Steuerung und Consent-Verknüpfung Die integrierte Consent-Lösung muss technisch zwingend mit dem Matomo Tag Manager interagieren. Erst nach expliziter und aktiver Zustimmung der Nutzenden dürfen zustim- mungspflichtige Tracking-Aktivitäten über den MTM dynamisch aktiviert werden. Eine rein anonyme, cookiefreie Basis-Reichweitenmessung im Rahmen der gesetzlichen Vor- gaben vor Erteilung der Einwilligung darf durch diese Logik nicht verhindert werden.

3. Data Layer Bereitstellung Alle Frontends des Gesamtsystems müssen eine strukturierte Datenschicht, den Data Layer, bereitstellen und kontinuierlich befüllen. Im CMS-Bereich sind Informationen wie Seitentyp, Inhaltskategorien oder Suchbegriffe zu übergeben. Im Bereich des Tickets- hops müssen zusätzlich alle standardisierten E-Commerce-Ereignisse in den Data Layer geschrieben werden, damit der Matomo Tag Manager diese für detaillierte E-Commerce- Analysen fehlerfrei auslesen kann.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 99 von 111

[Seite 100]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

6. Datenmigration, Testing & Go-live

Der Übergang vom bestehenden System auf die neue digitale Plattform der DVB muss für die Kundschaft nahtlos, unterbrechungsfrei und ohne Datenverluste erfolgen. Dieses Kapitel re- gelt die verbindlichen Anforderungen an die Übernahme der Bestandsdaten, die systemati- sche Qualitätssicherung vor dem Launch sowie den eigentlichen Umschaltprozess im Rahmen eines risikominimierten Rollout-Szenarios.

Das beauftragte Unternehmen trägt die gesamtverantwortliche Begleitung und technische Durchführung aller in diesem Kapitel genannten Phasen und stimmt sich hierzu eng mit den zuständigen Fachbereichen der DVB ab.

6.1 Migrationskonzept

Für die Übernahme relevanter Altdaten, Inhalte und Nutzungsdaten in das neue System hat das beauftragte Unternehmen ein detailliertes und methodisch fundiertes Migrationskonzept zu erarbeiten. Ziel ist es, eine lückenlose Datenintegrität zu gewährleisten und manuelle Nach- arbeiten seitens der DVB auf ein Minimum zu reduzieren.

6.1.1 Technische Ausgangslage und Systemanalyse

Die technische Überführung erfordert die Berücksichtigung der bestehenden Infrastrukturen der DVB, um Inkompatibilitäten beim Datentransfer vorab vollständig auszuschließen:

1. CMS-Basis des Quellsystems Das aktuelle Quellsystem der Website basiert auf Sitecore. Die Bereitstellung der not- wendigen Datenexporte aus diesem Altsystem erfolgt nach Absprache und in enger Ab- stimmung mit dem beauftragten Unternehmen.

2. Betriebsmodell der Infrastruktur Das Altsystem wird als Self-hosted On-Premise-Lösung auf der Infrastruktur der DVB be- ziehungsweise deren IT-Dienstleisters betrieben. Der Zugriff auf die Datenbestände für die Migrationsvorbereitung wird im Rahmen der Projektinitiierung technisch bereitgestellt.

3. Identitäts- und Vertriebsinfrastruktur Die bestehende Systemlandschaft verfügt über eine vernetzte Authentifizierungsarchitek- tur. Als zentraler Identitätsprovider kommt Keycloak zum Einsatz, welcher das Identitäts- und Authentifizierungsmanagement für die HybridApp DVB mobil sowie das Vertriebshin- tergrundsystem realisiert. Zudem existiert für das Identitätsmanagement der multimoda- len MOBIapp eine Anbindung an den MENTZ IDP (via OIDC/OAuth2 und SAML). Die Migration der Website-Komponenten darf diese bestehenden, vertriebs- und app-kriti- schen Authentifizierungspfade zu keinem Zeitpunkt beeinträchtigen.

6.1.2 Migrationsanforderungen

Die Übernahme der bestehenden Datenbestände muss automatisiert und unter Wahrung aller bestehenden Verknüpfungen sowie gesetzlicher Vorgaben erfolgen:

1. Migrationskonzept der Single-Sign-On-Infrastruktur Die Überführung der bestehenden Konten der Nutzenden hat im Rahmen einer dezidier- ten SSO-Migration zu erfolgen. Da Keycloak als Identitätsprovider direkt mit DVB mobil und dem Vertriebshintergrundsystem gekoppelt ist, muss die Migration so konzipiert sein,

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 100 von 111

[Seite 101]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

dass der Login und digitale Ticketvertrieb für die Kundschaft unterbrechungsfrei fortbe- stehen können. Für die technische Umsetzung sind vom bietenden Unternehmen zwei architekturbedingte Szenarien zu betrachten und im Angebot zu bewerten:

a) Identisches Verfahren: Basiert die angebotene Lösung auf demselben technologi- schen Verfahren wie die aktuelle Infrastruktur der DVB, so ist eine vollständige und lückenlose Migration aller bestehenden Kontodaten aus dem aktuellen Keycloak-Sys- tem umzusetzen, ohne die Schnittstellen zu den angebundenen Systemen zu beein- trächtigen.

b) Alternatives SSO-Verfahren: Setzt das beauftragte Unternehmen ein alternatives SSO-Verfahren ein, ist im Angebot zwingend ein detailliertes Migrationsszenario auf- zuzeigen. Dieses muss transparent darlegen, wie eine sichere Datenüberführung un- ter Berücksichtigung der technischen Schnittstellen (OIDC/OAuth2, SAML) und orga- nisatorischen Rahmenbedingungen der angebundenen Partnerunternehmen sowie der MOBIapp-Infrastruktur (Mentz IDP) realisiert werden kann, sofern dies mit den angebundenen Systemen technisch umsetzbar ist.

Unabhängig vom gewählten Technologiepfad hat die gesamte Migration unter strikter Einhaltung der DSGVO-Vorgaben zu erfolgen, wobei eine Klartext-Speicherung oder Ein- sicht in sensible Zugangsdaten und Passwörter zu jedem Zeitpunkt des Migrationspro- zesses systemisch unmöglich sein muss.

2. Historische Datenübernahme von Archiven Alle aktuellen redaktionellen Inhalte sowie historischen Meldungen und Pressemitteilun- gen sind in die neue Systemstruktur zu übertragen. Das beauftragte Unternehmen hat dabei sicherzustellen, dass die Datenbasis für Newsmeldungen, Pressemitteilungen und Baumaßnahmen der vergangenen sieben Jahre vollständig migriert und verlustfrei in die dafür vorgesehene Zielstruktur überführt wird.

3. Inhaltsgekoppelte Medienmigration Die Übernahme von Mediendateien wie Bildern, Grafiken und PDF-Dokumenten darf ausschließlich gekoppelt an die tatsächlich zu migrierenden redaktionellen Inhalte und Newsmeldungen erfolgen. Das beauftragte Unternehmen hat durch automatisierte Routi- nen sicherzustellen, dass nur diejenigen Medien in das neue System übertragen werden, die in den umgezogenen Texten aktiv verlinkt oder als Inhaltselement eingebunden sind. Um den Verlust aktuell nicht verlinkter, aber weiterhin benötigter Dokumente auszuschlie- ßen, wird der DVB vorab eine Liste der nicht-berücksichtigten Medien zur Freigabe vor- gelegt.

6.2 Abnahme- & Testverfahren

Vor der offiziellen Übergabe und Inbetriebnahme der neuen digitalen Systemlandschaft muss eine lückenlose, systematische Qualitätssicherung durch das beauftragte Unternehmen erfol- gen. Dieses Kapitel definiert die verbindlichen Anforderungen an die Testverfahren, das Feh- lermanagement sowie die Kompatibilitätsvorgaben, die als Voraussetzung für die formelle Ab- nahme durch die DVB zwingend zu erfüllen sind.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 101 von 111

[Seite 102]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

6.2.1 Systematische Qualitätssicherung und Teststufen

Die Verifizierung aller funktionalen und nicht-funktionalen Anforderungen erfordert ein struktu- riertes, mehrstufiges Testverfahren auf Seiten desbeauftragten Unternehmens:

1. Bereitstellung eines Konzepts zur Qualitätssicherung Das beauftragte Unternehmen hat zu Projektbeginn ein umfassendes Qualitätssiche- rungs- und Testkonzept vorzulegen. Dieses Konzept muss die methodische Vorgehens- weise, die geplanten Testzyklen sowie die Verantwortlichkeiten transparent darlegen und bedarf der formellen Freigabe durch die DVB.

2. Durchführung vorgelagerter Teststufen Das beauftragte Unternehmen ist verpflichtet, vor der Übergabe von Software-Inkremen- ten an die DVB eigenständige Code-Reviews, Unit-Tests, Integrations- und Systemtests durchzuführen. Jede Bereitstellung auf der Test- oder Staging-Umgebung muss zwin- gend über eine automatisierte CI/CD-Pipeline im Zuge des Build- und Deploymentpro- zesses fehlerfrei verifiziert worden sein.

3. Systemübergreifende End-to-End-Funktionstests Neben isolierten Komponententests müssen sämtliche systemübergreifenden Geschäfts- prozesse der digitalen Plattform in vollständigen End-to-End-Szenarien geprüft werden. Das beinhaltet die lückenlose Validierung aller Datenflüsse von der Benutzeroberfläche über die Schnittstellen bis in die tiefen Hintergrundsysteme und zurück. Zu diesen kriti- schen Kernprozessen gehören beispielhaft, aber nicht abschließend, der digitale Ticket- kauf, die Verbindungsauskunft, die Authentifizierung über das SSO-System sowie alle weiteren interaktiven Formular- und Serviceprozesse.

6.2.2 Browser- und Geräteübersicht sowie Barrierefreiheitsprüfung

Um eine optimale und barrierefreie Nutzbarkeit für alle Nutzenden sicherzustellen, muss die Anwendung auf einer definierten Auswahl an Endgeräten und Softwareversionen stabil per- formen:

1. Abdeckung von Browsern und Betriebssystemen Das beauftragte Unternehmen garantiert die uneingeschränkte Funktionalität und visuelle Konsistenz der Anwendung auf den jeweils aktuellen Hauptversionen der Desktop-Brow- ser Google Chrome, Mozilla Firefox, Apple Safari und Microsoft Edge sowie den mobilen Betriebssystemen iOS und Android unter Verwendung der jeweiligen Standard-Browser Safari und Chrome. Die genaue Versionsmatrix richtet sich nach der aktuellen Marktver- teilung zum Zeitpunkt der Entwicklung und wird im Konzept für die Qualitätssicherung verbindlich fixiert.

2. Responsives Design und Geräteklassen Das Frontend muss sich dynamisch und flüssig an unterschiedliche Bildschirmauflösun- gen und Geräteklassen wie Smartphones, Tablets und Desktop-Monitore anpassen. Be- dienungs- oder Darstellungsfehler aufgrund von Displaygrößen sind durch umfassende Cross-Device-Tests durch das beauftragte Unternehmen systemisch auszuschließen.

3. Validierung der Barrierefreiheit Da die DVB als Mobilitätsdienstleister gesetzlich zur Barrierefreiheit verpflichtet ist, hat das beauftragte Unternehmen die Einhaltung der gesetzlichen Barrierefreiheitsanforde- rungen, gemäß BITV 2.0 und WCAG 2.2 Level AA, im Rahmen der Qualitätssicherung

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 102 von 111

[Seite 103]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

explizit zu testen und zu dokumentieren. Hierbei sind sowohl automatisierte Prüfwerk- zeuge als auch manuelle Tests wie Screenreader-Kompatibilität und Tastaturbedienbar- keit einzusetzen.

6.2.3 Fehlerklassifizierung und Fehlermanagement

Während der Testphasen auftretende Abweichungen vom Soll-Zustand müssen strukturiert erfasst, kategorisiert und behoben werden:

1. Zentrales Ticket- und Fehlertracking Das beauftragte Unternehmen stellt ein gemeinsames, webbasiertes Fehlertracking-Sys- tem bereit, auf das sowohl das Projektteam des beauftragten Unternehmens als auch die Testverantwortlichen der DVB vollen Zugriff haben. Jede dokumentierte Abweichung muss eindeutig nachvollziehbar, reproduzierbar und mit dem entsprechenden Systemmo- dul verknüpft sein.

2. Verbindliche Fehlerkategorisierung Das beauftragte Unternehmen ist zur Einhaltung der Vorgaben gem. der Anlage XXX (Mängelklassifikation, Reaktions- und Wiederherstellungszeiten, Service Level) verpflich- tet. Sie hat der DVB ein Ticketsystem bereitzustellen, welches es der DVB ermöglicht er- kannte Fehler jederzeit anzuzeigen. Das System muss eine Kategorisierung der Fehler. gem. Anlage XXX zulassen. Ebenfalls sind die Vorgaben gem. Ziffer 7.1 dieses Lasten- hefts zu beachten. Das bereitzustellende System ist durch das beauftragte Unternehmen Rahmen des Qualitätssicherungs-Konzepts transparent zu beschreiben und bedarf der Freigabe durch die DVB. Unabhängig von der genutzten Systematik des beauftragten Unternehmens gilt als verbindliche Mindestanforderung für das Erreichen der nächsten Projektphase, dass gefundene Fehler mindestens in folgende Kategorien eingeteilt und entsprechend priorisiert behoben werden:

a) Kritische Fehler/Blocker: Fehler, welche die Nutzung von Kernfunktionen wie den di- gitalen Ticketvertrieb oder die Verbindungsauskunft unmöglich machen. Diese müs- sen vor einer Übergabe zur Abnahme durch Nutzende zwingend und vollständig be- hoben sein.

b) Wesentliche Fehler: Fehler, die wichtige Funktionen ohne praktikablen Workaround blockieren (also einen zumutbaren Ausweichweg, bei dem die Aufgabe ohne unzu- mutbaren Mehraufwand oder Datenverlust abgeschlossen werden kann). Auch diese müssen vor der Übergabe zur Abnahme durch Nutzende vollständig behoben sein.

c) Geringfügige Fehler: Abweichungen ohne signifikante Funktionseinbußen oder Kom- forteinschränkungen. Diese können nach einvernehmlicher Absprache in nachfolgen- den Entwicklungszyklen korrigiert werden.

6.2.4 User Acceptance Testing und formelle Abnahme

Nach erfolgreichem Abschluss aller interner Tests des beauftragten Unternehmens erfolgt die finale Validierung durch die Fachbereiche der DVB:

1. Übergabe zur Abnahme durch Nutzende Sobald das beauftragte Unternehmen die interne Testphase erfolgreich abgeschlossen und protokolliert hat, übergibt es das System für das sogenannte User Acceptance Tes- ting (UAT) an die DVB. Die DVB führt innerhalb eines vereinbarten Zeitfensters eigen- ständige Abnahmetests durch, um die fachliche Korrektheit aus Sicht der Endnutzenden zu verifizieren.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 103 von 111

[Seite 104]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Bereitstellung von Testdaten Das beauftragte Unternehmen unterstützt die DVB bei der Vorbereitung des UAT, indem es geeignete Testdatenumgebungen bereitstellt und bei Bedarf synthetische oder anony- misierte Testdatensätze für komplexe Vertriebs-, Schnittstellen- und Tariflogiken gene- riert.

3. Formelles Abnahmeprotokoll Die erfolgreiche Validierung aller Testkriterien wird durch die Erstellung eines gemeinsa- men, schriftlichen Abnahmeprotokolls dokumentiert. Bestehen zum Zeitpunkt der Ab- nahme noch offene Restfehler der Kategorie „geringfügige Fehler“, werden diese mit ei- ner verbindlichen Erledigungsfrist im Protokoll festgehalten und blockieren die Gesamt- abnahme nicht.

6.3 Rollout- und Go-live-Szenario

Der Übergang von der bestehenden Systemlandschaft auf die neue digitale Plattform erfordert eine sorgfältig geplante, risikominimierte Migrations- und Rollout-Strategie. Das beauftragte Unternehmen ist verpflichtet, die technische und organisatorische Umstellung so zu gestalten, dass Beeinträchtigungen des laufenden Betriebs sämtlicher digitaler Dienste, Funktionen und Anwendungsprozesse vollumfänglich ausgeschlossen werden. Sollten technisch bedingte Einschränkungen im Zuge der Umschaltung unvermeidbar sein, dürfen diese ausschließlich innerhalb vorab durch die DVB genehmigter Wartungsfenster erfolgen und sind auf das abso- lut unumgängliche Minimum zu beschränken.

6.3.1 Rollout-Planung und Umstellungsvorbereitung

Die Vorbereitung des Systemwechsels erfordert eine detaillierte und partnerschaftliche Ab- stimmung aller beteiligten Schnittstellenpartner:

1. Erstellung eines Migrations- und Rollout-Konzepts Das beauftragte Unternehmen hat in der Phase der Pflichtenhefterstellung ein erstes Migrations- und Rollout-Konzept zu erarbeiten. Rechtzeitig vor dem geplanten Termin der Inbetriebnahme ist dieses in detaillierter Form zur Genehmigung durch die DVB vorzule- gen. Dieses Dokument muss einen schrittweisen Ablaufplan für den Umstellungszeit- raum, die personellen Zuständigkeiten, die Kommunikationswege sowie die Kriterien für eine erfolgreiche Inbetriebnahme enthalten.

2. Durchführung von Probeläufen Um das Risiko von Systemausfällen am Tag der Umstellung zu minimieren, hat das be- auftragte Unternehmen mindestens einen vollständigen, simulierten Probelauf der Daten- migration und Systemumstellung unter produktionsnahen Bedingungen durchzuführen und zu protokollieren. Das Erreichen der definierten Performance- und Integritätsziele im Probelauf ist eine zwingende Voraussetzung für die Freigabe des realen Go-live durch die DVB.

3. Delta-Migration und finale Datensynchronisation Da zwischen dem letzten großen Test-Datenimport und dem eigentlichen Umschaltzeit- punkt im Altsystem weiterhin neue redaktionelle Inhalte eingepflegt oder Konten der Nut- zenden im SSO-System registriert werden können, hat das beauftragte Unternehmen ein Verfahren zur Delta-Migration zu definieren. Es muss sichergestellt werden, dass alle bis

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 104 von 111

[Seite 105]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

zur Minute des Datenstopps entstandenen Datenänderungen vollautomatisch und ohne Datenverlust in das Produktivsystem synchronisiert werden, bevor die Plattform live geht.

6.3.2 Durchführung der Systemumstellung

Der eigentliche Umschaltprozess vom Altsystem auf die neue Plattform unterliegt zeitlichen und betrieblichen Vorgaben:

1. Nutzungsarmes Umstellungszeitfenster Die finale Systemumstellung und die damit verbundenen technischen Wartungsfenster haben zwingend in einem nutzungsarmen Zeitraum, vorzugsweise in den nächtlichen Schwachverkehrszeiten oder an einem wenig frequentiertem Wochenende, zu erfolgen. Die genaue Terminierung wird in enger Abstimmung mit der DVB festgelegt.

2. Minimierung von Downtimes Das beauftragte Unternehmen garantiert, die technisch bedingten Ausfallzeiten der öf- fentlich zugänglichen Systeme so kurz wie möglich zu halten. Für kritische Kernprozesse sind während des Umstellungsfensters geeignete Überbrückungsmechanismen bereitzu- stellen.

3. Schnittstellenkoordination Während des Umschaltprozesses koordiniert das beauftragte Unternehmen die techni- sche Synchronisation mit allen angebundenen Drittsystemen und Identitätsprovidern, um sicherzustellen, dass die Authentifizierungspfade und Datenflüsse unmittelbar nach der Umschaltung nahtlos ineinandergreifen.

6.3.3 Fallback-Strategie und Rollback-Szenario

Für den Fall, dass während des Go-live-Prozesses unvorhergesehene, kritische Probleme auf- treten, muss die Betriebsfähigkeit der Anwendung jederzeit gesichert bleiben:

1. Verbindlicher Rollback-Plan Das Migrations- und Rollout-Konzept muss zwingend ein detailliertes Rollback-Szenario enthalten. Dieses Szenario beschreibt die technischen und organisatorischen Schritte, um das Gesamtsystem im Ernstfall innerhalb eines definierten, engen Zeitfensters voll- ständig und ohne Datenverlust auf den Zustand des Altsystems vor Beginn der Umstel- lung zurückzusetzen.

2. Definition von Abbruchkriterien Im Ablaufplan sind klare, messbare Meilensteine und Abbruchkriterien zu definieren. Werden diese Kriterien bis zu einem festgelegten Zeitpunkt im Ablaufplan nicht erfüllt, wird der Go-live-Prozess abgebrochen und das Rollback eingeleitet.

6.3.4 Hypercare-Phase und Stabilisierung

Nach dem erfolgreichen Go-live ist eine intensive Betreuung zur Stabilisierung des Systems im Realbetrieb sicherzustellen:

1. Bereitstellung eines Hypercare-Teams Unmittelbar nach der produktiven Umschaltung beginnt eine Hypercare-Phase von min- destens vier Wochen. Das beauftragte Unternehmen stellt für diesen Zeitraum ein geson- dertes, fachlich qualifiziertes Support- und Entwicklungs-Team bereit, das ausschließlich für die Überwachung der neuen Systemlandschaft, die Analyse von Logfiles und die schnelle Behebung von Problemen der Nutzenden zuständig ist. Sollten zum Ende der

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 105 von 111

[Seite 106]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

vierwöchigen Phase noch unbehobene Fehler der Kategorie „Kritische Fehler/Blocker“ vorliegen, verlängert sich die Hypercare-Phase für das beauftragte Unternehmen kosten- frei bis zu deren vollständigen Behebung.

2. Erweiterte Reaktions- und Wiederherstellungszeiten Während der Hypercare-Phase gelten erweiterte Reaktions- und Wiederherstellungszei- ten gem. der Anlage XXX (Mängelklassifikation, Reaktions- und Wiederherstellungszei- ten, Service Level), um die Stabilisierung des Systems im Realbetrieb sicherzustellen

3. Wissenstransfer und Dokumentationsabschluss Bis zum Ende der Hypercare-Phase hat das beauftragte Unternehmen alle Systemdoku- mentationen, Betriebshandbücher und Schulungsunterlagen auf den finalen, produktiven Stand zu bringen und den administrierenden sowie redaktionellen Mitarbeitenden der DVB vollständig zu übergeben.

6.4 Schulung, Dokumentation und Know-how-Transfer

Um einen nachhaltigen, eigenständigen und sicheren Betrieb der neuen Web-Plattform durch die DVB zu gewährleisten, hat das beauftragte Unternehmen ein umfassendes Wissensma- nagement bereitzustellen. Dies umfasst die Erstellung zielgruppenspezifischer Dokumentatio- nen sowie die Durchführung praxisorientierter Schulungsmaßnahmen.

6.4.1 Zielgruppenspezifisches Schulungskonzept

Das beauftragte Unternehmen hat in der Phase der Pflichtenhefterstellung ein grobes Schu- lungskonzept zu erarbeiten. Rechtzeitig vor Beginn der Abnahmephase ist dieses in detaillier- ter Form vorzulegen, das mindestens folgende Kernzielgruppen separat berücksichtigt:

1. Redaktionelle Schulung Befähigung der redaktionell verantwortlichen Mitarbeitenden zur eigenständigen Pflege, Erstellung und Strukturierung von Inhalten, Medien, Baustellenmeldungen und Presse- mitteilungen. Die Schulung muss die barrierefreie Inhaltspflege explizit beinhalten.

2. Vertrieb und Kundenservice Befähigung der im Vertrieb und Kundenservice tätigen Mitarbeitenden zur effizienten Be- arbeitung von Fahrgast- und Ticketinganliegen über das Kundenserviceportal. Die Schu- lung muss alle Prozesse zur Fallbearbeitung und Nutzung der vertrieblichen Service- Dashboards und Support-Werkzeuge vollumfänglich abdecken.

3. Technische Administration Befähigung der IT-Verantwortlichen der DVB zur technischen Verwaltung der Plattform. Dies beinhaltet das Rechtemanagement, das Einspielen von kleineren Updates, die Kon- figuration von Schnittstellen sowie die Fehleranalyse über Logfiles.

6.4.2 Durchführung und Rahmenbedingungen

Für die Durchführung der Schulungsmaßnahmen gelten folgende verbindliche Anforderungen:

1. Praxisorientierte Durchführung Die Schulungen haben anhand konkreter Anwendungsfälle direkt im bereitgestellten Test- oder Staging-System stattzufinden.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 106 von 111

[Seite 107]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

2. Zeitliche Einordnung Die Schulungen müssen zwingend vor dem produktiven Go-live so rechtzeitig abge- schlossen sein, dass die Teilnehmenden das System während der Abnahmephase sicher bedienen und prüfen können.

3. Form und Umfang Die Schulungen können nach Absprache mit der DVB als interaktive Workshops, entwe- der vor Ort in Dresden oder in einem Remote-Format durchgeführt werden. Das beauf- tragte Unternehmen hat im Angebot den empfohlenen Stunden- und Sitzungsumfang pro Zielgruppe transparent auszuweisen.

4. Schulungsunterlagen und Leitfäden Alle Schulungsinhalte sind in Form von leicht verständlichen Leitfäden in deutscher Spra- che bereitzustellen, sodass auch zukünftige neue Mitarbeitende ohne erneuten Dienst- leisteraufwand eingearbeitet werden können.

6.4.3 System- und Betriebsdokumentation

Neben den Schulungsunterlagen ist eine vollständige und lückenlose technische Dokumenta- tion des Gesamtsystems zu erstellen:

1. Technische Systemdokumentation Das beauftragte Unternehmen erstellt eine detaillierte Dokumentation der Systemarchi- tektur, der Datenmodelle, der programmierten Eigenentwicklungen sowie der konfigurier- ten Schnittstellen zu Drittsystemen und Identitätsprovidern.

2. Betriebs- und Administrationshandbuch Dieses Dokument muss alle notwendigen Informationen für den täglichen technischen Betrieb enthalten, darunter Backup- und Recovery-Prozesse, Deployment-Anleitungen, Monitoring-Vorgaben sowie Verhaltensweisen im Falle von Systemstörungen. Die Bereit- stellung dieser Dokumentation entbindet das beauftragte Unternehmen nicht von den in Kapitel 7 definierten laufenden Support-, Wartungs- und Betriebsaufgaben.

3. Sprache und Format Die gesamte Dokumentation ist in Deutsch zu verfassen und der DVB in einem editierba- ren, digitalen Format zur Verfügung zu stellen.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 107 von 111

[Seite 108]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

7. Betrieb, Support und Wartung nach Go-live

Nach dem erfolgreichen, vorbehaltlosen Abschluss der temporären Hypercare-Phase geht die neue Web-Plattform in den regulären Dauerbetrieb über. Um die langfristige Verfügbarkeit, IT- Sicherheit, Performanz und funktionale Aktualität des Gesamtsystems dauerhaft zu gewähr- leisten, hat das beauftragte Unternehmen den technischen Support sowie die kontinuierliche Software-Wartung und Systempflege zu den nachfolgend definierten Bedingungen vollum- fänglich sicherzustellen.

7.1 Service-Level-Agreement

Für den regulären Anwendungsbetrieb nach der Inbetriebnahme gelten die in der Anlage XXX des Vertrages definierten Bestimmungen zur Mängelklassifikation sowie zu den Reaktions- und Wiederherstellungszeiten. Das beauftragte Unternehmen stellt hierfür ein webbasiertes Ticketsystem bereit, über welches die IT-Verantwortlichen der DVB Störungen und Support- Anfragen jederzeit melden können.

1. Servicezeiten Der technische Support und die Ticketbearbeitung stehen der DVB von Montag bis Frei- tag im Zeitraum von 8 bis 18 Uhr, mit Ausnahme der am Sitz der DVB geltenden gesetzli- chen Feiertage, zur Verfügung.

2. Meldewege und Ticketsystem Das beauftragte Unternehmen stellt ein webbasiertes Ticketsystem bereit, über welches die IT-Verantwortlichen der DVB Störungen und Support-Anfragen jederzeit melden kön- nen. Für kritische Fehler ist zusätzlich zwingend eine telefonische Notfall-Hotline wäh- rend der Servicezeiten bereitzustellen.

3. Systemverfügbarkeit Das beauftragte Unternehmen gewährleistet eine cloudbasierte oder hochverfügbare Be- reitstellung der Web-Plattform. Die angestrebte Gesamtverfügbarkeit des Systems be- trägt mindestens 99,5 % im Monatsmittel. Planmäßige, mit der DVB vorab abgestimmte Wartungsfenster in nutzungsarmen Zeiten werden bei der Berechnung der Verfügbarkeit nicht als Ausfallzeit gewertet.

4. Definition der Reaktionszeit Als Reaktionszeit gilt die Zeitspanne zwischen dem dokumentierten Eingang der Fehler- meldung im Ticketsystem des beauftragten Unternehmens und dem Beginn der qualifi- zierten Fehleranalyse durch eine fachlich kompetente Person sowie der Rückmeldung an die DVB.

5. Verbindliche Reaktionszeiten innerhalb der Servicezeiten Die Priorisierung der Tickets richten sich nach den in der Anlage XXX definierten Fehler- schweregraden, wobei kritische Fehler am höchsten und geringfügige Fehler am nied- rigsten zu priorisieren sind:

7.2 Weiterentwicklung und Lifecycle-Management

Die Web-Plattform muss über den gesamten vertraglichen Lebenszyklus hinweg technolo- gisch auf dem neuesten Stand gehalten und kontinuierlich optimiert werden. Das beauftragte Unternehmen übernimmt hierbei das proaktive Lifecycle-Management:

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 108 von 111

[Seite 109]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

1. Sicherheits-Updates und Patch-Management Das beauftragte Unternehmen verpflichtet sich, das Gesamtsystem, alle eingesetzten Kernkomponenten, Bibliotheken, Frameworks sowie das zugrundeliegende CMS kontinu- ierlich auf Sicherheitsrisiken und Schwachstellen zu überwachen. Kritische Sicherheits- Patches sind unverzüglich, eigenständig und ohne gesonderte Aufforderung – in enger Abstimmung mit der IT der DVB – einzuspielen. Reguläre Minor- und Patch-Updates sind in geplanten, nutzungsarmen Wartungsfenstern zu implementieren.

2. Gewährleistung der technologischen Aktualität Das System ist so zu pflegen und weiterzuentwickeln, dass die uneingeschränkte Funk- tion sowie die vollständige Barrierefreiheit gemäß BITV 2.0 und WCAG stets mit den je- weils aktuellen Hauptversionen der gängigen Webbrowser und mobilen Betriebssyste- men kompatibel bleiben. Notwendige größere Versionssprünge der System-Basistechno- logien sind der DVB rechtzeitig anzuzeigen und gemeinsam zu koordinieren.

3. Kontinuierliche funktionale Weiterentwicklung Um nach dem Go-live flexibel auf veränderte Marktanforderungen, neue Tarifvorgaben oder Optimierungswünsche der Nutzenden reagieren zu können, vereinbaren die Ver- tragsparteien die Bereitstellung eines monatlich abrufbaren Dienstleistungskontingents. Die Beauftragung, Konzipierung und Priorisierung dieser funktionalen Erweiterungen er- folgen über ein standardisiertes, im Rahmen des Projekt-Setups definiertes Change-Re- quest-Verfahren.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 109 von 111

[Seite 110]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

8. Glossar und Begriffsdefinitionen

Das nachfolgende Glossar dient dem gemeinsamen Verständnis und fasst zentrale Fachbe- griffe sowie technische Abkürzungen zusammen, die in diesem Dokument verwendet werden.

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 110 von 111

[Seite 111]

Lastenheft für die Konzeption, Realisierung und Betreuung einer barrierefreien, geräteübergrei- fenden Web-Plattform mit nativer App-User-Experience

Fassung vom 05.10.2026 DVB, UB Markt & Verkehr Seite 111 von 111