Einleitung

Dieses Dokument definiert Spezifikationen und Qualitätsanforderungen für die Entwicklung, Bereitstellung, Wartung und den Betrieb von Onlineservices und -portalen der öffentlichen Verwaltung. Ziel ist es, benutzerfreundliche, effiziente und sichere digitale Dienstleistungen bereitzustellen, die gesetzlichen Vorgaben einhalten und den Bedürfnissen der Nutzenden entsprechen.

Die Zielgruppen dieses Dokuments unterteilen sich in drei Kategorien: Umsetzende, Steuernde und Prüfende. Diese sind nicht vollständig trennscharf und sollen primär als Orientierung dienen.

— Umsetzende sind all jene Personen, die an der Entwicklung von Onlineservices und -portalen der öffentlichen Verwaltung beteiligt sind, dies umfasst sowohl Mitarbeitende der Verwaltung und Justiz als auch externe Personen, beispielsweise IT-Dienstleister.

— Steuernde sind Projektverantwortliche bzw. für den Onlineservice (3.16) oder ein Onlineportal (3.15) verantwortliche Personen, welche gleichermaßen Mitarbeitende der Verwaltung und Justiz oder externe IT-Dienstleister sein können.

— Prüfende sind all jene Personen, die einen Onlineservice bzw. ein Onlineportal oder einen Vergabevertrag für ein IT-Projekt auf ihren Erfüllungsgrad der in DIN SPEC 66336 festgelegten Anforderungen hin prüfen.

Dieses Dokument stellt eine Konkretisierung des Servicestandards (3.29) dar. Der Servicestandard selbst definiert Qualitätsprinzipien für gute digitale Entwicklungspraxis, welche durch die in diesem Dokument formulierten Anforderungen überprüfbar werden. Die oben definierten Zielgruppen haben unterschiedliche Informationsbedarfe, welche durch verschiedene, aufeinander abgestimmte und miteinander verzahnte Informationsangebote adressiert werden.

Vorwort

Diese DIN SPEC wurde nach dem PAS-Verfahren erarbeitet. Die Erarbeitung von DIN SPEC nach dem PAS-Verfahren erfolgt in DIN-SPEC-Konsortien und nicht zwingend unter Einbeziehung aller interessierten Kreise.

Die Erarbeitung und Verabschiedung des Dokuments erfolgten durch die nachfolgend genannten Initiator(en) und Verfasser:

— Bundesministerium des Innern und für Heimat

Ralf Käck

Luise Kranich

— AKDB– Anstalt für kommunale Datenverarbeitung in Bayern

Markus Keller

— AWO Bundesverband e.V.

Maximilian Kühn

— BAGSO e.V.

Astrid Mönnikes

— Bundesanstalt für Landwirtschaft und Ernährung

Wolfgang Hennes

— Bundesbeauftragte für den Datenschutz und die Informationsfreiheit

Christopher Lentzsch

— Bundesfachstelle Barrierefreiheit

Marc-Daniel Klein

Simone Miesner

— Bundesministerium der Finanzen

Konrad Sebon

— Bundesministerium für Ernährung und Landwirtschaft

Andreas Collet

— Bundesministerium für Familie, Senioren, Frauen und Jugend

Fabian Odoj

— brain-SCC GmbH

Sirko Scheffler

— Capgemini Deutschland GmbH

Lars Santesson

— cit GmbH

Klaus Wanner

— Databund e.V.

Detlef Sander

— Dataport AöR

Isabell Pietta

— Deutsche Rentenversicherung Bund

Viola Piegelbrock

— Deutscher Landkreistag

Christian Stuffrein

— DigitalService des Bundes

Stefan Matanovic

Robert Tiedt

— Föderale IT-Kooperation (FITKO)

Tobias Schuh

— Fraunhofer Fokus

Jan Ziesing

— Freie Hansestadt Bremen

Christian Jost

— Freie und Hansestadt Hamburg

Nia Katranouschkova

Stefanie Koch

— Freistaat Sachsen

Gunnar Terhaag

— Generalzolldirektion

Jörg Bursian

— Infora GmbH

Peter Schoen

— Koordinierungsstelle für IT-Standards

Frank Steimke

— Land Berlin

Mario Anton

— Land Hessen LBIT

Prof. Dr. Erdmuthe Meyer zu Bexten

— Land Mecklenburg-Vorpommern

Hauke Rickertsen

— Land Niedersachsen

Luis Kramer

— Land Sachsen-Anhalt

Andreas Altmann

— Land Schleswig-Holstein

Martin Schuster

— Landeshauptstadt Wiesbaden

Hilmar Moser

Sabrina Palm

— MACH ProForms GmbH

Frank-Olaf Wilhelm

— mecodia GmbH

Felix Ebner

— nextgov iT GmbH

Martin Krengel

— Stadt Köln

Tanja Krins

Sabine Möwes

— Stadt Leipzig

Cornelia Pflüger

— Stadt Offenbach

Marius Müller

— SUMM AI GmbH

Vanessa Theel

— TSA Public Service GmbH

Stefan Weißwange

— Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) GmbH

Leonhard Kugler

Für dieses Thema bestehen derzeit keine Normen im Deutschen Normenwerk.

DIN SPEC sind nicht Teil des Deutschen Normenwerks

Für diese DIN SPEC wurde kein Entwurf veröffentlicht.

