Hinweise
| Vergabe: 0229/26 |
|---|
| Leistungskatalog - Allgemeine Hinweise |
| Stand: 21.08.2026 |
| Version: 1.0 |
| Allgemeine Hinweise zur Vergabeunterlage: |
| Der vorliegende Leistungskatalog besteht aus mehreren Bestandteilen. Er ist von den Bietenden bei Angebotsabgabe vollständig ausgefüllt einzureichen und wird im Falle des Zuschlags Vertragsbestandteil. |
| Das Tabellenblatt "Leistungsbeschreibung" enthält die Anforderungen der Auftraggeberin zum Ausschreibungsgegenstand. Hierin sind von den Bietenden Angaben zum Erfüllungsgrad der Anforderungen zu machen. |
| Die von den Bietenden zu befüllenden Felder sind grün markiert. |
| Die Anforderungen sind gegliedert in A und B Kriterien: |
| A Kriterien sind Mindestanforderungen an die ausgeschriebene Leistung. Die Nichterfüllung eines A-Kriteriums führt zum Ausschluss aus dem Vergabeverfahren. |
| B Kriterien sind qualitative Zuschlagskriterien im Rahmen des Vergabeverfahrens. Sie stellen wünschenswerte Eigenschaften der ausgeschriebenen Leistung dar und fließen entsprechend Ihrer Gewichtung in die Qualitätsbewertung des Vergabeverfahrens ein. |
| Die Bietenden machen hier Angaben zum Erfüllungsgrad des Kriteriums entsprechend dem angegebenen Bewertunsgmaßstab (Spalte E bis G). |
| Die Punkte für die B-Kriterien werden im Anschluss gewichtet und bilden zusammen mit der Punktzahl für das Konzept die Leistungspunkte für die Qualitätsbewertung. |
| B-Kriterien, zu denen keine Angaben gemacht werden, werden mit 0 Punkten bewertet. |
| Der angegebene Erfüllungsgrad der B-Kriterien gilt im Falle der Zuschlagserteilung als vertraglich zugesicherte Eigenschaft der angebotenen Leistung. |
| Die Bewertungsübersicht enthält eine Übersicht über den Bewertungsmaßstab und die Gewichtung der B-Kriterien. Hier sind von den Bietenden keine Angaben zu machen. |
| Das Tabellenblatt "Bewertungsmaßstab Konzept" enthält den Maßstab für die Bewertung des von den Bietenden bei Angebotsabgabe einzureichenden Einführungskonzeptes (Vgl. Afo 22 - Leistungsbeschreibung). |
| Hierin sind von den Bietenden keine Angaben zu machen. |
Leistungsbeschreibung
| Vergabe: 0229/26 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 | Unnamed: 6 |
|---|---|---|---|---|---|---|
| Leistungskatalog - Tabellenblatt Leistungsbeschreibung | ||||||
| Stand: 21.08.2026 | ||||||
| Version: 1.0 | ||||||
| Afo # | Beschreibung | Kriterium | Erfüllungsgrad | Soll Kriterium - 0 Wertungspunkte Maßstab | Soll Kriterium - 1 Wertungspunkt Maßstab | Soll Kriterium - 2 Wertungspunkte Maßstab |
| 1 Einleitung | ||||||
| Das Bundesamt für die Sicherheit der nuklearen Entsorgung (BASE) ist eine wissenschaftlich-technische Behörde mit ca. 450 Beschäftigten im Geschäftsbereich des Bundesministeriums für Umwelt, Klimaschutz, Naturschutz und nukleare Sicherheit (BMUKN) mit Hauptsitz in Berlin und Dienststellen in Salzgitter, Köln und Bonn. Das BASE bündelt die Kompetenzen im Bereich der nuklearen Entsorgung. Es arbeitet als Genehmigungsbehörde für die Sicherheit von Kernbrennstofftransporten und Zwischenlagern, bearbeitet Fragen der kerntechnischen Sicherheit und ist atomrechtliche Genehmigungs- und Aufsichtsbehörde für die Endlagerung. Das BASE betreibt Forschung und berät die Bundesregierung zu Fragen der nuklearen Sicherheit. Es führt die atomrechtliche Aufsicht über die Endlager Konrad und Morsleben sowie über die Stilllegung der Schachtanlage Asse. | ||||||
| Es begleitet und beaufsichtigt die Umsetzung des Standortauswahlverfahrens für ein Endlager für hochradioaktive Abfälle in der Bundesrepublik und verantwortet als Träger der Öffentlichkeitsbeteiligung die Beteiligung der Öffentlichkeit. | ||||||
| Mit dem Inkrafttreten des novellierten Standortauswahlgesetzes (StandAG) hat im Mai 2017 das Auswahlverfahren eines Standortes für die sichere Endlagerung von hochradioaktiven Abfällen in Deutschland begonnen. Ziel der ergebnisoffenen, vergleichenden, wissenschaftsbasierten und transparenten Suche ist es, den Standort für ein Endlager mit der bestmöglichen Sicherheit für einen Zeitraum von einer Million Jahren festzulegen. Das Ergebnis soll sich durch eine breite gesellschaftliche Tolerierbarkeit auszeichnen und von der Standortregion mitgetragen werden können. Das BASE beaufsichtigt die Suche nach dem Endlager für hochradioaktive Abfälle und agiert als Trägerin der Öffentlichkeitsbeteiligung. Es schafft die Grundlagen und Rahmenbedingungen dafür, wie verschiedene Stakeholder sowie Bürger:innen in die Standortsuche eingebunden werden können. Die Standortauswahl ist als „selbsthinterfragendes und lernendes Verfahren“ konzipiert. Entsprechend evaluieren die beteiligten Verfahrensakteur:innen den erreichten Verfahrensstand regelmäßig und nehmen gegebenenfalls Anpassungen vor. | ||||||
| Im Rahmen seiner Aufgaben führt das BASE Beteiligungsformate zur Beteiligung der Öffentlichkeit durch. In der Vergangenheit wurden bereits verschiedene Dokumente des BASE mit einfachen technischen Möglichkeiten in einer Basisversion online konsultiert, z. B. die Forschungsagenda und -strategie (2018), die Berechnungsgrundlage zur Dosisabschätzung der Abteilung A (2021), das Konzept zur Öffentlichkeitsbeteiligung in der Startphase der Endlagersuche (2018) sowie das Programm für die 2. Statuskonferenz Endlagerung (2019). | ||||||
| Vor diesem Hintergrund beabsichtigt das BASE die Beschaffung einer Online-Beteiligungsplattform (kurz: BTMS), auf der Informationen zum Stand der Beteiligungsmöglichkeiten und alle laufenden und abgeschlossenen Beteiligungsverfahren dargestellt werden können. Mit der Beteiligungsplattform soll ein digitales Beteiligungs- und Informationsangebot des BASE geschaffen werden, das Interesse sowohl an den Standortauswahlthemen als auch weiteren Themen der nuklearen Sicherheit weckt, sowie Bedarfe und Anregungen der interessierten Öffentlichkeit eruiert. Künftige Schwerpunkte der Beteiligungsplattform sind insbesondere die Vorbereitungen (2026-2027) und Einrichtung (2028) der Regionalkonferenzen sowie des Rats der Regionen im Rahmen des Standortauswahlverfahren (StandAV). | ||||||
| Um in dem komplexen Verfahren der Suche nach einem Endlager für hochradioaktiven Abfall flexibel auf neue Herausforderungen und spezifische Bedarfe reagieren zu können, soll es möglich sein, auf der digitalen Beteiligungsplattform weitere, im Standortauswahlverfahren eingebundene Stellen mit allen Funktionen der Plattform zu erstellen (Vgl. 8.2): Neben dem Hauptmandanten für das BASE auf der Plattform sollen optional bis zu 12 zusätzliche Mandanten mit einer separaten URL und Nutzer:innengruppen verfügbar gemacht werden können. Die nachfolgenden funktionalen Anforderungen gelten sowohl für den Hauptmandanten des BASE als auch für die weiteren, im Standortauswahlverfahren eingebundenen Stellen. Weitere Informationen zu den Aufgaben des BASE finden sich auf der Website der Behörde www.base.bund.de. | ||||||
| 2 Ausschreibungsgegenstand | ||||||
| Der Ausschreibungsgegenstand ist eine „Out-of-the-Box-Lösung“ (OOTB), also ein bereits vollständig entwickeltes Produkt, das die benötigten Funktionen standardmäßig enthält. Es sind lediglich Konfigurationen (z. B. Rechte, Rollen) und Anpassungen an das BASE-Branding vorzunehmen. | ||||||
| Das BASE vergibt den Auftrag zur Einrichtung, zum Betrieb der Beteiligungsplattform mit einer Landingpage und einem Content Management System (CMS) zur Verwaltung und Darstellung von Informationen für das jeweilige Beteiligungsverfahren. Die Plattform muss mit sämtlichen nachfolgend definierten Modulen zur Beteiligung von Bürger:innen und Teilnehmenden ab dem 1. Quartal 2027 produktiv im Einsatz sein – nach der Ausschreibung, der Auftragserteilung, der Konfiguration, dem Wissenstransfer und der Einarbeitung in das beschaffte System. | ||||||
| Die produktive Beteiligungsplattform macht sich dabei menschenzentrierte Designqualitätsstandards (HCD) für digitale Kommunikation zu nutze. Ziel ist es, dass Nutzer:innen effektiv, effizient und zufriedenstellend Informationen zu laufenden Beteiligungsverfahren des BASE erhalten und sich umgehend niedrigschwellig in laufende Beteiligungsverfahren einbringen können. Unterstützt werden die Nutzer:innen durch ein weiterführendes und vertiefendes Informationsangebot, das über verschiedene Contentdarstellungen zur Verfügung gestellt wird. | ||||||
| Nach durchgeführter Registrierung können Nutzer:innen auf der Plattform bestimmte Funktionalitäten der digitalen Beteiligung wahrnehmen. | ||||||
| Darüber hinaus muss die Plattform über eine konfigurierbare Schnittstelle zum Auslesen der gespeicherten Daten, sowie eine Schnittstelle zum Zurückspielen bearbeiteter Daten verfügen. Die Export-Konfiguration muss folgende Einstellungen erlauben: | ||||||
| · Export von Daten im Zeitraum von/bis | ||||||
| · Export der Daten zu einer bestimmten Beteiligung oder zu allen Beteiligungen | ||||||
| Der Export muss im JSON, XML oder CSV-Format erfolgen. | ||||||
| Die folgenden Zielgruppen sollen vorwiegend erreicht werden: | ||||||
| 1. Interessierte (Fach-)Öffentlichkeit: Einzelpersonen, wissenschaftliche Einrichtungen und organisierte Interessenvertretungen (z. B. Vereine i. S. d. §§ 21 ff. BGB oder Bürgerinitiativen), Beteiligte an den Regionalkonferenzen, die entsprechenden Geschäftsstellen in den Regionen unterhalten, der Rat der Regionen und Gebietskörperschaften usw. | ||||||
| 2. Menschen, die von den Beteiligungsgegenständen zur Endlagersuche direkt oder indirekt betroffen sind. | ||||||
| 3. Mitarbeitende des BASE als Initiator:innen, Redakteur:innen oder Moderator:innen von Beteiligungsprozessen: Das Kernteam und Mitarbeitende aus weiteren Abteilungen des BASE sowie externe Dienstleister:innen | ||||||
| 4. Administrator:innen des BASE, die mit dem System befasst sind. | ||||||
| Die Leistung umfasst die folgenden Bestandteile: | ||||||
| 1) Bereitstellung und Herbeiführung der Betriebsbereitschaft eines produktiven Systems | ||||||
| 2) Betrieb und Pflege des dem BASE verfügbar gemachten Systems sowie weitere damit verbundene Serviceleistungen, sowie Leistungen zum Vertragsende. | ||||||
| 3 Rahmenbedingungen | ||||||
| 3.1 Ort und Zeit der Leistungserbringung | ||||||
| Die Leistungserbringung erfolgt vorwiegend bei der/dem Auftragnehmer:in (AN) und bei möglichen Unterauftragnehmer:innen. Aufgaben können auch unter Einhaltung der datenschutzrechtlichen Verpflichtungen remote ausgeführt werden. Tätigkeiten beim BASE in Präsenz stimmt das BASE mit der AN mit einer Vorlaufzeit von mind. zwei Wochen ab. Das betrifft insbesondere Schulungen, soweit diese in Präsenz in Berlin vor Ort beim BASE oder ab 2028 in den vorgeschlagenen Standortregionen angeboten werden. | ||||||
| 3.2 Mengengerüst | ||||||
| Das folgende Mengengerüst zeigt die zu erwartenden Beteiligungsverfahren und Nutzer:innenzahlen auf der Plattform. Angesichts der langfristigen Dauer der Endlagersuche und der sich wandelnden Anforderungen sowie technischen Möglichkeiten werden zunächst nur die kommenden Jahre betrachtet. Mit fortschreitendem Prozess ist von einer abnehmenden Zahl beteiligter Personen, jedoch einer zunehmenden Beteiligungsintensität und komplexeren Verfahren auszugehen. Es obliegt der/dem Auftragnehmer:in diese Vorgaben im Rahmen seines Angebots bereits zu berücksichtigen und sicherzustellen, dass die angebotene Plattform diese Anforderungen (auch zukünftig) erfüllen kann. Ab dem 1. Quartal 2027 sollen erste digitale Beteiligungen zu Arbeitsergebnissen des BASE in Form von Textkommentierung und Feedback stattfinden. Die Beteiligung ist bundeweit und jede interessierte Person kann teilnehmen. Da es sich zunächst um fachliches Feedback z. B. zur Mustergeschäftsordnung der Regionalkonferenzen handelt und keine persönliche Betroffenheit besteht, ist mit 500 – 1.000 aktiven Teilnehmer:innen zu rechnen. Im Laufe der Jahre nach 2028 soll die Plattform grundsätzlich dem BASE für deutschlandweite Beteiligungsverfahren zur Verfügung stehen. Hierbei sind nach aktuellem Stand nur wenige Verfahren geplant, die sich im Wesentlichen auf die Funktionalitäten von Textkommentierung wie den Down und Upload von Dokumenten beschränken. Ggf. unterstützt durch ein Voting zum Rating der Textvorschläge. Die Plattform ist technisch so ausgelegt, dass sie bei Bedarf auch von weiteren Beteiligten im Verfahren genutzt werden kann. Auf Anfrage können diesen Nutzenden eigene Bereiche auf der Plattform eingerichtet werden, in denen sie eigenverantwortlich Beteiligungsformate durchführen. Da Umfang und Reichweite der Beteiligung im Verlauf des Verfahrens variieren können, muss die Plattform flexibel skalierbar sein. Je nach Verfahrensstand und regionalem Kontext ist mit sehr unterschiedlichen Nutzungsintensitäten zu rechnen: | ||||||
| Minimal-Szenario: In einem Szenario geringer Nutzung ist von etwa 10 bis 20 Beteiligungsverfahren pro Jahr auszugehen, mit insgesamt bis zu 1.000 aktiven Nutzer:innen auf der Plattform und maximal 100 gleichzeitigen Zugriffen. Maximal-Szenario: In einem Szenario intensiver Nutzung können über 100 Beteiligungsverfahren pro Jahr anfallen. Einzelne Nutzungsbereiche können dabei bis zu 10.000 aktive Nutzer:innen umfassen. Im Zeitverlauf ist mit einer sich verändernden Gesamtnutzung zu rechnen: Während die Anzahl aktiver Nutzungsbereiche abnehmen kann, ist in verbleibenden Bereichen mit einer Intensivierung der Nutzung zu rechnen. Zum Beispiel, wenn die Plattform für komplexere Beteiligungsprozesse eingesetzt wird. Insgesamt ist auch dann noch mit mehreren Tausend aktiven Nutzer:innen zu rechnen. | ||||||
| Sofern weitere Nutzende die Plattform einsetzen, benennen diese jeweils eine verantwortliche Ansprechperson, die die Hauptverantwortung für die in ihrem Bereich durchgeführten Beteiligungsverfahren trägt. Die im BASE verantwortliche Person steht als übergeordnete Ansprechpartner:in zur Verfügung. Die AN hat gegenüber diesen Ansprechpersonen dieselben Verpflichtungen wie gegenüber dem BASE als hauptverantwortlicher Stelle. Im Zuge eines bundesweiten Stellungnahmeverfahrens, das erst zu einem späteren Zeitpunkt durchgeführt wird und voraussichtlich erst ab 2029 erfolgt, muss die Plattform in der Lage sein, die Stellungnahmen einzusammeln und mittels der im Kapitel 7.2.5 Schnittstellen beschriebenen Anforderung weiterzuleiten. Voraussichtlich ab 2031 erfolgt darüber hinaus ein Beteiligungsverfahren im Zuge der Strategischen Umweltprüfung. Die Schnittstellen sollen frühzeitig etabliert werden, damit dies vor Start der Verfahren getestet werden können. Der Zeitplan bezüglich des Stellungnahmeverfahrens und der Beteiligung zur Strategischen Umweltprüfung beruht auf groben Schätzungen. Die Nutzung der Plattform ist für die gesamte Dauer der Phase 1 der Endlagersuche geplant. | ||||||
| Hier eine Tabellarische Übersicht: | ||||||
| Jahr | Ereignis / Nutzung | Beteiligungsverfahren | Beteiligte Personen (ca.) | |||
| in ca. Angaben | ||||||
| 2027 | Konsultation „Mustergeschäftsordnung“ | 1 Verfahren | Voraussichtlich | |||
| 500 – 1.000 aktive Nutzer:innen | ||||||
| 2028 ff. | Plattform erhält ggf. Unterseiten | Minimal-Szenario: | Minimal-Szenario: | |||
| 10–20 Verfahren/ Jahr | bis zu 1.000 Nutzer:innen gesamt/Jahr | |||||
| Maximal-Szenario: | Maximal-Szenario: | |||||
| >100 Verfahren/ Jahr | mehrere Tausend bis max. 100.000 Nutzer:innen gesamt/Jahr | |||||
| geplant ab 2029 | Stellungnahmeverfahren | 1 bundesweites Stellungnahmeverfahren | Da es sich um ein bundesweites Verfahren handelt, ist eine genaue Einschätzung der Beteiligtenzahlen nicht möglich. Die Plattform muss daher eine flexible Skalierung ermöglichen. | |||
| geplant ab 2031 | Strategische Umweltprüfung / Beteiligung | 1 Verfahren | Zum gegenwärtigen Zeitpunkt nicht einschätzbar | |||
| 3.3 Regelungen zur Zusammenarbeit von AG und AN | ||||||
| 1 | Der oder die Projektleiter:in des/der Auftragnehmer:in (AN) muss dem BASE im Rahmen des Projektes als „Single Point of Contact“ und fachliche:r Ansprechpartner:in zur Verfügung stehen. Für eine adäquate Stellvertretung ist Sorge getragen. | A | ||||
| 2 | Das BASE unterrichtet die AN über Ereignisse, die Einfluss auf die Aufgabenerfüllung der AN haben. | A | ||||
| 3 | Das BASE stellt, falls nötig, Kontakte zwischen der AN und fachspezifischen Ansprechpartner:innen her. | A | ||||
| 4 | Die AN erfragt rechtzeitig, mit mindestens zwei Wochen Vorlauf während der Projektlaufzeit und in regelmäßigen Abständen notwendige projektbezogene Informationen beim BASE. Für technische Incidents ist eine Notfallplanung mit Informations- und Entscheidungskaskaden vorab festzulegen. | A | ||||
| 5 | ||||||
| 4 Allgemeine Anforderungen an die AN, die Leistung und die Vertragsausführung. | ||||||
| 4.1 Projektphasen | ||||||
| Nach Bereitstellung der Ergebnisse jeder der nachfolgend beschriebenen Phasen prüft die AG die Ergebnisse auf inhaltliche Korrektheit und Vollständigkeit. Ist das Ergebnis der Prüfung positiv, erfolgt die Teilabnahme und damit die Freigabe für die Folgephase. Die in der Prüfung festgestellten Mängel müssen behoben und die Mängelbehebung durch eine erneute Prüfung seitens der AG festgestellt werden. Die Gesamtabnahme erfolgt in Phase 3. | ||||||
| 4.1.1 Phase1: Bereitstellung | ||||||
| 5 | In Phase 1 stellt die AN die Software für das BASE bereit und richtet die notwendigen Zugriffe für das BASE ein und stellt dem BASE alle notwendigen Dokumentationen für die Nutzung der Software zur Verfügung. Im Angebot beschreibt die AN auch, welche Dokumentationen und Handreichungen zur Verfügung gestellt wird (vgl. 4.5 Dokumentation / Handbücher). | A | ||||
| 4.1.2 Phase2: Konfiguration | ||||||
| 6 | In der Phase 2 erfolgt die Konfiguration und Einrichtung der Software an die nachfolgend beschriebenen Anforderungen des BASE. In dieser Phase werden auch alle für den Betrieb notwendigen Schnittstellenanbindungen an die BASE Anwendungslandschaft, sowie alle, aus Sicht der AN notwendigen, initialen Datenbestände eingerichtet. | A | ||||
| Sicherstellung der vollständigen Nutzbarkeit aus der BASE-IT-Infrastruktur heraus: | ||||||
| · Gewährleistung der Kompatibilität und Interoperabilität mit bestehenden Arbeitsplatzrechnern und Anwendungen. | ||||||
| Sicherheits- und Compliance-Maßnahmen: | ||||||
| · Implementierung von Sicherheitsprotokollen und -mechanismen, um die Integrität und Vertraulichkeit der archivierten Daten zu gewährleisten. | ||||||
| · Sicherstellung der Einhaltung aller relevanten gesetzlichen und regulatorischen Anforderungen. | ||||||
| 4.1.3 Phase3: Herbeiführung der Betriebsbereitschaft und Gesamtabnahme | ||||||
| 7 | Alle notwendigen Schulungen sind durchgeführt. | A | ||||
| Alle betriebs-behindernden oder -verhindernden Abweichungen aus dem Abnahmetest sind behoben. | ||||||
| Wartung und Updates: | ||||||
| · Regelmäßige Wartung des Systems, einschließlich der Installation von Software-Updates und Patches. | ||||||
| · Durchführung von Performance-Optimierungen und Systemüberprüfungen. | ||||||
| 4.2 Nachhaltigkeit | ||||||
| 8 | Die Rechenzentren, in denen die Plattform betrieben wird, sollen über ein Energiemanagementsystem verfügen, das an DIN EN 50600-3-1, DIN EN ISO 50001 oder an EMAS III angelehnt ist. | B | Die Rechenzentren, in denen die Plattform betrieben wird, verfügen nicht über ein Energiemanagementsystem, das an DIN EN 50600-3-1, DIN EN ISO 50001 oder an EMAS III angelehnt ist. | Die Rechenzentren, in denen die Plattform betrieben wird, verfügen über ein Energiemanagementsystem, das an DIN EN 50600-3-1, DIN EN ISO 50001 oder an EMAS III angelehnt ist. | ||
| 9 | Die Rechenzentren, in denen die Plattform betrieben wird, sollen ihren Strombedarf mindestens zu 50% und idealerweise zu 100% aus erneuerbaren Energien wie Wasserkraft, Photovoltaik, Windkraft oder Biomasse decken. | B | Die Rechenzentren, in denen die Plattform betrieben wird, decken weniger als 50% ihres Strombedarfs aus erneuerbaren Energien wie Wasserkraft, Photovoltaik, Windkraft oder Biomasse decken. | Die Rechenzentren, in denen die Plattform betrieben wird, decken mindestens 50% ihres Strombedarfs aus erneuerbaren Energien wie Wasserkraft, Photovoltaik, Windkraft oder Biomasse decken. | Die Rechenzentren, in denen die Plattform betrieben wird, decken 100% ihres Strombedarfs aus erneuerbaren Energien wie Wasserkraft, Photovoltaik, Windkraft oder Biomasse decken. | |
| Die Nachhaltigkeit kann auch durch die ZU 228 oder UZ161 & UZ214 nachgewiesen werden. | ||||||
| 10 | Die Rechenzentren, in denen die Plattform betrieben wird, sollen eine nach DIN EN 50600-4-2 bestimmte Power Usage Effectiveness (PUE2, Kategorie 2, mittlere Auflösung oder gleichwertig) von höchstens 1,25 im Jahresdurchschnitt haben. | B | Die Rechenzentren, in denen die Plattform betrieben wird, haben keine nach DIN EN 50600-4-2 bestimmte Power Usage Effectiveness (PUE2, Kategorie 2, mittlere Auflösung oder gleichwertig) von höchstens 1,25 im Jahresdurchschnitt. | Die Rechenzentren, in denen die Plattform betrieben wird, haben eine nach DIN EN 50600-4-2 bestimmte Power Usage Effectiveness (PUE2, Kategorie 2, mittlere Auflösung oder gleichwertig) von höchstens 1,25 im Jahresdurchschnitt. | ||
| 11 | Die Rechenzentren, in denen die Plattform betrieben wird, sollen eine nach DIN EN 50600-4-7 bestimmte Cooling Efficiency Ratio (CER) von mindestens 9 haben. | B | Die Rechenzentren, in denen die Plattform betrieben wird, haben keine nach DIN EN 50600-4-7 bestimmte Cooling Efficiency Ratio (CER) von unter 7 haben. | Die Rechenzentren, in denen die Plattform betrieben wird, haben eine nach DIN EN 50600-4-7 bestimmte Cooling Efficiency Ratio (CER) von mindestens 9. | ||
| 12 | Die Rechenzentren, in denen die Plattform betrieben wird, sollen in Kälteanlagen, Wärmepumpen und Entfeuchtern nur halogenfreie Kältemittel verwenden. | B | Die Rechenzentren, in denen die Plattform betrieben wird, verwenden in Kälteanlagen, Wärmepumpen und Entfeuchtern noch Kältemittel mit Halogen. | Die Rechenzentren, in denen die Plattform betrieben wird, verwenden in Kälteanlagen, Wärmepumpen und Entfeuchtern nur halogenfreie Kältemittel. | ||
| 13 | Die Rechenzentren, in denen die Plattform betrieben wird, sollen in elektrischen Schaltanlagen kein Schwefelhexafluorid enthalten. Bei vorhandenen Schaltanlagen mit Schwefelhexafluorid soll eine Erläuterung abgegeben werden, wann ein Wechsel zu Schwefelhexafluorid-freien Schaltanlagen geplant ist. | B | Die Rechenzentren, in denen die Plattform betrieben wird, enthalten in ihren elektrischen Schaltanlagen noch Schwefelhexafluorid. | Die Rechenzentren, in denen die Plattform betrieben wird, enthalten in ihren elektrischen Schaltanlagen kein Schwefelhexafluorid. | ||
| 14 | Der/die Auftragnehmer:in soll den Auftraggeber auf Basis von Angaben zum tatsächlichen Energieverbrauch der Plattform über Möglichkeiten der Energieeinsparung informieren und bei deren Umsetzung unterstützen | B | Die Auftragnehmer:in informiert den Auftraggeber nicht über Einsparpotenziale im Rahmen des Energieverbrauchs. Es gibt keine Maßnahmen zur Energieeinsparung. | Die Auftragnehmer:in informiert den Auftraggeber umfassend auf Basis der tatsächlichen Energieverbrauchsdaten über sämtliche relevanten Einsparpotenziale und unterstützt ihn aktiv bei der Umsetzung aller empfohlenen Maßnahmen. | ||
| 15 | Der Quellcode der Kern-Plattform-Software soll öffentlich zugänglich und unter einer Lizenz entsprechend der Definition der Open Source Initiative nutzbar sein. | B | Der Quellcode der Kern-Plattform-Software ist nicht öffentlich zugänglich. | Der Quellcode der Kern-Plattform-Software ist öffentlich zugänglich und unter einer Lizenz entsprechend der Definition der Open Source Initiative nutzbar. | ||
| 4.3 Projektsprache | ||||||
| 16 | Die Projektsprache ist Deutsch. Die Kommunikation im Rahmen der Vertragserfüllung muss ausschließlich in deutscher Sprache erfolgen. Die von der AN bereitgestellten Dokumente sind sämtlich in deutscher Sprache zu verfassen. Englische Fachbegriffe sind hiervon ausgenommen. | A | ||||
| 17 | Die durch die AN angebotenen Supportleistungen für Nutzer:innen durch z. B. die telefonische Hotline soll zusätzlich auch in Englisch erfolgen. | B | Keine durch die AN angebotenen Supportleistungen für Nutzer:innen sind auch in Englisch vorhanden | Die durch die AN angebotenen textbasierten Supportleistungen für Nutzer:innen sind auch auf Englisch verfügbar. | Alle durch die AN angebotenen Supportleistungen für Nutzer:innen sind auch in Englisch vorhanden. | |
| 4.4 Konzepte | ||||||
| Alle hier beschriebenen Konzepte sind in einer Entwurfsfassung vom AG freizugeben. Erst nach Freigabe durch den AG erfolgt die Erstellung des finalen Konzeptes durch den AN. Die finalen Entwürfe werden vom AN der AG zur Abnahme zur Verfügung gestellt. Im Zuge der Abnahme festgestellte Mängel werden, nach Behebung durch den AN, einer erneuten Prüfung durch den AG unterzogen. Sobald die Mängelbehebung durch den AG in Textform festgestellt wurde, gelten die Konzepte als abgenommen. | ||||||
| 4.4.1 Sicherheitskonzept | ||||||
| 18 | Die AN muss bis spätestens sechs Monate nach Betriebsbereitschaft ein Sicherheitskonzept erstellen und mit dem BASE abstimmen (vgl. Ziffer 6.2.1 EVB-IT Cloud-AGB). Das Sicherheitskonzept soll | A | ||||
| · Sicherheitsrichtlinien | ||||||
| · Zugriffsmanagement | ||||||
| · Datensicherheitsmaßnahmen | ||||||
| · Netzwerksicherheit | ||||||
| · Schwachstellenmanagement | ||||||
| · Notfallmanagement | ||||||
| · Schulung und Sensibilisierung sowie | ||||||
| · Compliance und Audits | ||||||
| · das Erkennen von Sicherheitslücken und Angriffen durch den AN | ||||||
| umfassen. | ||||||
| 4.4.2 Betriebskonzept | ||||||
| 19 | Die AN muss sämtliche für das BASE relevante Maßnahmen zum Betrieb der Software in einem Betriebskonzept dokumentieren und dort nachhaltig entsprechend neuesten Erkenntnissen während der gesamten Projektlaufzeit fortschreiben. Das Betriebskonzept umfasst folgende Themen: | A | ||||
| · Verantwortlichkeiten | ||||||
| · Monitoring und Logging | ||||||
| · Sicherstellung der vereinbarten Service-Level | ||||||
| · Umsetzung des Kapazitäts- und Performance-Managements | ||||||
| · Vorgehen und Maßnahmen zur Fehlerbehebung | ||||||
| · Umsetzung des Issue-Managements | ||||||
| · Wartung und Pflege | ||||||
| · Darstellung des Change- und Releasemanagements | ||||||
| · Darstellung des Support Managements | ||||||
| 20 | Die AN muss dem BASE spätestens drei Monate nach der Betriebsbereitschaft ein Betriebskonzept mit den oben beschriebenen Inhalten liefern. | A | ||||
| 21 | Die AN und mögliche Unterauftragnehmer:innen müssen sich verpflichten, das Betriebskonzept umzusetzen. | A | ||||
| 4.4.3 Einführungskonzept | ||||||
| 22 | Die AN muss mit Abgabe des Angebots ein maximal fünf Seiten umfassendes Einführungskonzept vorlegen (Schriftart Arial, Schriftgröße 10, einfacher Zeilenabstand). Das Konzept muss folgende Punkte adressieren: | A | ||||
| 1. Einsatz von KI: Das Konzept soll darlegen, wie der Einsatz von KI-gestützten Funktionen zur Unterstützung der Durchführung und Auswertung von digitalen Beteiligungsverfahren beiträgt. Es wird erwartet, dass die AN konkret aufzeigt, wie bestehende oder geplante KI-Anwendungen einen klar nachvollziehbaren Mehrwert für die Effizienz und Qualität des Beteiligungsprozesses bieten können. | ||||||
| 2. Passgenauigkeit zum Endlagersuchprozess: Es muss aufgezeigt werden, wie das BTMS die spezifischen Anforderungen, Rahmenbedingungen und Herausforderungen des BASE in den ersten Phasen des Standortauswahlprozesses integriert. Dazu gehört auch eine präzise Darstellung, wie die im Mengengerüst definierten Anforderungen durch die Plattform abgebildet werden können. Zudem wird erwartet, dass die AN die Rolle der Regionalkonferenzen, die Besonderheiten bundesweiter Beteiligungsprozesse sowie die Anforderungen an Datenschutz und IT-Sicherheit berücksichtigt. | ||||||
| 4.4.4 Rollen- und Rechtekonzept | ||||||
| 23 | Die Anwendung muss über ein Rechte- & Rollenkonzept verfügen. Dies ist bei der Angebotsabgabe einreichen. Das Rechte- & Rollenkonzept muss mindestens die folgenden Aspekte umfassen: | A | ||||
| · Es werden alle für die Plattform beschriebenen geforderten Rollen behandelt (vgl. Abschnitt 5.1.3). | ||||||
| · Es wird ersichtlich, welche Rollen die AN, das BASE oder beide grundsätzlich übernehmen können. Die AN spricht eine Empfehlung für die Rollenbesetzung aus. | ||||||
| · Die Zugriffsrechte, d. h. lesen, schreiben, löschen von Daten, sind für jede Rolle definiert. | ||||||
| · Die Verwaltung der Rollen und Rechte der einzelnen Nutzer:innen wird beschrieben. Es wird deutlich, wer unter welchen Umständen Rollen und Rechte verändern kann. | ||||||
| 4.4.5 Datenschutzkonzept | ||||||
| 24 | Der AN hat mit Abgabe seines Angebots ein Datenschutzkonzept für die Beteiligungsplattform vorzulegen, das die datenschutzrechtliche Ausgestaltung der Plattform vollständig und transparent beschreibt. Das Datenschutzkonzept dient dem Nachweis der Zulässigkeit, Erforderlichkeit und Verhältnismäßigkeit sämtlicher durch die Plattform durchgeführter Datenverarbeitungen. Das Datenschutzkonzept des AN hat insbesondere folgende Punkte zu enthalten: | A | ||||
| •\tGeografische Darstellung sämtlicher mit den Betriebsmitteln genutzten und erzeugten personenbezogenen Daten die aufzeigt, welche personenbezogenen Daten wo erhoben, verarbeitet, gespeichert und gelöscht werden – einschließlich aller Systemkomponenten (Frontend, Backend, Datenbank, CDN, Mail-Server). | ||||||
| •\tTechnische Beschreibung der logischen und physischen Trennung der Daten verschiedener Mandanten der Plattform (Mandantenkonzept). | ||||||
| •\tDarstellung der Maßnahmen zur Sicherstellung des datenschutzkonformen Einsatzes von Analyse- und Tracking-Werkzeugen auf der Plattform. Drittanbieter-Tools dürfen nur eingesetzt werden, wenn diese eine Datenverarbeitung und -speicherung in der EU/dem EWR sicherstellen. | ||||||
| •\tLöschkonzept für personenbezogene Daten, das Löschfristen und auslösende Ereignisse pro Datenkategorie definiert. | ||||||
| •\tDarstellung der technischen Umsetzung der Löschung (z. B. TTL-Mechanismen, automatisierte Löschjobs, administrative Routinen). | ||||||
| •\tTechnische und datenschutzrechtliche Beschreibung des Einsatzes von KI-Funktionen auf der Plattform. | ||||||
| Das Datenschutzkonzept hat die Einhaltung der DSGVO, des BDSG sowie ggf. einschlägiger landesrechtlicher Datenschutzvorschriften (insbesondere BlnDSG) über die gesamte Vertragslaufzeit nachzuweisen. Das Datenschutzkonzept muss den datenschutzrechtlichen Gewährleistungszielen, bspw. des Standard-Datenschutzmodells (SDM), entsprechen: Datenminimierung, Vertraulichkeit, Integrität (einschließlich Datenintegrität und Richtigkeit), Verfügbarkeit, Transparenz, Nichtverkettung und Intervenierbarkeit. Das Datenschutzkonzept ist als übergeordnetes Steuerungsdokument anzulegen, das systematisch auf mitgeltende Detailnachweise (z. B. Fachkonzepte, TOM-Nachweise, Risikoanalysen, AV-Verträge) verweist und diese in strukturierten Anlagenregistern führt. Das Datenschutzkonzept ist über die gesamte Vertragslaufzeit fortzuschreiben und bei Änderungen der Plattform, der einschlägigen Rechtsgrundlagen oder der Verarbeitungstätigkeiten unverzüglich anzupassen. | ||||||
| 25 | Das Datenschutzkonzept hat die Einhaltung der DSGVO, des BDSG sowie ggf. einschlägiger landesrechtlicher Datenschutzvorschriften (insbesondere BlnDSG) über die gesamte Vertragslaufzeit nachzuweisen. | A | ||||
| 26 | Das Datenschutzkonzept muss den datenschutzrechtlichen Gewährleistungszielen, bspw. des Standard-Datenschutzmodells (SDM), entsprechen: Datenminimierung, Vertraulichkeit, Integrität (einschließlich Datenintegrität und Richtigkeit), Verfügbarkeit, Transparenz, Nichtverkettung und Intervenierbarkeit. | A | ||||
| 27 | Das Datenschutzkonzept ist als übergeordnetes Steuerungsdokument anzulegen, das systematisch auf mitgeltende Detailnachweise (z. B. Fachkonzepte, TOM-Nachweise, Risikoanalysen, AV-Verträge) verweist und diese in strukturierten Anlagenregistern führt. | A | ||||
| 28 | Das Datenschutzkonzept ist über die gesamte Vertragslaufzeit fortzuschreiben und bei Änderungen der Plattform, der einschlägigen Rechtsgrundlagen oder der Verarbeitungstätigkeiten unverzüglich anzupassen. | A | ||||
| 29 | Die Plattform muss die technische Möglichkeit bieten, verpflichtende Einwilligungserklärungen per Checkbox anzubieten. Es muss möglich sein, nachträglich weitere Checkboxen auf Anforderung des AG zu implementieren. | A | ||||
| 30 | Die Plattform muss ein vollständiges Einwilligungsmanagement bereitstellen, das insbesondere Datum und Uhrzeit der Einwilligungserklärung, die konkrete Zuordnung zum Teilnehmer sowie die Steuerung und Dokumentation widerrufener Einwilligungserklärungen umfasst, damit der AG seiner Rechenschaftspflicht nach Art. 5 DSGVO nachkommen kann. | A | ||||
| 4.5 Dokumentation / Handbücher | ||||||
| 31 | Die AN muss sicherstellen, dass alle Dokumentationen in deutscher Sprache vorliegen. Englische Fachbegriffe sind davon ausgenommen. Sind die englischen Fachbegriffe nicht allgemein gebräuchlich, so müssen diese in Form eines Glossars oder vergleichbar in deutscher Übersetzung oder entsprechender Erläuterung angegeben werden. | A | ||||
| 32 | Die AN muss sicherstellen, dass alle Funktionalitäten der Plattform in Form eines Benutzer:innenhandbuchs dokumentiert sind. Das Benutzer:innenhandbuch muss der AG bzw. den Nutzer:innen vollständig und nachvollziehbar die Funktionalitäten der Plattform beschreiben. Das Benutzer:innenhandbuch muss die Funktionen und Rechte für alle definierten Rollen. | A | ||||
| 33 | Die AN soll den für externe Nutzer:innen zugänglichen Hilfebereich bzw. das Wiki, PDF oder vergleichbares zur Erklärung der Nutzer:innenfunktionen laufend aktuell halten. | B | Es gibt keinen für externe Nutzer:innen zugänglichen Hilfebereich bzw. Wiki, PDF oder eine vergleichbare Erklärung der Nutzer:innenfunktionen. | Die AN hält den für externe Nutzer:innen zugänglichen Hilfebereich bzw. das Wiki, PDF oder vergleichbares zur Erklärung der Nutzer:innenfunktionen laufend aktuell. | ||
| 34 | Die AN muss sicherstellen, dass ein Administrator:innenhandbuch zur Verfügung gestellt wird, das dem/der Fachliche:r Administrator:in des BASE alle Konfigurationsmöglichkeiten, bzw. jene Konfigurationsmöglichkeiten, die durch das BASE vorgenommen werden können, darlegt. | A | ||||
| 4.6 Zertifizierungen und Testierungen | ||||||
| 35 | Die AN muss eine Zertifizierung nach ISO 27001 (Informationssicherheits-Managementsystem (ISMS)) für den Teil des Betriebs der Plattform, der für die Nutzung durch die Anwender:innen eingesetzt wird, über die gesamte Vertragsdauer gewährleisten und dem BASE bei Angebotsabgabe nachweisen. | A | ||||
| 36 | Die Rechenzentren, in denen die Plattform betrieben wird, sollen über die gesamte Vertragsdauer eine Zertifizierung nach ISO 27018 (Datenschutz in der Cloud) gewährleisten. | B | Die Rechenzentren verfügen über keine Zertifizierung nach ISO 27018 (Datenschutz in der Cloud). | Die Rechenzentren befinden sich im Prüfprozess für die Zertifizierung nach ISO 27018 (Datenschutz in der Cloud). | Die Rechenzentren können über die gesamte Vertragsdauer eine Zertifizierung nach ISO 27018 (Datenschutz in der Cloud) gewährleisten. | |
| 37 | Die Rechenzentren, in denen die Plattform betrieben wird, müssen über die gesamte Vertragsdauer eine Testierung nach BSI C5 (Cloudsicherheit-Katalog der BSI) gewährleisten. | A | ||||
| 38 | Die AN verpflichtet sich zur Einhaltung der Datenschutz-Grundverordnung (DSGVO) über die gesamte Vertragsdauer. Insbesondere ist eine Vereinbarung zur Auftragsdatenverarbeitung nach Art. 28 der DSGVO zwischen dem BASE und der AN zu schließen. Ein Muster der Vereinbarung wird vom BASE initial zur Verfügung gestellt, der AN ergänzt die technisch organisatorischen Maßnahmen. Die Vereinbarung wird vom BASE geprüft und nach Prüfung gezeichnet. Für weitere, vom BASE benannte Stellen, die über eigene Mandanten (vgl. 8.2.) die Plattform nutzen, erklärt sich der AN bereit, die erforderlichen datenschutzrechtlichen Vereinbarungen (bspw. Auftrags- verarbeitungsvereinbarung nach Art. 28 DSGVO) bei Bedarf im Rahmen der Vertragsausführung abzuschließen. | A | ||||
| 5 Anforderungen an die Plattform | ||||||
| 5.1 Nicht-funktionale Anforderungen | ||||||
| 5.1.1 Datenschutz | ||||||
| 39 | Die AN und mögliche Unterauftragnehmer:innen müssen jederzeit für die Plattform die Vorgaben der Datenschutz-Grundverordnung (DSGVO) und der weiteren relevanten Gesetzgebung zum Datenschutz einhalten. Zudem hat die AN die von dem BASE für das Impressum, die Nutzungsbedingungen und die Datenschutzerklärung zur Verfügung gestellten Texte zu verwenden. | A | ||||
| 40 | Die AN darf die Datenhaltung und -verarbeitung, ebenso im Falle von Fernzugriffen, zum Beispiel in Zuge von Support- und Wartungsmaßnahmen, nur innerhalb der EU oder EWR vornehmen (vgl. EVB-IT-Cloud-AGB und § 8 der AVV). | A | ||||
| 41 | Bei der Registrierung von Beteiligten in der Plattform ist eine Datenschutz-Erklärung für die Verarbeitung personenbezogener Daten im BTMS, wie auch für die Weiterverarbeitung mit dem Einwendungsmanagementsystem (EWMS) oder anderen IT-Systemen des BASE einzuholen. | A | ||||
| 5.1.2 Barrierefreiheit | ||||||
| 42 | Die Plattform inklusive des Hilfesystems und der Benutzerhandbücher muss grundsätzlich die Vorgaben der BITV 2.0, d. h. alle WCAG 2.1 Level A und Level AA (und ggf. Level AAA) Anforderungen, erfüllen. | A | ||||
| Hinweis: | ||||||
| Die Notwendigkeit der Barrierefreiheit wird im §12a BGG in Verbindung mit der BITV 2.0 festgelegt. Es erfolgt ein Verweis auf die harmonisierte EU-Norm EN 301 549, die wiederum für die Erfüllung der Anforderungen auf die WCAG 2.1 verweist. Die Anforderungen sind in der WCAG 2.1 definiert. Diese gliedern sich in folgende Kategorien: | ||||||
| · Wahrnehmbarkeit | ||||||
| · Bedienbarkeit | ||||||
| · Verständlichkeit | ||||||
| · Robustheit | ||||||
| Die Klassifizierung der Anforderungen erfolgt dabei in 3 Konformitätsstufen: | ||||||
| · A: Mindestanforderungen | ||||||
| · AA: gute Zugänglichkeit | ||||||
| · AAA: Maximalanforderungen | ||||||
| Die definierten Mindestanforderungen (A) und die Anforderungen für gute Zugänglichkeit (AA) sind umzusetzen. | ||||||
| 43 | Die AN muss innerhalb von 12 Monaten an der Plattform (Basisversion) den BIK BITV-Test erfolgreich durchführen. Die AN übernimmt alle damit in Zusammenhang stehenden Kosten. | A | ||||
| Hinweis: | ||||||
| Im Rahmen des Tests erfolgt die Prüfung der Barrierefreiheit von Webangeboten und Anwendungen. Der Test ist hinsichtlich einer Webanwendung erfolgreich durchgeführt, wenn der Test alle Anforderungen für alle geprüften Seiten als "erfüllt" bewertet. Die Umsetzung wird der AN vom BASE beispielhaft aufgezeigt. | ||||||
| 44 | Die AN muss im Rahmen der Leistungserbringung alle Leistungsbestandteile stets entsprechend der BITV 2.0 erbringen und ggf. nachbessern, bis eine endgültige Abnahme durch das BASE erfolgt. Auch nach der Abnahme muss die AN die Barrierefreiheit entsprechend BITV 2.0 stets gewährleisten. | A | ||||
| 5.1.3 Rollen- und Rechtemanagement | ||||||
| Es ist von der AN ein Rollen- und Rechtemanagement verfügbar zu machen, das folgenden Anforderungen entsprechen muss: | ||||||
| 45 | Die Plattform muss es ermöglichen, verschiedene Rollen im System anzulegen und zu verwalten. Darüber hinaus müssen den Rollen über das Rechtemanagement verschiedene Rechte zugewiesen werden können. Folgende Rollen müssen mind. im System verwaltet werden können: | A | ||||
| · Technische:r Administrator:in: Die Rolle der technischen Administrator:in wird von der AN ausgefüllt. Die Technische Administrator:in hat vollständige Zugriffsrechte auf das technische System und kann technische Änderungen im Backend vornehmen. Die technische Administrator:in überwacht, prüft und pflegt das technische System und trägt Sorge dafür, dass alle in dieser Leistungsbeschreibung gestellten Anforderungen an das technische System (z. B. Datenschutz, Performance, Wartung, Systemservice) stets eingehalten werden. Die technische Administrator:in hat vollumfänglichen Zugriff auf das Rollenmanagement und kann die Rolle der fachlichen Administrator:in vergeben. | ||||||
| · Fachliche:r Administrator:in: Kann auf Daten im Backend zugreifen und bspw. Rollen vergeben. Fachliche Administrator:innen haben Zugriff auf alle Funktionen im Informationsbereich und Beteiligungsbereich. | ||||||
| · Initiator:in: Kann Beteiligungsprojekte im Beteiligungsbereich der Plattform initiieren, bearbeiten, löschen und ggf. archivieren. | ||||||
| · Redakteur:in: Kann im Informationsbereich der Plattform Inhalte einstellen, bearbeiten, veröffentlichen und löschen. | ||||||
| · Moderator:in: Verfügt über Rechte der Moderation in zugewiesenen Beteiligungsprojekten und ist als Moderator:in in diesen Projekten kenntlich gemacht. | ||||||
| · Angemeldete:r Nutzer:in: Kann sich bei öffentlichen Beteiligungsprojekten auf der Plattform einbringen. | ||||||
| · Nicht-angemeldete Nutzer:in: Nicht registrierte Personen, die alle öffentlichen Inhalte einsehen können. | ||||||
| Die AN hat sicherzustellen, dass die Rolle der technischen Administrator:in kontinuierlich über den gesamten Vertragszeitraum erfüllt wird. | ||||||
| Alle im angebotenen System der AN bereitgestellten Rollen werden von der AN in einem Rollenkonzept (vgl. 4.4.3) beschrieben. | ||||||
| 5.1.4 Open Source Software | ||||||
| Damit das BASE ein hohes Maß an Transparenz, Sicherheit und Nachnutzbarkeit im Sinne der Digitalen Souveränität[1] sicherstellen kann, ist eine Plattform auf Open-Source-Basis die bevorzugte Lösung: | ||||||
| 46 | Die Plattform und ihre Komponenten sollten vollständig als Open Source Software[2] (OSS) entwickelt sein und unter einer freien Lizenz veröffentlicht werden (z. B. European Union Public Licence). | B | Die Plattform und ihre Komponenten wurden nicht als Open Source Software entwickelt und sind nicht unter einer freien Lizenz veröffentlicht (z. B. European Union Public Licence). | Die Plattform und ihre Komponenten wurden vollständig als Open Source Software entwickelt und sind unter einer freien Lizenz veröffentlicht (z. B. European Union Public Licence). | ||
| 47 | Falls die angebotene Plattform nicht als OSS entwickelt sein sollte, muss die Lizenzausgestaltung auch die Nutzung durch weitere Nutzer:innengruppen ermöglichen. (siehe Abschnitt 8.2 Leistungsbeschreibung) | A | ||||
| 5.2 Funktionale Anforderungen | ||||||
| In diesem Abschnitt werden die funktionalen Anforderungen formuliert. Die Anforderungen unterteilen sich in die unten beschriebenen Bereiche zur Information und Beteiligung. Grundsätzlich bietet die Plattform unterschiedliche CMS-Funktionen zur Bearbeitung des Informationsbereiches und des Beteiligungsbereiches. Die CMS-Funktionen der beiden Bereiche müssen den jeweils dafür zugeteilten Rollen zugänglich sein und können in einem oder zwei voneinander getrennten CMS-Systemen umgesetzt werden. | ||||||
| 48 | Die Plattform muss über einen Bereich zur Information verfügen, auf dem Hintergrundinformationen für Nutzer:innen bereitgestellt werden können. | A | ||||
| 49 | Die Plattform muss über einen Bereich zur Beteiligung verfügen, über den Nutzer:innen an laufenden Beteiligungsverfahren partizipieren können. | A | ||||
| 50 | Alle Seiten der Plattform müssen über einen Header, Footer und eine Navigation verfügen. | A | ||||
| 51 | Verweise zwischen Seiten des Inhaltsbereiches (z. B. Content Pages) und des Beteiligungsbereichs (z. B. Projektseiten) müssen über das CMS gestaltet werden können. | A | ||||
| 5.2.1 Allgemeine Funktionale Anforderungen | ||||||
| In diesem Kapitel werden u.a. die Funktionen zur Registrierung, Anmeldung und Löschung, sowie die Gestaltung, Erreichbarkeit und Mehrsprachigkeit der Plattform beschrieben. | ||||||
| 5.2.1.1 Registrierung, Anmeldung und Löschung | ||||||
| 52 | Die Plattform muss über eine Login-Seite verfügen, die es registrierten Nutzer:innen ermöglicht sich im Beteiligungsbereich der Plattform anzumelden | A | ||||
| 53 | Eine verpflichtende Einwilligungserklärung ist per Checkbox anzubieten. Mit der Einwilligungserklärung erklären Nutzer:innen ihre Einwilligung zu „Benutzungsregeln“ des Beteiligungsportals und zu den in der Datenschutzerklärung beschriebene Erhebung und Verwendung der Daten des/der Benutzer:in. | A | ||||
| 54 | Die Plattform muss es Nutzer:innen ermöglichen, sich mit Klarnamen oder einem Pseudonym und einer E-Mail-Adresse zu registrieren, um an den Beteiligungsprojekten partizipieren zu können. Die bei der Registrierung angegebene E-Mail-Adresse ist durch ein geeignetes Bestätigungsverfahren zu verifizieren (z. B. Double-Opt-In). | A | ||||
| 55 | Die Plattform ermöglicht es den Nutzer:innen weitere soziodemografische Daten zu hinterlegen. | B | Die Plattform ermöglicht es den Nutzer:innen nicht weitere soziodemografische Daten zu hinterlegen. | Die Plattform ermöglicht es den Nutzer:innen weitere soziodemografische Daten zu hinterlegen. | ||
| 56 | Nutzer:innen müssen ihr Konto eigenständig löschen können. | A | ||||
| 57 | Beiträge von Nutzer:innen, deren Konto gelöscht wurde, müssen mit anonymisierten Nutzer:innennamen weiterhin angezeigt werden. | A | ||||
| 58 | Einmal registrierte Nutzer:innen müssen die Möglichkeit haben, ein neues Passwort anzufordern. | A | ||||
| 59 | Die Plattform muss über ein Captcha verfügen, das unabhängig der verwendeten Sprache funktioniert und nicht über einen externen Dienst betrieben wird (z. B. reCaptcha o. ä). | A | ||||
| 5.2.1.2 Design | ||||||
| 60 | Die Plattform muss es ermöglichen, Farben des BASE Corporate Designs einzustellen. | A | ||||
| 5.2.1.3 Responsive Design und Erreichbarkeit | ||||||
| 61 | Die Plattform soll für Nutzer:innen sowohl von Desktop-Rechnern als auch gängigen mobilen Endgeräten erreichbar und bedienbar sein. | A | ||||
| Die Plattform muss für Nutzer:innen über gängige Webbrowser (einschließlich mobile Versionen; mindestens Mozilla Firefox, Safari, Microsoft Edge und Google Chrome) in der jeweils aktuellen Version erreichbar sein. | ||||||
| 62 | Die Plattform muss gemäß eines Responsive Designs entwickelt werden. Das bedeutet, dass die Plattform bzw. deren Layout sich automatisch auf das von Nutzer:innen verwendete Endgerät anpassen können muss. | A | ||||
| 63 | Die Plattform muss über eine von dem BASE gewählten Webadresse erreichbar sein. | A | ||||
| 5.2.1.4 Mehrsprachigkeit | ||||||
| 64 | Die Plattform muss es ermöglichen, eine grafische Benutzer:innenoberfläche auf Deutsch und Englisch darzustellen, die zur Bedienung verwendet wird und der Visualisierung der Inhalte dient. | A | ||||
| 65 | Die Plattform soll es ermöglichen, Inhalte in den auf der Plattform verfügbaren Sprachen auf der Seite anzulegen und zu veröffentlichen. Die AN listet die verfügbaren Sprachen im Angebot auf. | B | Die AN stellt keine Liste mit den verfügbaren Sprachen zur Verfügung. | Die Plattform ermöglicht es, Inhalte in den auf der Plattform verfügbaren Sprachen auf der Seite anzulegen und zu veröffentlichen. Die AN listet die verfügbaren Sprachen im Angebot auf. | ||
| 66 | Die Fallback-Sprache des redaktionell erstellten Contents ist Deutsch. Nicht übersetzter Content wird in deutscher Sprache angezeigt. | A | ||||
| 67 | Die Plattform soll es ermöglichen, sämtliche Sprachelemente der Benutzer:innenoberfläche als auch die redaktionell erstellten Contents maschinell in Sprachen der Anrainerstaaten Deutschlands (polnisch, tschechisch, französisch, niederländisch, dänisch) zu übersetzen. | B | Die Plattform ermöglicht die maschinelle Übersetzung von Sprachelementen der Benutzer:innenoberfläche und der redaktionell erstellten Contents nur zu 50 % oder weniger und deckt maximal eine der Sprachen der Anrainerstaaten Deutschlands (polnisch, tschechisch, französisch, niederländisch, dänisch) ab.“ | Die Plattform ermöglicht die maschinelle Übersetzung von Sprachelementen der Benutzer:innenoberfläche und der redaktionell erstellten Contents zu über 50 % und deckt mindestens zwei, aber nicht alle Sprachen der Anrainerstaaten Deutschlands (polnisch, tschechisch, französisch, niederländisch, dänisch) ab. | Die Plattform ermöglicht es, sämtliche Sprachelemente der Benutzer:innenoberfläche sowie die redaktionell erstellten Contents maschinell in alle Sprachen der Anrainerstaaten Deutschlands (polnisch, tschechisch, französisch, niederländisch, dänisch) zu übersetzen.“ | |
| 68 | Die Plattform soll es ermöglichen, sämtliche Sprachelemente der Benutzer:innenoberfläche als auch die redaktionell erstellten Contents maschinell in Sprachen von Menschen mit Migrationshintergrund in Deutschland: türkisch, russisch, arabisch zu übersetzen. | B | Die Plattform ermöglicht die maschinelle Übersetzung von Sprachelementen der Benutzer:innenoberfläche und der redaktionell erstellten Contents nur zu 50 % oder weniger und deckt maximal eine der Sprachen von Menschen mit Migrationshintergrund in Deutschland (türkisch, russisch, arabisch) ab. | Die Plattform ermöglicht die maschinelle Übersetzung von Sprachelementen der Benutzer:innenoberfläche und der redaktionell erstellten Contents zu über 50 % und deckt mindestens zwei, aber nicht alle Sprachen von Menschen mit Migrationshintergrund in Deutschland (türkisch, russisch, arabisch) ab. | Die Plattform ermöglicht es, sämtliche Sprachelemente der Benutzer:innenoberfläche sowie die redaktionell erstellten Contents maschinell in alle genannten Sprachen von Menschen mit Migrationshintergrund in Deutschland (türkisch, russisch, arabisch) zu übersetzen. | |
| 5.2.2 Funktionale Anforderungen für den Beteiligungsbereich | ||||||
| In dem folgenden Unterabschnitt werden die Anforderungen an die Plattform in Bezug auf den modularen Aufbau des Beteiligungsbereichs, die Projektseiten, die Administration und Nutzer:innenfunktionen definiert. | ||||||
| 5.2.2.1 Modularer Aufbau des Beteiligungsbereichs | ||||||
| 69 | Die Plattform muss modular und erweiterbar sein und es Initiator:innen und Fach-Administrator:innen des BASE ermöglichen, eigenständig Module zu aktivieren und zu konfigurieren und in Beteiligungsprojekten miteinander zu kombinieren. | A | ||||
| 70 | Der Beteiligungsbereich muss über eine Übersicht aller laufenden und abgeschlossenen Beteiligungsprojekte verfügen, z. B. eine filter- und sortierbare Liste aller Verfahren mit Titel, Status (laufend/abgeschlossen) und Zeitraum. | A | ||||
| 5.2.2.2 Projektseiten | ||||||
| Projektseiten sind in Abgrenzung zu Content Pages Seiten, auf denen Beteiligungsprojekte geschaltet werden können. | ||||||
| 71 | Die Plattform muss es dem BASE ermöglichen, für jedes Beteiligungsprojekt eine eigene Projektseite anzulegen und zu veröffentlichen, in der alle Informationen zu dem Vorhaben dargestellt werden können. | A | ||||
| 72 | Projekte auf der Plattform sollen entweder zur öffentlichen Beteiligung (öffentlich) oder für einen von dem BASE bestimmten Nutzer:innenkreis (nicht öffentlich) veröffentlicht werden können. | A | ||||
| Bei öffentlichen Beteiligungsprojekten können alle registrierten Nutzer:innen sich beteiligen und alle Inhalte einsehen. | ||||||
| Bei nicht öffentlichen Beteiligungsprojekten kann das BASE eigenständig Personen zur Beteiligung einladen (z. B. per Mail). In diesem Fall sind die Inhalte nur für eingeladene Nutzer:innen sichtbar. | ||||||
| 73 | Projektseiten sollen die Meilensteine des Projektes, wie z. B. Veranstaltungen oder Module der digitalen Beteiligung übersichtlich darstellen können (z. B. mit einer Zeitleiste). | B | Projektseiten können die Meilensteine des Projektes (z. B. Veranstaltungen, Module der digitalen Beteiligung) nicht übersichtlich darstellen. | Projektseiten können Meilensteine grundsätzlich darstellen, jedoch nur in einfacher oder eingeschränkter Form (z. B. tabellarisch oder als Liste ohne strukturierende Visualisierung; keine Zeitleiste oder vergleichbare übersichtliche Darstellungsform). | Projektseiten können die Meilensteine des Projektes übersichtlich und strukturiert darstellen, einschließlich einer Zeitleiste oder einer vergleichbar intuitiven und visuellen Darstellung von Veranstaltungen und Modulen der digitalen Beteiligung. | |
| 5.2.2.3 Administration der Beteiligung | ||||||
| 74 | Die Plattform muss den Initiator:innen und Fach-Administrator:innen des BASE eine Exportfunktion für alle Beiträge von Nutzer:innen (z. B. für Texte, kommentierte Texte, Umfragen und Stellungnahmen) bieten (z. B. Excel, PDF), damit diese ausgewertet werden können. | A | ||||
| 75 | Die Plattform soll über eine projektbezogene Newsletterfunktion verfügen. Fach-Administrator:innen und Initiator:innen können über die Plattform Newsletter an Nutzer:innen erstellen und (automatisiert) versenden, die sich an einem Projekt beteiligen. | B | Die Plattform verfügt nicht über eine projektbezogene Newsletterfunktion, die Fach-Administrator:innen oder Initiator:innen das Erstellen und Versenden von Newslettern an beteiligte Nutzer:innen ermöglicht. | Die Plattform verfügt grundsätzlich über eine projektbezogene Newsletterfunktion, ermöglicht jedoch nur einzelne Teilfunktionen: z. B. Erstellung, aber kein automatisierter Versand oder ein Versand, der nur manuell möglich ist, oder eine Funktion, die nur für eine der beiden Rollen (Fach-Administrator:innen oder Initiator:innen) zur Verfügung steht. | Die Plattform verfügt über eine projektbezogene Newsletterfunktion. Fach-Administrator:innen und Initiator:innen können über die Plattform Newsletter an Nutzer:innen, die sich an einem Projekt beteiligen, erstellen und automatisiert versenden. | |
| 76 | Administrator:innen müssen die Möglichkeit zur Sperrung von Nutzer:innenaccounts unter Einhaltung der Netiquette und Nutzungsbedingungen haben. | A | ||||
| 5.2.2.4 Moderationsfunktionen des Beteiligungsbereichs | ||||||
| Der Begriff Moderation bezeichnet die inhaltliche Interaktion von Content-Moderator:innen mit Nutzer:innen auf der Beteiligungsplattform zum Zweck der Aktivierung oder aus restriktiven Gründen. | ||||||
| 77 | Die Plattform muss die Möglichkeit bieten, auf Beiträge (z. B. Kommentare, Texte, kommentierte Texte und Stellungnahmen) zu antworten. Dabei muss die Rolle der Moderation in der Antwort sichtbar sein. | A | ||||
| 78 | Die Plattform muss die Möglichkeit bieten, Beiträge (z. B. Kommentare, Texte, kommentierte Texte und Stellungnahmen) zu löschen. | A | ||||
| 79 | Die Plattform soll eine Übersicht für Moderator:innen bieten, in der Beiträge (z. B. Kommentare, Texte, kommentierte Texte und Stellungnahmen) nach verschiedenen Kategorien (z. B. Neuste, am meisten kommentiert) sortiert werden können. | B | Die Plattform bietet keine Übersicht für Moderator:innen, in der Beiträge (z. B. Kommentare, Texte, kommentierte Texte und Stellungnahmen) nach verschiedenen Kategorien sortiert werden können. | Die Plattform bietet eine Übersicht für Moderator:innen, in der Beiträge nach einigen, aber nicht allen Kategorien (z. B. nur „Neuste“ oder nur „am meisten kommentiert“) sortiert werden können, oder die Übersicht umfasst nicht alle Beitragstypen (Kommentare, Texte, kommentierte Texte, Stellungnahmen). | Die Plattform bietet eine Übersicht für Moderator:innen, in der sämtliche Beiträge (Kommentare, Texte, kommentierte Texte, Stellungnahmen) nach allen relevanten Kategorien (z. B. Neuste, am meisten kommentiert) sortiert werden können. | |
| 80 | Moderator:innen müssen darüber informiert werden, wenn Nutzer:innen Beiträge anderer Nutzer:innen melden. | A | ||||
| 81 | Moderator:innen müssen informiert werden (z. B. per Mail oder Notification), sobald ein:e Nutzer:in einen neuen Beitrag auf der Plattform verfasst hat. | A | ||||
| 82 | Die Plattform muss es ermöglichen, dass bei bestimmten Beteiligungsverfahren Kommentare und andere Beiträge der Nutzer:innen erst durch die Moderation freigegeben werden müssen. | A | ||||
| 83 | Das Portal erhält ein Analytics-Dashboard mit dem die Nutzerzahlen, Klick- und Verweildauer sowie soziodemografische Segmentierungen ausgewertet werden können. Hierbei sollten keine Drittanbieter-Tools zum Einsatz kommen. Lässt sich dies nicht ausschließen dürfen nur Drittanbieter-Tools verwendet werden, die eine Datenverarbeitung- und -speicherung in der EU/dem EWR sicherstellen. | B | Die Plattform bietet kein Analytics-Dashboard und ermöglicht keine Auswertung von Nutzerzahlen, Klick- oder Verweildauer oder soziodemografischen Segmentierungen. | Die Plattform bietet ein Analytics-Dashboard, das nur einige der geforderten Kennzahlen auswertet, z. B. nur Nutzerzahlen und Klickzahlen, oder es werden nicht alle relevanten Segmentierungen bereitgestellt. | Die Plattform bietet ein Analytics-Dashboard, mit dem sämtliche geforderten Kennzahlen (Nutzerzahlen, Klick- und Verweildauer) sowie alle relevanten soziodemografischen Segmentierungen ausgewertet werden können | |
| 5.2.2.5 Nutzer:innen-Funktionen des Beteiligungsbereichs | ||||||
| 84 | Online-Konsultation: | A | ||||
| Als Bürger:in möchte ich online zu bestimmten Themen oder Dokumenten Stellung nehmen können, um meine Meinung/Position/Kompetenz einzubringen. Die Online-Konsultation muss je nach Verfahren auch über konfigurierbare Formulare erfolgen können. | ||||||
| 85 | Abstimmung / Voting: | A | ||||
| Als Bürger:in möchte ich über Vorschläge oder Maßnahmen abstimmen können, um meine Präferenzen zu zeigen. | ||||||
| 86 | Umfrage / Online-Befragung: | A | ||||
| Als Bürger:in möchte ich an Umfragen teilnehmen können, um meine Meinung zu spezifischen Fragestellungen abzugeben | ||||||
| 87 | Textdiskussion (absatzweise): | A | ||||
| Als Bürger:in möchte ich Dokumente absatzweise kommentieren und diskutieren können, um detailliertes Feedback zu geben. | ||||||
| 88 | Feedbackrunde: | A | ||||
| Als Bürger:in möchte ich nach Abschluss eines Beteiligungsformats Feedback zum Prozess und zu den Ergebnissen geben können. | ||||||
| 89 | FAQ / Frage-Antwort-Portal | A | ||||
| Als Bürger:in kann ich bestehendes Wissen über strukturierte FAQ erfassen und kann neue Fragen stellen, die in einem kanalisierten Prozess beantwortet werden | ||||||
| 90 | Datei-Upload: | A | ||||
| Als Büger:in möchte ich bei Online-Konsultationen Dokumente als Anhang meiner Stellungnahme hinzufügen können. Der Anhang ist auf max. 20MB zu begrenzen. Die Anhänge müssen vom BTMS auf Schadsoftware überprüft werden. Wird Schadsoftware im Anhang gefunden, kann der/die Büger:in wählen, die Stellungnahme ohne Anhang hochzuladen, oder die Stellungnahme abzubrechen. Wird die Stellungnahme abgebrochen wird diese nicht im BTMS gespeichert. | ||||||
| 91 | Authentifizierung bei Online-Konsultation: | A | ||||
| Die BTMS Plattform muss es ermöglichen, bei Online-Konsultationen Stellungnahmen entweder für anonyme, oder ausschließlich für verifizierte Büger:innen zu erlauben. | ||||||
| Diese Einstellung kann von dem/der zuständigen BASE Redakteur:in beim Erstellen der Konsultation eingestellt werden. | ||||||
| Die Verifikation erfolgt über ein marktübliches Verfahren, z. B. E-Mail-Verifikation. | ||||||
| 6 Abnahme | ||||||
| 6.1 Abnahmeprozess | ||||||
| 6.1.1 Prozessbeschreibung | ||||||
| 92 | Die AN muss dem BASE die Bereitschaft zur Gesamtabnahme für die Plattform inkl. der Systemumgebung in Textform kommunizieren. | A | ||||
| Die Abnahme besteht aus | ||||||
| - Systemtests (vgl. Abschnitt 6.1.4) und | ||||||
| - einer Überprüfung der Systemumgebung (vgl. Abschnitt 6.1.2). | ||||||
| 93 | Die AN und das BASE müssen die Systemtests durchführen und das BASE oder ein durch sie beauftragte:r Dienstleister:in muss mit Unterstützung der AN die Überprüfung der Systemumgebung durchführen. | A | ||||
| Hinweis: | ||||||
| Das BASE beabsichtigt, den Systemtest und die Überprüfung der Produktivumgebung innerhalb von 15 Werktagen nach der Bereitschaft zur Abnahme durch die AN durchzuführen. | ||||||
| Betriebsverhindernde Mängel (vgl. Abschnitt 10.1) sind abnahmeverhindernd. Werden betriebsbehindernde Mängel identifiziert, hat die AN ab dem Zeitpunkt des Bekanntwerdens 15 Werktage Zeit, diese zu beheben. Auch leichte Mängel sollten während dieser Zeit behoben werden. | ||||||
| Im Anschluss an die Mängelbehebung findet innerhalb von 15 Werktagen ab Mitteilung der Behebung in Textform durch die AN ein Mängelbehebungstest statt. Werden während des Mängelbehebungstests unverhältnismäßig viele (mehr als 5) leichte Mängel identifiziert, die in der Summe zu einer eingeschränkten Nutzung des Systems führen, sind auch diese Mängel abnahmeverhindernd. Werden während des Mängelbehebungstests betriebsbehindernde oder betriebsverhindernde Mängel identifiziert, ist dies abnahmeverhindernd. | ||||||
| 6.1.2 Allgemeine Leistungen | ||||||
| 94 | Die AN muss grundsätzlich alle Maßnahmen durchführen, die zu einer reibungslosen Abnahme der Systemumgebung nötig sind. Dazu gehört u. a. das Festlegen von organisatorischen Maßnahmen (u. a. Bereitstellung einer Test-Umgebung und passenden Zugängen, Abstimmung eines Zeitplans, Abstimmung der Struktur des Abnahmeprotokolls). Die AN unterstützt das BASE bei der Protokollierung der Gesamtabnahme. | A | ||||
| 6.1.3 Systemtests | ||||||
| Ziel der Systemtests ist, die Betriebsreife der bereitgestellten Plattform festzustellen. | ||||||
| 95 | Die Systemtests müssen aus den folgenden Tests bestehen: | A | ||||
| · Das BASE (nicht die AN) führt funktionale und nicht-funktionale Systemtests der Plattform durch. Das BASE prüft dabei, ob alle funktionalen und nicht-funktionalen Anforderungen an die Plattform korrekt umgesetzt worden sind. | ||||||
| Die AN unterstützt das BASE bei der Durchführung der Tests. Das heißt insbesondere, dass die AN dem BASE ausgearbeitete Testfälle inkl. dem erwarteten Systemverhalten zur Abnahme zur Verfügung stellt. Alle Testfälle beziehen sich dabei auf die in dieser Leistungsbeschreibung beschriebenen Anforderungen. | ||||||
| · Die AN führt gemeinsam mit dem BASE oder einem von BASE beauftragten Dienstleister:in einen Last- und Stresstest auf einer Test-Umgebung durch. Dabei wird getestet, wie sich das System unter hoher Belastung verhält. | ||||||
| 7 Hosting und Betrieb der Plattform | ||||||
| 7.1 Hosting | ||||||
| 7.1.1 Allgemein | ||||||
| 96 | Die AN und mögliche Unterauftragnehmer:innen müssen das Hosting im Rahmen einer Software-as-a-Service (SaaS) für die Plattform übernehmen inkl. aller dafür benötigten Lizenzkosten. SaaS bedeutet, dass die Software über das Internet zugänglich ist und weder lokal auf den Computern der Nutzer:innen installiert noch vom BASE selbst betrieben werden muss. | A | ||||
| Hinweis: | ||||||
| Diesbezüglich wird insbesondere auf die Regelungen des EVB-IT-Cloud-Vertrages, den EVB-IT-Cloud-AGB und dem EVB-IT Cloud Kriterienkatalog verwiesen. | ||||||
| 97 | Aufgrund der hohen Unsicherheit der Beteiligtenzahl ist ein möglichst großer Spielraum bei der Skalierung des Systems erforderlich. Die AN muss mit Angebotsabgabe die monatlichen Kosten für eine mögliche Skalierung des Systems in den folgenden Kategorien angeben: | A | ||||
| · 100.000 Einreichungen pro Monat | ||||||
| · 200.000 Einreichungen pro Monat | ||||||
| · 500.000 Einreichungen pro Monat | ||||||
| Die Hochskalierung muss zwei Monate nach Bedarfsanmeldung durch das BASE zur Verfügung stehen. Die Dauer der Hochskalierung ist je nach Projekt individuell festlegbar. | ||||||
| 7.1.2 Rahmenbedingungen zur Wartung und für den Systemservice | ||||||
| 98 | Die AN muss Leistungen zur Wartung und zum Systemservice an der Produktivumgebung grundsätzlich in einem mit dem BASE fest vereinbarten Wartungsfenster durchführen. Die AN stimmt die geplanten Wartungsfenster mit dem BASE ab oder das BASE beauftragt bei der AN ein Wartungsfenster (z. B. für ein Release-Wechsel). Die Wartungsfenster werden vom BASE freigegeben. Die Angaben zu den Wartungsfenstern umfassen mindestens: | A | ||||
| · Wartungsbeginn und -ende mit Datum und Uhrzeit | ||||||
| · Gegenstand der Wartung (z. B. Release-Wechsel) | ||||||
| · Beteiligte inkl. Hotline und Telefonnummern für Support-Anfragen (z. B. Software-Hersteller, Betrieb, usw.) und | ||||||
| · eine Rückfalllösung inkl. Zeitplan | ||||||
| 99 | Die AN muss den Wartungsplan für die Produktivumgebung pflegen, worin sämtliche geplanten und durchgeführten Wartungen dokumentiert sind. Das BASE muss jederzeit Zugriff auf den Wartungsplan haben. | A | ||||
| 100 | Die AN muss grundsätzlich die Wartungsleistungen und den Systemservice an der Produktivumgebung außerhalb der Geschäftszeiten gemäß EVB-IT-Cloudvertrag erbringen. | A | ||||
| 101 | Die AN und mögliche Unterauftragnehmer:innen müssen die Wartung der von ihr bereitgestellten Software übernehmen und protokollieren. | A | ||||
| 7.2 Betrieb | ||||||
| Unter den Betrieb der Software fallen unter anderem das Deployment der Plattform und die Installation von Updates, Upgrades und Patches. | ||||||
| 7.2.1 Allgemein | ||||||
| 102 | Die AN muss den Betrieb der Software im Rahmen einer Software-as-a-Service erbringen und hierbei die Regelungen der EVB-IT-Cloud-AGB inkl. aller dafür benötigten Lizenzkosten wie zum Beispiel für die benötigten Betriebssysteme übernehmen. | A | ||||
| 103 | Im Angebot sind die Kosten für einen 3-Jährigen und einen 5-Jährigen Betrieb der Software aufzuzeigen. Zusätzlich sollen die jährlichen Kosten für die Fortführung der Plattform über diesen Zeitraum hinaus angegeben werden. | A | ||||
| 104 | Die AN stellt eine Preistabelle für die Zuschaltung weiterer in der Plattform verfügbarer, aktuell im Angebot nicht angefragter Beteiligungsformate und Funktionen mit einer Angabe zur Zeitdauer zur Freischaltung bzw. Einrichtung dieser Formate bzw. Funktionen zur Verfügung. | B | Die AN stellt keine Preistabelle für die Zuschaltung zusätzlicher Beteiligungsformate oder Funktionen bereit und gibt keine Angaben zur Zeitdauer für Freischaltung bzw. Einrichtung dieser Formate/Funktionen. | Die AN stellt eine Preistabelle bereit, die nur einige der verfügbaren zusätzlichen Beteiligungsformate oder Funktionen abdeckt oder die Angaben zur Zeitdauer für Freischaltung bzw. Einrichtung sind unvollständig oder unklar. | Die AN stellt eine Preistabelle bereit, die sämtliche zusätzlich in der Plattform verfügbare Beteiligungsformate und Funktionen enthält, inklusive klarer Angaben zur Zeitdauer für deren Freischaltung bzw. Einrichtung. | |
| 7.2.2 Löschen, Datensicherung und Wiederherstellung | ||||||
| 105 | Die AN und mögliche Unterauftragnehmer:innen müssen auf dem aktuellen Stand der Technik basierte Verfahren zur | A | ||||
| • Redundanten Datensicherung: Die Daten müssen mindestens an zwei getrennten Speicherorten redundant gespeichert werden. Diese Maßnahme dient der Erhöhung der Datensicherheit und Verfügbarkeit. Die genannten Speicherorte müssen sich innerhalb Deutschlands befinden und die C5-Kriterien (Cloud Computing Compliance Controls Catalogue) des Bundesamtes für Sicherheit in der Informationstechnik (BSI) umsetzen. Dies garantiert, dass die Speicherorte hohe Sicherheitsstandards erfüllen und | ||||||
| · Wiederherstellung, | ||||||
| · Herausgabe und | ||||||
| · Löschung | ||||||
| für alle relevanten Daten der Plattform realisieren. Ergänzend hierzu müssen sie die im EVB-IT Cloud Kriterienkatalog dargelegten Regelungen einhalten. | ||||||
| 106 | Die AN muss einen initialen Wiederherstellungstest einen Monat nach Abnahme der Plattform durchführen. Anschließend führt die AN den Wiederherstellungstest mindestens jährlich durch. Die AN muss dabei die Mindestanforderungen des Kriterienkatalog C5 erfüllen. | A | ||||
| 7.2.3 Performance & Skalierung | ||||||
| 107 | Die AN muss das Performance-Verhalten der Plattform gemäß EVB-IT-Cloud-AGB prüfen. | A | ||||
| 108 | Die AN muss dem BASE auf Aufforderung nachweisen, dass 95 % der Benutzer:innenanfragen (Absenden einer Systemanfrage durch ein(e) Benutzer:in am Frontend, Bearbeiten der Anfrage im Backend und Anzeige des Ergebnisses der Anfrage am Frontend ) innerhalb von 1,5 Sekunden beantwortet werden. | A | ||||
| 109 | Die AN muss das BASE unverzüglich in Textform auf eine gemessene Verschlechterung der Performance hinweisen und die von der AN durchgeführten bedarfsgerechten Anpassungen zur Performanceoptimierung kommunizieren. | A | ||||
| 7.2.4 Überwachung und Sicherheit | ||||||
| 110 | Die AN muss den Betrieb der Plattform gemäß EVB-IT-Cloud-AGB überwachen. Das Erkennen von Sicherheitslücken und Angriffen muss vom AN im Sicherheitskonzept dargestellt werden. Die Überwachung umfasst: | A | ||||
| · Verfügbarkeits-Monitoring | ||||||
| · Störungs-Monitoring | ||||||
| · Performance-Monitoring | ||||||
| · Sicherheits-Monitoring | ||||||
| 111 | Die AN muss die Überwachung mit von ihr ausgewählten Werkzeugen automatisiert durchführen und dem BASE bei Bedarf die Möglichkeit der Überprüfung einräumen. | B | Die AN führt keine automatisierte Überwachung mit von ihr ausgewählten Werkzeugen durch und räumt dem BASE keine Möglichkeit zur Überprüfung ein. | Die AN führt eine automatisierte Überwachung durch, jedoch nur eingeschränkt oder mit Werkzeugen, die nicht alle relevanten Aspekte abdecken, oder die Möglichkeit für das BASE, die Überwachung zu prüfen, ist nur teilweise oder unklar gewährleistet | Die AN führt die Überwachung automatisiert mit von ihr ausgewählten Werkzeugen durch und räumt dem BASE jederzeit die Möglichkeit ein, die Überwachung umfassend zu überprüfen. | |
| 7.2.5 Schnittstellen | ||||||
| 112 | Exportschnittstelle: Der Export soll bevorzugt in JSON erfolgen. XML oder CSV sind ebenfalls zugelassen. Der AN macht im Angebot Angaben zu verfügbaren Datenformaten. (Hinweis zur Selbsteinordnung: Sind mehrere Dateiformate verfügbar, so ist die Auswahl für das höchstwertige verfügbare Format zu treffen) . | B | Der Export erfolgt im Format CSV | Der Export erfolgt im Format XML | Der Export erfolgt im Format JSON | |
| 113 | Anbindung an Active Directory der BASE. Die Base nutzt dabei Kerberos oder SAML (Authentifizierung). Die Endnutzer:innen (Nutzer:innen gemäß Glossar, Anhang B) werden hiervon unabhängig über die plattformeigene Registrierung/Anmeldung verwaltet (vgl. Afo 52–59). | A | ||||
| 114 | Neben der Export-Schnittstelle soll ab Januar 2028 eine bidirektionale Schnittstelle zum Einwendungsmanagementsystem (EWMS) zur Verfügung stehen, um Einwendungen aus dem BTMS automatisch ans EWMS senden zu können. Die Schnittstelle MUSS in der Lage sein strukturierte Formulardaten zur übertragen. Folgende Daten müssen nach aktuellem Stand mindestens vom BTMS an das EWMS übermittelt werden: | A | ||||
| · Vorname & Name des Einwendenden | ||||||
| · Adresse des Einwendenden | ||||||
| · E-Mailadresse für die Rückmeldung | ||||||
| · Text mit der Beschreibung der Einwendung (strukturiertes Objekt) | ||||||
| · Angehängte Dokumente | ||||||
| · Vom EWMS wird die Bestätigung über den Eingang der Stellungnahme zurückgemeldet. | ||||||
| Darüber hinaus muss es die Möglichkeit geben, nachträglich die Übertragung zusätzlicher Metadaten zu ermöglichen. Der Auftragnehmer muss in der Lage sein eine API-Spezifikation nach Open-API (Swagger) Stack zu erstellen. | ||||||
| · Eine Identifikationsnummer (ID) muss für jede eingehende Stellungnahme vergeben werden, die in allen beteiligten Systemen genutzt werden kann. · Für die Erprobung der EWMS-Schnittstelle steht eine Testumgebung zur Verfügung. Diese ist – unabhängig vom Zeitpunkt der Bereitstellung der EWMS-Schnittstelle – auch nach der initialen Gesamtabnahme für Schnittstellentests nutzbar. | ||||||
| 115 | Nach erfolgreicher Datenübergabe ans EWMS müssen alle personenbezogenen Daten einer Stellungnahme im BTMS gelöscht werden. | A | ||||
| 116 | Der Mail-Server des BASE soll mittelfristig an die Plattform angeschlossen werden. Eine Anbindung der Plattform an den Mail-Server des BASE ist aufgrund der aktuellen IT-Infrastruktur zum aktuellen Zeitpunkt nicht umsetzbar. Gegebenenfalls wird es zukünftig Änderungen in der IT-Infrastruktur des BASE geben, die eine Anbindung ermöglichen könnten. | A | ||||
| Der Mailversand des BTMS muss technisch so umgesetzt werden, dass E-Mails die von BASE-Mitarbeitenden aus der BTMS versendet werden nicht durch übliche Filter als Spam erkannt werden. | ||||||
| 8 Weitere Serviceleistungen | ||||||
| 8.1 Schulungen | ||||||
| 117 | Die AN muss das BASE im Umgang mit der Plattform schulen. Hierfür muss die AN vor Meldung der Betriebsbereitschaft und nach Absprache mit dem BASE zwei Schulungen mit einem Umfang von maximal vier Stunden anbieten, die dem BASE bestimmte Funktionen der Plattform (z. B. Beteiligungsprojekte anlegen und verwalten, Inhaltsseiten erstellen und bearbeiten) vermitteln. | A | ||||
| Zielgruppe für die Schulungen sind die Mitarbeitenden im BASE als Anwender:innen der Plattform oder Mitarbeitende von Dienstleister:innen, die das BASE beauftragt. | ||||||
| Die AN muss bei Bedarf und nach Absprache mit dem BASE bis zu drei weitere Schulungen pro Jahr für die Anwender:innen ermöglichen. | ||||||
| 118 | Die Schulung für Mitarbeiter:innen des BASE umfasst inhaltlich die allgemeinen funktionalen Anforderungen, beispielsweise die Möglichkeiten zur Moderation oder Redaktion. Die AN muss den Teilnehmenden alle für den jeweiligen Nutzungskontext notwendigen Funktionen der Plattform vermitteln. | A | ||||
| 119 | Die Schulungen müssen sowohl einen Praxisanteil als auch einen interaktiven Anteil beinhalten. Die Inhalte und Ausgestaltung der Schulungen können müssen gemeinsam mit dem BASE konkretisiert werden. | A | ||||
| 120 | Die Schulungen müssen als Webinar konzipiert und online durchgeführt werden. Das Webinar muss auf Video-Basis durchgeführt werden. Die AN muss sich bei der Konzeption der Schulungen mit dem BASE, insb. zu technischen und datenschutzrechtlichen Themen, abstimmen. | A | ||||
| 121 | Hinsichtlich der Schulungsunterlagen sind folgende Anforderungen von der AN einzuhalten: | A | ||||
| · Die AN muss für jede Schulung Schulungsunterlagen in deutscher Sprache bereitstellen, die sämtliche zu schulenden Inhalte umfassen. | ||||||
| · Die AN muss die Schulungsunterlagen mindestens eine Woche vor der Schulung dem BASE in elektronischer Form verfügbar machen. | ||||||
| · Die AN muss eine Aufzeichnung einer durchgeführten Schulung als Lernvideo anfertigen und dem BASE für einen ersten Einstiegspunkt für künftige Mitarbeitende des BASE als Anwender:innen des Systems überlassen. | ||||||
| · Die AN muss dem BASE die Nutzungsrechte an sämtlichen Schulungsunterlagen und dem Lernvideo kostenfrei einräumen. | ||||||
| 122 | Ab 2028 erhalten verantwortliche Personen in weiteren, im Standortauswahlverfahren eingebundenen Stellen bei einer Einrichtung der jeweiligen Mandanten identische Schulungen wie für das BASE mit den identischen Anforderungen erhalten. | A | ||||
| 8.2 Optional - Einrichtung zusätzlicher Mandanten | ||||||
| Nach Herbeiführung der Betriebsbereitschaft besteht im laufenden Betrieb ggf. die Notwendigkeit für andere, im Standortauswahlverfahren eingebundene Stellen (z.B. Organisationseinheiten des Bundes) sowie die vom BASE hierfür beauftragten Dienstleister Beteiligungsmöglichkeiten anzubieten. Dies soll über die Verfügbarmachung von zusätzlichen Mandanten auf der Plattform erfolgen. Die AG beauftragt die Verfügbarmachung zusätzlicher Mandanten separat beim AN. Der Betrieb dieser Mandanten ist im Mengengerüst der Leistungsbeschreibung bereits enthalten. Hier ist explizit keine separate Instanz gefragt. | ||||||
| 123 | Die AN muss auf Abruf bis zu 12 zusätzliche Mandanten mit einer separaten URL und Nutzer:innengruppen auf der Plattform verfügbar machen. | A | ||||
| 124 | Die Mandanten erfüllen die funktionalen und nicht-funktionalen Anforderungen, sowie die+B372 Anforderungen für den Betrieb und das Hosting dieser Leistungsbeschreibung. Ausgenommen sind hiervon die Afo 113 - 116. | A | ||||
| 125 | Die Mandanten müssen über eine abweichende, von der AG gewählte Webadresse erreichbar sein. | A | ||||
| 126 | Weitere Mandanten müssen unabhängig vom Hauptmandanten für getrennte Nutzer:innengruppen einstellbar sein. | A | ||||
| 127 | Bestandteil der Verfügbarmachung sind kleinere optische Konfigurationen (bspw. Logoaustausch). | A | ||||
| 9 Übergabe zum Vertragsende | ||||||
| 128 | Die AN muss sich verpflichten, im Falle einer Übergabe des Betriebs der Plattform zu einer neuen AN mit dieser kooperativ zusammenzuarbeiten und ihr keine Informationen für einen erfolgreichen Betrieb der Plattform wissentlich vorzuenthalten. | A | ||||
| 129 | Die AN muss alle relevanten Inhalte für das Hosting und den Betrieb der Plattform in einer mit dem BASE abgestimmten Form für die neue AN zur Übernahme bereitstellen. | A | ||||
| 130 | Der AN verpflichtet sich nach einer Bedarfsanmeldung des BASE an zwei Übergabegesprächsterminen mit dem BASE und der neuen AN produktiv teilzunehmen. | A | ||||
| 131 | Die AN muss dem BASE sämtliche Informationen zum Hosting und des IT-Gesamtsystems jederzeit in Textform bereitstellen (z. B. Anzahl Domains, Dimensionierung, Speichervolumen). | A | ||||
| 132 | Die AN verpflichtet sich, nach Beendigung des Vertrags alle von dem BASE bei Auftragsbeginn zur Verfügung gestellten Daten, die dem BASE gehören, zurückzugeben. Ebenso alle während des Betriebs gespeicherten Daten. | A | ||||
| 133 | Die AN verpflichtet sich gemäß AVV, nach Beendigung des Vertrags und nach der erfolgreichen Übergabe zu einer neuen AN alle vorhandenen Daten inklusive Datensicherungen auf Anweisung des BASE zurückzugeben und auf sämtlichen Systemen der AN so zu löschen, dass diese nicht wiederhergestellt werden können. | A | ||||
| 134 | Die AN muss in Absprache mit dem BASE eine datenschutzkonforme Archivierung der Plattform vornehmen. | A | ||||
| 10 Service Level Agreements (SLAs) | ||||||
| In diesem Kapitel werden die SLAs in Ergänzung zu EVB-IT-Cloudvertrag und den EVB-IT Cloud AGB beschrieben. | ||||||
| 10.1 Mängelklassifizierung | ||||||
| Tabelle 1 konkretisiert die Klassifizierung der Mängel, die bei der Verwendung der Plattform auftreten können. | ||||||
| Klasse | Beschreibung | |||||
| Schwerwiegende Störung | Eine schwerwiegende Störung liegt vor, wenn die Nutzung der Plattform unmöglich oder schwerwiegend eingeschränkt ist. Es existieren keine zumutbaren Umgehungslösungen für den Mangel. | |||||
| Beispielhafte Indikatoren für betriebsverhindernde Mängel: | ||||||
| · Mängel, die zum Abbruch der Plattform-Software führen | ||||||
| · Mängel, die zu Datenverlusten führen | ||||||
| · Mängel bei der Verarbeitung von Daten von Fremdsystemen | ||||||
| · fehlerhafte Verwendung von Systemressourcen und Speicherallokation | ||||||
| · Erzeugung von Dateninkonsistenzen | ||||||
| · Endlosschleifen | ||||||
| · Nicht autorisierter Zugriff auf Daten | ||||||
| Erhebliche Störung | Eine erhebliche Störung liegt vor, wenn die Nutzung der Plattform erheblich eingeschränkt ist. Ein betriebsbehindernder Mangel liegt auch vor, wenn die leichten Mängel insgesamt zu einer nicht unerheblichen Einschränkung der Nutzung der Software führen. | |||||
| Beispielhafte Indikatoren für behindernde Mängel: | ||||||
| · Mehrdeutige oder falsche Log-Meldungen | ||||||
| · wesentliche Leistungsmerkmale der Plattform fehlen, eine provisorische Lösung ist nicht oder nur mit Einschränkungen möglich (z B. fehlende oder stark eingeschränkte Barrierefreiheit). | ||||||
| Leichte Störung | Eine leichte Störung liegt vor, wenn die Nutzung der Plattform ohne oder mit unwesentlichen Einschränkungen möglich ist. | |||||
| Alle Mängel, die keine betriebsverhindernde oder betriebsbehindernde Mängel sind, sind leichte Mängel. | ||||||
| Beispielhafte Indikatoren für leichte Mängel: | ||||||
| · Mängel, die keine bedeutsame Auswirkung auf die Funktion der Plattform haben, z. B. ergonomische Fehler (Mängel an Bedienbarkeit und Nutzer:innenfreundlichkeit) oder nicht funktionsrelevante Layout- oder Anzeigefehler (Mängel in der optischen Erscheinung und Gestaltung). | ||||||
| · Mängel, deren Korrektur für den Betrieb wünschenswert, aber nicht notwendig sind. | ||||||
| · Mängel, bei denen die Gebrauchstauglichkeit nicht wesentlich beeinflusst wird oder mit denen die Benutzer:innen mit provisorischen Lösungen umgehen können. | ||||||
| Tabelle 1 Übersicht der Mängel | ||||||
| 10.2 Verfügbarkeit | ||||||
| Die AN sichert zu, dass die Server sowie die darauf betriebene Plattform die Verfügbarkeitsklasse 1[3] einhalten. Die Verfügbarkeitsklasse 1 entspricht einer Verfügbarkeit von 99,0%, das heißt, dass die maximale Ausfallzeit pro Jahr weniger als 88 Stunden und die maximale Ausfallzeit pro Monat weniger als 8 Stunden beträgt. | ||||||
| Im Übrigen gelten die Regelungen zur Verfügbarkeit im EVB-IT-Cloud-Vertrag sowie in den EVB-IT-Cloud-AGB. | ||||||
| 10.3 Support | ||||||
| Die Vergütung der Supportleistungen erfolgt über eine monatliche Pauschale. Das BASE rechnet mit einem Aufwand von mindestens 360 Tickets im Jahr. | ||||||
| 135 | Die AN muss für das BASE eine Hotline und ein Ticketsystem betreiben (siehe Afo-122). Beides ist in den Geschäftszeiten gemäß EVB-IT-Cloudvertrag verfügbar. Dadurch können der AN Vorfälle beim Betrieb der Plattform gemeldet werden. | A | ||||
| 136 | Es muss dem BASE möglich sein Supportanfragen telefonisch, per E-Mail oder direkt im Ticketsystem der AN zu stellen. | A | ||||
| 137 | Die AN ist für den technischen Nutzer:innen-Support verantwortlich. Hierzu zählen die Entgegennahme, Koordination und die Beantwortung von Supportanfragen (z. B. Probleme beim Login, Probleme bei der Nutzung der Plattform). Die AN unterstützt die Nutzer:innen bei allen systembezogenen Anfragen und stellt den Nutzer:innen eine E-Mail-Adresse und / oder ein Kontaktformular auf der Plattform zur Verfügung, an die sich die Nutzer:innen bei Anfragen wenden können. | A | ||||
| 138 | Die AN muss Supportanfragen annehmen und innerhalb von maximal zwei Arbeitstagen bearbeiten und das Anliegen entweder lösen oder einen Lösungsvorschlag unterbreiten. Der Eingang von in Textform gestellten Anfragen muss automatisch bestätigt werden. | A | ||||
| 139 | Die AN muss dem BASE und den weiteren Nutzer:innen der Plattform Supportleistungen zur Lösung der Supportanfrage bereitstellen. | A | ||||
| 140 | Die AN muss weitere Maßnahmen für den Support nach eigenem Ermessen und nach Rücksprache mit dem BASE ergreifen, bspw. das Einführen von Information Technology Infrastructure Library (ITIL)-Standards, die Organisation des Supports in 1st-, 2nd- und 3rd Level Support oder der Aufbau einer internen Wissensdatenbank. | A | ||||
| 141 | Alle Ticketbearbeitungen müssen dokumentiert und auf Wunsch dem BASE vorgelegt werden. | A | ||||
| 10.4 Reaktions- und Wiederherstellungszeiten | ||||||
| Für die Software gelten die in Tabelle 2 aufgelisteten Reaktions- und Wiederherstellungszeiten. | ||||||
| Mängelklasse | Reaktionszeit in h | Wiederherstellungszeit in h | ||||
| Schwerwiegende Störung | 4 | 8 | ||||
| Erhebliche Störung | 8 | 16 | ||||
| Leichte Störung | 24 | Innerhalb von 20 Arbeitstagen oder mit dem nächsten Release | ||||
| Tabelle 2 Reaktions- und Wiederherstellungszeiten | ||||||
| 10.5 Service Level Management | ||||||
| In diesem Abschnitt werden Anforderungen im Bereich Service Level Management aufgeführt. Das Service Level Management arbeitet dabei auf Grundlage dieser Leistungsbeschreibung. | ||||||
| 142 | Die AN muss dem BASE Service-Level-Berichte über sämtliche vereinbarte Service-Level sowie dessen Erreichung bzw. Erfüllungsgrad in der vereinbarten Form übersenden (Service Level Reporting). | A | ||||
| 143 | Die AN muss dem BASE vertraglich vereinbarte Kontroll- und Prüfrechte zusichern, um sicherzustellen, dass die weiteren Anforderungen (z. B. aus Gesetzen oder Verordnungen) erfüllt werden. | A | ||||
| 144 | Die AN muss eine aktuelle Systembeschreibung bereitstellen und diese gemäß den Vereinbarungen regelmäßig aktualisieren. | A | ||||
| 145 | Das System muss Protokolldaten erzeugen, die alle Fehler oder kritischen Systemzustände festhalten. | A | ||||
| 146 | Das System muss Protokolldaten erzeugen, die System- und Datenzugriffe festhalten können. | A | ||||
| 147 | Das System muss Protokolle revisionssicher aufbewahren. | A | ||||
| 148 | Der/die Auftragnehmer:in muss folgende Protokolle führen: | A | ||||
| · Protokolle über den Sicherheitsstatus des Cloud-Managementsystems (Vollständigkeit, Verfügbarkeit, Integrität und Vertraulichkeit der verarbeiteten Daten). | ||||||
| · Protokolle über Art und Zeitpunkte der durchgeführten Datensicherungsmaßnahmen und Rücksicherungen. | ||||||
| Der Auftraggeber hat das jederzeitige Recht, diese Protokolle einzusehen und in elektronisch bearbeitbarer Form abrufen zu können. | ||||||
| 149 | Ergänzend zu Ziffer 9 EVB-IT Cloud-AGB muss das Reporting folgende Inhalte beinhalten: | A | ||||
| · sämtliche für die Leistungen relevante Sicherheitsvorfälle (Zeitpunkt, Art, und Umfang des Vorfalls) und die von der AN getroffenen Maßnahmen zu deren Beseitigung | ||||||
| · die durchgeführten Backups und Datenexporte sowie ihre erfolgreiche Verifikation. | ||||||
| 150 | Das System muss über einen Benachrichtigungsmechanismus beim Auftreten von Fehlern oder definierten Zuständen verfügen, um die Administrator:innen des BASE schnellstmöglich zu informieren (z. B. Ergebnisse der Integritätsprüfung und -wiederherstellung). | A | ||||
| 10.6 Sicherheitsvorfälle | ||||||
| 151 | Die AN muss bei einem Sicherheitsvorfall (vergleiche EVB-IT Cloud-AGB, Abschnitt „Begriffsbestimmungen“) dazu empfohlene Workarounds und kritische Sicherheitsupdates unverzüglich implementieren. Die AN muss das BASE über die implementierten Änderungen und dadurch verursachte Auswirkungen informieren. Die AN muss mit dem BASE Einvernehmen für den Ablauf der Wiederherstellung der Betriebsbereitschaft herstellen. | A | ||||
| 152 | Die AN muss für den Fall, dass noch keine Workarounds oder Updates verfügbar sind, geeignete Maßnahmen ergreifen, um Sicherheitslücken zu schließen, beispielsweise durch Blockieren von Traffic an der Firewall | A | ||||
| 153 | Sicherheitspatches sollen ab dem Zeitpunkt ihrer Verfügbarkeit in Abhängigkeit des nach der jüngsten Version des Common Vulnerability Scoring Systems (CVSS) eingeordneten Schweregrades der dadurch adressierten Schwachstellen eingespielt werden: | A | ||||
| · Kritisch (CVSS = 9.0 - 10.0): innerhalb von 3 Stunden | ||||||
| · Hoch (CVSS = 7.0 - 8.9): innerhalb von 3 Tagen | ||||||
| · Mittel (CVSS = 4.0 - 6.9): innerhalb von 1 Monat | ||||||
| · Niedrig (CVSS = 0.1 - 3.9): innerhalb von 3 Monaten | ||||||
| 10.7 Kommunikation bei IT-Sicherheitsvorfällen | ||||||
| 154 | Die AN muss in Fällen von bekanntwerdenden Sicherheitslücken oder Vorfällen dazu empfohlene Workarounds und kritische Sicherheitsupdates unverzüglich implementieren und das BASE über mögliche Auswirkungen informieren sowie Änderungen dokumentieren. | A | ||||
| 155 | Die Kommunikation zwischen BASE und AN muss bei sicherheitsrelevanten Vorfällen über die definierten Kommunikationswege (vgl. Abschnitt 4.1) erfolgen. Wenn die Meldung per E-Mail bei der AN eingeht, erhält das BASE innerhalb von zwei Stunden eine Antwort, dass der Vorfall angenommen wurde, die Dringlichkeit erkannt ist sowie der Vorfall seitens der AN untersucht und bearbeitet wird. | A | ||||
| 156 | Die AN muss für den Fall, dass noch keine Workarounds oder Updates verfügbar sind, geeignete Maßnahmen ergreifen, um Sicherheitslücken zu schließen, beispielsweise durch Blockieren von Traffic an der Firewall. | A | ||||
| 157 | Sollten Rückfragen auftreten, muss sich die AN umgehend mit dem BASE in Verbindung setzen. Nach Abschluss der Arbeiten erhält das BASE eine entsprechende Rückmeldung der AN. | A | ||||
| 10.8 Zusammenarbeit im Incident-Management | ||||||
| Das BASE führt folgende Maßnahmen vor Abgabe einer Störungsmeldung durch: | ||||||
| 158 | Erfassung der Störung: Das BASE dokumentiert das Problem, einschließlich der beobachteten Symptome, der betroffenen Systeme und der zeitlichen Abfolge der Ereignisse. | A | ||||
| 159 | Überprüfung interner Systeme: Das BASE überprüft, ob die Störung durch interne IT-Systeme oder Netzwerke verursacht wurde. | A | ||||
| 160 | Reproduktionsversuch: Das BASE versucht, die Störung zu reproduzieren, um festzustellen, ob das Problem konsistent auftritt oder durch einen einmaligen Fehler verursacht wurde. | A | ||||
| 161 | Dokumentation der bisherigen Maßnahmen: Das BASE dokumentiert alle bisher durchgeführten Maßnahmen zur Behebung der Störung, einschließlich der Ergebnisse dieser Maßnahmen. | A | ||||
| 162 | Sicherstellung der Erreichbarkeit: Das BASE stellt sicher, dass die Ansprechpartner, die die Störung gemeldet haben, für Rückfragen des Dienstleisters erreichbar sind. Dies umfasst die Bereitstellung von Kontaktinformationen und die Sicherstellung, dass die Ansprechpartner während der Bearbeitung der Störung zu den üblichen Geschäftszeiten des BASE verfügbar sind. | A | ||||
| Anhang B Glossar | ||||||
| Begriff | Definition | |||||
| Administrator:in, fachliche:r | Kann auf Daten im Backend zugreifen und hat Zugriff auf alle Funktionen im Informationsbereich und Beteiligungsbereich. Details siehe 5.1.1. | |||||
| Administrator:in, technische:r | Hat vollständige Zugriffsrechte auf das technische System und kann technische Änderungen im Backend vornehmen. Details siehe 5.1.1. | |||||
| Anwender:innen | Unter Anwender:innen werden Mitarbeitende des BASE zusammengefasst, die z. B. in der Rolle der Redakteur:in, der Moderator:in oder Initiator:in in ihrer täglichen Arbeit mit der Plattform interagieren. | |||||
| Bewertungskriterien | Die Angaben zu Bewertungskriterien werden im Rahmen der Angebotsauswertung des Vergabeverfahrens durch die Auftraggeberin bewertet. | |||||
| Die Wertung und Gewichtung ist dem Tabellenblatt "Bewertungsübersicht" zu entnehmen. | ||||||
| Initiator:innen | Können Beteiligungsprojekte im Beteiligungsbereich der Plattform initiieren, bearbeiten, löschen und ggf. archivieren. Details siehe 5.1.1. | |||||
| Instanz | Eigenständige Installation und Betriebsumgebung der Plattform-Software. Zusätzliche Mandanten werden ohne separate Instanz auf derselben Plattform bereitgestellt. | |||||
| Mandant | Eigenständig adressierbarer, abgetrennter Nutzungsbereich auf derselben Plattform-Instanz mit eigener URL und eigenen Nutzer:innengruppen. Ein Mandant ist keine separate Installation (vgl. Abschnitt 8.2, Afo 123–127)." | |||||
| Moderator:innen | Verfügen über Rechte der Moderation in zugewiesenen Beteiligungsprojekten. Sie sind jeweils als Moderator:in in diesen Projekten kenntlich gemacht. Details siehe 5.1.1. | |||||
| Nutzer:innen; nicht-angemeldet | Besucher:innen der Beteiligungsplattform, die alle öffentlichen Inhalte einsehen können, jedoch nicht selbst aktiv werden. | |||||
| Nutzer:innen; angemeldet | Besucher:innen der Beteiligungsplattform, die sich bei öffentlichen digitale Beteiligungsprojekten auf der Plattform aktiv einbringen. | |||||
| Plattform | Online-Beteiligungsplattform (BTMS) | |||||
| Redakteur:innen | Können im Informationsbereich der Plattform Inhalte einstellen, bearbeiten, veröffentlichen und löschen. | |||||
| Systemumgebung | Umfasst die Bereiche der Test- und Produktivumgebung | |||||
| Anhang C Abkürzungsverzeichnis | ||||||
| Bezeichnung / Abkürzung | Bedeutung | |||||
| Afo | Anforderung | |||||
| AG | Auftraggeber:in | |||||
| AGB | Allgemeine Geschäftsbedingungen | |||||
| AN | Auftragnehmer:in (inkl. möglicher Unterauftragnehmer:innen) | |||||
| AVV | Auftragsverarbeitungsvertrag | |||||
| BASE | Bundesamt für die Sicherheit der nuklearen Entsorgung | |||||
| BITV | Barrierefreie-Informationstechnik-Verordnung | |||||
| BSI | Bundesamt für die Sicherheit in der Informationstechnik | |||||
| CMS | Content Management System | |||||
| DSGVO | Datenschutz-Grundverordnung | |||||
| EVB-IT | Ergänzende Vertragsbedingungen für IT-Dienstleistungen | |||||
| EWR | Europäischer Wirtschaftsraum | |||||
| ISMS | Informationssicherheits-Managementsystem | |||||
| OOTB | Out of the Box | |||||
| SaaS | Software-as-a-Service | |||||
| SLA | Service Level Agreements | |||||
| StandAG | Standortauswahlgesetz | |||||
| WCAG | Web Content Accessibility Guidelines | |||||
| Fußnoten | ||||||
| [1] Vgl. IT Planungsrat. Stärkung der Digitalen Souveränität der Öffentlichen Verwaltung: https://www.it-planungsrat.de/fileadmin/beschluesse/2021/Beschluss2021-09\_Strategie\_zur\_Staerkung\_der\_digitalen\_Souveraenitaet.pdf; zuletzt abgerufen am 08.05.2024. | ||||||
| Architekturrichtlinie des Bundes, Version 2022, S.9f.: https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/digitaler-wandel/architekturen-standard/Architekturrichtlinie\_techn\_Anhang.html; zuletzt abgerufen am 08.05.2024 | ||||||
| [2] Vgl. ebd., S. 54f.: ID: AV-9075-R01, ÜBAV-17 Open Source. | ||||||
| [3] BSI Hochverfügbarkeitskompendium V1.6, Band G, Kapitel 2: Definitionen, siehe Tabelle 3. |
Bewertungsübersicht
| Vergabe: 0229/26 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 | Unnamed: 5 | Unnamed: 6 |
|---|---|---|---|---|---|---|
| Leistungskatalog - Tabellenblatt Bewertungsübersicht | ||||||
| Stand: 21.08.2026 | ||||||
| Version: 1.0 | ||||||
| Afo # | Beschreibung | Maximale Wertungspunkte | Gewichtung | Erreichte Wertungspunkte | Maximale Leistungspunkte | Erreichte Leistungspunkte |
| 8 | Energiemanagementsystem des Rechenzentrums | 2 | 1 | 0 | 2 | 0 |
| 9 | Deckung des Strombedarfs des Rechenzentrums | 2 | 1 | 0 | 2 | 0 |
| 10 | Power Usage Effectiveness | 2 | 1 | 0 | 2 | 0 |
| 11 | Cooling Efficiency Ratio | 2 | 1 | 0 | 2 | 0 |
| 12 | Halogenfreie Kältemittel | 2 | 1 | 0 | 2 | 0 |
| 13 | Schwefelhexafluorid-freie Schaltanlagen | 2 | 1 | 0 | 2 | 0 |
| 14 | Information der AG zu Möglichkeiten der Energieeinsparung und Umsetzungsuntertstützung | 2 | 1 | 0 | 2 | 0 |
| 15 | Open Source Quellcode | 2 | 1 | 0 | 2 | 0 |
| 17 | Supportleistungen auf Englisch | 2 | 1 | 0 | 2 | 0 |
| 33 | Hilfebereich für externe Nutzer:innen | 2 | 2 | 0 | 4 | 0 |
| 36 | Zertifizierung nach ISO 27018 (Datenschutz in der Cloud) | 2 | 2 | 0 | 4 | 0 |
| 46 | Open Source Software und Veröffentlichung unter einer freien Lizenz | 2 | 1 | 0 | 2 | 0 |
| 55 | Hinterlegung soziodemografischer Daten | 2 | 2 | 0 | 4 | 0 |
| 65 | Inhalte in den auf der Plattform verfügbaren Sprachen | 2 | 2 | 0 | 4 | 0 |
| 67 | Maschinelle Übersetzung in Sprachen der Anrainerstaaten Deutschlands | 2 | 2 | 0 | 4 | 0 |
| 68 | Maschinelle Übersetzung in Sprachen von Menschen mit Migrationshintergrund in Deutschland | 2 | 2 | 0 | 4 | 0 |
| 71 | Übersichtliche Darstellung der Meilensteine des Projektes auf Projektseiten | 2 | 2 | 0 | 4 | 0 |
| 75 | Projektbezogene Newsletterfunktion | 2 | 2 | 0 | 4 | 0 |
| 79 | Übersicht für Moderator:innen | 2 | 2 | 0 | 4 | 0 |
| 83 | Analytics-Dashboard | 2 | 2 | 0 | 4 | 0 |
| 104 | Preistabelle für die Zuschaltung weiterer in der Plattform verfügbarer Beteiligungsformate und Funktionen | 2 | 1 | 0 | 2 | 0 |
| 111 | Automatisierte Überwachung durch den AN | 2 | 2 | 0 | 4 | 0 |
| 112 | Formate Exportschnittstelle | 2 | 1 | 0 | 2 | 0 |
| Konzept | Bewertungsergebnis des von den Bietenden eingereichten Einführungskonzepts (Vgl .Afo-22) (Wird von der Auftraggeberin bei Angebotsauswertung entsprechend dem Bewertunsmaßstab für das Konzept ergänzt) | 10 | 4 | 40 | ||
| Gesamtpunktzahl | 108 | 0 |
Bewertungsmaßstab Konzept
| Vergabe: 0229/26 | Unnamed: 1 |
|---|---|
| Leistungskatalog - Tabellenblatt Bewertungsmaßstab Konzept | |
| Stand: 21.08.2026 | |
| Version: 1.0 | |
| Bewertung des "Konzeptes": | |
| Hinweis: | |
| Die AN muss mit Abgabe des Angebots ein maximal fünf DIN A4 Seiten umfassendes Einführungskonzept vorlegen (Schriftart Arial, Schriftgröße 10, einfacher Zeilenabstand). Bei Konzepten, die mit der oben angegebenen Formatierung 5 Seiten überschreiten, fließen nur die ersten 5 Seiten in die Angebotsbewertung ein. Der Rest wird nicht berücksichtigt. Das Konzept muss folgende Punkte adressieren: | |
| 1.\tEinsatz von KI: Das Konzept soll darlegen, wie der Einsatz von KI-gestützten Funktionen zur Unterstützung der Durchführung und Auswertung von digitalen Beteiligungsverfahren beiträgt. Es wird erwartet, dass die AN konkret aufzeigt, wie bestehende oder geplante KI-Anwendungen einen klar nachvollziehbaren Mehrwert für die Effizienz und Qualität), das die Konfiguration des Beteiligungsprozesses bieten können. | |
| 2.\tPassgenauigkeit zum Endlagersuchprozess: Es muss aufgezeigt werden, wie das BTMS an die spezifischen Anforderungen, Rahmenbedingungen und Herausforderungen des BASE in den ersten Phasen des Standortauswahlprozesses integriert. Dazu gehört auch eine präzise Darstellung, wie die im Mengengerüst definierten Anforderungen durch die Plattform abgebildet werden können. Zudem wird erwartet, dass die AN die Rolle der Regionalkonferenzen, die Besonderheiten bundesweiter Beteiligungsprozesse, sowie die Anforderungen an Datenschutz und IT-Sicherheit berücksichtigt. Das BASE plant die Beschaffung einer Online-Beteiligungsplattform (BTMS) die Informationen zu den aktuellen und abgeschlossenen Beteiligungsverfahren sowie dem Stand der Beteiligungsmöglichkeiten bereitstellt. Ziel der Plattform ist es, ein digitales Beteiligungs- und Informationsangebot zu schaffen, das das Interesse an den Themen der Standortauswahl weckt und gleichzeitig Bedarfe sowie Anregungen der interessierten Öffentlichkeit aufnimmt. Die Plattform soll insbesondere zur Vorbereitung (2026-2027), Einführung (2028) und Begleitung der Regionalkonferenzen (ab 2028) im Rahmen des Standortauswahlverfahrens (StandAV) genutzt werden. Da weder die Anzahl der Regionalkonferenzen noch die Standortregionen vor Ende 2027 bekannt sind und darüber hinaus nicht feststeht, welche der Regionalkonferenzen das Angebot des BASE zur Nutzung des BTMS in Anspruch nehmen werden, ergibt sich eine Einschränkung der Planungssicherheit hinsichtlich der Mengengerüste zum Zeitpunkt der Ausschreibung. Dies gilt ebenfalls für die Besonderheit, dass das BASE das BTMS auch für deutschlandweite sowie möglicherweise für grenzüberschreitende Beteiligungsverfahren einsetzen möchte. Für diese Verfahren existieren zum jetzigen Zeitpunkt keine belastbaren Grundlagen für eine detaillierte Planung und Anforderungsdefinition hinsichtlich der Bedarfe und Mengengerüste. Der Grund hierfür sind unvorhersehbare Dynamiken der politischen Diskurse im Standortauswahlverfahren sowie eine geplante Novellierung des Standortauswahlgesetzes. Aus dem Angebot muss klar hervorgehen, dass der Bieter diesen Umstand angemessen berücksichtigt hat, die Randbedingungen reflektiert wurden und dies ausdrücklich im Angebot dargelegt wird. | |
| Als Teil der Kundenzentierung der Bieter wird zum einen die umfassende "Verständlichkeit" des Angebots als Gesamtkonzept, zum anderen wird ein "Mitdenken" hinsichtlich aller Punkte erwartet, die in diesem Erwartungshorizont benannt werden. | |
| Die Konzepte der Bietenden werden in den folgenden Unterkriterien gewertet: | |
| 1. Unterkriterium Einsatz von KI | |
| 0 Punkte: Keine konkreten KI-Anwendungen oder nur allgemeine, unverbindliche Aussagen. | |
| 2 Punkte: Vorhandene oder geplante KI-Funktionen mit erkennbarem Nutzen für die Durchführung oder Auswertung. | |
| 4 Punkte: Konkrete KI-Anwendungen mit nachweisbarem Mehrwert für die Durchführung und Auswertung der Beteiligungsverfahren. | |
| Erläuterung: Die Auftraggeberin erwartet den Einsatz von KI-gestützten Funktionen zur Unterstützung der Durchführung und Auswertung von digitalen Beteiligungsverfahren. Bewertet wird, in welchem Umfang KI-Implementierungen bereits vorhanden sind oder geplant werden und wie diese den Beteiligungsprozess sowie die Auswertung konkret und nachvollziehbar unterstützen. | |
| 2. Unterkriterium Passgenauigkeit zum Kontext des Endlagersuchprozess | |
| Abgrenzung: Bewertet wird ausschließlich der inhaltliche Bezug zum Endlagersuchprozess (Relevanz und Spezifität), nicht die logische Stringenz der Darstellung — diese bewertet Kriterium 3. | |
| 0 Punkte: Allgemeine, austauschbare Aussagen ohne erkennbaren Bezug zum Endlagersuchprozess; die spezifischen Anforderungen werden nicht aufgegriffen. | |
| 2 Punkte: Die spezifischen Anforderungen und Rahmenbedingungen werden grundsätzlich aufgegriffen, jedoch teils allgemein/unspezifisch; der Bezug zur Standortauswahl bleibt stellenweise pauschal. | |
| 4 Punkte: Durchgehend konkreter, spezifischer und belegter Bezug: Mengengerüst-Anforderungen, vorhandene Beteiligungsformate, Rolle der Regionalkonferenzen sowie Datenschutz/IT-Sicherheit werden fallbezogen und mit konkreten Beispielen adressiert. | |
| Erläuterung: Bewertet wird, inwieweit der Bieter die spezifischen Anforderungen, Rahmenbedingungen und Herausforderungen der ersten Phase der Standortauswahl erkennt und in sein Konzept integriert — u. a. die Abbildung der im Mengengerüst definierten Anforderungen, die detaillierte Darstellung der vorhandenen digitalen Beteiligungsformate und ihrer Eignung für den Anwendungsfall, die Rolle der Regionalkonferenzen, die Besonderheiten bundesweiter Beteiligungsprozesse sowie Datenschutz und IT-Sicherheit. Ein hoher Passungsgrad zeigt sich durch konkrete, spezifische und belegte Ausführungen mit klarem Bezug zum Anwendungsfall. | |
| 3. Unterkriterium – Schlüssigkeit und Nachvollziehbarkeit des Konzepts | |
| Abgrenzung: Bewertet wird die innere Logik der Darstellung — Widerspruchsfreiheit, konsistente Herleitung, roter Faden — unabhängig davon, wie gut die Lösung inhaltlich zum Endlagersuchprozess passt (das bewertet Kriterium 2). | |
| 0 Punkte: Die Darstellung ist nicht schlüssig: Aussagen widersprechen sich, oder wesentliche Schritte/Begründungen fehlen bzw. sind nicht hergeleitet. | |
| 1 Punkt: Die Darstellung ist im Wesentlichen schlüssig und in sich stimmig; einzelne Begründungslücken oder Brüche im Ablauf bleiben. | |
| 2 Punkte: Die Darstellung ist durchgängig schlüssig, widerspruchsfrei und logisch hergeleitet; Annahmen, Vorgehen und Ergebnis greifen konsistent ineinander. | |
| Erläuterung: Bewertet wird nicht, was der Bieter vorschlägt, sondern ob die Darstellung in sich logisch, widerspruchsfrei und konsistent ist — ob Annahmen, Vorgehen, Maßnahmen und Ergebnis nachvollziehbar zusammenpassen. Der inhaltliche Bezug zum Endlagersuchprozess wird ausschließlich in Kriterium 2 bewertet. |
Drop_down
| A | Unnamed: 1 | B 0 | Unnamed: 3 | B 1 |
|---|---|---|---|---|
| Ja | 0 | 0.0 | ||
| Nein | 1 | 2.0 | ||
| 2 |