Trotz großer Anstrengungen zur Sicherstellung der Korrektheit, Verlässlichkeit und Präzision technischer und nicht-technischer Beschreibungen kann das DIN-SPEC-Konsortium weder eine explizite noch eine implizite Gewährleistung für die Korrektheit des Dokuments übernehmen. Die Anwendung dieses Dokuments geschieht in dem Bewusstsein, dass das DIN-SPEC-Konsortium für Schäden oder Verluste jeglicher Art nicht haftbar gemacht werden kann. Die Anwendung der vorliegenden DIN SPEC entbindet den Nutzer nicht von der Verantwortung für eigenes Handeln und geschieht damit auf eigene Gefahr.

Es wird auf die Möglichkeit hingewiesen, dass einige Elemente dieses Dokuments Patentrechte berühren können. DIN ist nicht dafür verantwortlich, einige oder alle diesbezüglichen Patentrechte zu identifizieren.

Die kostenfreie Bereitstellung dieses Dokuments als PDF-Version über den DIN Media Webshop wurde im Vorfeld finanziert.

Mit Ausnahme der DIN-Referenzen (Logo usw.), oder wo anders vermerkt, wird dieses Dokument unter einer Creative Commons Namensnennung 4.0 International Lizenz (CC-BY 4.0) veröffentlicht. Bei einer Weiterverarbeitung sind entsprechende Urheber- und Rechtehinweise (z. B. DIN e. V. als Herausgeber), ein Link zur Lizenz und Angaben zu vorgenommenen Änderungen aufzunehmen. Diese Informationen können in jeder geeigneten Weise gegeben werden, jedoch nicht in einer Weise, die den Eindruck vermittelt, dass der Lizenzgeber Sie oder Ihre Nutzung besonders unterstützt. Weitere Informationen erhalten Sie unter www.creativecommons.org.

Diese DINSPEC wird ebenfalls auf www.din.one veröffentlicht und lädt Anwender bzw. Interessierte dazu ein, die Inhalte zu kommentieren, um zur möglichen Weiterentwicklung beizutragen.

Aktuelle Informationen zu diesem Dokument können über die Internetseiten von DIN (www.din.de) durch eine Suche nach der Dokumentennummer aufgerufen werden.

1. Anwendungsbereich

Dieses Dokument legt die Qualitätsanforderungen an informationstechnische Systeme der digitalen öffentlichen Verwaltung fest. Dieses Dokument ist anwendbar für informationstechnische Systeme, die für den übergreifenden informationstechnischen Zugang zu den Verwaltungsleistungen von Bund, Ländern und Kommunen genutzt werden.

Dieses Dokument adressiert neu zu entwickelnde Onlineservices und -portale sowie Basisdienste (3.3). Dieses Dokument adressiert nicht bereits implementierte Onlineservices und -portale, es sei denn, der Onlineservice (3.16) wird einer grundlegenden Überarbeitung (3.9) unterzogen.

2. Normative Verweisungen

Die folgenden Dokumente werden im Text in solcher Weise in Bezug genommen, dass einige Teile davon oder ihr gesamter Inhalt Anforderungen des vorliegenden Dokuments darstellen. Bei datierten Verweisungen gilt nur die in Bezug genommene Ausgabe. Bei undatierten Verweisungen gilt die letzte Ausgabe des in Bezug genommenen Dokuments (einschließlich aller Änderungen).

DIN 85811, Einfache Sprache — Anwendung für das Deutsche — Teil 1: Sprachspezifische Festlegungen Zu beziehen bei www.dinmedia.de.

DIN EN ISO 9241110, Ergonomie der Mensch-System-Interaktion — Teil 110: Interaktionsprinzipien Zu beziehen bei www.dinmedia.de.

DIN SPEC 33429, Empfehlungen für Deutsche Leichte Sprache Zu beziehen bei www.dinmedia.de.

BSI 200-4, Business Continuity Management Zu beziehen bei www.bsi.bund.de.

BSI TR-03172-3, Technische Richtline Portalverbund — Teil 3: Onlinedienst Zu beziehen bei www.bsi.bund.de.

3. Begriffe

Für die Anwendung dieses Dokuments gelten die folgenden Begriffe. DIN und DKE stellen terminologische Datenbanken für die Verwendung in der Normung unter den folgenden Adressen bereit:

• DIN-TERMinologieportal: verfügbar unter www.din.de
• DKE-IEV: verfügbar unter www.dke.de

3.1 1st-Level-Support erste Anlaufstelle im IT-Support

3.2 andere digitale Angebote wiederverwendbare Software wie zum Beispiel Datenbanken, Skripte und Frameworks

3.3 Basisdienste Basiskomponenten zentral für die digitale Verwaltung bereitgestellte Grundfunktionalitäten wie beispielsweise zur Bezahlung, zur Authentifizierung, zur Datenhaltung und -bereitstellung oder zur Realisierung der erforderlichen Datensicherheit

3.4 Einstiegspunkt Start der Interaktion eines Nutzenden mit einem digitalen Angebot

3.5 End2End vollständiger Prozess oder Workflow, der den Teil des Prozesses zu den Nutzenden und auch den verwaltungsinternen Teil des Prozesses umfasst

3.6 Fachlichkeit Gesamtheit der fachlichen Kompetenzen, Kenntnisse und Methoden, die in einem spezifischen beruflichen oder thematischen Kontext angewendet werden

3.7 Fachstruktur Gremien innerhalb der öffentlichen Verwaltung

3.8 gängiges Endgerät übliches digitales Gerät wie Smartphone, Tablet, Laptop und Desktop-Computer

3.9 grundlegende Überarbeitung wesentliche Änderung an Architektur, Kernfunktion oder Technologie

3.10 interdisziplinär in Zusammenarbeit von Expertinnen und Experten aus verschiedenen Fachbereichen

3.11 iteratives Vorgehen schrittweise Entwicklung durch Entwurf, Test und Verbesserung

3.12 Key Performance Indicator KPI Kenn- und Geschäftszahlen zur Messung des Erfolgs von Zielen

3.13 kritischer Fehler Fehler, der Systemstabilität oder Sicherheit gefährdet

3.14 Monitoring systematische Überprüfung des Fortschritts oder der Qualität

3.15 Onlineportal Bündelung elektronischer Verwaltungsangebote, insbesondere innerhalb des Portalverbunds im Sinne des Onlinezugangsgesetzes (OZG)

3.16 Onlineservice IT-Komponente, die ein eigenständiges elektronisches Angebot an die Nutzenden darstellt, welches die Abwicklung einer oder mehrerer elektronischer Verwaltungsleistungen von Bund oder Ländern ermöglicht

3.17 Open Source Lizenz, die nach Kriterien der Open Source Initiative (OSI) hinreichende Freiheiten zur Kollaboration und dem Schutz der Nutzenden gewährt

3.18 Nutzende Bürgerinnen und Bürger, einschließlich Menschen mit Behinderung, Unternehmen, Vereine und Organisationen, Beschäftigte der öffentlichen Verwaltung und Justiz, die mit einem Onlineservice interagieren

3.19 Nutzendenanalyse Untersuchung, wie Menschen ein Produkt oder einen Service nutzen

3.20 Nutzendengruppe Gruppe von Menschen mit ähnlichen Bedürfnissen, Zielen oder Anforderungen

3.21 Nutzendenproblem Herausforderung, die Nutzende bei der Verwendung eines Onlineservices bzw. Onlineportals erfahren

3.22 Nutzendenreise Weg eines Nutzenden durch einen Onlineservice

3.23 Produkt vollständig entwickelte digitale Anwendung, die über das Internet oder ein Netzwerk zugänglich ist, eine klar definierte Funktion oder Dienstleistung für Nutzende bereitstellt und die ein Onlineservice, ein Onlineportal, ein Projektergebnis oder eine technische Komponente sein kann

3.24 Produktlebenszyklus Phasen eines Produkts von Konzeption bis Abschaffung

3.25 Produktvision nutzendenzentriertes Zielbild eines Onlineservice

3.26 Prototyp Entwurf, um Konzepte zu testen und Ideen zu visualisieren

3.27 Self-Service eigenständige Erledigung administrativer Tätigkeiten für einen Onlineservice durch den Umsetzenden und Steuernden selbst

3.28 Servicedesign Gestaltung von Abläufen, um Nutzendenerlebnisse und Dienstleistungen zu verbessern

3.29 Servicestandard Qualitätsprinzipien für gute digitale Entwicklungspraxis

3.30 steuernde Stelle Projektverantwortliche bzw. für den Onlineservice verantwortliche Personen, welche gleichermaßen Beschäftigte der Verwaltung und Justiz oder externe IT-Dienstleister sein können

3.31 Steuerungskreis übergeordnetes Entscheidungsgremium für die Wiederverwendung von Onlineservices der öffentlichen Verwaltung

3.32 übergeordnete Entscheidungsebene Stelle in der öffentlichen Verwaltung, die der zentral verantwortlichen Stelle gegenüber weisungsbefugt ist

3.33 Usability Grad der Nutzendenfreundlicheit eines informationstechnischen Systems

3.34 Usabilityproblem Hindernis aufgrund schlechter Nutzendenführung

3.35 User Research Untersuchung von Nutzendenbedürfnissen und -verhalten

3.36 wiederverwendeter Onlineservice zentral entwickelter, digitaler Verwaltungsdienst, der flexibel durch andere zentral oder dezentral genutzt wird

3.37 Wiederverwendung Nutzung einer bereits im Einsatz befindlichen Software

4. Kurzbeschreibung

Die folgenden Unterabschnitte 5.1 bis 5.13 definieren Anforderungen entlang eines Entwicklungsprozesses, der den gesamten Lebenszyklus eines digitalen Produkts umfasst. Dieser Entwicklungsprozess lässt sich in vier Phasen (Analyse, Umsetzung, Betrieb und Weiterentwicklung) einteilen, ist aber nicht als streng linearer Prozess zu verstehen. Vielmehr zeigt die Praxis, dass es in jeder der vier Phasen Iterationsschleifen gibt und dass ein Teil der Anforderungen in mehreren Phasen von Bedeutung ist. Beispielsweise steigt die Wahrscheinlichkeit einen von den Nutzenden akzeptierten und als nützlich angesehenen Onlineservice zu entwickeln, wenn die Nutzendenanalyse (3.19) nicht nur am Anfang einmalig durchgeführt wird, sondern im Sinne eines nutzendenzentrierten Ansatzes in jeder der vier Phasen zum Einsatz kommt.

5 Anforderungen

5.1 Nutzendenanalyse

5.1.1 Nutzendengruppen (3.20) müssen identifiziert, quantifiziert und beschrieben werden.

ANMERKUNG Eine Beispiel-Methode zur Beschreibung von Nutzendengruppen sind Personas. Andere Methoden sind möglich.

5.1.2 Nutzendenprobleme (3.21) des Status Quo müssen identifiziert und priorisiert werden.

5.1.3 Nutzendenbedürfnisse müssen unter Beteiligung der Nutzenden (3.18) und Stakeholder erhoben, systematisch abgeleitet und priorisiert werden.

5.1.4 Die Ergebnisse der Nutzendenanalyse (3.19) müssen dokumentiert werden und einsehbar sein.

5.2 Bedarfs- und Prozessanalyse

5.2.1 Die zu lösenden Probleme und der Ist-Prozess (einer Verwaltungsleistung oder eines Onlineservices bzw. -portals) mit ihren relevanten fachlichen, rechtlichen und technischen Rahmenbedingungen sowie den Anforderungen und Bedarfen der Nutzenden (3.18) müssen strukturiert analysiert werden.

ANMERKUNG Eine Beispiel-Methode zur Problemanalyse ist die Problembeschreibung (en: „Problem Statement”). Andere Methoden sind möglich.

5.2.2 Ein Soll-Prozess muss auf Basis der Bedarfs- und Nutzendenanalyse (3.19) erstellt werden und alle relevanten Rahmenbedingungen für das Zielbild berücksichtigen. Er kann als Produktvision (3.25) formuliert werden, die wiederum eine Grundlage für die Releaseplanung bietet.

5.2.3 Die Ergebnisse der Bedarfs- und Prozessanalyse sowie die ggf. vorhandene Produktvision (3.25) müssen dokumentiert werden.

ANMERKUNG Eine Beispiel-Methode für die Dokumentation ist ein Fachkonzept. Andere Methoden sind möglich.

5.2.4 Es müssen quantitative und qualitative Key Performance Indicators (KPIs) (3.12) sowie Methoden für die spätere Wirkungsmessung des Soll-Prozesses definiert und erfasst werden.

5.2.5 Der Soll-Prozess muss Key Performance Indicators (KPIs) (3.12) enthalten, die den Mehrwert bzw. die Verbesserung vom Ist-Prozess zum Soll-Prozess konkret nachweisen.

5.2.6 Es sollte systematisch geprüft werden, ob der Onlineservice (3.16), der Soll-Prozess oder die Produktvision (3.25) (unbeabsichtigte) ethische oder soziale Folgen hat, auch in der Gesamtschau mit anderen Diensten, zum Beispiel Ausschluss vulnerabler Gruppen, systematische Verzerrung oder Diskriminierung.

5.3 Rollen und Verantwortung

5.3.1 Es muss eine steuernde Stelle (3.30) für den Onlineservice (3.16) bzw. das Onlineportal (3.15) festgelegt werden. Innerhalb der steuernden Stelle muss eine Vertretungsregelung festgelegt werden. Die steuernde Stelle verantwortet Produktmanagement, Umsetzung, Betrieb und Weiterentwicklung (u. a. Nutzendenanalyse (3.19), Bedarfs- und Prozessanalyse, Support, Wartung, IT-Sicherheit, Datenschutz) und beinhaltet die Sicherstellung der organisatorischen, rechtlichen, finanziellen und technischen Rahmenbedingungen. Die Verantwortung kann für einzelne Bereiche delegiert werden.

5.3.2 Welche einzelne Stelle die zentrale Verantwortung für den jeweiligen Onlineservice (3.16) bzw. das Onlineportal (3.15) trägt, muss für die Nutzenden (3.18) des Onlineservices bzw. des Onlineportals einfach ersichtlich sein. Dazu gehören auch die Möglichkeiten, wie mit der steuernden Stelle (bzw. delegierten Stellen) in direkten Kontakt getreten wird.

ANMERKUNG 1 Direkte Kontaktmöglichkeiten sind beispielsweise eine E-Mail-Adresse, ein Kontaktformular oder eine Telefonnummer.

ANMERKUNG 2 Dazu kann auch ein zusätzliches maschinenlesbares Dokument nach RFC 9116 („security.txt”) gehören.

5.3.3 Die Rollen und Verantwortlichkeiten für Fachlichkeit (3.6), die technische Umsetzung und den Betrieb müssen festgelegt werden. Dazu gehört die Definition von entsprechenden Rollen und deren Kompetenzen sowie die der Verantwortungsbereiche.

5.3.4 Es müssen im Rahmen der haushaltsrechtlichen Möglichkeiten die notwendigen Vorkehrungen getroffen werden, dass die notwendigen Ressourcen (Personal, Hardware, Software, weitere Hilfsmittel) zur kontinuierlichen Analyse, Umsetzung, Betrieb und Weiterentwicklung des Onlineservices (3.16) bzw. des Onlineportals (3.15) vorhanden sind.

5.3.5 Mit der übergeordneten Entscheidungsebene (3.32) muss vor Beginn der Umsetzungsphase des Onlineservices (3.16) bzw. des Onlineportals (3.15) geklärt werden, welche Entscheidungen die steuernde Stelle (3.30) selbst treffen darf, welche abzustimmen sind und wie der Entscheidungsprozess abläuft.

5.4 Vorgehen und Zusammenarbeit

5.4.1 Onlineservices und -portale sind als Produkte (3.23) zu verstehen, die im Sinne eines Produktlebenszyklus (3.24) beständig überprüft, weiterentwickelt und veränderten Nutzendenbedürfnissen angepasst werden müssen.

5.4.2 Die Art der Umsetzung muss flexibel an die spezifischen Herausforderungen der Ergebnisse aus der Bedarfs- und Prozessanalyse (5.2) angepasst sein. Onlineservices und -portale mit sehr geringer fachlicher und funktionaler Komplexität können in einem Schritt umgesetzt werden. Für fachlich und funktional komplexe Prozesse, die beispielsweise die Integration mehrerer Datenquellen, Validierungsmechanismen oder Berechnungslogiken umfassen, muss hingegen ein iteratives Vorgehen (3.11) genutzt werden.

ANMERKUNG Onlineservices mit sehr geringer funktionaler Komplexität sind beispielsweise einfache elektronische Formulare ohne Prüf- oder Verarbeitungslogik.

5.4.3 Durch die Nutzendenanalyse (Unterabschnitt 5.1) und kontinuierliches Testen entlang des Produktlebenszyklus (3.24) muss sichergestellt werden, dass Probleme hinsichtlich Benutzbarkeit, Verständlichkeit oder Leistungsfähigkeit eines Onlineservices (3.16) bzw. Onlineportals (3.15) frühzeitig sichtbar gemacht und behoben werden. Für das Prüfen und Testen eignen sich Datenauswertungen und Prototypen (3.26).

5.4.4 Eine kontinuierliche und transparente Wirkungssteuerung anhand definierter Key Performance Indicators (KPIs) (3.12) muss sichergestellt werden. Neben datengestützten, quantitativen KPIs (Beispiel-Kennzahlen finden sich in 5.12.2) müssen auch qualitative Erkenntnisse einfließen.

BEISPIEL Zu qualitativen Erkenntnissen zählen Feedbacks aus Nutzendentests, Rückmeldungen aus dem Support sowie aus den Behörden.

5.4.5 Die Umsetzung von Onlineservices und -portalen muss interdisziplinär (3.10) geschehen. Abhängig von der Komplexität des Onlineservices kann sie Expertisen wie fachliches Wissen, User Research (3.35), User Interface Design, Servicedesign (3.28)/User Experience Design, Produktmanagement, Software-Entwicklung, IT-Sicherheit, Prozessmanagement, Anforderungsmanagement, Software-Architektur, Testmanagement, Informationssicherheit, IT-Betriebsmanagement, IT-Support, Barrierefreiheit, Datenschutz und Recht umfassen.

5.5 Synergien und Wiederverwendung

5.5.1 Bevor ein Onlineservice (3.16) oder Onlineportal (3.15) neu entwickelt wird, muss geprüft werden, ob ein entsprechender Onlineservice bereits verfügbar ist, zum Beispiel am Markt oder auf Marktplätzen der öffentlichen Verwaltung. Dabei muss die Passgenauigkeit bezüglich der Nutzendenbedürfnisse und technischer sowie prozessualer Anforderungen geprüft werden. Bei einer Neuentwicklung muss geprüft werden, ob Bestandteile bereits vorhandener Onlineservices oder andere digitale Angebote (3.2) wiederverwendet werden können.

BEISPIEL Ein Bestandteil bereits vorhandener Onlineservices könnte unter anderem ein Design-System sein.

5.5.2 Gibt es nach erfolgter Prüfung mehrere bestehende Onlineservices (3.16) oder andere digitale Angebote (3.2), die für die Wiederverwendung (3.37) infrage kommen, muss bei Gleichwertigkeit in allen anderen Belangen (insbesondere Gesamtkosten, Leistungsumfang, Qualität, Bereitstellungsgeschwindigkeit, Weiterentwicklungspotenzial) ein Onlineservice unter einer Open-Source-Lizenz vorgezogen werden.

5.5.3 Bestehende Onlineservices (3.16) oder andere digitale Angebote (3.2) der öffentlichen Verwaltung müssen bei erfolgreicher Prüfung auf Wiederverwendung (3.37) genutzt werden.

5.5.4 Für neu zu entwickelnde Onlineservices und -portale muss geprüft werden, ob andere Behörden bzw. Organisationen der öffentlichen Verwaltung ein Interesse an einer Wiederverwendung (3.37) haben.

5.5.5 Ist die Prüfung auf Wiederverwendung (3.37) in 5.5.4 positiv, muss der Onlineservice (3.16) bzw. das Onlineportal (3.15) in Abstimmung mit anderen Behörden bzw. Organisationen der öffentlichen Verwaltung im Sinne einer gemeinsamen Anforderungsklärung konzipiert und entwickelt werden. Die beteiligten Behörden und Organisationen, sowie deren Fachexperten und Fachexpertinnen, müssen sich zur gemeinsamen Anforderungsklärung abstimmen. Die Fachlichkeit (3.6) sollte mit Personen besetzt werden, die die aktuellen Ist- und die abzustimmenden Soll-Prozesse der Verwaltungsleistung bzw. der Nutzendenreise (3.22) am besten kennen.

5.5.6 Für jeden wiederverwendeten Onlineservice (3.36) muss ein Steuerungskreis (3.31) genutzt werden. Hierzu sollten bestehende Fachstrukturen (3.7) genutzt werden.

5.5.7 Für den wiederverwendeten Onlineservice (3.36) kann eine Expertengruppe einberufen werden, die die Inhalte des Steuerungskreises (3.31) fachlich, rechtlich und technisch aufbereitet und bewertet. Hier sind Fachleute aus Bund, Ländern, Kommunen oder andere Experten bei Bedarf einzubinden.

5.5.8 Der Betreiber eines wiederverwendeten Onlineservices (3.36) muss die Verantwortung für Betrieb und Pflege seines Onlineservices übernehmen bzw. organisieren.

5.6 Nutzendenfreundlichkeit, digitale Barrierefreiheit und Inklusion

5.6.1 Ineffiziente, nutzendenunfreundliche und komplexe Prozesse müssen in Richtung des in 5.2.2 definierten Soll-Prozesses verbessert werden, wenn sie Teil des Onlineservices (3.16) sind. Die Verbesserung der Prozesse muss „End2End” (3.5) erfolgen. Der Roll-out des verbesserten Prozesses sollte vor der Umsetzung des Onlineservices geschehen. Beispiel-Key Performance Indicators (KPIs) (3.12) für (In-)Effizienz sind in 5.12.2 zu finden.

5.6.2 Onlineservices und -portale müssen so gestaltet sein, dass Nutzende (3.18) ihre Ziele effektiv, effizient und zufriedenstellend erreichen. Benutzerschnittstellen sind nach DIN EN ISO 9241110 ergonomisch zu gestalten, zudem muss die Usability (3.33) auf gängigen Endgeräten (3.8) berücksichtigt werden. Es dürfen keine mittelschweren oder schweren Usabilityprobleme (3.34) auftreten. Zur Bewertung sollte die 5-stufige Skala nach Nielsen [1] genutzt werden.

5.6.3 Onlineservices, die Verwaltungsleistungen anbieten, müssen über die zentralen Onlineportale (3.15) der öffentlichen Verwaltung auffindbar sein.

5.6.4 Onlineservices und -portale sollten die Zwischenspeicherung von Eingaben der Nutzenden (3.18) ermöglichen.

5.6.5 Onlineservices und -portale müssen Nachweise und Daten der Nutzenden (3.18) auf deren Ersuchen automatisch einholen, wenn eine entsprechende Rechtsgrundlage besteht und sie bei Behörden in Deutschland oder anderen EU-Mitgliedstaaten verfügbar sowie über eine Schnittstelle (API) zugänglich sind (Erfüllung des Once-Only-Prinzips).

5.6.6 Onlineservices und portale müssen die Regelungen der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) einhalten. Onlineservices und portale müssen eine Erklärung zur Barrierefreiheit (EzB) und einen Feedback-Mechanismus zur digitalen Barrierefreiheit gemäß BITV 2.0, § 7, enthalten. Onlineservices und -portale müssen die Vorgaben gemäß BITV 2.0, § 4, zur Gebärdensprache und Leichten Sprache erfüllen. Leichte Sprache muss nach DIN SPEC 33429 angeboten werden. Alle Inhalte des Onlineservices sollten in Leichter Sprache und Gebärdensprache angeboten werden.

ANMERKUNG Ziel ist die Schaffung eines einheitlichen Barrierefreiheitsniveaus der BITV 2.0 über die Regelungen der Länder hinaus.

5.6.7 Onlineservices und -portale müssen in Einfacher Sprache nach DIN 85811 angeboten werden, die dem Bedarf der Nutzenden (3.18) angepasst ist. Auf komplizierte Fachsprache sollte möglichst weitgehend verzichtet werden.

5.6.8 Onlineservices und -portale müssen in deutscher Sprache angeboten werden. Zusätzlich müssen Onlineservices und -portale technisch in der Lage sein, die Inhalte in Fremdsprachen anzubieten und zu verarbeiten. Darüber hinaus sollten Onlineservices und -portale in Fremdsprachen angeboten werden, die sich an den Erfordernissen der Nutzenden und regionalen Gegebenheiten orientieren. Bei Fremdsprachen sollte die rechtliche Verbindlichkeit geprüft und kenntlich gemacht werden.

5.7 Nutzung offener Standards

5.7.1 Die Nutzenden des Onlineservices (3.16) und dessen Schnittstellen bzw. des Onlineportals (3.15) müssen diese mit offener und kostenfreier Software nutzen können. Die Überprüfung sollte jährlich erfolgen.

5.7.2 Es muss geprüft werden, ob im geplanten Einsatzkontext des Onlineservices (3.16) bzw. des Onlineportals (3.15) die Nutzung föderaler IT-Standards empfohlen oder verbindlich vorgegeben ist. Gibt es keine Vorgaben, sollte geprüft werden, ob bereits in anderen Kontexten geeignete IT-Standards verwendet werden, die ggf. wiederverwendet werden können. Diese Standards sollten offen sein.

5.7.3 Fehlen Standards für die effiziente Entwicklung von Onlineservices und -portalen, müssen diese Bedarfe an die zuständige Stelle gemeldet werden.

5.7.4 Für den Datenaustausch mit anderen Systemen müssen Schnittstellen (API) angeboten werden. Die Anmeldung zur Nutzung sollte per Self-Service (3.27) möglich sein.

5.8 Datenschutzfreundlichkeit

5.8.1 Bereits in der Konzeption sollte, ausgehend von den vorgesehenen Verarbeitungsvorgängen (Verzeichnis der Verarbeitungstätigkeiten), eine Datenschutzfolgenabschätzung (DSFA) gemäß Datenschutz-Grundverordnung (Art. 35 DSGVO) durchgeführt werden.

5.8.2 Es muss bereits bei der Konzeption ein Datenschutzkonzept entwickelt werden, das geeignete technische und organisatorische Maßnahmen festlegt, um die mit der Verarbeitung der Daten einhergehenden Risiken angemessen zu mindern.

5.8.3 Onlineservices und -portale müssen den Umfang der genutzten Daten auf das erforderliche Maß reduzieren.

BEISPIEL Die Prüfung, ob das Geschlecht der Person für die Bearbeitung des Antrags zwingend erforderlich ist, oder ausschließlich für die Begrüßungsformel Verwendung findet.

5.8.4 Onlineservices und -portale müssen die Prinzipien „Datenschutz durch Technikgestaltung” (en: „Data protection by design and by default” aus der DSGVO) und „datenschutzfreundliche Voreinstellungen” umsetzen.

5.8.5 Onlineservices und -portale müssen die betroffenen Personen transparent über die Verarbeitungen und Schnittstellen zu weiteren Onlineservices (3.16) informieren und die Betroffenenrechte sicherstellen.

5.8.6 Onlineservices und -portale müssen Aufbewahrungsfristen festlegen und personenbezogene Daten fristgerecht löschen.

5.9 Sicherheit und Vertrauenswürdigkeit

5.9.1 Onlineservices (3.16) müssen die Regelungen von BSI/TR 031723 einhalten.

5.9.2 Die IT-Sicherheit der Onlineservices und -portale muss sichergestellt sein. Onlineservices und -portale müssen durch Webchecks und Penetrationstests auf Schwachstellen getestet werden. Onlineservices und portale müssen auf Leistungsfähigkeit bei vielen gleichzeitig Nutzenden (3.18) getestet werden, wenn viele gleichzeitig Nutzende erwartet werden.

5.9.3 Es muss für die Nutzenden (3.18) ein oder mehrere Unterstützungsangebote geben – zur Hilfestellung beim Bearbeiten/Ausfüllen, bei Fragen zum Onlineservice (3.16) bzw. zum Onlineportal (3.15) und zum Melden von technischen Problemen. Die Kontaktmöglichkeiten müssen ab Beginn der Nutzendenreise (3.22) bekannt gemacht werden, Nutzende (3.18) müssen bei geäußertem Bedarf auf alternative Möglichkeiten hingewiesen werden.

5.9.4 Onlineservices und -portale müssen als Leistung der öffentlichen Verwaltung klar erkennbar und unter einer vertrauenswürdigen Domain erreichbar sein.

5.10 Open Source

5.10.1 Zwischen der öffentlichen Verwaltung und dem IT-Dienstleister, der den Onlineservice (3.16) bzw. das Onlineportal (3.15) umsetzt, sollte vereinbart werden, dass der Quellcode eines neu entwickelten Onlineservices (3.16) bzw. des Onlineportals (3.15) als Open Source (3.17) veröffentlicht wird. Die abweichende Verwendung proprietärer Software anstelle von Open-Source-Software muss finanziell, technisch oder organisatorisch begründet und dokumentiert werden.

5.10.2 Sofern nach 5.10.1 der Quellcode als Open Source (3.17) veröffentlicht wird, muss eine geeignete Open-Source-Lizenz ausgewählt werden. Die Lizenz sollte mit Hinblick auf die langfristige Nutzung der Software gewählt werden. Sowohl permissive Lizenzen wie MIT, als auch CopyLeft Lizenzen wie die European Union Public Licence (EuPL) können Verwendung finden.

ANMERKUNG Bei der Open Source Initiative (OSI) und auf der vom Zentrum Digitale Souveränität (ZenDiS) betriebenen Plattform „openCode” finden sich juristisch auf ihre spezifische Nutzbarkeit in der öffentlichen Verwaltung hin geprüfte Listen geeigneter Lizenzen.

5.11 Betrieb und Support

5.11.1 Die Verfügbarkeit von Onlineservices und -portalen muss nach BSI 2004 des Bundesamts für Sicherheit in der Informationstechnik (BSI) sichergestellt werden.

5.11.2 Das technische Monitoring (3.14) des Onlineservices (3.16) bzw. Onlineportals (3.15) muss implementiert sein.

5.11.3 Ist die Nutzung des Onlineservices (3.16) beeinträchtigt, zum Beispiel durch einen temporären Ausfall, müssen die Nutzenden (3.18) an Einstiegspunkten (3.4) und im Onlineservice darauf hingewiesen werden. Dieser Hinweis muss zeitlich unverzüglich erfolgen.

5.11.4 Ein 1st-Level-Support (3.1) als Erstkontakt für die Nutzenden (3.18) muss bereitgestellt sein.

5.11.5Die Betreiber von Onlineservices (3.16) müssen Strukturen für 2nd- und 3rd-Level-Support bereitstellen und mit den nachnutzenden Behörden abstimmen.

5.11.6 Als zusätzliche Support-Möglichkeit sollte die einheitliche Behördenrufnummer 115 als Erstkontakt für die Nutzenden (3.18) bereitgestellt werden, sofern verfügbar.

5.11.7 Die Reaktionszeiten für das Beseitigen von Fehlern müssen zwischen Verwaltung und IT-Dienstleister vereinbart sein. Dabei muss nach dem Schweregrad des technischen Fehlers unterschieden werden. Kritische Fehler (3.13) müssen umgehend behoben werden.

5.11.8 Betrieb und Support müssen mit Key Performance Indicators (KPIs) (3.12) nach dem Stand der Technik überwacht werden.

ANMERKUNG Für weitere Informationen zu geeigneten KPIs und deren Anwendung siehe auch 5.2.4, 5.4.4 und 5.12.2.

5.11.9 Onlineservices und -portale nutzen zum Teil Basisdienste (3.3), für die eine andere Stelle innerhalb der öffentlichen Verwaltung zuständig sein kann. Fallen der steuernden Stelle für den Onlineservice (3.16) bzw. des Onlineportals (3.15) Usabilityprobleme (3.34) oder technische Probleme des genutzten Basisdienstes auf, muss die steuernde verantwortliche Stelle für den Basisdienst darüber umgehend und direkt informiert werden.

5.11.10 Der Quellcode sowie die Dokumentation müssen für eine sachkundige Person verständlich sein und nach dem Stand der Technik entwickelt werden. Die Qualität des Quellcodes muss nach Best Practices der jeweiligen Entwicklungssprachen geprüft werden.

5.12 Evaluation und Weiterentwicklung

5.12.1 Qualitatives und quantitatives Nutzendenfeedback muss in anonymisierter Form kontinuierlich gesammelt und von der steuernden Stelle ausgewertet werden. Für die Nutzenden (3.18) muss dies optional sein.

5.12.2 Es müssen Key Performance Indicators (KPIs) (3.12) zur Nutzung des Onlineservices (3.16) bzw. des Onlineportals (3.15) automatisiert mithilfe einer datenschutzkonformen Lösung erfasst werden. Die Auswahl der KPIs hängt von den betrachteten Nutzendengruppen (3.20) und vom Onlineservice bzw. Onlineportal ab. Die KPIs sollten über weite Strecken einer Nutzendenreise (3.22) erhoben werden.

5.12.2.1 Folgende Kennzahlen müssen erhoben werden:

• Besuche: Anzahl der Nutzenden (3.18) bzw. Besuchende eines Onlineservices und Seitenaufrufe einer Website bzw. Bildschirmansichten einer App;
• Konvertierungsrate/Abschlüsse: Anzahl der Nutzenden eines Onlineservices, die erfolgreich ein vordefiniertes Ziel erreicht haben, zum Beispiel einen Antrag übermittelt haben;
• Nutzendenzufriedenheit: Durchschnittliche Bewertung eines Onlineservices auf einer klar definierten quantifizierten Skala.

5.12.2.2 Folgende Kennzahlen sollten erhoben werden:

• Anzahl korrekt eingereichter Anträge;
• Anteil der fehlerhaft ausgefüllten Anträge;
• Anzahl der Übermittlungsfehler nach dem Versand an die Behörde;
• durchschnittliche Bearbeitungsdauer eines Antrags;
• Anzahl an Medienbrüchen: Anzahl der Medienwechsel, z. B. digital zu analog;
• Anzahl der technischen Supportanfragen zum Onlineservice bzw. -portal;
• Anzahl der Usabilityprobleme (3.34) oder technische Probleme mit verwendeten Basisdiensten (3.3);
• qualitatives Feedback: Anzahl der Nutzendenfeedbacks zur Verbesserung;
• Digital Take-Up/Nutzungsgrad: Anteil der digital übermittelten Anträge über einen Onlineservice im Verhältnis zu allen eingegangenen Anträgen;
• durchschnittliche Kosten je abgeschlossener Transaktion.

5.12.2.3 Weitere Kennzahlen können erhoben werden.

ANMERKUNG Nicht alle unter 5.12.2.2 aufgeführten Kennzahlen sind für Basisdienste (3.3) relevant.

5.12.3 Erkenntnisse aus der Auswertung von Nutzendenfeedback und quantitativen Nutzungsdaten müssen in die Weiterentwicklung des Onlineservices (3.16) bzw. des Onlineportals (3.15) einfließen.

5.12.4 Sind die Nutzendenzufriedenheit und/oder der Nutzungsgrad, unter Beachtung der zu erwartenden Nutzung, nachweislich niedrig, müssen Maßnahmen zur Verbesserung des Onlineservices (3.16) bzw. des Onlineportals (3.15) und zur Steigerung der Nutzendenzufriedenheit und/oder des Nutzungsgrads umgesetzt werden.

5.12.5 Wird ein Onlineservice wiederverwendet, sollten die oben definierten Kennzahlen den Mitnutzungsverantwortlichen in einem auswertbaren Format regelmäßig zur Verfügung gestellt werden.

BEISPIEL Auswertbare Formate sind .json, .csv- oder .txt-Format, die über Dashboards oder eine Schnittstelle (API) bereitgestellt werden. Andere Formate sind möglich.

5.13 Rechtlicher Änderungsbedarf

Die steuernde Stelle (3.30) für den Onlineservice (3.16) bzw. das Onlineportal (3.15) muss rechtliche Änderungsbedarfe an die für die Rechtssetzung zuständigen Ministerien melden, wenn:

• bestehende gesetzliche Regelungen einem optimalen, nutzendenfreundlichen Onlineservice entgegenstehen;
• Änderungen den Onlineservice vereinfachen könnten; oder
• eine wirtschaftlichere Umsetzung oder Betrieb dadurch möglich werden würde.

ANMERKUNG Bestehende Formerfordernisse sind im digitalen Zeitalter teilweise nicht mehr notwendig. Beispiele: Schriftformerfordernisse oder die Anordnung des persönlichen Erscheinens. Das Erkennen und die Beseitigung solcher rechtlichen Hürden erhöhen die Digitaltauglichkeit des Rechts.