[Seite 1]

Anhang B:

- Anforderungen_Lastenheft -

Neuentwicklung der EUginius-Webanwendung

("EUginius 2.0")

Version: 1.0

Projektnummer
Name des Projekts	Neuentwicklung der EUginius-Webanwendung ("EUginius-2.0")
Projektleiter	(Hinweis: wird nach Zuschlagserteilung bekannt gegeben)
Verantwortlich	(Hinweis: wird nach Zuschlagserteilung bekannt gegeben) Mitwirkend: (Hinweis: wird nach Zuschlagserteilung bekannt gegeben) (Hinweis: wird nach Zuschlagserteilung bekannt gegeben)
Erstellt am	03.04.2024 11:57
Zuletzt geändert	29.07.2026 09:25
Bearbeitungsstatus	x	in Arbeit eingereicht fertiggestellt
Speicherung von Dokumenten	O:\EUginius 2.0\Ausschreibung
V-Modell-Version	Version 2.3

29.07.2026 09:25

[Seite 2]

Anforderungen (Spezifikationen) EUginius 2.0

Inhaltsübersicht

Einleitung ......................................................................................................................... 3

1.1. Projekt-Übersicht ....................................................................................................... 3

1.2. Übersicht über das aktuelle System und Zweck der Neuentwicklung ...................... 3

1.3. Ziele ......................................................................................................................... 4

1.4. Umfang der Leistung .................................................................................................. 5

1.5. Überblick über die Anforderungen und Priorisierungsrichtlinien....................................... 5

1.6. Zielpublikum und Stakeholder ................................................................................. 6

1.7. Erwartete Ergebnisse .................................................................................................. 7

Projektmanagement ....................................................................................................... 7

2.1. Projektphasen und Meilensteine ............................................................................. 7

2.1.1. Anforderungserhebung und Initialisierung ........................................................ 8

2.1.2. Minimal Viable Product (MVP) Entwicklung (agile Umsetzung in Sprints)......... 9

2.1.3. Endprodukt Entwicklung ..................................................................................10

2.2. Kommunikation und Berichtsstruktur ......................................................................12

2.3. Mitwirkung des Auftraggebers ................................................................................13

Technische Anforderungen ...........................................................................................13

3.1. Systemarchitektur und technische Spezifikationen .................................................13

3.1.1. Technische Infrastruktur und Plattformanforderungen .....................................13

3.1.2. Zugangskontrolle und Sicherheitsanforderungen ............................................15

3.1.3. Anforderungen an die Anwendungsentwicklung ..............................................17

3.2. Datenbank-Management ........................................................................................20

3.2.1. Aktuelle Datenbankstruktur.................................................................................20

3.2.2. Vorgeschlagene Änderungen an der Datenbank .............................................23

3.2.3. Datenintegrität und Migrationsplan......................................................................26

Funktionale Anforderungen ...............................................................................................27

4.1. Fragenkatalog ...........................................................................................................28

4.2. Nutzerrollen und Dateneingabe ..................................................................................29

4.2.1. Nutzerrollen und Berechtigungen ........................................................................29

4.2.2. Nutzerverwaltung (Registrierung, Anmeldung, Passwortwiederherstellung) ....30

4.2.3. Dateneingabe und -aktualisierung ........................................................................31

1 29.07.2026 09:25

[Seite 3]

Anforderungen (Spezifikationen) EUginius 2.0

4.2.4. Review Workflow .............................................................................................37

4.3. Webanwendung Features ......................................................................................39

4.3.1. Gemeinsame Funktionalitäten über alle Module ..............................................39

4.3.2. Homepage ......................................................................................................42

4.3.3. Modul “GMO” ..................................................................................................43

4.3.4. Modul “Detection” ............................................................................................45

4.3.5. Modul “Analysis Tool” ......................................................................................47

4.3.6. Help ................................................................................................................50

Nicht-funktionale Anforderungen ...................................................................................51

5.1. Zugänglichkeit und Konformität ..............................................................................51

5.2. Nutzerfreundlichkeit................................................................................................52

5.3. Leistung .................................................................................................................54

5.4. Wartbarkeit und Aktualisierbarkeit ..........................................................................55

5.5. Zuverlässigkeit .......................................................................................................57

5.6. Sicherheit ...............................................................................................................58

5.7. Skalierbarkeit .........................................................................................................59

Prüfung, Lieferumfang und Abnahme ...........................................................................59

6.1. Prüfung und Qualitätssicherung .............................................................................60

6.1.1. Durchführung der statischen Quellcode-Analyse .............................................60

6.1.2. Überprüfung ....................................................................................................60

6.2. Umfang der Lieferung .............................................................................................60

6.3. Abnahme ................................................................................................................63

6.3.1. 63

Abkürzungsverzeichnis .................................................................................................64

2 29.07.2026 09:25

[Seite 4]

Anforderungen (Spezifikationen) EUginius 2.0

1. Einleitung

Gentechnisch veränderte Organismen (GVO) sind Pflanzen, Tiere oder Mikroorganismen, deren Erbgut mit gentechnischen Methoden gezielt verändert wurde, um ihnen verbesserte Eigenschaften zu verleihen.

GVO, die in der EU freigesetzt oder in Verkehr gebracht werden, müssen einer Risikobewertung unterzogen und auf Antrag gemäß der Richtlinie 2001/18/EG oder der Verordnung (EG) Nr. 1829/2003 zugelassen werden. Die Risikobewertung stützt sich im Wesentlichen auf die Informationen über die genetischen Veränderungen in dem GVO, insbesondere auf Informationen über die Art, den Ursprung und die Beschreibung der Zusammensetzung der eingeführten genetischen Elemente (molekulare Charakterisierung).

In Verkehr gebrachte GVO und daraus hergestellte Produkte unterliegen den Vorschriften zur Kennzeichnung und Rückverfolgbarkeit gemäß der Verordnung (EG) Nr. 1830/2003. Zur Überwachung dieser Vorschriften werden vor allem Nachweismethoden auf Nukleinsäurebasis eingesetzt, die Informationen über die Nukleinsäuresequenz erfordern. Darüber hinaus sind GVO und GVO-Produkte, die aufgrund fehlender Zulassung in der EU nicht verkehrsfähig sind, von besonderem Interesse für die Überwachungsinstitutionen und - falls sie auftreten - für die Öffentlichkeit.

1.1. Projekt-Übersicht

Ziel dieses Projekts ist die (Neu-)Entwicklung einer webbasierten Anwendung (nachfolgend auch „Webanwendung“ oder kurz „Anwendung“ genannt) für die Erfassung und Bereitstellung von Informationen über GVO. Die Anwendung wird verschiedenen Stakeholdern, darunter amtlichen Laboratorien, gentechnikrechtlichen Vollzugsbehörden, Forschenden, Unternehmen und der interessierten Öffentlichkeit, dienen, indem sie Werkzeuge für eine effiziente Datenverwaltung, Datenabfrage und Datenauswertung zu GVO-Analysen bereitstellt. Außerdem wird sie der Öffentlichkeit Zugang zu wichtigen GVO-Daten bieten und so zu Transparenz und fundierten Entscheidungen beitragen. Bei der Entwicklung des Systems wird auf Skalierbarkeit geachtet, um künftigen Fortschritten in der GVO-Forschung und den gesetzlichen Anforderungen gerecht zu werden.

1.2. Übersicht über das aktuelle System und Zweck der Neuentwicklung

Die derzeitige Webanwendung (EUginius 1.0) führt wichtige Informationen über zugelassene und nicht zugelassene GVO in der EU zusammen, einschließlich GVO, die mit neuen Züchtungstechniken entwickelt wurden (genom-editierte GVO/GE-GVO), und dient der Durchsetzung der Gentechnikvorschriften. Allgemeine Informationen über die GVO, spezifische Informationen über die genetische Veränderung sowie Informationen über ihren Zulassungsstatus in der EU und gegebenenfalls entsprechende Zulassungsanträge und mögliche Nachweismethoden sind in EUginius 1.0 verknüpft und können über verschiedene Abfrageoptionen abgerufen werden.

3 29.07.2026 09:25

[Seite 5]

Anforderungen (Spezifikationen) EUginius 2.0

Diese Webanwendung, die seit dem Jahr 2014 online ist, besteht aus einer öffentlichen und einer privaten Anwendung mit täglicher Synchronisation der zugrundeliegenden Datenbank: (1) Die öffentliche Anwendung (siehe Internetlink: https://www.euginius.eu) verfügt über eine Startseite mit allgemeinen Informationen und vier thematisch differenzierte Module ("GMO", "Detection", "Analysis" und "Authorisation"), die spezifischen Abfragen und Tools zu GVO- relevanten Informationen bieten. (2) Die private Anwendung ist nur für registrierte Nutzende zugänglich. Die Nutzende können unterschiedliche Rollen und Rechte haben. Registrierte Nutzende haben Zugriff auf alle in EUginius eingegebenen Daten sowie auf das Modul "Data entry". Die für die Öffentlichkeit bereitgestellten Daten werden von einer Gruppe von ca. 20 registrierten Nutzenden gepflegt; ein Überprüfungsprozess (basierend auf dem 6-Augen- Prinzip) stellt die Qualität der Daten sicher.

Das bestehende System ist veraltet, was zu erheblichen Sicherheits- und Leistungsproblemen sowie zu einem veralteten Design führt. Diese Faktoren machen es zunehmend schwieriger, es zu pflegen und effektiv zu nutzen. Angesichts all dieser Probleme besteht dringender Bedarf an einem technisch auf dem neuesten Stand befindlichen zentralen System, das eine effiziente Datenverwaltung, Datenabfrage und Datenauswertung ermöglicht. Eine moderne, nutzer- und wartungsfreundliche Webanwendung wird die Nutzerfreundlichkeit erheblich verbessern, die Datensicherheit erhöhen und die Verwaltung von GVO-bezogenen Informationen effizienter gestalten.

1.3. Ziele

Die zu erstellende Anwendung EUginius 2.0 soll weiterhin ein breites Spektrum an Informationen bieten und muss den größten Teil der bestehenden Fachdaten übernehmen (siehe Kapitel 3.2). Die Architektur von EUginius 2.0 muss umgestaltet und vereinfacht werden. In EUginius 2.0 soll es nur noch eine (im Wesentlichen) öffentliche Anwendung geben, wobei der Dateneingabebereich durch ein Login geschützt ist. Das Informationsangebot wird leicht verändert und die Funktionalitäten werden angepasst, um den aktuellen Anforderungen der Nutzenden gerecht zu werden. Aufgrund der Leistungs- und Sicherheitsprobleme der Altanwendung und der veränderten technischen Rahmenbedingungen besteht auch bei der Neuentwicklung ein erheblicher Optimierungsbedarf. Die primären Ziele der Webanwendung sind wie folgt:

Zentralisierte Datenbank: Entwicklung einer robusten Datenbank zur Speicherung und Verwaltung detaillierter Informationen über GVO.
Effiziente Dateneingabe und -integration: Verbesserung des Dateneingabeprozesses durch ein überarbeitetes und (teilweise) automatisiertes System und Vereinfachung der Eingabe.
Verbesserte Zugänglichkeit: Bereitstellung einer nutzerfreundlichen Webanwendung, die das intuitive Suchen und Abrufen von GVO-bezogenen Daten erleichtert und sie sowohl für Experten als auch für die breite Öffentlichkeit zugänglich macht.

4 29.07.2026 09:25

[Seite 6]

Anforderungen (Spezifikationen) EUginius 2.0

Modernisierung und Wartbarkeit: Ersetzen der veralteten Anwendung durch eine moderne Webanwendung, die den Wartungsaufwand reduziert, die Skalierbarkeit verbessert und künftige Anpassungen mit minimalen Kosten auch nach Abschluss des Projekts ermöglicht.
Verbesserter Datenexport: Ermöglichen eines automatisierten Datenexports durch die verschiedenen Beteiligten.
Einhaltung gesetzlicher Vorschriften: Sicherstellen, dass die Webanwendung den Datenschutzgesetzen (Datenschutz- Grundverordnung (DSGVO) und dem Bundesdatenschutzgesetz (BDSG)) und den Zugänglichkeitsstandards des Bundes (Barrierefreiheit gemäß BITV bzw. EN 301 549) entspricht.
Datenintegrität und -sicherheit: Gewährleistung der Sicherheit der Daten unter Einhaltung der in den Ausschreibungsdokumenten genannten Sicherheitsstandards und Richtlinien (organisatorische, technische und rechtliche Vorgaben, unter anderem IT-Grundschutz des BSI, BSI-Mindeststandards für den Bund, Architekturrichtlinie des Bundes, DSGVO, BITV 2.0, SAGA, XÖV, DIN EN ISO 9241-110 & -210). Sicherstellen der Unveränderlichkeit, Authentizität und Zuverlässigkeit der Daten über den gesamten Lebenszyklus.

1.4. Umfang der Leistung

Der Umfang dieser Leistung umfasst das komplette Design, die Entwicklung, das Testen, die Bereitstellung und die Service- und Pflegeleistungen der Webanwendung. Dazu gehört auch die Migration der bestehenden GVO-bezogenen Daten auf die neue Webanwendung (siehe Abschnitt 3.2 für weitere Informationen).

Das Projekt umfasst:

Implementierung der Datenmigration.
Realisierung über mehrere agile Entwicklungszyklen.
Entwicklung des Front-End und Back-End der Webanwendung.
Erstellung der Dokumentation.
Testen und Sicherstellen der Systemsicherheitsmaßnahmen.
Laufende Pflege- und Serviceleistungen und Aktualisierung nach der Bereitstellung.

Die Details sind in den Abschnitten 2 bis 6 dieses Dokuments sowie im Anhang C näher beschrieben.

1.5. Überblick über die Anforderungen und Priorisierungsrichtlinien

Die folgenden Hinweise dienen der Verdeutlichung der Darstellung und Interpretation der Anforderungen im gesamten Dokument:

Viele der Anforderungen werden einzeln aufgeführt und nach Kontext geordnet.
Deren Nummerierung sagt nichts über ihre relative Bedeutung aus. 5 29.07.2026 09:25

[Seite 7]

Anforderungen (Spezifikationen) EUginius 2.0

Weitere Anforderungen sind im Fließtext beschrieben.
Die Anforderungen sind nicht in jedem Detail vollständig ausgearbeitet.
Die Priorisierung kategorisiert die Anforderungen auf der Grundlage der Notwendigkeit ihrer Umsetzung:

 MUSS: Wesentliche Anforderungen, die umgesetzt werden müssen, um den Projekterfolg zu gewährleisten. Hinweis: Die Erfüllung der MUSS-Kriterien sind im Leistungsverzeichnis zu bestätigen. Eine Nicht-Erfüllung eines oder mehrerer Ausschlusskriterien (MUSS-Kriterien) führt zum Ausschluss des Angebotes.

 SOLL: Bewertungskriterium; Wichtige Anforderungen, die umgesetzt werden sollen.  KANN: Bewertungskriterium; Erweiterungen, die einen Mehrwert darstellen können.

Die Ausführung der vorgegebenen Anforderungen wird während der Sprint-Phasen zwischen Auftraggeber und Auftragnehmer abgestimmt und weiter spezifiziert. Der Auftraggeber entscheidet in diesem Rahmen auch darüber, ob und welche der im Lastenheft aufgeführten Soll- und Kann-Kriterien durch den Auftragnehmer umgesetzt werden.

1.6. Zielpublikum und Stakeholder

Zu den Stakeholdern der Anwendung gehören:

	Beteiligte			Beschreibung
Fachabteilung des Auftraggebers			Die Fachabteilung des Auftraggebers stellt die fachliche Administration und Datenpflege der Anwendung und ist außerdem Nutzende der Anwendung. Des Weiteren beteiligt sich die IT-Fachkoordination des Auftraggebers an der Betreuung der Projektumsetzung und des laufenden Betriebes der Webanwendung.
Internationale (Kooperations-)Partner			EUginius wird von fachlicher Seite in Zusammenarbeit mit Partnern in den Niederlanden (Wageningen Food Safety Research (WFSR)) betrieben. Des Weiteren beteiligen sich Partner aus Österreich, Italien und Polen am fachlichen Austausch.
Nutzende			Nutzende aus amtlichen Laboratorien, Vollzugsbehörden für Gentechnikrecht, Forschende, Unternehmen und die interessierte Öffentlichkeit schätzen EUginius für das

6 29.07.2026 09:25

[Seite 8]

Anforderungen (Spezifikationen) EUginius 2.0

	vorhandene Datenangebot und die unterstützenden Funktionen in der Anwendung.
IT-Abteilung des Auftraggebers	Die IT-Abteilung des Auftraggebers begleitet die Entwicklung des Systems, dessen Implementierung in die Umgebung des Auftraggebers und schlussendlich den Dauerbetrieb der Anwendung. Sie definiert die für alle Phasen notwendigen technischen Rahmenbedingungen und andere nicht- funktionale Anforderungen.

1.7. Erwartete Ergebnisse

Die wichtigsten Ergebnisse, die von der Webanwendung erwartet werden, sind:

Eine voll funktionsfähige und sichere Webanwendung für die Verwaltung von GVO- Daten,
eine nutzerfreundliche Schnittstelle mit leistungsstarken Such- und Berichtsfunktionen,
Einhaltung der einschlägigen Vorschriften und Sicherheitsstandards,
verbesserte Entscheidungsmöglichkeiten für Regulierungsbehörden und Forschende,
positives Nutzerfeedback aufgrund der Zugänglichkeit und Nutzerfreundlichkeit der Webanwendung.

2. Projektmanagement

In diesem Abschnitt werden der Projektmanagementansatz und die Methodik für die

Durchführung des Projekts dargelegt. Der Prozess wird in Phasen unterteilt, mit einer klaren

Ressourcenzuweisung und einer effizienten Kommunikationsstruktur, um sicherzustellen,

dass das Projekt rechtzeitig fertiggestellt wird und alle Anforderungen erfüllt.

Das Projekt wird mit Hilfe des hybriden Projektmanagements, der sogenannten Water-Scrum-

Fall-Methodik, durchgeführt. Das hybride Projektmanagement ist eine Kombination aus agilen

und klassischen Methoden und basiert auf dem Vorgehensmodell "V-Modell XT Bund (Version 2.3)1" und dem agilen Scrum-Projektmanagement unter Berücksichtigung von

organisationsspezifischen Anpassungen.

2.1. Projektphasen und Meilensteine

Das Projekt wird in drei Hauptphasen unterteilt, die jeweils eigene Leistungen und

Meilensteine umfassen. Diese Phasen sind so konzipiert, dass bei klarer Vorgehensweise

Fortschritt und Abschluss des Projekts gewährleistet sind. Generell wird eine Beteiligung des

1 Abrufbar unter Internetlink: https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/digitaler- wandel/architekturen-standard/v_modell_xt_bund_pdf.html 7 29.07.2026 09:25

[Seite 9]

Anforderungen (Spezifikationen) EUginius 2.0

Auftragnehmers in allen Phasen des Softwareentwicklungsprozesses (Analyse, Entwurf,

Entwicklung, Testung und Inbetriebnahme) vorausgesetzt.

2.1.1. Anforderungserhebung und Initialisierung

In dieser ersten Projektphase werden alle relevanten funktionalen und technischen

Anforderungen erhoben, zwischen den Vertragsparteien abgestimmt und vom Auftragnehmer

dokumentiert. Die Phase beginnt mit einem Kickoff-Meeting und endet mit der Durchführung

der Datenmigration.

In dieser ersten Projektphase gibt es fünf Meilensteine:

Kickoff-Meeting

Ein Kickoff-Meeting wird zwischen den Vertragsparteien schnellstmöglich, aber spätestens

vier Wochen nach Zuschlagserteilung (xx.xx.2026) in Präsenz beim Auftraggeber in 13347

Berlin durchgeführt, um ein gemeinsames Verständnis, klare Erwartungen und einen

strukturierten Projektstart zu ermöglichen. In diesem ersten Kickoff-Meeting in Präsenz werden

die Rollen festgelegt, die Vision und Ziele geklärt, Rahmenbedingungen wie Projektumfang,

Zeitrahmen u. s. w. definiert und die einzusetzenden Tools und Kommunikationswege

abgestimmt.

Meilenstein 1: Kick-off-Meeting durchgeführt und protokolliert.

Product Backlog

Alle Anforderungen müssen im Rahmen eines digitalen Workshop mit dem Scrum-Team

erfasst und in einem strukturierten Product Backlog dokumentiert und priorisiert werden,

sodass das Entwicklungsteam mit der Sprint-Planung beginnen kann. Dabei ist der Umfang

des Minimum Viable Product (MVP) eindeutig zu definieren und abzugrenzen. Der Zugang

zum Product Backlog ist für alle Vertragsparteien sicherzustellen (siehe Abschnitt 2.2).

Meilenstein 2: Product Backlog einschließlich MVP-Umfang, vom Auftraggeber definiert und

genehmigt

Prototyp

Der Auftragnehmer stellt einen Prototyp und gegebenenfalls Wireframes bereit, welche die

zentralen Designelemente der Webanwendung illustrieren. Dieser Prototyp dient dazu,

frühzeitig Feedback von den Stakeholdern einzuholen, um die Gestaltung und Funktionalität

vor Beginn der eigentlichen Implementierung optimal abzustimmen.

Meilenstein 3: Designdokumente durch den Auftragnehmer vorgelegt und Prototyp durch den

Auftraggeber freigegeben

8 29.07.2026 09:25

[Seite 10]

Anforderungen (Spezifikationen) EUginius 2.0

Erstes funktionales Inkrement (Sprint 1)

Im Rahmen des ersten Sprints wird ein initial lauffähiger Systemstand von EUginius 2.0

erstellt. Dieses Inkrement umfasst die im Sprint 1 priorisierten Anforderungen aus dem Product

Backlog und bildet die technische Grundstruktur sowie die Systemarchitektur des Systems ab.

Es stellt die erste integrierte und ausführbare Version der Anwendung dar.

Meilenstein 4: Erstes funktionales Inkrement durch den Auftragnehmer erstellt und durch den

Auftraggeber validiert (Sprint 1)

Datenmigration

Die Datenmigration umfasst die Extraktion, Transformation und Zuordnung der relevanten

Daten aus der Altanwendung in das neue Zielsystem EUginius 2.0. Dabei wurden das

Migrationskonzept und die SQL-Migrationsskripte iterativ entwickelt und validiert, um eine

vollständige, korrekte und einsatzbereite Übernahme der relevanten Daten sicherzustellen

(siehe Abschnitt 3.2.3).

Meilenstein 5: Auftragnehmer hat das Migrationskonzept erstellt, initiale Testmigration

durchgeführt und erfolgreich geprüft

2.1.2. Minimal Viable Products (MVP; agile Umsetzung in Sprints)

In dieser zweiten Projektphase wird ein Minimal Viable Product (MVP) von EUginius 2.0

gemäß der Anforderungserhebung entwickelt, wobei die Übereinstimmung mit den

Geschäftszielen durch die agile Scrum-Methodik sichergestellt wird. Das MVP umfasst einen

gebrauchsfähigen Systemstand mit den zuvor definierten Kernfunktionalitäten (z. B. Startseite,

Modul GMO und Modul Detektion; siehe Abschnitt 4.3). Die Umsetzung der priorisierten

Anforderungen erfolgt in inkrementellen Entwicklungsschritten. Diese zweite Projektphase

umfasst auch die iterativen Validierungs- und Fehlerbehebungszyklen inklusive der Unit-Tests,

um sicherzustellen, dass alle Anforderungen erfüllt werden.

In dieser zweiten Projektphase gibt es vier Meilensteine:

Entwicklung der MVP-Funktionalitäten

Im Rahmen der MVP-Entwicklung werden die priorisierten Anforderungen aus dem Product

Backlog technisch umgesetzt und in die bestehende Systemarchitektur integriert. Dies umfasst

sowohl die Implementierung der fachlichen Kernfunktionalitäten als auch notwendige

Anpassungen an Frontend-, Backend- und Datenbankkomponenten.

Meilenstein 6: MVP-Funktionalitäten implementiert

9 29.07.2026 09:25

[Seite 11]

Anforderungen (Spezifikationen) EUginius 2.0

Migration neu hinzugefügter Daten

Während der Entwicklung des MVP können in EUginius 1.0 weiterhin neue Daten erfasst oder

bestehende Daten geändert werden. Diese seit Projektbeginn neu hinzugefügten oder

aktualisierten Daten werden durch definierte Migrationsprozesse und SQL-Migrationsskripte

in EUginius 2.0 übernommen, validiert und geprüft.

Meilenstein 7: Migration neuer Daten erfolgreich durchgeführt

Test und Abnahme des MVP

Nach Abschluss der MVP-Implementierung wird das System fachlich und technisch getestet.

Im Rahmen der Funktionstests prüft und bestätigt der Auftraggeber die Erfüllung der

funktionalen Anforderungen und Qualitätskriterien. Im Rahmen der technischen Tests wird der

MVP durch die IT-Abteilung des Auftraggebers auf technische Aspekte geprüft.

Meilenstein 8: MVP durch den Auftraggeber erfolgreich validiert, getestet und abgenommen

(siehe Abschnitt 6)

Bereitstellung des MVP

Nach erfolgreicher Abnahme wird das MVP in der Produktionsumgebung bereitgestellt. Hierzu

gehören die Durchführung des Deployments, die Konfiguration der Systemumgebung sowie

die Bereitstellung der erforderlichen technischen Komponenten für den Produktivbetrieb.

Meilenstein 9: MVP in der Produktionsumgebung bereitgestellt

2.1.3. Endprodukt

In dieser dritten Projektphase wird die Entwicklung von EUginius 2.0 abgeschlossen, indem

alle noch nicht im MVP realisierten Funktionen implementiert werden (z. B. Modul Analysis

Tool, Data Entry; siehe Abschnitt 4.3). Die Umsetzung der finalen Anforderungen erfolgt

weiterhin iterativ, unterstützt durch umfangreiche Tests. Nach Abschluss der Entwicklung

werden alle während der Entwicklungsphase erfassten oder aktualisierten Daten in das neue

System übertragen. Die Phase schließt mit der finalen Projektdokumentation, Lessons

Learned und der offiziellen Projektübergabe in den Betriebs- und Pflegezustand ab.

In dieser dritten Projektphase gibt es sechs Meilensteine:

Entwicklung aller verbleibenden Funktionen

Alle Webanwendung Features (siehe Abschnitt 4) sind unter Berücksichtigung der technischen

und funktionalen Anforderungen (siehe Abschnitte 3 und 4) in der Anwendung EUginius 2.0

vollständig erfolgreich implementiert.

10 29.07.2026 09:25

[Seite 12]

Anforderungen (Spezifikationen) EUginius 2.0

Meilenstein 10: 100 % der Product-Backlog-Items implementiert

Migration neu hinzugefügter Daten

Nach Abschluss der Entwicklung werden alle Daten, die während der Entwicklungsphase

erfasst oder aktualisiert wurden, in das neue System migriert, validiert und geprüft.

Meilenstein 11: Abschluss der Datenmigration in das neue System

Test und Abnahme des Endprodukts

Es sollten umfassende Tests durchgeführt werden. Darüber hinaus wird durch den

Auftraggeber ein umfassender funktionaler und technischer Abnahmetest durchgeführt, bei

dem alle Funktionen, Leistungsmerkmale und Sicherheitsanforderungen überprüft werden.

Ziel ist sicherzustellen, dass EUginius 2.0 den definierten Spezifikationen entspricht, voll

funktionsfähig ist und für den produktiven Einsatz bereitsteht.

Meilenstein 12: Abschluss aller Tests und Abnahme von EUginius 2.0 (siehe Abschnitt 6)

Bereitstellung des Endprodukts

Nach erfolgreichem Abschluss aller Tests und Vorbereitungen geht die Anwendung EUginius

2.0 in den regulären Betrieb. Ab diesem Zeitpunkt ist die Anwendung EUginius 2.0 für die

Nutzenden verfügbar.

Meilenstein 13: EUginius 2.0 bereitgestellt

Bereitstellung der Dokumentation

Dieser Meilenstein umfasst die vollständige Erstellung, Überprüfung und Übergabe aller

relevanten Dokumentationen (siehe Abschnitt 6.2). Damit wird sichergestellt, dass alle

Dokumente vollständig, korrekt und zeitgerecht bereitgestellt werden, um eine reibungslose

Projektübergabe und Nachvollziehbarkeit zu gewährleisten.

Meilenstein 14: Abschluss und Übergabe aller relevanten Projektdokumentationen an den

Auftraggeber

Projektabschluss

Dieser Schritt markiert das Ende des Projekts und überführt die Anwendung EUginius 2.0 in

den Betriebs- und Pflegezustand. In diesem Schritt wird das Projekt offiziell abgeschlossen,

alle offenen Aufgaben werden finalisiert, und die Ergebnisse werden dokumentiert. Zudem

werden im Rahmen von einer Lessons Learned-Besprechung Erfahrungen, Erfolge und

Herausforderungen des Projekts reflektiert. Dadurch können wertvolle Erkenntnisse

11 29.07.2026 09:25

[Seite 13]

Anforderungen (Spezifikationen) EUginius 2.0

gewonnen werden, die bei zukünftigen Projekten helfen, Prozesse zu verbessern und Fehler

zu vermeiden.

Meilenstein 15: Projektabschluss und Übergabe von EUginius 2.0 in Betrieb und Pflege

2.2. Kommunikation und Berichtsstruktur

Eine klare Kommunikation ist unerlässlich, um sicherzustellen, dass alle Beteiligten während

des gesamten Projekts informiert und eingebunden sind. Die Kommunikationsstrategie des

Auftragnehmers muss Folgendes umfassen:

Kommunikation im Scrum-Team (Product Owner, Scrum Master, Entwickler): Innerhalb des Scrum-Teams finden folgende Events statt: “Sprint Planning”,“Sprint Review” und ggfs. “Sprint Retrospective“, um den Fortschritt zu verfolgen, Hindernisse zu beseitigen und die Prioritäten abzustimmen. Darüber hinaus trifft sich das vom Auftragnehmer definiertes Entwicklerteam in „Daily Scrum“ um täglich die bevorstehende geplante Arbeit zu justieren. Das Product Backlog wird kontinuierlich gepflegt, priorisiert und verfeinert, um Anforderungen, User Stories und Aufgaben für kommende Sprints vorzubereiten. Am Ende des Projekts findet eine besondere Retrospektive statt, die Lessons learned-Besprechung, um die Ergebnisse aus dem gesamten Projekt zu bewerten und ggf. auf zukünftige Projekte zu übertragen.
Updates für Stakeholder: Bei Bedarf lädt der Auftraggeber die Stakeholder (siehe Abschnitt 1.6) durch die Fachabteilung des Auftraggebers zu den Sprint-Reviews ein, so werden sie über die Ergebnisse des Sprints informiert und haben die Möglichkeit Anregungen zu geben.
Ablage der Projektdokumentation: Die gesamte Projektdokumentation, einschließlich Besprechungsnotizen, Entwurfsdokumenten und Testberichten, wird in einer gemeinsamen Ablage auf Seiten des Auftragnehmers aufbewahrt, die allen Teammitgliedern zugänglich ist.
Projektmanagement-Tool: Der Einsatz eines durch den Auftragnehmer zur Verfügung gestellten Projektmanagement-Tools mit einem Kanban-Board ist unverzichtbar, um Transparenz für alle Beteiligten zu gewährleisten. So sieht jeder auf einen Blick, was geplant, in Bearbeitung oder abgeschlossen ist und kann den Fortschritt leicht nachvollziehen. Es erleichtert die Planung von Sprints, Aufgaben, Prioritäten und mehr. Zudem fördert es die Teamkommunikation durch Funktionen wie Kommentare, Anhänge und Benachrichtigungen, was die Zusammenarbeit zwischen den Vertragsparteien deutlich verbessert.
Ticketing-System und Problemverfolgung: Die gesamte Kommunikation zwischen den Vertragsparteien, einschließlich der Meldung, Verfolgung und Lösung von Problemen, erfolgt über ein durch den Auftragnehmer zur Verfügung gestelltes, formelles Ticket-System wie zum Beispiel Jira.

12 29.07.2026 09:25

[Seite 14]

Anforderungen (Spezifikationen) EUginius 2.0

Dieser Ansatz gewährleistet Transparenz, Verantwortlichkeit und eine effiziente Verwaltung von Aufgaben, indem er eine zentrale Plattform für die Dokumentation von Diskussionen, Statusaktualisierungen, Prioritäten und Lösungen bietet.

2.3. Mitwirkung des Auftraggebers

Der Auftraggeber erbringt die folgenden Mitwirkungsleistungen:

Bereitstellung der IT-Infrastruktur und der Systemumgebung für die Abnahme der Anwendung EUginius 2.0. (Entwicklungsumgebung und Testumgebung),
gemeinsame Klärung von offenen technischen und fachlichen Fragen mit dem Auftragnehmer,
Bereitstellung der Räumlichkeiten und Infrastruktur für die Durchführung der im Lastenheft aufgeführten Besprechungen (Kickoff-Meeting und ggf. Lessons learned in Präsenz, weitere virtuell),
Überprüfung und Freigabe aller Sprints und Inkremente in iterativen Validierungs- und Fehlerbehebungszyklen inklusive der Unit-Tests.
Begleitung der Installation der Software auf den Serversystemen des Auftraggebers.

3. Technische Anforderungen

In diesem Abschnitt werden die technischen Anforderungen festgelegt, die für die erfolgreiche Implementierung und den Betrieb des Systems erforderlich sind. Er besteht aus zwei wichtigen Unterabschnitten: (1) Systemarchitektur und technische Spezifikationen und (2) Datenbankmanagement. Der erste Unterabschnitt Systemarchitektur und technische Spezifikationen umreißt die wichtigsten architektonischen Entscheidungen, einschließlich der Plattformanforderungen, Sicherheitsstandards und Praktiken für die Entwicklung von Webanwendungen. Der zweite Unterabschnitt Datenbankmanagement konzentriert sich auf das Datenbankdesign und den Datenmigrationsplan.

3.1. Systemarchitektur und technische Spezifikationen

In diesem Abschnitt wird die Systemarchitektur definiert und es werden die grundlegenden Elemente beschrieben, die für den Entwurf, die Entwicklung und das Deployment der Anwendung erforderlich sind. Er beginnt mit einer Beschreibung der technischen Zielplattform, gefolgt von den Sicherheitsanforderungen. Abschließend werden die Technologien zur Entwicklung von Webanwendungen behandelt.

3.1.1. Technische Infrastruktur und Plattformanforderungen

Die Anwendung EUginius 2.0 muss nach dem aktuellen Planungsstand auf der folgenden technischen Plattform lauffähig sein (technical requirement (TR)). Änderungen oder Abweichungen von den geforderten Versionen des Betriebssystems, der Datenbankmanagementsysteme, der Anwendungsserver oder der Laufzeitumgebungen müssen begründet und vom Auftraggeber genehmigt werden.

13 29.07.2026 09:25

[Seite 15]

Anforderungen (Spezifikationen) EUginius 2.0


TR-01	Betriebssystem Als Betriebssystem für virtuelle Maschinen im Serverbereich wird das Produkt "Red Hat Enterprise Linux" (RHEL) eingesetzt. Ziel ist es, immer die neueste, vom Hersteller unterstützte und als allgemein verfügbar deklarierte Version zu verwenden, in diesem Fall: RHEL 9.12 .	MUSS
TR-02	Datenbank-Management-Systeme Für die Persistenz der normalisierten Daten verwendet der Auftraggeber ausschließlich schema-basierte relationale Datenbanken nach der Structured Query Language (SQL). Die Verwendung von PostgreSQL wird gegenüber Oracle DB bevorzugt. Ziel ist es, immer die neueste, vom Hersteller unterstützte und als allgemein verfügbar deklarierte Version zu verwenden, in diesem Fall PostgreSQL 153.	MUSS
TR-03	Applikationsserver Die Produkte "Red Hat JBoss Web Server" (RH JWS) und "Red Hat Java Beans Open-Source Server Enterprise Application Platform" (RH JBoss EAP) werden als Servlet-Container bzw. Anwendungsserver eingesetzt. Ziel ist es, immer die neueste, vom Hersteller unterstützte und als allgemein verfügbar deklarierte Version zu verwenden, in diesem Fall: RH JWS 64 oder RH JBoss EAP 85.	MUSS
TR-04	Laufzeitumgebung Auf der Grundlage des Betriebssystems wird eine gemeinsame Laufzeitumgebung als Abstraktionsschicht verwendet. Der Auftraggeber stützt sich ausschließlich auf das Java-Ökosystem. Ziel ist es, immer die neueste Version zu verwenden, die vom Hersteller unterstützt wird und als allgemein verfügbar deklariert ist, in diesem Fall: OpenJDK Long Term Support (LTS) 17. 6 Neben der Standard Edition (Java SE) wird auch die Spezifikation	MUSS

2 https://access.redhat.com/support/policy/updates/errata 3 https://www.postgresql.org/support/versioning/ 4 https://access.redhat.com/support/policy/updates/jboss_notes#p_jws 5 https://access.redhat.com/support/policy/updates/jboss_notes#p_eap 6 https://access.redhat.com/articles/1299013 14 29.07.2026 09:25

[Seite 16]

Anforderungen (Spezifikationen) EUginius 2.0

	der Jakarta Enterprise Edition (Jakarta EE) verwendet, in diesem Fall Jakarta EE Version 10. Eine Aktualisierung der Laufzeitumgebung während der Projektlaufzeit muss vom Auftragnehmer unterstützt werden.
TR-05	Format der Daten Textliche Informationen werden standardmäßig im UTF-8- Zeichenformat übertragen und gespeichert. Dies gilt insbesondere für: - Speicherung von Textinformationen in Datenbanken, - Speicherung von textlichen Informationen in der Anwendungskonfiguration, - Übertragung von Daten über die Webservice-Schnittstelle und die GUI-Schnittstelle.	MUSS
TR-06	IPv6-Kompatibilität der Webanwendung Die Webanwendung muss vollständig IPv6-fähig sein, um eine reibungslose Kommunikation in IPv6-Netzwerken zu gewährleisten. Das umfasst die Unterstützung der Verarbeitung und Speicherung von IPv6-Adressen, die Fähigkeit, über IPv6-basierte Netzwerke zu kommunizieren, sowie die Kompatibilität der zugrunde liegenden Infrastruktur wie Server und Netzwerke. Der Auftragnehmer muss vor der Einführung die Anwendung in einer IPv6-Umgebung testen, um Funktionalität und Sicherheit sicherzustellen.	MUSS

3.1.2. Zugangskontrolle und Sicherheitsanforderungen

In diesem Abschnitt werden die Sicherheitsanforderungen wie Verschlüsselungsmethoden (TLS), Validierungsmechanismen (Verhinderung von SQL-Injektionen), Kennwort-Hashing- Algorithmen, Authentifizierungsverfahren und die Einhaltung von Standards für sichere Kodierung beschrieben.

	Nr.			Beschreibung			Bewertung
TR-07			Unterstützung für TLS-Verschlüsselung - Die Anwendung muss über die Möglichkeit verfügen, Daten, die an der Nutzerschnittstelle zwischen der clientseitigen Anwendung (Webbrowser) und der serverseitigen Anwendung (Applikationsserver) ausgetauscht werden, verschlüsselt zu übertragen. Die Verschlüsselung muss zwischen der Anwendung und den Schnittstellen ebenfalls gewährleistet sein.			MUSS

15 29.07.2026 09:25

[Seite 17]

Anforderungen (Spezifikationen) EUginius 2.0

	- Die TLS-Verschlüsselung muss auch dann uneingeschränkt funktionieren, wenn Proxy-Server und Reverse-Proxy-Server beteiligt sind. - HTTPS auf der Grundlage von TLS muss als Verschlüsselungsmethode unterstützt werden.
TR-08	Eingabevalidierung und Verhinderung von SQL-Injections - Alle Eingabefelder müssen validiert werden, und bei der Implementierung der Webanwendung müssen Schutzmaß- nahmen gegen SQL-Injektion (vorbereitete Anweisungen und parametrisierte Abfragen) getroffen werden. Es müssen vorbereitete Anweisungen und parametrisierte Abfragen ver- wendet werden, um das Risiko einer SQL-Injektion zu verringern. - Die clientseitige Validierung im Browser ermöglicht es dem Nutzenden, Eingabefehler schnell zu erkennen und erhöht die Nutzerfreundlichkeit. Zur Gewährleistung der Sicherheit muss jedoch eine serverseitige Validierung erfolgen, da die clientseitige Validierung umgangen werden kann. - Bei der Validierung von Eingaben müssen erwartete Datentypen, Längenbeschränkungen und das Herausfiltern potenziell gefährlicher Zeichen überprüft werden.	MUSS
TR-09	Verschlüsselte Passwörter - Die Nutzerpasswörter müssen verschlüsselt und mit dem Hash- Verfahren "SSHA-512" (Salted Secure Hash Algorithm) gespeichert werden. - Passwörter dürfen nicht im Klartext gespeichert werden.	MUSS
TR-10	Verfahren zur Authentifizierung - Das System muss Authentifizierungsprotokolle wie LDAP, OpenLDAP und SSO (Single Sign-On) unterstützen und in diese integriert werden können, wobei bewährte Sicherheitspraktiken für ein zentralisiertes Identitätsmanagement und eine sichere Authentifizierung zu beachten sind. - Die Anwendung enthält bestimmte Bereiche, die sich in einem geschützten Bereich befinden und nur nach erfolgreicher Authentifizierung und Autorisierung zugänglich sind. Der Zugang zu bestimmten Bereichen der Anwendung muss über personalisierte Nutzernamen und Passwörter gesichert werden.	MUSS

16 29.07.2026 09:25

[Seite 18]

Anforderungen (Spezifikationen) EUginius 2.0

	- Starke Passwortrichtlinien und sichere Protokolle müssen in Übereinstimmung mit den Sicherheitsrichtlinien des Auftraggebers implementiert werden. Das System muss starke Authentifizierungsmechanismen und ein rollenbasiertes Zugangskontrollmodell implementieren, um sicherzustellen, dass der Nutzerzugang zu bestimmten Bereichen der Anwendung kontrolliert wird (siehe Abschnitt 4.2). Ein auf Red Hat Single Sign-On (RH-SSO) bzw. Red Hat build of Keycloak (RHBK) basierendes Authentifizierungsverfahren wird zur Verwaltung der Nutzerkonten und der für die Authentifizierung erforderlichen Anmeldeinformationen verwendet. Die Anbindung der Webanwendung an das vorhandene RHBK (Version 26) muss ermöglicht werden.
TR-11	Secure Coding Standards Die Anwendung muss die Secure Coding Standards einhalten, insbesondere die Secure Coding Guidelines for Java SE, um sicherzustellen, dass der Entwicklungsprozess gängige Sicherheitsschwachstellen und bewährte Verfahren berücksichtigt.	MUSS
TR-12	Schwachstellen und Sicherheitslücken Die Anwendung muss während der Entwicklung regelmäßig vom Auftragnehmer, spätestens alle drei Monate, auf Schwachstellen und Sicherheitslücken überprüft werden. Falls solche gefunden werden, müssen sie umgehend vom Auftragnehmer behoben werden.	MUSS

3.1.3. Anforderungen an die Anwendungsentwicklung

In diesem Unterabschnitt werden die Anforderungen an die Entwicklung der Anwendung EUginius 2.0 beschrieben und die Grundlagen für die Erstellung dieser festgelegt.

	Nr.			Beschreibung			Bewertung
TR-13			Webdienst-Schnittstelle und Protokolle Alle Webdienstaufrufe müssen als synchrone Aufrufe ausgeführt werden, so dass das System auf eine Antwort wartet, bevor es fortfährt. Dazu muss das SOAP- oder REST-Webdienst-Protokoll mit den nachfolgenden Bedingungen genutzt werden. - SOAP-Webdienst-Protokoll: Alle an der Webdienstschnittstelle bereitgestellten Webdienste werden auf der Grundlage des			MUSS

17 29.07.2026 09:25

[Seite 19]

Anforderungen (Spezifikationen) EUginius 2.0

	SOAP-Protokolls implementiert. XML muss als Nachrichtenformat und HTTPS als Transportprotokoll unterstützt werden. Die Struktur der XML-Request- und Response- Nachrichten muss durch eine WSDL definiert sein. Die Systemtests müssen nach Möglichkeit automatisch durchgeführt werden können. Sowohl für den Test der Nutzerschnittstelle als auch für den Test der Webservice-Schnittstelle sind geeignete und mit dem Auftraggeber abgestimmte Testwerkzeuge einzusetzen. Der Auftraggeber verwendet derzeit das Testwerkzeug "soapUI (siehe Internetlink; https://www.soapui.org/)" zum Testen von SOAP-basierten Schnittstellen. - REST-Webdienst-Protokoll: Bei Bedarf werden die Webdienste als REST-Webdienste implementiert, wobei XML oder JSON als Datenformat und HTTP/HTTPS als Transportprotokoll zu unterstützen sind. Im Rahmen der Entwurfsphase muss geklärt werden, welche Webservices als REST-Webservices bereitgestellt werden.
TR-14	Systemintegration und API-Schnittstellen - Das System muss spezifische API-Schnittstellen implementieren, um den Datenaustausch mit externen GVO- Datenbanken wie der BCH-Datenbank (Biosafety Clearing- House) und der JRC-Datenbank für GMO-Methoden zu erleichtern. - Die APIs müssen den Datentransfer auf sichere und effiziente Weise unterstützen und die von den externen Systemen geforderten Datenstandards und Protokolle einhalten.	MUSS
TR-15	Protokollierung und Ereignisverfolgung - Um die Ursachen von Störungen oder technischen Problemen zur Laufzeit leichter und schneller identifizieren zu können, muss die Anwendung in der Lage sein, das Laufzeitverhalten einschließlich der auftretenden Fehlersituationen bei Bedarf detailliert zu protokollieren. - Für die Protokollierung des Systemverhaltens muss ein standardisiertes Logging-Framework verwendet werden, das es erlaubt, den Umfang der zu protokollierenden Informationen gezielt über die Protokollierungsebene zu steuern.	MUSS

18 29.07.2026 09:25

[Seite 20]

Anforderungen (Spezifikationen) EUginius 2.0

	- Die Anwendung muss alle wichtigen Ereignisse protokollieren, die aus Sicht des Nutzenden oder des Betriebs von Bedeutung sind, wobei jedes Ereignis einer der folgenden Kategorien zugeordnet wird: Debug, Info, Warnung, Fehler. Die folgenden Ereignisse müssen protokolliert werden:  Start bzw. Beendigung der Anwendung (Info),  Aufzeichnung und Bearbeitung jedes Datensatzes (Debug),  Löschung jedes Datensatzes (Info),  alle internen Fehlersituationen: Ausnahmen, Konfigurations- fehler (Fehler), - Verbindungsprobleme mit der Datenbank (Warnung) - Für jeden Protokolleintrag müssen die folgenden Informationen aufgezeichnet werden:  Zeitpunkt (Datum bzw. Uhrzeit) des Auftretens des Ereignisses,  Kategorie des Ereignisses (Info, Warnung, Fehler),  Beschreibung des Ereignisses. - Bei Fehlern oder abnormalem Verhalten müssen Warnmeldungen ausgelöst werden, um eine schnelle Lösung zu ermöglichen.
TR-16	Qualitätsstandards für den Quellcode - Der Quellcode muss den folgenden Qualitätsanforderungen entsprechen, um Lesbarkeit, Verständlichkeit und langfristige Wartbarkeit sicherzustellen: - Der gesamte Quellcode muss den branchenüblichen Codierungskonventionen für Jakarta EE entsprechen. - Variablen, Funktionen und Klassen müssen sprechende, selbsterklärende Namen verwenden. - Jede öffentliche Funktion, Klasse und jedes Modul müssen mit einer klaren und vollständigen Kommentar-Struktur dokumentieren werden. Die Dokumentation muss Zweck, Eingabeparameter, Rückgabewerte und Ausnahmen beschreiben. Der Quellcode muss so kommentiert werden, dass Konfigurationsänderungen oder nachträgliche Anpassungen durch Dritte erleichtert werden.	MUSS

19 29.07.2026 09:25

[Seite 21]

Anforderungen (Spezifikationen) EUginius 2.0

	- Der Auftragnehmer muss statische Quellcode-Analyse-Tools verwenden, um Quellcode-Qualitätsprobleme zu erkennen und zu beheben. - Die Testabdeckung der Software muss bei 30 % liegen, das bedeutet, dass etwa ein Drittel der Funktionen durch Unit- und Integrationstests validiert werden. Dadurch wird eine gute Korrektheit und Stabilität des Quellcodes erwartet. - Es muss eine Versionskontrolle eingesetzt werden, bei der der Quellcode in einem Git-Repository gespeichert wird und regelmäßige Übertragungen vorgenommen werden, um Änderungen zu verfolgen. - Der Quellcode muss modular und auf Skalierbarkeit hin optimiert sein, so dass einzelne Komponenten der Anwendung unabhängig voneinander skaliert und erweitert werden können, ohne andere Teile des Systems zu beeinträchtigen. - Der Quellcode der Anwendung muss ressourceneffizient (Optimierung von CPU-, Speicher- und I/O-Verbrauch, durch unter anderem effiziente Algorithmen, Caching, Lazy Evaluation, Benchmark-basiertes Tuning und skalierbare Architektur) sein und den Einsatz von Rechenressourcen zur Bewältigung wachsender Arbeitslasten minimieren.
TR-17	Nachhaltigkeit in Entwicklung und Betrieb von Software Bei der Softwareentwicklung und -bereitstellung soll der CO - 2 Fußabdruck niedrig gehalten werden (z. B: durch die Verwendung von 100 % Strom aus erneuerbaren Energiequellen, stromsparende Prozesse, energieeffiziente Softwareprogrammierung).	SOLL

3.2. Datenbank-Management

In diesem Abschnitt werden die Datenbankstruktur, die erforderlichen Änderungen, die Datenintegrität und der Migrationsplan definiert.

3.2.1. Aktuelle Datenbankstruktur

Die Anwendung EUginius 2.0 wird die Altanwendung EUginius 1.0 vollständig ablösen. Die Internetadresse (https://www.euginius.eu) wird beibehalten. Das neue Datenbankmodell wird auf dem alten basieren, aber auch Änderungen beinhalten (siehe folgendes Kapitel). Die Anwendung EUginius 2.0 bzw. das neue Datenbankmodell muss weiterhin Informationen zur Beschreibung, zum Nachweis und zur Identifizierung von GVO in strukturierter Form bereitstellen und die Darstellung von sinnvollen Beziehungen zwischen den Daten ermöglichen.

20 29.07.2026 09:25

[Seite 22]

Anforderungen (Spezifikationen) EUginius 2.0

Das derzeitige Datenvolumen besteht aus ca. 1.000 GVO-Datensätzen einschließlich molekularer Charakterisierung(en), ca. 300 Methoden, > 450 Referenzmaterialien, > 250 EU- Anträge. Die Zunahme des Datenvolumens wird für die nächsten Jahre auf etwa 50 bis 200 GVO-Datensätze geschätzt. Die Migration wird voraussichtlich etwa 60.000 Datensätze, verteilt über ca. 60 Tabellen, umfassen.

Das aktuelle Datenbankmodell von EUginius 1.0 ist in Annex 1 “DatenbankModell_EUginius" (siehe Anhang) zu finden. Dieses Modell besteht aus sieben Hauptelementen: GMO, Composite-DNA, Method, Verification, Application, Thesaurus und Literature (siehe Abbildung 1 auf der nächsten Seite; die Farben in der Abbildung entsprechen der Farbgebung in Annex 1).

Abbildung1 . Entity-Relationship-Diagramm Im Folgenden wird jede Entität kurz beschrieben. Eine ausführliche Darstellung der Attribute der einzelnen Entitäten ist in der Annex 2 " Hauptentitäten" (siehe Anhang B_Annex 2_Hauptentitäten) zu finden.

GMO: Die GVO-Entität enthält Informationen über GVO wie Name, Unique Identifier (UID), Alias und Spezies. Des Weiteren werden Informationen, die im weitesten Sinne mit der Identität des GVO und dessen Präsenz auf dem Markt zusammenhängen, sofern vorhanden, für eine weitere Differenzierung aufgenommen. Dazu zählen beispielsweise die Transformationsmethode, veränderte Eigenschaften (Traits), der Produkteigentümer bzw. der Produktentwickler oder Lizenznehmer, der Produktname, der Zulassungsstatus in unterschiedlichen Ländern sowie Referenzmaterialien für den GVO-Nachweis.

21 29.07.2026 09:25

[Seite 23]

Anforderungen (Spezifikationen) EUginius 2.0

Composite DNA: Die Composite DNA-Entität beschreibt die strukturierte Kombination aller verfügbaren Informationen für die molekularbiologische Charakterisierung eines GVO. Sie dient der detaillierten Beschreibung und Kartierung der eingeführten oder veränderten Nukleinsäurefragmente (genetische Elemente) und ihrer spezifischen Sequenzen. Sie enthält Informationen über den Namen und den Typ der composite DNA (Insert für die tatsächlich eingefügten Nukleinsäurefragmente und Vektor für die zur Entwicklung verwendeten Nukleinsäurefragmente) sowie ihre Sequenzen.
Method: Die Entität gibt Auskunft über die Nachweismethoden, ihre Eigenschaften und ihre Ziele [GVO-Event, Konstrukt (konsekutive genetische Elemente), genetisches Element oder Spezies]. Sie bietet Unterstützung für den Nachweis oder die Identifizierung von GVO im Labor - dies umfasst insbesondere die Beschreibung der Nachweismethode und der verwendeten Oligonukleotide. Sie enthält Informationen wie: Name der Methode, Beschreibung, Nachweistyp [eventspezifisch, konstruktspezifisch, elementspezifisch, taxonspezifisch], Standardisierung, Validierungsstatus, Amplikon- und Oligoname und -sequenz und das Ziel der Methode je nach Nachweistyp.
Verification: Diese Entität verknüpft Methoden mit GVO und enthält den für jedes Paar spezifischen Verifizierungswert. Ein Verifizierungswert gibt einen Hinweis auf die Anwendbarkeit (-/+) und Zuverlässigkeit (1-3) der Methode für den Nachweis des GVO.
Application: Genehmigungsverfahren für GVO können für verschiedene Verwendungszwecke im Rahmen verschiedener Rechtsetzungsverfahren (einschließlich Mehrfachanträgen) angemeldet oder beantragt worden sein. Die entsprechenden Daten (Aktenzeichen, Antragsteller, Antragsstatus, Entscheidungsdatum, Rechtsvorschriften, beabsichtigter Verwendungszweck, Entscheidung) werden dem Zulassungsantrag zugeordnet. Die Entität “Application” wird nicht in der Anwendung EUginius 2.0 enthalten sein.
Thesaurus: Ein Thesaurus ist ein hierarchisch strukturiertes kontrolliertes Vokabular. Es gibt in der Webanwendung zwei Kategorien von Thesaurus: der Trait-Thesaurus für die Eigenschaften (Traits) und der DNA-Thesaurus für die genetische Elemente (Elements). Traits beziehen sich auf GVO und Elemente, und genetische Elemente beziehen sich auf Composite DNA und elementspezifische Methoden. Sowohl Traits als auch genetische Elemente können im Thesaurus bis zu vier Ebenen haben. Die Thesaurus- Entität enthält unter anderem Informationen über den Namen des Traits oder den Namen des genetischen Elements und ggf. die Synonyme, die Definition, die Funktion, die Spezies des Spenderorganismus des genetischen Elements, die entsprechende BCH- ID und die entsprechende Eigenschaft. Die Thesauri werden durch den Ontologie-Editor “OBO-Edit” als Textdateien generiert.
Literature: Die Entität "Literature" stellt relevante Veröffentlichungen und/oder andere Dokumente zusammen, die sich auf bestimmte Datenbankentitäten beziehen, darunter “GMO”, “composite DNA”, “Method”, “Application” und “Element”. Es enthält Zitierangaben (Autor, Titel, Veröffentlichungsjahr, Nummer des Kommissionsbeschlusses) und mehrere Klassifizierungskriterien (Publikationstyp, Inhaltstyp und Schlüsselwörter). 22 29.07.2026 09:25

[Seite 24]

Anforderungen (Spezifikationen) EUginius 2.0

3.2.2. Vorgeschlagene Änderungen an der Datenbank

Die Datenbank muss für die neue Anwendung angepasst werden. In diesem Unterabschnitt wird die Liste der Änderungen präsentiert, die an der bestehenden Datenbank vorgenommen werden müssen. Zusätzliche, als während der Entwicklung hilfreich angesehene, Datenbankänderungen können während der Sprints und im Rahmen des Pauschalfestpreises nach Absprache der Vertragsparteien aufgenommen werden (Beispiel dafür in untenstehender Tabelle kursiv dargestellt).

Zu entfernende Tabellen und Spalten:

Name der Tabelle	Name der Spalte	Beschreibung
ALL TABLES	CBIFIELDS	Entfernung der Spalte CBIFIELDS aus allen Tabellen
ABSTRACT_GMO	INSERTNUMBER	Entfernung der Spalte INSERTNUMBER
	TYPE	Entfernung der Spalte TYPE
ANNOTATEDSEQUENCE	NUMBEROFPARTS	Entfernung der Spalte NUMBEROFPARTS
APPLICANT		Entfernung der gesamten Tabelle
APPLICATION		Entfernung der gesamten Tabelle
APPLICATION_LITERATURE		Entfernung der gesamten Tabelle
APPLICATION2APPLICATION		Entfernung der gesamten Tabelle
APPLICATION2GMO		Entfernung der gesamten Tabelle
APPLICATION2USE2STATUS		Entfernung der gesamten Tabelle
COMPANY		Entfernung der Spalte COMPANY_COMMENT
COUNTRY		Entfernung der Spalte ZONE_ID
		Entfernung der Spalte EUROPE
DATARETRIEVALPROFILE		Entfernung der gesamten Tabelle
DEVELOPER		Entfernung der gesamten Tabelle
DNA_INTEGRATION_TYPE		Entfernung der gesamten Tabelle
DNAMAP		Entfernung der gesamten Tabelle
GMO_DEVELOPER		Entfernung der gesamten Tabelle
INTEGRATION		Entfernung der gesamten Tabelle
INTENDED_USE	TEXT	Entfernung der gesamten Tabelle
LEGISLATION		Entfernung der gesamten Tabelle
MATERIAL	MATERIAL_COMMENT	Entfernung der Spalte MATERIAL_COMMENT
MATERIALDESCRIPTION		Entfernung der gesamten Tabelle
PUBLICROLES		Entfernung der gesamten Tabelle
PUBLICUSER		Entfernung der gesamten Tabelle
PUBLICUSER_PUBLICROLE		Entfernung der gesamten Tabelle
REFERENCE		Entfernung der Spalte REFERENCE_COMMENT
RSSURL		Entfernung der gesamten Tabelle
SOURCE_PROVIDER	SOURCE_COMMENT	Entfernung der Spalte SOURCE_COMMENT
ZONE		Entfernung der gesamten Tabelle

Hinzuzufügende Tabellen und Spalten:

Name der Tabelle	Name der Spalte	Beschreibung
ABSTRACT_GMO	CATEGORY	Hinzufügen einer neuen Spalte CATEGORY zur Berücksichtigung von NGT-Kategorien. Diese Spalte muss sich

23 29.07.2026 09:25

[Seite 25]

Anforderungen (Spezifikationen) EUginius 2.0

Name der Tabelle	Name der Spalte	Beschreibung
		auf die Kategorien in der Tabelle GMO_CATEGORIES beziehen. Jeder GVO hat genau eine Kategorie.
GMO_CATEGORIES		Hinzufügen einer neuen Tabelle GMO_CATEGORIES, um die NGT-Kategorien für GE-GMO zu berücksichtigen. Diese Tabelle muss 2 Spalten haben: CATEGORY_NAME und CATEGORY_DESCRIPTION.
	CATEGORY_NAME	Die Spalte CATEGORY_NAME ist vom Typ VARCHAR2 und kann mehrere Werte haben, wie z. B. NGT1 (Kategorie 1), NGT2 (Kategorie 2) und GMO (klassisches GVO), usw.
	CATEGORY_DESCRIPTION	Die Spalte CATEGORY_DESCRIPTION ermöglicht es den Nutzenden, eine Beschreibung für jede Kategorie hinzuzufügen. Sie ist vom Typ VARCHAR2.
SPECIES	KINGDOM	Hinzufügen einer neuen Spalte KINGDOM, um die einzelnen Spezies (Arten) den entsprechenden Königreichen zuzuordnen. Diese Spalte muss sich auf die Königreiche in der Tabelle KINGDOM beziehen. Jede Art gehört zu genau einem Königreich.
KINGDOM		Hinzufügen einer neuen Tabelle KINGDOM, um Gruppen von Organismen zu berücksichtigen. Diese Tabelle muss 2 Spalten haben: KINGDOM_NAME und KINGDOM_DESCRIPTION.
	KINGDOM_NAME	Die Spalte KINGDOM_NAME ist vom Typ VARCHAR2 und kann mehrere Werte haben: PFLANZEN, TIERE, MIKROORGANISMEN, usw.
	KINGDOM_DESCRIPTION	Die Spalte KINGDOM_DESCRIPTION ermöglicht es den Nutzenden, jedem Königreich eine Beschreibung hinzuzufügen, und ist vom Typ VARCHAR2.
ANNOTATED_SEQUENCE	SEQUENCE_NAME	Hinzufügen einer Spalte SEQUENCE_NAME vom Typ VARCHAR2. Der Name der Sequenz wird automatisch nach Konvention generiert, z. B.: gmo_origine_type_timestamp
	ELEMENTS_REFERENCE	Hinzufügen einer Spalte ELEMENTS_REFERENCE, die auf die Spalte REFERENCE_NAME in der Tabelle REFERENCE verweist, um die Referenz der platzierten genetischen Elemente der annotierten Sequenz hinzuzufügen.
	SEQUENCE_TECHNIQUE	Hinzufügen einer SEQUENCE_TECHNIQUE, um die Technik jeder Sequenz zu definieren. Diese Spalte soll auf die Tabelle SEQUENCE_TECHNIQUE verweisen. Jede Sequenz ist mit einer Technik verbunden.
	SEQUENCE_TYPE	Hinzufügen einer Spalte SEQUENCE_TYPE, um den Typ der einzelnen Sequenzen zu definieren. Diese Spalte soll auf die Tabelle SEQUENCE_TYPE verweisen. Jede Sequenz ist mit einem Typ verbunden.
SEQUENCE_TECHNIQUE		Hinzufügen einer neuen Tabelle SEQUENCE_TECHNIQUE, um die Sequenztechniken aufzunehmen. Diese Tabelle soll eine Spalte TECHNIQUE_NAME haben.
	TECHNIQUE_NAME	Die Spalte TECHNIQUE_NAME ist vom Typ VARCHAR2 und kann mehrere Werte haben: SBS MISEQ, SBB PACBIO SEQUELL II, usw.
SEQUENCE_TYPE		Hinzufügen einer neuen Tabelle SEQUENCE_TYPE, um die Sequenznamen aufzunehmen. Diese Tabelle soll eine Spalte TYPE_NAME haben.
	TYPE_NAME	Die Spalte TYPE_NAME ist vom Typ VARCHAR2 und kann mehrere Werte haben: CDNA, RNA, usw.
GMO2LIGHT2COUNTRY	DECISION_DATE	Hinzufügen einer Spalte DECISION_DATE vom Typ DATE. Sie stellt das Datum der Zulassungsentscheidung für jede Verwendungskategorie jedes GVO dar.
	EXPIRY_DATE	Hinzufügung einer Spalte EXPIRY_DATE des Typs DATE. Diese Spalte gibt das Ablaufdatum der Zulassung für jede Verwendungskategorie jedes GVO an. Das EXPIRY_DATE wird auf 10 Jahre minus einen Tag ab dem DECISION_DATE festgelegt.

Zu ändernde Tabellen und Spalten:

Name der Tabelle Spalte Name Beschreibung

24 29.07.2026 09:25

[Seite 26]

Anforderungen (Spezifikationen) EUginius 2.0

ABSTRACT_GMO	OECDID	Änderung des Spaltennamens in: UID
	GMO_COMMENT	Ändern Sie den Spaltennamen in: INTERNAL_COMMUNICATION
ANNOTATEDSEQUENCE	ACCESSIONNUMBER	Änderung des Spaltennamens in: SEQUENCE_SOURCE. Diese Spalte sollte einen Link zu der Sequenz aus der Referenz enthalten, falls zutreffend, und nicht die Hinterlegungsnummer
PRIVATEROLES PRIVATEUSER PRIVATEUSER_PRIVATEROL E ACT_HI_ACTINST ACT_HI_TASKINST ACT_HI_PROCINST ACT_HI_DETAIL DATACHANGERECORD DATAENTRY_CHANGE ACT_RE_DEPLOYMENT ACT_GE_PROPERTY ACT_GE_BYTEARRAY ACT_RE_PROCDEF ACT_RU_VARIABLE ACT_RU_EXECUTION ACT_RU_TASK ACT_RU_IDENTITY_LINK ACT_ID_MEMBERSHIP ACT_ID_GROUP ACT_ID_USER ACT_ID_INFO ACT_HI_COMMENT ACT_HI_ATTACHEMENT ACT_RU_JOB ACT_RE_EVENT_SUBSCR		In diesen Tabellen werden Informationen über die Änderungshistorie (Änderungsdatensatz, Dateneingabe- status, Änderungsdatum, Nutzerkennung usw.), den Überprüfungsprozess und Details zu Nutzenden, Rollen und Berechtigungen gespeichert. Änderungen an der Struktur oder dem Inhalt dieser Tabellen können nach Gesprächen mit dem Auftragnehmer vorgenommen werden, um neue Rollen/Berechtigungen oder Aktualisierungen des Überprüfungsprozesses und der Dateneingabeanforderungen zu berücksichtigen.
COMPOSITEDNA	DNA_FUNCTION	Änderung des Spaltennamens in: INTERNAL_COMMUNICATION
	DNA_NAME	Änderung des Spaltennamens in: NAME
	DNA_COMMENT	Änderung des Spaltennamens in: COMMENT
GMO2LIGHT2COUNTRY	STATUS_CATEGORY	Verknüpfung der Spalte STATUS_CATEGORY mit der Tabelle STATUS
	USE_CATEGORY	Bezug der Spalte USE_CATEGORY auf die Tabelle INTENDED_USE
LITERATURE	LIT_COMMENT	Änderung des Spaltennamens in: INTERNE_KOMMUNIKATION
MATERIAL	EXTRA_COMMENT	Änderung des Spaltennamens in: MATERIAL_COMMENT
	GMO_ID	Die Beziehung zwischen GVO und Referenzmaterialien ist n zu n für "Blanks". Es müssen Änderungen vorgenommen werden, um dieser neuen Randbedingungen Rechnung zu tragen.
METHOD	COMMUNICATION	Ändern Sie den Spaltennamen in: INTERNAL_COMMUNICATION
	STANDARDISATION	Eine Methode kann mit 0 bis n Standards in Verbindung gebracht werden. Es müssen Änderungen vorgenommen werden, um diese neue Randbedingungen zu berücksichtigen.
METHOD_TARGET		Es müssen Änderungen vorgenommen werden, um diese beiden neuen Randbedingungen zu berücksichtigen: - Wenn die Methode taxonspezifisch ist, kann das Ziel 1 bis n Spezies sein und nicht nur eine Spezies, wie es jetzt in EUginius 1.0 der Fall ist. - Wenn die Methode konstruktspezifisch ist, können als Ziel, zusätzlich zur Liste der GVO, 2 genetische Zielelemente angegeben werden
THESAURUS	OBO_TRAIT_ID	Ändern Sie den Spaltennamen in: OBO_ID
	TRAIT_ID	Ein Thesaurus Element kann mit mehr als einem TRAIT in verknüpft werden. Es sollen Änderungen vorgenommen werden, um dieser neuen Randbedingung Rechnung zu tragen
VERIFICATION	VERIFICATION_COMMENT	Ändern Sie den Spaltennamen in: INTERNAL_COMMUNICATION

25 29.07.2026 09:25

[Seite 27]

Anforderungen (Spezifikationen) EUginius 2.0

3.2.3. Datenintegrität und Migrationsplan

Die weiterhin erforderlichen Altdaten müssen vollständig in das neue System migriert werden. Die oben genannten Anpassungen und Änderungen an der Datenbank-Struktur müssen berücksichtigt werden. Der Datenintegritäts- und Migrationsplan beschreibt die Methodik und den Prozess für die Änderung der bestehenden Datenbank und die Migration der Daten in die neue Struktur, wobei sichergestellt wird, dass die Datenintegrität bei minimalem Risiko eines Datenverlusts oder einer Systemunterbrechung erhalten bleibt. In diesem Abschnitt werden die Schritte definiert, mit denen die notwendigen Datenbankänderungen vorgenommen, die Migration durchgeführt und die Richtigkeit und Konsistenz der Daten während des gesamten Prozesses überprüft werden.

Übersicht über die Datenbankmodifikation:

Vor der Migration muss der Auftragnehmer die bestehende Datenbankstruktur analysieren, um Dateninkonsistenzen auszuschließen bzw. Abhängigkeiten von Altdaten zu ermitteln. Die in Abschnitt 3.2.2 beschriebenen Datenbankänderungen müssen dann durch den Auftragnehmer entworfen und dokumentiert werden:

 Datenbankschema-Diagramm: Zur Darstellung der geplanten Änderungen an den Datenbanken wird ein aktualisiertes Datenbankschema-Diagramm erstellt. Dieses Diagramm stellt die an den Tabellen, Spalten und Beziehungen vorgenommenen Änderungen visuell dar und hilft dem Team, die Struktur der aktualisierten Datenbank zu visualisieren. Der Auftraggeber verlangt, dass die Daten- und Prozessmodellierung mit UML (Unified Modelling Language) durchgeführt wird.

 Änderungsprotokoll: Ein detailliertes Änderungsprotokoll wird vom Auftragnehmer geführt, in dem jede Änderung, einschließlich des Grundes für die Änderung, der betroffenen Tabellen oder Spalten und der entsprechenden Aktualisierungen, festgehalten wird. Dieses Änderungsprotokoll stellt sicher, dass die Änderungen transparent sind und für spätere Zwecke nachvollzogen werden können. Das Änderungsprotokoll wird dem Auftraggeber digital zur Verfügung gestellt.

 SQL-Skripte: SQL-Skripte werden durch den Auftragnehmer entwickelt und getestet, um die Änderungen in der Datenbank zu übernehmen und korrekt auszuführen.

 Genehmigungsverfahren: Es wird sichergestellt, dass alle Änderungen von den Vertragsparteien geprüft und vom Auftragsgeber genehmigt werden, bevor mit der Implementierung fortgefahren wird.

Migrationsprozess:

Der Migrationsprozess umfasst mehrere Phasen, darunter Datenzuordnung, -extraktion, - umwandlung und -laden, mit dem Ziel, die Datenintegrität sicherzustellen.

 Datenzuordnung und -umwandlung: Dieser Schritt stellt sicher, dass die Daten korrekt an das neue Datenbankschema angepasst werden und dass die Integrität der Daten während der Anpassung an die neue Struktur erhalten bleibt. Weitere Informationen und

26 29.07.2026 09:25

[Seite 28]

Anforderungen (Spezifikationen) EUginius 2.0

Details zum Daten-Mapping und zur Migration werden in den Sprint-Phasen ausführlich besprochen.

 Migrationsschritte: Die Migrationsschritte ermöglichen die Übertragung der Daten aus dem alten System in das neue System. Dazu gehört ein sorgfältiger ETL-Prozess der Datenextraktion aus der bestehenden Datenbank, der Datentransformation zur Anpassung an die Struktur und die Einschränkungen der neuen Datenbank und das Einspielen der transformierten Daten in die neue Datenbank.

Integritätsüberprüfung und Validierung:

Um die Korrektheit der Migration zu gewährleisten, müssen die folgenden Prüfungen vom Auftragnehmer konzipiert und durchgeführt werden:  Datensatz-Validierung: Überprüfung, ob die richtige Anzahl von Datensätzen übertragen wurde und ob keine Daten fehlen.  Einschränkungsüberprüfung (Constraints verification): Sicherstellen, dass alle Primärschlüssel, Fremdschlüssel, eindeutige Beschränkungen und andere Integritätsbeschränkungen in der neuen Datenbank beibehalten werden.  Konsistenz-Prüfungen: Identifizieren und Korrigieren von Inkonsistenzen, wie verwaiste Datensätze, doppelte Einträge oder ungültige Beziehungen.

Nach der Migration müssen diese Prüfungen vom Auftragnehmer durchgeführt werden, um die Integrität und Leistungsfähigkeit der Daten in der neuen Datenbank zu überprüfen und zu bestätigen, dass keine Daten verloren gegangen sind oder beschädigt wurden und dass alle Beziehungen erhalten geblieben sind.

4. Funktionale Anforderungen

Die neue Webanwendung wird das Altsystem ersetzen. Die Anwendung EUginius 2.0 soll Funktionalitäten bieten, die es den Nutzenden ermöglichen, unterschiedliche Fragestellungen zu untersuchen und zu beantworten und so die Erlangung wichtiger Erkenntnisse über GVO zu unterstützen. Sie soll eine effiziente und sichere Verwaltung von Nutzerrollen und - berechtigungen, Dateneingabe- und Überprüfungsprozessen sowie weiteren Webanwendung Features bieten. In diesem Abschnitt werden der Fragenkatalog und die wichtigsten funktionalen Anforderungen an die Webanwendung beschrieben. Die Anwendung EUginius 2.0 muss den Nutzenden folgendes ermöglichen:

Nutzerverwaltungsfunktionen zu aktivieren (z. B. Registrierung, Anmeldung, Passwortwiederherstellung).
Systeminhalte zu verwalten, wie z. B. das Hinzufügen, Aktualisieren und Löschen von Datensätzen.
Suche und Abfrage der Datenbank mit Hilfe mehrerer Filter (z. B. GMO name, species, genetic element, verification method, target).
Zugang zu detaillierten Aufzeichnungen über GVO und den damit verbundenen Daten.
Unterstützung erweiterter Funktionalitäten in den Modulen “Detection” und “Analysis Tool”.
Erstellung und Export von Berichten.

27 29.07.2026 09:25

[Seite 29]

Anforderungen (Spezifikationen) EUginius 2.0

Im Folgenden werden der Fragenkatalog und die einzelnen Funktionalitäten näher erläutert.

4.1. Fragenkatalog

Der folgende Fragenkatalog enthält einige beispielhafte Kernfragen (ohne Anspruch auf Vollständigkeit oder Ausschließlichkeit) und Aktionen, die die Nutzenden mit Hilfe von EUginius abfragen oder durchführen.

1	Wie viele "MON-"GVOs gibt es in der DB?
2	Welche GVOs der Firma “x” enthalten ein Element der Gruppe “CS-crystal delta- endotoxin”?
3	Welche Elemente sind in dem GVO “x” enthalten?
4	Welches sind die zugelassenen GVO - der Spezies "x"? Was sind die zugelassenen Produktkategorien und die Eigenschaften (Traits) des jeweiligen GVO? - mit dem genetischen Element “z”/ mit den genetischen Elementen “x“ und „y“?
5	Wie ist der genetische Aufbau von GVO “x“?
6	Welche Informationen hält die Datenbank zu dem GVO „x“ vor?
7	Gibt es Informationen über die in der GVO-Insertion enthaltenen Elemente?
8	Welche GVOs enthalten das genetische Element „x“?
9	Welche sind die GVO, die das Element “x” enthalten? Welchen Zulassungsstatus haben diese GVO in der EU /ggf. außerhalb der EU?
10	Wo finde ich weiterführende Informationen zu dem GVO „x“?
11	Welche GVOs sind als Lebensmittel in der EU zugelassen?
12	Ist ein bestimmter GVO in der EU zugelassen? Für welche Verwendungszwecke?
13	Welche Zulassungen wurden vor/nach dem Datum dd.mm.yyyy erteilt
14	Welche Zulassungen laufen vor/nach dem Datum dd.mm.yyyy aus?
15	Welche EU-Zulassungsentscheidung gibt es für GVO "x"?
16	Welche Sequenzen von GVO der Spezies “x” und “y” sind in der Datenbank verfügbar?
17	Gibt es annotierte Sequenzen zu dem GVO „x“?
18	Was ist das Referenzgenome, dass der GVO Sequenz entgegen steht?
19	Welche Methode(n) kann ich anwenden, um GVO “x“ nachzuweisen?
20	Mit welcher Methode weise ich ganz spezifisch den GVO „x“ nach?
21	Gibt es eine Nachweismethode für Spezies “w” / Element “x” / Konstrukt ”y” ?
22	Welche GVO werden von meinem Screening-Ansatz nicht erfasst? - Ergebnis soll GVO anzeigen, in der die GVO nach Organismen gelistet sind - Nachträgliche Erweiterung der Suchanfrage: Hinzufügen von weiteren Methoden, die für ein weiteres Screening geeignet sein könnten
23	Welche GVO können mit dieser Methode nachgewiesen werden? Bei welche GVO wurde die Methode experimentell bestätigt?
24	Wird der GVO "x" von der elementspezifischen Methode "y" erfasst?
25	Gibt es Screening-Methoden zur Unterscheidung zwischen GVO "x" und "y"?
26	Besteht die Möglichkeit, dass in meiner Probe ein zugelassener GVO enthalten ist, wenn die PCR-Targets “x“, “y“ und “z“ nachgewiesen wurden?
27	Welcher GVO befindet sich in meiner Probe angesichts der experimentell- nachgewiesenen PCR-Targets?
28	Welches sind die neuesten GVO/Methoden, die in der DB eingetragen sind?
29	Welche Einträge sind neu seit "Datum"?
30	Ich möchte die Informationen aus der GVO Detail-Seite (Tabellen) exportieren. Ich möchte GVO Sequenzen exportieren.

28 29.07.2026 09:25

[Seite 30]

Anforderungen (Spezifikationen) EUginius 2.0

31	Ich möchte alle gefilterte GVO-Einträge exportieren.
32	Ich möchte ausgewählte Sequenzen von GVO der Spezies “x” und “y” im ausgewählten Format exportieren.
33	Ich möchte alle GVO Sequenzen einfach herunterladen.

4.2. Nutzerrollen und Dateneingabe

In diesem Abschnitt werden die verschiedenen Nutzerrollen innerhalb der Webanwendung und die entsprechenden Berechtigungen, insbesondere in Bezug auf die Dateneingabe und - änderung, definiert (funktionale Anforderungen (FA)). Darin sind die Zuständigkeiten und Zugriffsebenen für die einzelnen Rollen festgelegt, um sicherzustellen, dass der Prozess des Hinzufügens, Aktualisierens und Überprüfens von Daten sicher und effizient durchgeführt wird. Der Review-Prozess, der eine rollenbasierte Überprüfung beinhaltet, ist ein entscheidender Aspekt für die Gewährleistung der Datenqualität und -integrität und wird durch das Sechs- Augen-Prinzip geregelt.

4.2.1. Nutzerrollen und Berechtigungen

Die Anwendung EUginius 2.0 muss verschiedene Nutzerrollen unterstützen, die jeweils mit spezifischen Berechtigungen ausgestattet sind. Diese Rollen regeln den Zugang zu verschiedenen Teilen der Anwendung. Registrierten Nutzenden werden über das SSO Rechte entsprechend ihrer Rolle zugewiesen.


Externe Stakeholder Externe Stakeholder sind Nutzende, die nur Lesezugriff auf Daten oder bestimmte Bereiche der GVO-Datenbank benötigen. Sie können alle Daten im öffentlichen Bereich einsehen, einschließlich der Suche, der Abfrage und des Zugriffs auf Links zu detaillierten Datensätzen, haben aber keinen Zugriff auf die Dateneingabe, ergänzende Daten und zusätzliche Funktionen.	NEIN	MUSS
Partner (Rolle: Authorised) Partner (wie z. B. offizielle GVO-Kontrolllabore) sind Nutzende, die Zugang zu eingeschränkten Bereichen innerhalb der Anwendung haben können (z. B. zu bestimmten Sequenzen, siehe FA-26 „vertrauliche Sequenzen“).	JA	KANN
User Manager (Rolle: Useradmin) Nutzermanager sind für die Verwaltung von Nutzerkonten zuständig. Sie können wichtige Aufgaben wie das Erstellen, Ändern und Löschen	JA	MUSS

29 29.07.2026 09:25

[Seite 31]

Anforderungen (Spezifikationen) EUginius 2.0

	Beschreibung			Registriert			Bewertung
von Nutzerkonten sowie die Zuweisung von Rollen und Berechtigungen durchführen.
Database Operator (Rolle: Data_Entry) Datenbankoperatoren sind für die Verwaltung der Dateneingabe zuständig. Datenbankoperatoren haben vollen Zugriff auf die Dateneingabe, -aktualisierung und -löschung und sind berechtigt, den Überprüfungsprozess (Review) zu starten.			JA			MUSS

Expert (Rolle: Review_Expert) JA MUSS

Experten haben die höchste Zugriffsebene innerhalb des Systems. Zusätzlich zu den Dateneingabeaufgaben stellen Experten sicher, dass Änderungen nach dem sechs-Augen-Prinzip überprüft werden. Es gibt zwei Kategorien von Experten, die Experten aus zwei verschiedenen Institutionen entsprechen (WFSR - Experten und BVL - Experten). Eingaben oder Änderungen, die von anderen Nutzenden vorgenommen werden, müssen von zwei Experten aus unterschiedlichen Kategorien überprüft werden. Die Experten haben das Recht, die zu überprüfenden Datensätze zu akzeptieren oder sie abzulehnen und damit den Review-Prozess abzubrechen (siehe Abschnitt 4.2.4).

4.2.2. Nutzerverwaltung (Registrierung, Anmeldung, Passwortwiederherstellung)

Das System muss sichere Nutzerregistrierungs-, Anmelde- und Passwortwiederherstellungsfunktionen unterstützen, um einen autorisierten Zugang zur Webanwendung zu gewährleisten. Die folgenden funktionalen Anforderungen (FA) gewährleisten die Zugänglichkeit und Konformität des Systems:

	Nr.			Beschreibung			Bewertung
FA-01			Nutzerverwaltung - Die Anwendung muss es Nutzermanagern ermöglichen, Nutzerkonten und Berechtigungen (siehe Abschnitt 4.2.1) über einen sicheren Registrierungsprozess zu erstellen. - Die Nutzenden müssen sich mit ihren personalisierten Nutzernamen und Passwörtern anmelden können, um Zugang zu bestimmten Bereichen der Anwendung zu erhalten.			MUSS

30 29.07.2026 09:25

[Seite 32]

Anforderungen (Spezifikationen) EUginius 2.0

	Nr.			Beschreibung			Bewertung
			- Die Nutzenden müssen in der Lage sein, ihre Passwörter auf sichere Weise zurückzusetzen. Die für die Authentifizierung erforderlichen Nutzerkonten und Anmeldedaten werden nicht in der Anwendung verwaltet, sondern in einem bereits bestehenden System, dem RH-SSO des Clients. - Verschiedene Nutzerrollen (z. B. externe Stakeholder, Datenbankoperatoren, Experten) müssen je nach ihrer Rolle unterschiedliche Zugriffsrechte haben.

4.2.3. Dateneingabe und -aktualisierung

Das „Data Entry”-Modul ist eine wichtige Komponente der Webanwendung, die speziell für den internen Verwaltungsgebrauch entwickelt wurde. Es dient als primäre Schnittstelle für Nutzende mit den entsprechenden Rechten im „Data Entry“-Bereich zur Verwaltung der zugrundeliegenden Datenbankinhalte, auf denen die öffentlich zugängliche Anwendung basiert. Mit diesem Modul können Datenbankoperatoren strukturierte Daten zu verschiedenen Entitäten wie GMO, Method, Thesauri, Literature und anderen relevanten Datensätzen leicht erstellen, aktualisieren und verwalten und dabei strenge Validierungs- und Integritätsregeln durchsetzen.

Während sich die öffentliche Schnittstelle auf die Visualisierung und Durchsuchbarkeit der Daten konzentriert, muss die Schnittstelle für die Dateneingabe robuste und nutzerfreundliche Datenverwaltungswerkzeuge unterstützen. Die Funktionalität muss modular und sicher sein, wobei der Schwerpunkt auf der Datenintegrität, der Validierung und der Nutzerfreundlichkeit liegt. Die in diesem Modul erforderlichen Funktionalitäten sind in der folgenden Tabelle aufgeführt.

	Nr.			Beschreibung			Bewertung
FA-02			Modularer Aufbau und Navigation - Der Dateneingabereich muss modular aufgebaut sein, wobei jede Einheit einer bestimmten Entität in der Datenbank entspricht (z. B. GMO, Thesaurus, Method, usw.). Jede Einheit muss über eine übersichtliche Seitenleiste oder ein oberes Navigationsmenü innerhalb des Dateneingabe-Dashboards zugänglich und mit der entsprechenden Dateneingabeschnittstelle verknüpft sein. Innerhalb jeder Schnittstelle müssen die folgenden Standardkomponenten implementiert sein:  eine Listenansicht zum Durchsuchen und Auswählen vorhandener Datensätze,			MUSS

31 29.07.2026 09:25

[Seite 33]

Anforderungen (Spezifikationen) EUginius 2.0

	Nr.			Beschreibung			Bewertung
			 eine Formularansicht zum Erstellen oder Bearbeiten von Datensätzen (siehe FA-03),  ein Vergleichspanel zur Anzeige früherer Daten während der Bearbeitung (siehe FA-04). - Das System muss die Möglichkeit bieten, Texte, Bilder und Links auf verschiedenen Seiten zu bearbeiten (Homepage, News, about the partners, GMO-related Webpages, usw.).
FA-03			Formularbasierte Dateneingabe - Jede Schnittstelle für die Dateneingabe umfasst eine spezielle formularbasierte Schnittstelle für das Hinzufügen und Aktualisieren von Daten. Für komplexe Entitäten wie GMO und Method muss das Formularlayout mit gruppierten Feldern für logische Kategorien (z. B. allgemeine Informationen, verwandte Daten) strukturiert sein. Diese Felder werden nach Datentyp oder Funktionalität gruppiert und mit klaren Überschriften und einer klaren Navigation versehen, um die Datenbankoperatoren bei der effizienten Eingabe und Überprüfung von Daten durch einen logischen Datenfluss zu unterstützen. - Das System muss einen Datenerfassungsassistenten mit mehreren Datenmanagementfunktionen je nach Datenverarbeitungsphase bieten, wie z. B. Erstellen, Abbrechen, Speichern, Löschen von Datensätzen, Starten der Überprüfung (Review) usw. - Es müssen verschiedene Eingabearten unterstützt werden, wie z. B.:  Textfelder (z. B. für ein- und mehrzeilige Beschreibungen) mit der Möglichkeit, Links sowie Formatierungs- und Vorschauoptionen einzubinden,  Dropdowns und Multiselect-Listen für verknüpfte Entitäten,  Kontrollkästchen und Kippschalter für boolesche Werte,  Datumspicker für Datumsfelder,  Dateieingaben für beliebige Anhänge oder Bilder. - Dateneingabeformulare müssen die Direkterstellung von Bezugsdatensätzen unterstützen, damit Nutzende neue Daten zu verknüpften Entitäten direkt im Kontext des aktuellen Formulars hinzufügen können, ohne zu separaten Formularen für die Bezugsdaten navigieren zu müssen (z. B. wenn die erforderlichen Informationen nicht in der Dropdown-Liste			MUSS

32 29.07.2026 09:25

[Seite 34]

Anforderungen (Spezifikationen) EUginius 2.0


	vorhanden sind). Dadurch wird der Dateneingabeprozess schneller und reibungsloser, da die Anzahl der Formularwechsel minimiert wird. - Das System muss die automatische Dateneingabe auf der Grundlage der in die Eingabefelder eingegebenen Werte unterstützen. Diese Funktionalität minimiert die manuelle Eingabe durch den Nutzenden, wodurch die Effizienz verbessert und die Wahrscheinlichkeit von Fehlern oder Auslassungen verringert wird:  Wenn ein übergeordnetes Element innerhalb der Thesaurus-Hierarchie mit einem bestimmten Datensatz, z. B. einer Methode, verknüpft ist, müssen alle untergeordneten Elemente diese Verknüpfung erben. Mit anderen Worten: Wenn eine bestimmte Assoziation für einen übergeordneten Knoten gilt, gilt sie automatisch auch für alle seine Nachkommen. Der umgekehrte Fall trifft jedoch nicht zu (d. h. die Assoziation eines Kindelements impliziert nicht dasselbe für sein Elternteil).  Einige “Verification” Werte müssen der Grundlage der verfügbaren Informationen automatisch in die GVO/Methoden-Matrix aufgenommen werden können (z. B. indem die Werte für eventspezifische Methoden auf +3 gesetzt werden).
FA-04	Vergleichspanel - Bei der Bearbeitung eines bestehenden Datensatzes muss das System einen Seite-an-Seite-Vergleich anzeigen:  die aktuellen Daten (rechts schreibgeschützt),  die bearbeitbaren Felder auf der linken Seite für neue Werte. Mit dieser Funktion kann der “Expert” Nutzende klar erkennen, was sich geändert hat, bevor er die Aktualisierung bestätigt, wodurch Fehler vermieden werden.	MUSS
FA-05	Datenintegrität und -validierung - Das System muss Plausibilitätsprüfungen für alle Eingaben vorsehen. Während der Dateneingabe validieren die Felder die Eingaben in Echtzeit und geben sofort eine Rückmeldung, wenn der Nutzende einen Fehler macht (z. B. eine falsch formatierte Zahl oder fehlende Pflichtfelder).	MUSS

33 29.07.2026 09:25

[Seite 35]

Anforderungen (Spezifikationen) EUginius 2.0

	Nr.			Beschreibung			Bewertung
			- Es muss möglich sein, Sequenzen in verschiedenen Dateiformaten (z. B. FASTA, FASTQ, GFF) hochzuladen. Nach dem Upload von Sequenzen wird eine Plausibilitätsprüfung durchgeführt, ob das Korrekte Format eingehalten wird. - Felder, die obligatorisch sind, werden deutlich mit einem Sternchen (*) und einem visuellen Hinweis (z. B. einem roten Rahmen) gekennzeichnet, wenn sie leer bleiben. - Tooltips oder Online-Hilfen werden neben Feldern angezeigt, die zusätzliche Anweisungen erfordern. - Eingabemasken müssen auf alle Formularfelder angewendet werden, die bestimmte Datenformate erfordern. Die Maske muss im Feld visuell dargestellt werden und den Nutzenden bei der Eingabe leiten. - Die Anzahl der Eingabemasken muss optimiert werden, um den Aufwand für die Eingabe und Überprüfung der Daten zu verringern. - Bei Einträgen mit Beziehungen zwischen Entitäten (z. B. GVO, die mit Methoden verknüpft sind) müssen Dropdowns oder Autovervollständigungen verwendet werden, die aus verwandten Tabellen gezogen werden, um die Effizienz zu verbessern und Datendopplungen zu vermeiden. - Die Nutzeroberfläche müssen intuitiv und die Validierungsmeldungen nutzerfreundlich und spezifisch sein. - Wenn ein Nutzender versucht, einen Eintrag zu löschen, der mit anderen Daten verknüpft ist, muss das System das Löschen verhindern und eine deutliche Warnmeldung anzeigen. Außerdem muss dem Nutzenden eine Tabelle angezeigt werden, in der nur die verknüpften Daten aufgeführt sind, die das Löschen blockieren, und die angibt, welche Daten zuerst entfernt werden müssen, bevor der aktuelle Eintrag gelöscht werden kann.
FA-06			Import großer Datenmengen (Bulk Import) - Für Abschnitte, in denen große Datenmengen verarbeitet werden (z. B. Verification), muss das System die Massen- Datenerfassung unterstützen, indem es den Nutzenden ermöglicht, Excel-Dateien hochzuladen.			MUSS

34 29.07.2026 09:25

[Seite 36]

Anforderungen (Spezifikationen) EUginius 2.0


	- Der Datenbankoperator wählt eine Excel-Datei aus und lädt sie über eine Drag-and-Drop- oder Dateiauswahl-Schnittstelle hoch. - Es muss eine Vorlagedatei heruntergeladen werden können, um sicherzustellen, dass der Datenbankoperator die richtige Struktur verwendet. - Nach dem Parsen der Datei prüft das System auf mögliche Datenprobleme (z. B. fehlende Pflichtfelder, ungültige Werte). Der Importprozess muss Prüfungen auf doppelte Einträge anhand von Schlüsselfeldern umfassen. - Fehler müssen durch eindeutige Meldungen hervorgehoben werden. - Der Datenbankoperator erhält die Möglichkeit nach der Fehlerbehebung eine korrigierte Datei erneut hochladen. - Sobald die Daten überprüft sind, bestätigt der Datenbankoperator den Upload. Das System führt dann eine Batch-Einfügung bzw. Aktualisierung mit vollständiger Datenvalidierung durch. - Nach dem Import muss ein zusammenfassender Bericht angezeigt werden, der angibt, wie viele Zeilen hinzugefügt, aktualisiert, übersprungen oder fehlgeschlagen sind. - Ein umfangreiches sechs-Augen-Prinzip darf beim Import großer Datenmengen vermieden werden.
FA-07	Thesaurus - Eine Datei, die alle Daten eines Thesaurus enthält, muss herunterladbar sein. Der Datenbankoperator kann dann die Datei aktualisieren und sie über eine Drag-and-Drop- oder eine Dateiauswahl-Schnittstelle hochladen. - Wie beim Bulk Import prüft das System nach dem Parsen der Datei auf mögliche Probleme und weist mit klaren Meldungen auf Fehler hin.	MUSS
FA-08	Open Changes In dem Dateneingabemodul bietet die Tabelle der Open Changes einen umfassenden Überblick über alle aktuell erstellten und in Bearbeitung befindlichen Dateneinträge. - Die Übersicht muss klare Strukturen aufweisen, damit der Status der Dateneinträge schnell erkannt werden kann.	MUSS

35 29.07.2026 09:25

[Seite 37]

Anforderungen (Spezifikationen) EUginius 2.0

	Nr.			Beschreibung			Bewertung
			- Die Tabelle der Open Changes muss mit Funktionalitäten verknüpft sein, welche die Verwaltung der Datensätze während des Review-Prozesses ermöglichen. Sie muss Schlüsselinformationen zu allen offenen Änderungen anzeigen, wie Eingabetyp, Name, Status, Art der Änderung, Datum und Bearbeiter, wenn nötig werden die Spalten der Tabelle gefiltert. - Das System muss detaillierte Informationen zu jeder offenen Änderung in Tabellenform anzeigen (z. B. den Nutzenden, der die Änderung vorgenommen hat, das Datum, den Kommentar des Überprüfers und den Status) sowie eine Gegenüberstellung der ursprünglichen und der aktualisierten Werte für jede vorgenommene Änderung.
FA-09			Tabelle History - Aus Gründen der Transparenz und Nachvollziehbarkeit muss eine Historientabelle für alle Datensätze in der Datenbank angezeigt werden, die eine chronologische Liste aller Änderungen enthält. - Die letzten Änderungen an einem Datensatz müssen im Dateneingabemodul angezeigt werden. Die letzte Änderungshistorie eines jeden Datensatzes muss in einer eigenen Tabelle gespeichert werden, die folgende Informationen enthält:  Record Name  Record Type: d. h. Erstellung, Änderung, Löschung usw.  Review Decision Date: Der genaue Zeitpunkt der letzten Entscheidung.  Review Decision: Die Entscheidung des Experts (z. B. angenommen, abgelehnt).  Reviewer Comment: Der letzte Kommentar des Experts.  Details-Link: Ein Link zu einer detaillierten Seite, die einen umfassenden Überblick über alle an dem Datensatz vorgenommenen Änderungen bietet. - Das System muss eine detaillierte Historie aller Änderungen an jedem Datensatz führen. Die spezielle Seite mit den Änderungsdetails eines jeden Datensatzes muss folgendes enthalten:  Eine Tabelle, die alle Änderungen für den Datensatz auflistet, mit Details wie: der Nutzende, der die Änderung			MUSS

36 29.07.2026 09:25

[Seite 38]

Anforderungen (Spezifikationen) EUginius 2.0

	Nr.			Beschreibung			Bewertung
			vorgenommen hat, der Änderungsstatus (z. B. erstellt, genehmigt, abgelehnt), das Datum und die Uhrzeit der Änderung, der Kommentar des Experts.  Ein Seite-an-Seite-Vergleich der ursprünglichen und der aktualisierten Werte nach jeder Änderung.

4.2.4. Review Workflow

Im Modul "Data Entry" werden die Daten in entsprechende Datenblätter oder Kataloge eingetragen; die Freigabe der Daten erfolgt durch einen Überprüfungsprozess (siehe Abbildung 2), der einem sechs-Augen-Prinzip unterliegt. Jede Datenänderung, einschließlich Ergänzungen, Bearbeitungen und Löschungen, muss einen mehrstufigen Review-Prozess durchlaufen, um die Richtigkeit und Integrität der Daten zu gewährleisten. Alle Dateneingaben und -aktualisierungen werden mit Angaben darüber protokolliert, wer die Aktion wann durchgeführt hat.

Abbildung 2 “Arbeitsablauf der Überprüfung“

37 29.07.2026 09:25

[Seite 39]

Anforderungen (Spezifikationen) EUginius 2.0

	Nr.			Beschreibung			Bewertung
FA-10			Review nach dem Sechs-Augen-Prinzip Das System muss einen Sechs-Augen-review-Prozess für jeden Eintrag gewährleisten. Der Prozess läuft wie folgt ab (siehe Abbildung 2): - Sobald ein Eintrag in einem Datenblatt abgeschlossen ist, startet der registrierte Nutzende 1 (user 1) mit den entsprechenden Rechten (Data_entry) den Review-Prozess, wobei die zuvor bearbeitbaren Daten "eingefroren" werden. Sobald ein Datenbankoperator das Review gestartet hat, markiert das System die Änderung als “ausstehende Genehmigung” (pending approval). - Nutzender 2 (user 2) mit erweiterten Rechten (z. B. Review_expert Kategorie 1) sperrt das Datenblatt, überprüft die eingefrorenen Daten und entscheidet, ob der Vorgang abgebrochen (z. B. wenn die Daten korrigiert werden sollen) oder fortgesetzt werden soll. - Wird der Vorgang fortgesetzt, kann Nutzender 3 (user 3) mit anderen erweiterten Rechten (z. B. Review_expert Kategorie 2) das Datenblatt übernehmen und die Daten prüfen. Auch er hat die Wahl, den Vorgang abzubrechen oder fortzusetzen. Die Fortsetzung durch Nutzender 3 führt dann dazu, dass die Daten freigegeben und in der Anwendung veröffentlicht werden. - Wird der Vorgang von einem der Nutzenden abgebrochen, kehrt das Datenblatt in einen editierbaren Modus zurück.			MUSS
FA-11			Benachrichtigung über ausstehende Änderungen (Open Changes) - Bei Annahme oder Abbruch bietet das System dem Experten die Möglichkeit, Kommentare zu schreiben, um den Datenbankoperator über gewünschte Korrekturen zu informieren oder seine Entscheidung dem anderen Experten zu erläutern. - Das System stellt sicher, dass die Änderungen erst nach Überprüfung durch den zweiten Experten abgeschlossen werden können, um unbefugte Änderungen zu verhindern. Sobald die Änderungen genehmigt sind, werden sie im System als endgültig markiert und aktualisiert, und die beteiligten Nutzenden werden benachrichtigt.			MUSS

38 29.07.2026 09:25

[Seite 40]

Anforderungen (Spezifikationen) EUginius 2.0

Die Experten werden benachrichtigt, wenn Änderungen zur Überprüfung oder Genehmigung anstehen.

4.3. Webanwendung Features

Die Webanwendung ist strukturiert aufgebaut, so dass der Nutzende die Informationen systematisch und nach Kontext geordnet abrufen kann. Die Darstellung der Informationen und das Angebot an Werkzeugen ist daher in Module gegliedert (“Homepage”, “GMO”, “Detection”, “Analysis Tool”, “Help”). Dieser Bereich ist für die Öffentlichkeit frei zugänglich.

Im Folgenden werden die funktionalen Anforderungen an die einzelnen Module sowie die zu erwartenden Nutzerinteraktionen innerhalb des zu entwickelnden Systems näher beschrieben.

4.3.1. Gemeinsame Funktionalitäten über alle Module

Dieser Abschnitt beschreibt die gemeinsamen Funktionalitäten, die in allen Modulen der Anwendung implementiert werden müssen bzw. sollen, wobei der Schwerpunkt auf den Such- und Filterfunktionen sowie der Anzeige der Ergebnisse liegt. Dies Vereinheitlichung der Funktionen in der gesamten Anwendung dient dazu die Nutzerfreundlichkeit zu verbessern und den Nutzern zu ermöglichen, die Daten leicht zu finden und mit ihnen zu interagieren.

	Nr.			Beschreibung			Bewertung
FA-12			Anzeige der Ergebnisse - Die Ergebnisse von Suchvorgängen (einschließlich Freitextsuche und Filteroptionen) müssen in einem Tabellenformat angezeigt werden, wobei die angezeigten Spalten vom Nutzende angepasst werden können. - Die meisten Spalten müssen alphanumerisch sortierbar sein, wobei einige Spalten eigene Sortierregeln erfordern. - Die Suchergebnisse müssen auf derselben Seite wie die Suchkriterien dargestellt werden, einschließlich aller eingegebenen Werte und ausgewählten Filter, um eine vollständige kontextuelle Klarheit zu gewährleisten. - Relevante Details und Schlüsselinformationen (z. B. Zulassungsstatus, Trait(s) usw.) müssen visuell hervorgehoben werden, z. B. durch Hover-Effekt oder andere intuitive Techniken, um den Nutzenden eine schnelle und einfache Interpretation der Suchergebnisse zu ermöglichen.			MUSS
FA-13			Kontextbezogene interne Verlinkung - Die Werte in den Ergebnisanzeigen (z. B. GVO-Namen, Methodennamen) müssen anklickbar sein und zu den			MUSS

39 29.07.2026 09:25

[Seite 41]

Anforderungen (Spezifikationen) EUginius 2.0

	entsprechenden Detailseiten innerhalb der Anwendung führen gegebenenfalls in eine neue Registerkarte. Dies verbessert die Navigierbarkeit und die Nutzerfreundlichkeit und hilft den Nutzenden, verwandte Daten intuitiv zu erkunden. - Alle GVO-Namen, die in der Anwendung als String ausgegeben werden, müssen anklickbar sein und als interner Link zur Detailseite des jeweiligen GVO führen.
FA-14	Suchfunktion - Die Anwendung bietet derzeit separate Suchoptionen für mehrere Module (z. B. “GMO” und “Detection”). Diese Suchoptionen müssen auf weniger Seiten zusammengefasst werden, um die Navigation zu vereinfachen. - Die Suchseiten müssen den Nutzenden das erwartete Format der verschiedenen Suchfelder klar vorgeben. - Die Suchfunktion muss dynamische Vorschläge anbieten, während der Nutzende das Freitextsuchfeld eingibt (z. B. automatische Vervollständigung). Dies hilft den Nutzenden, relevante Ergebnisse schnell und präzise zu finden. - Die Freitextsuchfunktion muss flexible und intelligente Abfragen unterstützen, um die Nutzerfreundlichkeit zu erhöhen und die Suchgenauigkeit zu verbessern:  Das System muss partielle oder unvollständige Suchbegriffe automatisch interpretieren, indem es Platzhalterlogik anwendet. So können Nutzende Wortfragmente oder Codes eingeben, und die Suche liefert dennoch relevante Ergebnisse, ohne dass der Nutzende explizite Platzhalterzeichen (wie * oder ?) in die Eingabe eingeben muss. Wenn ein Nutzender beispielsweise nach "DAS591" sucht, findet das System Einträge wie "DAS59122", "DAS59123" sowie alle anderen Einträge, die mit dieser Sequenz beginnen oder sie enthalten.  Die Suchmaschine muss auf gängige Tippfehler und geringfügige Abweichungen bei der Nutzereingabe (z. B. Rechtschreibfehler, Einfügen oder Auslassen von Sonderzeichen oder leichte Tippfehler bei den Suchbegriffen) reagieren. Das heißt, wenn ein Nutzender beispielsweise "DAS59123" eingibt, berücksichtigt das System auch Ergebnisse wie "DAS-59122", "DAS-59123" oder "59122", indem es Ähnlichkeiten und kleine Abweichungen im Text erkennt.	MUSS

40 29.07.2026 09:25

[Seite 42]

Anforderungen (Spezifikationen) EUginius 2.0

	- Das System muss erweiterte Abfragefunktionen unterstützen, die es den Nutzenden ermöglichen, die logischen Operatoren "AND" und "OR" nicht nur zwischen mehreren ausgewählten Werten innerhalb eines einzelnen Suchfeldes, sondern auch über mehrere Felder hinweg anzugeben. Diese Funktion muss eine präzise und flexible Erstellung komplexer Suchanfragen ermöglichen, um den unterschiedlichen Nutzeranforderungen gerecht zu werden.
FA-15	Integration von Filtern - Es muss möglich sein, Filter unabhängig von der Freitextsuche anzuwenden. Dies bedeutet, dass die Nutzenden die Ergebnisse mithilfe von Filtern eingrenzen können, ohne zuvor eine Suche durchführen zu müssen. - Die Filter müssen neben der Suche verfügbar und anpassbar sein, ohne die Suchseite zu verlassen, so dass die Nutzende ihre Suche auf die Daten, die sie interessieren, abstimmen können. Um sie anzuwenden oder zu ändern, muss die Seite nicht neu geladen werden. - Filter müssen mit geeigneten Eingabearten bereitgestellt werden: Textfelder, Dropdowns, Schieberegler, Datumsauswahl, Kontrollkästchen usw. - Die Filter müssen erweiterte Filterfunktionen für mehrere Datenkategorien enthalten und gegebenenfalls eine Mehrfachauswahl unterstützen (z. B. die Auswahl mehrerer Traits). - Die kombinierte Freitextsuche mit Filtern muss die verfügbaren Filterkombinationen auf intelligente Weise verwalten. Einige Filterkombinationen können nicht angewendet werden und müssen ausgegraut oder deaktiviert werden. Die genaue Art und das Format dieser Filter, ihre Anzeigereihenfolge und die spezifischen Interaktionen auf der Nutzeroberfläche können in Zusammenarbeit mit Nutzenden und Interessengruppen während der Entwicklungsphase weiter verfeinert werden.	MUSS
FA-16	Exportfunktionen - Alle von der Suchfunktionalität (Freitextsuche, gefilterte Suche oder kombinierte Abfragen) erzeugten Ergebnistabellen müssen eine Exportoption direkt auf der Ergebnisseite enthalten.	MUSS MUSS

41 29.07.2026 09:25

[Seite 43]

Anforderungen (Spezifikationen) EUginius 2.0

Der Export muss vom Nutzenden über eine Schaltfläche oder ein Menü "Export" eingeleitet werden, die bzw. das sich deutlich in MUSS der Nähe der Ergebnistabelle befindet.
Die Anwendung muss den Export von Ergebnissen im xlsx- Format unterstützen. MUSS
Die exportierten Dateien müssen eine klare und beschreibende Namenskonvention verwenden (z. B. search- results_GMO_YYYY-MM-DD.csv). SOLL
Die Anwendung unterstützt den Export von Ergebnissen in weitere gängige Formate, um den Bedürfnissen verschiedener Nutzenden und Anwendungsfälle gerecht zu werden. Die Erstellung eines Exports in verschiedenen Datenformaten wie PDF, JSON oder CSV mit Optionen zur Anpassung ist wünschenswert.

4.3.2. Homepage

Die Homepage ist die zentrale Einstiegsseite der Anwendung, die einen Überblick über den Zweck der Anwendung, die verfügbaren Daten und die Suchmöglichkeiten bietet. Auf der Homepage werden allgemeine Informationen über die Anwendung und die Navigation zu anderen Modulen angezeigt.


FA-17	Anzeige aktueller Daten - Auf der Homepage müssen die neuesten Dateneinträge aus der Datenbank angezeigt werden. Diese Einträge müssen nach Kategorien (z. B. GMO, Method, etc.) und innerhalb der Kategorien chronologisch sortiert sein. - Der Name der Daten muss angezeigt werden und auf die Hauptseite der Daten innerhalb der Anwendung verlinken.	MUSS
FA-18	Automatische Aktualisierung Die Homepage muss automatisch und regelmäßig (z. B. jeden Tag bzw. jede Stunde) aktualisiert werden, um neue Dateneinträge anzuzeigen, ohne dass die Nutzenden die Seite manuell aktualisieren müssen.	MUSS
FA-19	Suchfunktion Die Homepage muss eine Suchfunktion enthalten, mit der die Nutzenden nach Dateneinträgen suchen oder zu den zugänglichen	MUSS

42 29.07.2026 09:25

[Seite 44]

Anforderungen (Spezifikationen) EUginius 2.0

	Seiten navigieren können. Dies kann die Navigation verbessern und es den Nutzenden ermöglichen, direkt auf die Informationen zuzugreifen, an denen sie interessiert sind.
FA-20	Verlinkung zu externen Webseiten (u.a. durch Logos) Die Homepage muss die Integration von Logos (oder anderen Bildern) unterstützen, die als anklickbare Links zu externen Websites dienen. Diese Logos müssen: - in einem visuell ausgewogenen Bereich der Homepage angezeigt werden (z. B. in der Fußzeile, in der Seitenleiste oder in einem speziellen Bereich "Partner"), - leicht zu aktualisieren sein (z. B. um Logos zu ersetzen oder URLs zu ändern), - die verlinkte Website muss in einer neuen Registerkarte oder einem neuen Fenster des Browsers geöffnet werden, um zu verhindern, dass die Sitzung des Nutzenden in der Anwendung verloren geht.	MUSS
FA-21	Zugang zu editierbaren Seiten - Die Homepage muss eine einfache Navigation zu anderen Seiten bieten, die von den Experten bearbeitet werden können, wie z. B. "Über", "Links" und "Artikel". Diese Seiten müssen von der Homepage aus zugänglich sein.	MUSS
FA-22	Newsletter-Anmeldung Die Nutzenden haben die Möglichkeit haben, sich auf der Homepage für einen Newsletter zu registrieren. Der Newsletter soll in einem bestimmten Zeitrahmen (z. B. monatlich) über neue Dateneinträge informieren, damit die Nutzenden auf dem Laufenden bleiben, ohne die Seite ständig besuchen zu müssen.	KANN

4.3.3. Modul “GMO”

Die Webanwendung muss den Nutzenden die Möglichkeit bieten, eine umfassende GVO- Datenbank zu durchsuchen und abzufragen, einschließlich Informationen zu Spezies, Unique Identifiers, Traits und anderen relevanten Daten. Die Suchergebnisse müssen in einem strukturierten Tabellenformat dargestellt werden, das die wichtigsten Informationen über GVO auflistet (siehe FA-12 in Abschnitt 4.2.1). Durch Anklicken eines GVO-Namens in dieser Übersichtstabelle wird der Nutzende auf die zugehörige GVO-Detailseite weitergeleitet.

43 29.07.2026 09:25

[Seite 45]

Anforderungen (Spezifikationen) EUginius 2.0


FA-23	GVO-Suchansicht und Filter Die Nutzenden müssen in der Lage sein, GVO nach verschiedenen Attributen wie GVO-Name, UID, Handelsname, Spezies, Zulassungsstatus und Unternehmen bzw. Institutionen usw. zu filtern.	MUSS
FA-24	Filtern von GVOs nach Eigenschaften (Traits) oder genetischen Elementen Thesaurus - Die Nutzenden müssen die Möglichkeit haben, die Liste der GVO nach einem oder mehreren Traits oder einem oder mehreren genetischen Elementen zu filtern. - Traits und genetische Elemente müssen entsprechend dem Thesaurus für Traits und genetische Elemente hierarchisch strukturiert sein. - Der Thesaurus muss in Form einer Baumstruktur dargestellt werden, die vier Hierarchieebenen unterstützt. Die Filterschnittstelle muss es dem Nutzenden ermöglichen, mehrere Traits oder genetische Elemente gleichzeitig auszuwählen, wobei die Möglichkeit besteht, logische Operatoren (z. B. "AND", "OR") anzuwenden, um die Beziehung zwischen den ausgewählten Kriterien zu definieren.	MUSS
FA-25	Anzeige der GVO-Detailseite - Am oberen Rand der GVO-Detailseite muss an prominenter Stelle eine GVO-Identitätsbox angezeigt werden. Diese Box enthält die wichtigsten Informationen zur Identifizierung des ausgewählten GVO, wie z. B. Art, UID, Trait(s), Alias und andere wichtige Identifikatoren, welche die Merkmale des GVO kurz und bündig zusammenfassen. - Unterhalb der Identitätsbox werden auf der GVO-Detailseite alle mit dem ausgewählten GVO verbundenen Daten zusammengefasst. Dazu gehören sowohl die über das GVO- Eingabeformular eingegebenen Informationen als auch zusätzliche Daten, die entweder direkt oder indirekt mit dem GVO in der Datenbank verknüpft sind. - Um die Übersichtlichkeit und Nutzerfreundlichkeit zu gewährleisten, müssen die detaillierten Informationen in thematisch gruppierten Containern (z. B. Insert / Modification,	MUSS

44 29.07.2026 09:25

[Seite 46]

Anforderungen (Spezifikationen) EUginius 2.0

	Detection Methods, usw.) organisiert werden. Jeder Container ist unabhängig voneinander ein- und ausklappbar, sodass die Nutzenden je nach Bedarf einzelne Abschnitte oder mehrere Container gleichzeitig anzeigen können. - In der GVO-Detailansicht müssen kontextbezogene interne Links vorhanden sein, die eine nahtlose Navigation zu anderen relevanten Modulen oder Seiten innerhalb der Anwendung ermöglichen.
FA-26	Sequenzen - Der Nutzende ist in der Lage anhand verschiedener Suchkriterien und Filter nach bestimmten Sequenzen zu suchen. - Das Suchergebnis wird in Tabellenform mit allen Details zu den Sequenzen angezeigt. - Es muss möglich sein, Sequenzen in verschiedenen Dateiformaten (z. B. FASTA, FASTQ, GFF) herunterzuladen. Bei Sequenzdaten sind insbesondere die Formate FASTA und GenBank zu berücksichtigen und einzeln oder in Kombination (z. B. im ZIP-Format) zu exportieren. Vertrauliche Sequenzen sollen nur für autorisierte Nutzende zugänglich sein.	MUSS MUSS MUSS

4.3.4. Modul “Detection”

Die Webanwendung bietet den Nutzenden die Möglichkeit, eine umfassende Datenbank mit Nachweismethoden zu durchsuchen und abzufragen, einschließlich Informationen wie Methodenname, Methodenset (z. B. Screening-Set, ABC-Set), Ziel(e) und Validierung. Die Suchergebnisse müssen in einem strukturierten Tabellenformat angezeigt werden, das die wichtigsten Details zu jeder Nachweismethode auflistet. Von dieser Übersichtstabelle aus wird der Nutzende durch Anklicken eines Methodennamens auf die Detailseite der Methode (detection method detail page) geleitet.

	Nr.			Beschreibung			Bewertung
FA-27			Ansicht und Filter für die Methodensuche Nutzende müssen in der Lage sein, Methoden nach verschiedenen Attributen zu filtern, wie z. B. GVO-Name, Methodenname, Methodenset (Screening bzw. ABC), Zielname, Zieltyp, Validierung, Standardisierung, Primer- bzw. Sondername, Primer-, Sonder-, Amplikonsequenz usw.			MUSS
FA-28			Anzeige der Methoden-Detailseite - Oben auf der Detailseite der Methode muss an prominenter Stelle eine Box für die Methodenidentität angezeigt werden.			MUSS

45 29.07.2026 09:25

[Seite 47]

Anforderungen (Spezifikationen) EUginius 2.0

	Diese Box enthält wichtige Informationen über die ausgewählte Methode, wie z. B. Beschreibung, Validierung, Standardisierung, verwandte Methoden, Zieltyp, Zielname und andere wichtige Kennzeichnungen, welche die Merkmale der Methode kurz zusammenfassen. - Unterhalb der Identitätsbox werden auf der Detailseite der Methode alle mit der ausgewählten Methode verbundenen Daten zusammengefasst. Dazu gehören Informationen zu Primer- bzw. Sondername, Primer-, Sonder-, Amplikonsequenz und zugehörige Dokumente.
FA-29	Anzeige der GMO/Method-Matrix Die GMO/Method-Matrix ermöglicht es dem Nutzenden, Informationen über die Spezifität von PCR-Methoden und ihre Fähigkeit zum Nachweis bestimmter GVO zu finden. Die Auswahl und Filterung von Methoden und GVO wird unterstützt, um eine Verifizierungsmatrix zu erstellen, welche die Abdeckung der Nachweismethoden für ausgewählte GVO anzeigt. - Die Nutzenden müssen auf die GMO/Method-Matrix zugreifen können, um die Spezifität der PCR-Methoden und ihre Fähigkeit zum Nachweis von GVO zu überprüfen. Die Matrix muss Informationen über die Nachweisfähigkeit der ausgewählten Methoden für die ausgewählten GVO anzeigen. - Sobald die methoden- und GVO-spezifischen Filter ausgewählt sind, erstellt das System eine Matrix, welche die Verifizierungsdaten anzeigt und die Abdeckung der ausgewählten PCR-Methoden für die entsprechenden GVO visualisiert. Die Matrix hebt den Abdeckungsgrad oder etwaige Nachweislücken des ausgewählten Satzes hervor. - Die Ergebnisse müssen klar zwischen GVO, die mit den ausgewählten Methoden nachgewiesen werden, und solchen, die nicht nachgewiesen werden, unterscheiden. - GVO, die mit einer Methode als nachweisbar eingestuft werden (Ziel-Sequenz bzw. Verifizierungsdaten vorhanden), müssen visuell hervorgehoben werden (z. B. durch einen grünen Kasten). - In der Matrix muss der Verifizierungswert jeder Methode für einen bestimmten GVO angegeben werden. Dieser Wert gibt die Fähigkeit und die Zuverlässigkeit jeder Methode an, einen bestimmten GVO nachzuweisen. Er basiert auf:	MUSS

46 29.07.2026 09:25

[Seite 48]

Anforderungen (Spezifikationen) EUginius 2.0

	 Experimentelle Verifizierung: Verwendung von Referenzmaterial (+/-3).  In-Silico-Überprüfung: Mit Sequenzabgleich (+/-2).  Theoretische Verifizierung: Basierend auf verfügbaren Informationen aus Antragsunterlagen, Veröffentlichungen usw. (+/-1).
FA-30	Anzeige von Referenzmaterial - Die Webanwendung muss den Nutzenden die Möglichkeit bieten, nach detaillierten Informationen über GVO- Referenzmaterialien zu suchen und auf diese zuzugreifen, einschließlich Materialverfügbarkeit, Quelle und spezifische Merkmale. - Das System muss es den Nutzenden ermöglichen, anhand der folgenden Parameter nach Referenzmaterialien zu suchen: GVO, Spezies, Quelle, Zertifizierung, kommerzielle Verfügbarkeit, usw. - Das System muss ein Warnsymbol neben den Referenzmaterialien anzeigen, bei denen zusätzlich zu dem angegebenen GVO das unbeabsichtigte Vorhandensein anderer GVO festgestellt wurde. - Durch Anklicken der Katalognummer eines Referenzmaterials wird der Nutzende auf eine detaillierte Materialseite weitergeleitet. Auf dieser Seite werden umfassende Informationen über das ausgewählte Referenzmaterial angezeigt, wie z. B.: Zugehöriger GVO, Materialtyp, Beschreibung, Konzentration, Zertifizierung, Verfügbarkeit, Quellenanbieter usw.	MUSS

4.3.5. Modul “Analysis Tool”

Das “Analysis Tool”- Modul wurde entwickelt, um Labore bei der Analyse von Proben auf das Vorhandensein von GVO zu unterstützen. Es unterstützt den Prozess der Interpretation von Untersuchungsergebnissen, indem es die notwendigen Funktionen für die Dateneingabe und die Identifizierung potenzieller GVO-Ziele auf der Grundlage der durchgeführten Analyse bereitstellt. Nutzende können experimentelle Daten eingeben und eine detaillierte Suche nach möglichen GVO-Zielen durchzuführen. Anhand der detaillierten Untersuchungsergebnisse können Labore nachgewiesene Ziele GVO zuordnen, negative Ergebnisse bestätigen und GVO finden, welche die nachgewiesenen Zielsequenzen enthalten und somit eine Erklärung für ihre Untersuchungsergebnisse liefern. Das Modul ermöglicht es den Nutzenden eine systematische Analyse der Untersuchungsergebnisse und liefert Erklärungsvorschläge für nachgewiesene Ziele.

47 29.07.2026 09:25

[Seite 49]

Anforderungen (Spezifikationen) EUginius 2.0

	Nr.			Beschreibung			Bewertung
FA-31			Eingabe von experimentelle GVO-Nachweis-Ergebnissen - Das Modul muss mehrere Eingabefelder für die Eingabe von GVO-Untersuchungsergebnissen bieten, darunter: Spezies, GVO, Promotoren, Terminatoren, kodierende Sequenzen, andere Elemente und Konstrukte. - Die Nutzenden müssen die Möglichkeit haben, GVO- Untersuchungsergebnisse manuell einzugeben. Es muss möglich sein, sowohl detektierte (detected) als auch nicht detektierte Ziele (z. B. Spezies, GVO, Elemente usw.) auszuwählen. Wenn ein Ziel aus der Liste detected ausgewählt wird, muss es automatisch aus der Liste der not detected entfernt werden und umgekehrt.			MUSS
FA-32			Schritt-für-Schritt-Analyseprozess - Die Nutzenden wählen zunächst die detektierten Ziele aus. - Dann werden die Ziele ausgewählt, die getestet, aber nicht detektiert wurden (confirmed negative targets). - Wenn die detektierten Ziele durch die detektierten Events (GVO) erklärt werden können, sind keine weiteren Maßnahmen erforderlich. - Wenn die Ziele nicht durch die nachgewiesenen GVO erklärt werden können, listet das System GVO auf, die möglicherweise die nachgewiesenen Ziele erklären könnten. - Nach Anklicken der Schaltfläche "Analyse" muss das System eine detaillierte Analyse der Probenergebnisse des Labors auf der Grundlage der GVO-bezogenen Informationen erstellen. Die Analyseergebnisse sind in zwei Hauptteile gegliedert: die bestätigten Ergebnisse und die GVO-Vorhersage-Ansicht.			MUSS

48 29.07.2026 09:25

[Seite 50]

Anforderungen (Spezifikationen) EUginius 2.0

FA-33	Bestätigte Ergebnisse (Confirmed output) - Die Webanwendung muss eine Zusammenfassung der detektierten und nicht detektierten Ziele auf der Grundlage der ausgewählten Methoden liefern. - Die Webanwendung muss eine tabellarische Liste der mit eventspezifischen Methoden identifizierten GVO anzeigen. - Die Tabelle muss die relevanten GVO und Zielinformationen enthalten, wobei die in den einzelnen GVO vorhandenen (Ziel-)Elemente visuell hervorgehoben werden, z. B. durch Symbole oder Farben, um den Nutzenden eine schnelle Interpretation der Daten zu ermöglichen:  Unexplained Detected Target: Zeigt ein detektiertes Ziel an, das in keinem der identifizierten GVO vorhanden ist.  Confirmed Not Detected Target: Weist auf ein Ziel hin, das getestet, aber nicht detektiert wurde.  Explained Detected Target: Zeigt ein detektiertes Ziel an, das in mindestens einem der identifizierten GVO vorhanden ist.	MUSS
FA-34	GVO-Vorhersage - Die Webanwendung bietet eine GVO-Vorhersagefunktion, die GVO auflistet, die die in der Probe detektierten Ziele enthalten, aber nicht in den identifizierten GVO vorhanden sind. - Die in den einzelnen GVO vorhandenen (Ziel-)Elemente werden mit farbcodierten Symbolen versehen, die es dem Nutzenden ermöglichen, zwischen den enthaltenen Elementen, die in den identifizierten GVO vorhanden sind, und den detektierten Elementen, die bisher nicht erklärt werden konnten (d. h. in den identifizierten GVO nicht vorhanden sind), zu unterscheiden. - Die GVO werden standardmäßig alphabetisch nach Spezies sortiert. - Der Nutzende hat die Möglichkeit, die GVO-Liste auf Basis des Analyse-Inputs (z. B. Beschränkung auf GVO von nachgewiesenen Spezies) oder auf Informationen über die Verknüpfung von GVO mit Methoden (z. B. Beschränkung auf GVO, die mit Methoden mit einem hohen Verifizierungswert verknüpft sind) einzuschränken.	MUSS

49 29.07.2026 09:25

[Seite 51]

Anforderungen (Spezifikationen) EUginius 2.0

4.3.6. Help

Die Hilfeseite der Anwendung muss den Nutzenden das Verständnis und die Navigation in der Anwendung erleichtern. Sie muss von der Homepage und allen anderen Hauptseiten aus leicht zugänglich sein und den Nutzenden Anleitungen, Definitionen und Anweisungen bieten.


FA-35	Strukturierter Inhalt - Die Hilfeseite muss einen klar strukturierten Inhalt bieten, einschließlich Überschriften, Unterüberschriften und Links zu relevanten Abschnitten. - Die Hilfeseite muss Schritt-für-Schritt-Anweisungen enthalten, gegebenenfalls mit kommentierten Screenshots oder Abbildungen. - Interne Links zu verwandten Artikeln oder Abschnitten müssen zur Erleichterung der Navigation enthalten sein.	MUSS
FA-36	Suchfunktionalität Die Nutzenden müssen die Möglichkeit haben, innerhalb der Hilfeseite nach Schlüsselwörtern zu suchen, um bestimmte Themen oder Anweisungen zu finden.	MUSS
FA-37	Editierbarer Inhalt Der Inhalt der Hilfeseite muss bearbeitbar sein, damit Administratoren den Text aktualisieren, Themen hinzufügen oder die Anweisungen nach Bedarf anpassen können.	MUSS
FA-38	Abschnitt der Hilfeseite Die Nutzenden müssen in der Lage sein, den spezifischen Abschnitt der Hilfeseite für jedes Modul direkt über die Schnittstelle des Moduls aufzurufen. Die Hilfeseite muss in einer neuen Registerkarte geöffnet werden.	MUSS
FA-39	Einbindung von weiteren Bereichen - Die Hilfeseite soll als html-Datei in die Anwendung integriert sein. Die Nutzenden sollen die Möglichkeit haben, die Datei auszudrucken oder als PDF zu speichern, um sie Offline nachschlagen zu können.	KANN

50 29.07.2026 09:25

[Seite 52]

Anforderungen (Spezifikationen) EUginius 2.0

Es soll möglich sein, Erklärvideos an vordefinierten Stellen einzubinden und bei Bedarf durch den Auftragnehmer selbstständig Videos hochzuladen.
Es soll ein Abschnitt mit häufig gestellten Fragen (FAQ) erstellt werden, um häufige Probleme und Fragen der Nutzenden zu behandeln.

5. Nicht-funktionale Anforderungen

In diesem Abschnitt werden nicht-funktionale Anforderungen an die Webanwendung beschrieben, die entscheidend zur dauerhaften Nutzbarkeit für den Nutzenden beitragen und daher grundsätzlich bei der Architekturgestaltung der Webanwendung berücksichtigt werden müssen. Die Software muss die im Folgenden beschriebenen nicht-funktionalen Anforderungen vollständig erfüllen.

5.1. Zugänglichkeit und Konformität

Zugänglichkeit und Konformität beziehen sich auf die Fähigkeit der Webanwendung, von allen Nutzenden, einschließlich Menschen mit Behinderungen, effektiv genutzt zu werden, wobei die einschlägigen Normen eingehalten werden müssen. Die folgenden nicht-funktionale Anforderungen (NFA) gewährleisten die Zugänglichkeit und Konformität des Systems:

	Nr.			Beschreibung			Bewertung
NFA-01			Browser- und Gerätekompatibilität Die Anwendung muss mit den neuesten Versionen der wichtigsten Webbrowser (Chrome, Firefox, Safari, Edge) und mobilen Plattformen (iOS, Android) kompatibel sein, um die Zugänglichkeit auf Desktops, Tablets und Smartphones zu gewährleisten.			MUSS
NFA-02			Einhaltung von Normen Die folgenden Standards müssen bei der Entwicklung der Anwendung eingehalten werden. - Die Vorgaben aus den Softwareentwicklungsstandards des Auftraggebers (Version 4.0) sind für die Realisierung verbindlich und müssen berücksichtigt werden (siehe Anhang D mit den dazugehörigen Dokumenten). Über die Vorgaben hinaus muss als Markupsprache HTML 5 unter Einsatz von CSS 3.x verwendet werden. - Die Webanwendung EUginius 2.0 wird als Jakarta-EE- Webanwendung implementiert und die Architektur der Webanwendung folgt dem 4-Schichten-Modell.			MUSS

51 29.07.2026 09:25

[Seite 53]

Anforderungen (Spezifikationen) EUginius 2.0

Die Einhaltung und Berücksichtigung der beiden Frameworks SAGA und XÖV ist für die Softwareentwicklung von grundlegender Bedeutung. SAGA7 ist eine Zusammenstellung von Referenzen zu Spezifikationen und Methoden für Softwaresysteme der öffentlichen Verwaltung. Durch Beschluss des IT-Rates ist die Anwendung von SAGA 5 für die Bundesverwaltung bei der Auswahl ihrer Informations- technologien verbindlich. Die XÖV-Standards8 sind Vorgaben für den Datenaustausch in der öffentlichen Verwaltung oder zwischen der öffentlichen Verwaltung und ihren Kunden. Die Anwendung des XÖV-Frameworks in der Version 2.0 ist dabei zu berücksichtigen.
Die Nutzeroberfläche muss so gestaltet sein, dass eine barrierefreie Nutzung möglich ist, um sicherzustellen, dass Nutzende mit Behinderungen effektiv mit der Anwendung inter- agieren können. Dazu gehören Funktionen wie Tastatur- navigation, Screenreader-Kompatibilität und Alternativtexte für Bilder. Für die barrierefreie Darstellung von Inhalten fordert der Auftraggeber die Einhaltung der BITV9 (Verordnung zur Schaffung barrierefreier Informationstechnik) (siehe SAGA- Modul Technische Spezifikationen 5.0, Abschnitt 7.1 "Barrierefreie Darstellung").
Die Systemvoraussetzungen für die Soft- und Hardware des Auftraggebers sind zu berücksichtigen. Dies gilt insbesondere für die Anpassung der Software an die folgenden Standards:  Standards für die Softwareentwicklung beim Auftraggeber

(siehe Anhang D und dazugehörige Dokumente).

 Die Norm – Systemumgebung beim Auftraggeber (siehe

Anhang E)

 Installations- und Betriebsbedingungen für IT-Systeme beim

Auftraggeber (siehe Anhang F)

5.2. Nutzerfreundlichkeit

Die Nutzerfreundlichkeit bezieht sich darauf, wie einfach und intuitiv die Webanwendung für die Nutzenden zu navigieren und zu bedienen ist. Die Webanwendung muss für alle

7 https://www.cio.bund.de/SharedDocs/downloads/Webs/CIO/DE/digitaler-wandel/architekturen-standard/AM_SAGA_Grundlagen.html 8 https://www.xoev.de/ 9 https://www.gesetze-im-internet.de/bitv_2_0/BJNR184300011.html 52 29.07.2026 09:25

[Seite 54]

Anforderungen (Spezifikationen) EUginius 2.0

Nutzertypen eine zufriedenstellende und effiziente Erfahrung bieten. Die folgenden Anforderungen gewährleisten die Nutzerfreundlichkeit des Systems:


NFA-03	Unterstützung für mehrere Browser-Tabs Die Anwendung muss von einem Nutzenden im Browser z. B. in mehreren Tabs geöffnet werden können, so dass mehrere Bearbeitungsschritte (auf verschiedenen Seiten bzw. Prozessen) parallel durchgeführt werden können.	MUSS
NFA-04	Verwendung der Suchfunktion im Browser Die im Frontend angezeigten Texte müssen auch mit der im Browser eingebauten Suchfunktion durchsuchbar sein. Alle angezeigten Texte müssen auch markierbar sein, z.B. für Copy & Paste.	MUSS
NFA-05	Grundsätze der Dialoggestaltung Die in der DIN EN ISO 9241.110 festgelegten Richtlinien für Software-Ergonomie sind zu berücksichtigen. Insbesondere sind bei der Gestaltung der Nutzeroberfläche die folgenden Gestaltungsprinzipien anzuwenden: - Aufgabenangemessenheit, - Selbstbeschreibungsfähigkeit, - Steuerbarkeit, - Erwartungskonformität, - Fehlertoleranz, - Lernförderlichkeit.	MUSS
NFA-06	Responsive Webdesign - Das Layout muss entsprechend dem definierten Styleguide des Auftraggebers umgesetzt werden (siehe Anhang G). - Geringfügige Abweichungen, die sich am Layout der aktuellen Website https://www.euginius.eu orientieren (z. B. Integration bestimmter Logos), werden bei der Entwicklung in Absprache zwischen den Vertragsparteien festgelegt. - Die Nutzeroberfläche der Anwendung muss nach den Grundsätzen des "Responsive Web Design" gestaltet werden,	MUSS

53 29.07.2026 09:25

[Seite 55]

Anforderungen (Spezifikationen) EUginius 2.0

	soweit dies im Rahmen des Online-Styleguides des Auftraggebers möglich ist. - Das Layout der Nutzeroberfläche muss so flexibel gestaltet sein, dass sich Inhalt und Struktur der Website dynamisch an die Auflösung des jeweiligen Ausgabegeräts (Desktop, Tablet, Smartphone) anpassen, so dass eine gleichbleibend optimale Darstellung und Nutzerfreundlichkeit gewährleistet ist.
NFA-07	Spezifikationen für das Corporate Design Die Nutzeroberfläche der Webanwendung muss den Vorgaben des Online-Styleguides des Auftraggebers zur Umsetzung eines standardisierten Corporate Designs entsprechen.	MUSS
NFA-08	Intuitive Seitennavigation Die Bedienung der Seiten muss für den Nutzenden intuitiv sein. Dazu gehören gegenüber der aktuell produktiven Anwendung EUginius 1.0, eine reduzierte Anzahl von aufzurufenden Seiten, klare interne Verknüpfungen zwischen den Seiten und Modulen und eine Reduzierung der Anzahl von Suchseiten.	MUSS
NFA-09	HTML- und CSS-Validierung Das HTML und das CSS darf bei der Validierung durch den W3C- Validator10 keine kritischen Fehler erzeugen.	MUSS
NFA-10	Funktionalität ohne JavaScript Alle wesentlichen Funktionen der Weboberfläche müssen auch nach Deaktivierung von JavaScript im Browser verfügbar sein. Wenn die Verwendung von JavaScript eine wesentliche technische Voraussetzung für die Nutzung der Weboberfläche ist und die Nutzbarkeit der Anwendung ohne JavaScript stark eingeschränkt ist, müssen die Einschränkungen mit dem Auftraggeber besprochen und vereinbart werden.	MUSS

5.3. Leistung

Die Leistung bezieht sich darauf, wie effizient die Webanwendung unter verschiedenen Bedingungen arbeitet, einschließlich Reaktionsfähigkeit, Geschwindigkeit und Ressourcennutzung. Die Webanwendung muss so optimiert sein, dass es die erwarteten Arbeitslasten mit minimalen Latenzzeiten bewältigen kann, und es muss angemessen skaliert

10 http://validator.w3.org/ 54 29.07.2026 09:25

[Seite 56]

Anforderungen (Spezifikationen) EUginius 2.0

werden, um der Nachfrage gerecht zu werden. Die folgenden Anforderungen gewährleisten die Leistung des Systems:


NFA-11	Anzahl der Nutzenden Die Anwendung muss jederzeit und bei jedweder Belastungsgröße zuverlässig reagieren. Es wird davon ausgegangen, dass 100 Personen die Webanwendung gleichzeitig nutzen. Die Webanwendung muss in der Lage sein, alle Abfragen der verschiedenen Nutzenden effizient zu bearbeiten.	MUSS
NFA-12	Frontend-Leistung Alle statischen Elemente (Bilder, CSS, JavaScript) müssen für schnelle Ladezeiten optimiert sein.	MUSS
NFA-13	Reaktionszeit - Die Anwendung muss unter normalen Nutzungsbedingungen (siehe NFA-11) innerhalb von 2 Sekunden geladen werden. - Die Antwortzeit der Webanwendung bei normaler Belastung darf 1,5 Sekunden für jede Aktion auf der Nutzeroberfläche nicht überschreiten. Ausnahmen müssen mit dem Auftraggeber vereinbart werden. - Die Antwortzeit für einen Klick muss weniger als eine Sekunde betragen. Bei längeren Vorgängen oder großen Datenbankabfragen muss der Nutzende eine Rückmeldung über die verbleibende Zeit erhalten. - Komplexe Suchen und Analysen dürfen je nach Art der Suche bzw. Analyse Sekunden dauern. - Auf Fehler und Fehleingaben muss der Nutzende zeitnah hingewiesen werden. In diesem Fall darf die Antwortzeit 2 Sekunden nicht überschreiten.	MUSS

5.4. Wartbarkeit und Aktualisierbarkeit

Wartbarkeit und Aktualisierbarkeit beziehen sich darauf, wie leicht die Webanwendung während seines Lebenszyklus aktualisiert, verbessert oder repariert werden kann. Die Webanwendung muss über eine modulare, gut dokumentierte Architektur verfügen, welche die Fehlersuche und künftige Upgrades mit minimalen Unterbrechungen unterstützt. Die folgenden Anforderungen gewährleisten die Wartbarkeit und Aufrüstbarkeit des Systems:

55 29.07.2026 09:25

[Seite 57]

Anforderungen (Spezifikationen) EUginius 2.0

	Nr.			Beschreibung			Bewertung
NFA-14			Unterstützung von Updates und Versions-Upgrades - Die Anwendung muss so aufgebaut sein, dass künftige Aktualisierungen oder Versionserweiterungen der Plattform (Datenbanksysteme, Anwendungsserver, Laufzeitumgebung) ohne größere Unterbrechungen (Ausfall länger als vier Stunden) oder Nacharbeiten durchgeführt werden können.  Unterstützung für Datenbank-Updates: Die Anwendung muss mit dem Datenbank-Management-System (siehe Abschnitt 3.1.1) kompatibel sein. Es muss möglich sein, mit minimalem Aufwand von der aktuellen Version auf höhere Versionen zu wechseln.  Unterstützung für die Aktualisierung von Webanwendungen: Die Anwendung muss auf dem in Abschnitt 3.1.1 spezifizierten Applikationsserver installiert werden. Es muss möglich sein, mit minimalem Aufwand von der aktuellen Version auf höhere Versionen zu wechseln.  Unterstützung für Java oder Jakarta Updates: Die Anwendung muss Änderungen an höheren Versionen von Java EE oder Jakarta EE mit minimalem Aufwand unterstützen.  Unterstützung für Aktualisierungen der Laufzeitumgebung: Die Anwendung muss kontinuierliche Aktualisierungen der Laufzeitumgebung unterstützen, einschließlich größerer oder kleinerer Versionsaktualisierungen, Sicherheitspatches und Fehlerbehebungen. - Die Stabilität der Anwendung muss auch nach Software- Änderungen oder regelmäßigen Änderungen an der Systemumgebung (Änderungen, die laut Systemdokumentation zulässig sind: z. B. Änderungen an der Konfiguration) gewährleistet sein. - Die Architektur der Anwendung muss technisch so gestaltet sein, dass Fehlerkorrekturen und kleinere Softwareänderungen (Bugfixing) ohne großen Aufwand durchgeführt werden können.			MUSS

56 29.07.2026 09:25

[Seite 58]

Anforderungen (Spezifikationen) EUginius 2.0

5.5. Zuverlässigkeit

Die Zuverlässigkeit bezieht sich auf die Fähigkeit der Webanwendung, seine beabsichtigten Funktionen unter den erwarteten Bedingungen ohne Ausfälle zu erfüllen. Die Webanwendung muss robust, widerstandsfähig und so konzipiert sein, dass Ausfallzeiten minimiert werden, und über Mechanismen zur Fehlererkennung, Wiederherstellung und Aufrechterhaltung der Dienstkontinuität verfügen. Die folgenden Anforderungen gewährleisten die Zuverlässigkeit des Systems:

	Nr.			Beschreibung			Bewertung
NFA-15			Verfügbarkeit des Systems - Die Anwendung muss zu jeder Zeit und unter jeder Belastungsgröße zuverlässig reagieren. Es darf nicht zu unkontrollierten Systemabstürzen oder Datenverlusten kommen. - Das System muss automatische Failover-Mechanismen zur Aufrechterhaltung der Verfügbarkeit bei Komponentenausfällen unterstützen. Nach einem Systemausfall muss sichergestellt sein, dass ein Neustart der Anwendung das System ohne manuellen Eingriff wieder in einen konsistenten Gesamtzustand (fehlerfreier Verarbeitungsstatus und Datenkonsistenz) bringt. - Geplante Wartungsarbeiten müssen außerhalb der Hauptverkehrszeiten (montags bis freitags in der Zeit von 09 Uhr bis 17 Uhr) durchgeführt werden, um die Auswirkungen auf die Nutzenden möglichst gering zu halten. Die Wartungsfenster müssen den Beteiligten so früh wie möglich, aber spätestens drei Arbeitstage (Montag bis Freitag) im Voraus mitgeteilt werden.			MUSS
NFA-16			Fehlertoleranz - Das System muss fehlertolerant sein und über Mechanismen zur Erkennung von Fehlern verfügen. Zu den Mechanismen auf Auftragnehmerebene zählen unter anderem die automatisierten Tests (Unit-, Integrations-Tests), Input Validation, strukturiertes Exception Handling und ausführliches Logging. - Auf keinen Fall dürfen inkonsistente oder unvollständige Informationen in die Datenbank übertragen werden. Es muss sichergestellt werden, dass Aktionen im Fehlerfall entweder vollständig oder gar nicht ausgeführt werden (Transaktion).			MUSS

57 29.07.2026 09:25

[Seite 59]

Anforderungen (Spezifikationen) EUginius 2.0

NFA-17 Wiederherstellung MUSS

Im Falle einer Störung muss das System automatisch in den Normalzustand zurückkehren, ohne dass ein manuelles Eingreifen erforderlich ist.
Nach einem Systemausfall muss sichergestellt sein, dass durch den Neustart der Anwendung das System ohne manuellen Eingriff wieder einen konsistenten Gesamtzustand (fehlerfreier Bearbeitungsstatus und Datenkonsistenz) erreicht.

5.6. Sicherheit

Sicherheit bezieht sich auf die Fähigkeit der Webanwendung, Daten, Ressourcen und Nutzerinteraktionen vor unberechtigtem Zugriff oder anderen bösartigen Bedrohungen zu schützen. Die Webanwendung muss mit robusten Schutzmechanismen ausgestattet sein, um Vertraulichkeit, Integrität und Verfügbarkeit zu gewährleisten und gleichzeitig die einschlägigen Sicherheitsstandards und -vorschriften einzuhalten. Die folgenden Anforderungen gewährleisten die Sicherheit des Systems:


NFA-18	Sitzungsmanagement Nutzersitzungen müssen sicher verwaltet werden. Nutzersitzungen müssen nach einer gewissen Zeit der Inaktivität ablaufen, und Sitzungs-Tokens müssen sicher gespeichert und übertragen werden.	MUSS
NFA-19	Protokollierung Die Webanwendung muss Protokolle über kritische Aktionen, einschließlich Nutzeranmeldungen, Datenzugriff und Änderungen der Systemkonfiguration, führen (siehe Abschnitt 3.1.3). Die Protokolle müssen sicher aufbewahrt werden und nur dem IT- Personal zu Prüfungs- und Fehlerbehebungszwecken zugänglich sein.	MUSS
NFA-20	Datenschutz-Grundverordnung (DSGVO) -Konformität - Die Anwendung muss bewährte Sicherheitspraktiken zum Schutz von Nutzerdaten einhalten, unter anderem die sichere Kommunikation, sichere Speicherung von Anmeldeinformationen und Nutzerauthentifizierung. - Das System muss Datenschutzstandards wie DSGVO einhalten, insbesondere im Hinblick auf die Speicherung und Verarbeitung	MUSS

58 29.07.2026 09:25

[Seite 60]

Anforderungen (Spezifikationen) EUginius 2.0

personenbezogener Daten. So müssen beispielsweise Nutzerpasswörter sicher gespeichert werden und die erfassten personenbezogenen Daten müssen anonymisiert werden.

Die Nutzenden müssen einer einmaligen Nutzungsvereinbarung zustimmen, bevor sie Zugang erhalten, und ihr ursprüngliches Passwort im Rahmen des Compliance-Prozesses ändern müssen.

5.7. Skalierbarkeit

Die Skalierbarkeit bezieht sich auf die Fähigkeit des Systems, ein wachsendes Arbeitsaufkommen zu bewältigen oder sein Wachstumspotenzial zu nutzen, ohne die Leistung oder Stabilität zu beeinträchtigen. Das System muss so konzipiert sein, dass es effizient skaliert werden kann, um sicherzustellen, dass es die Anforderungen einer zunehmenden Nutzerlast und eines wachsenden Datenvolumens erfüllen kann, ohne die Leistung zu beeinträchtigen. Die folgenden Anforderungen gewährleisten die Skalierbarkeit des Systems:

	Nr.			Beschreibung			Bewertung
NFA-21			Caching-Strategie Die Webanwendung soll Caching-Mechanismen integrieren, um die Belastung der Datenbanken zu verringern und die Reaktionsfähigkeit der Webanwendung durch die Zwischenspeicherung häufig abgerufener Daten oder rechenintensiver Operationen zu verbessern.			SOLL
NFA-22			Skalierbarer Datenbankzugriff Die Anwendung soll in der Lage sein, eine hohe Gleichzeitigkeit zu bewältigen und große Datenmengen effizient abzufragen, ohne die Leistung zu beeinträchtigen, wobei sichergestellt werden muss, dass die Datenbankaufrufe für die Skalierbarkeit optimiert sind.			SOLL

6. Prüfung, Lieferumfang und Abnahme

In diesem Abschnitt wird sichergestellt, dass das Projekt alle erforderlichen Normen in Bezug auf Vorschriften, Zugänglichkeit und Datenaustausch erfüllt und dass die Anwendung allen Anforderungen gerecht wird. Außerdem werden hier die Grenzen der bereitzustellenden Produkte, Dienste und Leistungen sowie die Kriterien und das Verfahren für deren Abnahme festgelegt. Dieser Abschnitt umreißt die spezifischen Komponenten, Merkmale und Funktionen, die geliefert werden müssen, sowie die Bedingungen, unter denen das System oder Produkt als vollständig und akzeptabel angesehen wird. Die folgenden Anforderungen gewährleisten ein klares Verständnis der Erwartungen und Verantwortlichkeiten in Bezug auf Prüfung, Lieferung und Abnahme: 59 29.07.2026 09:25

[Seite 61]

Anforderungen (Spezifikationen) EUginius 2.0

6.1. Prüfung und Qualitätssicherung

Die Anwendung muss umfassenden Tests unterzogen werden, um Funktionalität, Leistung, Sicherheit und Nutzerfreundlichkeit zu gewährleisten. Die Teststrategie umfasst verschiedene Arten von Tests, darunter Unit-Tests, Integrationstests und End-to-End-Tests, um sicherzustellen, dass alle Komponenten und Funktionen die definierten Anforderungen erfüllen und wie erwartet funktionieren.

6.1.1. Durchführung der statischen Quellcode-Analyse

Zur Gewährleistung der Softwarequalität muss der Auftragnehmer den Quellcode im Rahmen der Qualitätssicherung einer statischen Quellcode- und Schwachstellenanalyse unterziehen und protokollieren.

Die Tests müssen so automatisch wie möglich durchgeführt werden. Für diese Automatisierung muss der Auftragnehmer die folgenden Werkzeuge verwenden:

Durchführung von Tests einer Webanwendung mit Selenium.
Durchführung von Lasttests mit JMeter oder Maven Gatling.
Ausführung von Unit-Tests mit JUnit.
Durchführung von Integrationstests mit Arquillian oder Maven Surefire Plugin.
Statische Quellcode-Analyse mit PMD, Checkstyle und Findbugs.
Schwachstellenanalyse mit OWASP.
Durchführung von Tests von SOAP-basierten Schnittstellen mit SoapUI.

6.1.2. Überprüfung

Vor der Überführung einer neuen Softwareversion (ein Inkrement, siehe Scrum) in den produktiven Betrieb durchläuft diese einen definierten Qualitätssicherungsprozess. Zunächst wird der Quellcode durch die Entwickler des Auftragnehmers auf dessen Systemen geprüft und anschließend durch die Qualitätssicherung (QS) des Auftragnehmers ausgiebig getestet.

Die Übergabe des Quellcodes an den Auftraggeber erfolgt erst nach erfolgreichem Abschluss dieser internen Tests. Anschließend führt der Auftraggeber eine eigene Prüfung sowie den Build-Prozess durch und deployt die Version auf den kundeneigenen Testsystemen. Nach erfolgreichen fachlichen und technischen Abnahmetests des MVP und des Endprodukts wird die Software für das Produktivsystem freigegeben.

Der Prozess umfasst obligatorische Regressionstests (möglichst automatisiert) sowie spezifische Verifizierungstests der vorgenommenen Änderungen. Dabei ist eine Testabdeckung von mindestens 30 % durch Unit- und Integrationstests sicherzustellen.

6.2. Umfang der Lieferung

Die Artefakte können in Teillieferungen bereitgestellt werden. Die Aufteilung in verschiedene Teillieferungen und der konkrete Liefertermin werden im Rahmen der Projektplanung oder während der Sprints zwischen den Vertragsparteien vereinbart. Die folgende Tabelle gibt einen Überblick über die wichtigsten Softwarekomponenten, Dokumentationen und 60 29.07.2026 09:25

[Seite 62]

Anforderungen (Spezifikationen) EUginius 2.0

unterstützenden Materialien, die im Rahmen der Lieferung bereitgestellt werden. Dadurch wird sichergestellt, dass alle notwendigen Artefakte, Handbücher und Anleitungen, in digitaler Form, enthalten sind, um die erfolgreiche Installation, den Betrieb und die Verwaltung des Systems zu erleichtern.

	Beschreibung			Bewertung
Lieferung der Software / Artefakte: - Eine verlässliche Version des kompletten Quellcodes (inkl. DB-Skripte) muss vom Auftragnehmer in digitaler Form zur Verfügung gestellt werden. - Das Open-Source-Repository git wird vom Client zur Verwaltung des Quellcodes verwendet. - Der bereitgestellte Quellcode muss als Projekt in die Entwicklungsumgebung Eclipse oder IntelliJ IDEA importiert werden können. Es muss möglich sein, mit dem MAVEN-Build-Tool in der Entwicklungsumgebung alle notwendigen Artefakte (jar-, war-, ear- Dateien) zu erzeugen, die auf dem Anwendungsserver zur Ausführung der Anwendung benötigt werden. - Eine umfassende Dokumentation des Quellcodes ist erforderlich, damit eine Anpassung bzw. Konfiguration durch Dritte möglich ist. - Jede zusätzliche Software, die für die Installation und die Grundkonfiguration erforderlich ist und über die bereits vorhandenen Funktionen hinausgeht, muss vom Auftragnehmer bereitgestellt werden. - Bei jeder Version muss die Lieferung der vollständigen Anwendung erfolgen. - Wenn eine Neuinstallation unvermeidlich ist, muss die Anzahl der Aktualisierungsskripte minimiert werden.			MUSS
Installations- und Betriebsanleitung - Die technische Anleitung zur Installation der Software muss eine detaillierte Beschreibung aller Installations- und Konfigurationsschritte enthalten, die für die Inbetriebnahme der Anwendung erforderlich sind. - Darüber hinaus müssen die Dokumente eine Beschreibung der technischen Rahmenbedingungen und Maßnahmen enthalten, die für die Nutzung der Anwendung umgesetzt werden müssen. - Eine ausführliche Anleitung für die Inbetriebnahme neuer Softwareversionen muss alle erforderlichen Teilschritte enthalten:  Übertragung des Quellcodes in das Git-Repository.  Übertragung des Quellcodes in die Entwicklungsumgebung.			MUSS

61 29.07.2026 09:25

[Seite 63]

Anforderungen (Spezifikationen) EUginius 2.0

 Erstellen einer neuen Version.  Konfiguration und Bereitstellung der neuen Version auf dem Anwendungsserver.  Beschreibung der erforderlichen Datenbankanpassungen und Migrationsmaßnahmen für die Datenmigration von EUginius 1.0 auf die Anwendung EUginius 2.0.  Beschreibung der Konfigurationsmaßnahmen zur Realisierung der Anwendung auf Basis des o. g. Anwendungsservers (siehe Abschnitt 3.1.1).
System-Handbuch Das Systemhandbuch muss die technische Dokumentation der Anwendung enthalten, einschließlich einer detaillierten technischen Dokumentation der Architektur und des Datenbankschemas.	MUSS
Fachadministratoren- und Nutzerhandbuch Das Fachadministratoren- und Nutzerhandbuch muss eine Beschreibung der Struktur und der Funktionen der Nutzeroberfläche aus Anwendersicht enthalten und sowohl im PDF- als auch im HTML-Format beim Auftraggeber vorliegen.	MUSS
Bereitstellung der Systemtestfälle Der Auftragnehmer muss die Dokumentation und die Implementierung von Systemtestfällen (z. B. soapUI, Selenium, Arquillian, JUnit) digital bereitstellen, damit der Auftraggeber die Gesamtfunktionalität, einschließlich der Nutzeroberfläche und der Webservice-Schnittstelle überprüfen kann.	MUSS
Ausschließlich bei der Lieferung des Endproduktes benötigt: Dokumentation der Webservice-Schnittstelle - Der Auftragnehmer muss eine umfassende Dokumentation für die Webanwendung bereitstellen, einschließlich der technischen Dokumentation für die Architektur, die APIs, die Schnittstelle und die an der Schnittstelle ausgetauschten Daten und deren Formate. Die Schnittstellenbeschreibung muss alle Informationen enthalten, die zur Nutzung der Webdienste durch eine Webdienst-Client-Anwendung erforderlich sind. - Für alle Endnutzenden der Anwendung muss je nach Bedarf eine digitale Nutzerdokumentation erstellt werden. - Die Beschreibung der technischen Eigenschaften der Webservice- Schnittstelle, ihrer Dokumentation und aller angezeigten Inhalte muss in englischer Sprache erfolgen.	MUSS

62 29.07.2026 09:25

[Seite 64]

Anforderungen (Spezifikationen) EUginius 2.0

6.3. Abnahme

Die Anwendung EUginius 2.0 muss vom Auftragnehmer in abnahmebereitem Zustand an den Auftraggeber geliefert und auf einer vom Auftraggeber bereitgestellten Testumgebung installiert werden. Der Auftraggeber muss dem Auftragnehmer die erfolgreiche Abnahme des IT-Systems erklären, wenn alle aufgeführten Abnahmekriterien erfüllt sind.

6.3.1. Abnahmetests

Die Abnahmetests von MVP und Endprodukt werden vom Auftraggeber durchgeführt und umfassen die folgenden Kriterien:

Entwicklung eines Abnahmetestkatalogs, der Testfälle enthält, mit denen die Erfüllung der funktionalen und nicht-funktionalen Anforderungen, wie sie in den Projektspezifikationen oder User Stories spezifiziert sind, überprüft werden kann.
Erfolgreiche Durchführung der Abnahmetests, die im Abnahmetestkatalog aufgeführt sind. Dazu gehören die folgenden Testarten:

 Überprüfung der funktionalen und nicht-funktionalen Anforderungen darunter auch spezialisierte Leistungstests mit Schwerpunkt auf Durchsatz und Reaktionszeit  Überprüfung der Vollständigkeit und Richtigkeit der System- und Nutzerdokumentation

6.3.2. Hinweis zu den Abnahmen

Das Erreichen der Meilensteine sowie das erfolgreiche Durchführen und Dokumentieren der erforderlichen Prüfungen und Abnahmetests sind die Bedingungen, unter den das MVP und das Endprodukt als erfolgreich umgesetzt deklariert werden können. In diesem Fall erfolgt jeweils die Abnahme.

Zur Unterstützung des Abnahmeprozesses:

Zur Dokumentation festgestellter Fehler sowie zur Nachverfolgung ihrer Behebung wird ein Ticketsystem eingesetzt.
Zwischen den Vertragsparteien finden voraussichtlich wöchentlich Telefon- oder Videokonferenzen statt, in denen der Fortschritt der Testdurchführung erörtet und Maßnahmen zur Fehlerbehebung abgestimmt werden.

63 29.07.2026 09:25

[Seite 65]

Anforderungen (Spezifikationen) EUginius 2.0

7. Abkürzungsverzeichnis

	Abkürzung			Erläuterung
API			Application Programming Interface
AUT			Austria – Österreich
BCH			Biosafety Clearing-House
BITV			Barrierefreie Informationstechnik-Verordnung
BSI			Bundesamt für Sicherheit in der Informationstechnik
BVL			Bundesamt für Verbraucherschutz und Lebensmittelsicherheit (www.bvl.bund.de)
CBI			Confidential Business Information – Vertrauliche Geschäftsinformationen
CSS			Cascading Style Sheets
DB			Datenbank
DIN / EN / ISO			Deutsches Institut für Normung e.V. / Europäische Norm / Internationale Organisation für Normung
DNA			deoxyribonucleic acid – Desoxyribonukleinsäure
DSGVO			Datenschutz-Grundverordnung
EG			Europäische Gemeinschaft
EU			Europäische Union
FA			Funktionale Anforderungen
GE-GVO			Geneditierter Gentechnisch veränderter Organismus
GMO/GVO			Genetically Modified Organism – Gentechnisch veränderter Organismus
GUI			Graphical User Interface
HTML			Hypertext Markup Language
http			Hypertext Transfer Protocol
HTTPS			Hypertext Transfer Protocol Secure

64 29.07.2026 09:25

[Seite 66]

Anforderungen (Spezifikationen) EUginius 2.0

IP	Internet Protocol
IT	Informationstechnologie
ITA	Italien
Java EE / Jakarta EE	Java Enterprise Edition / Jakarta Enterprise Edition
Java SE	Java Platform, Standard Edition
GFS	Gemeinsame Forschungsstelle
JSON	JavaScript-Objekt-Notation
LTS	Long Term Support
NFA	Nicht-funktionale Anforderungen
NGT	Neue genomische Techniken
PCR	polymerase chain reaction – Polymerase-Kettenreaktion Standard-Nachweismethode in der GVO-Analytik
PDF	portable document format von Adobe Systems
REST	Representational State Transfer
RHBK	Red Hat build of Keycloak
RHEL	Red Hat Enterprise Linux
RH-SSO	Red Hat Single Sign-On
SAGA	Standards und Architekturen für E-Government-Anwendungen
SOAP	Simple Object Access Protocol
SQL	Structured Query Language
SSHA-512	Salted Secure Hash Algorithm
SSO	Single sign-on
TLS	Transport Layer Security
UML	Unified Modeling Language

65 29.07.2026 09:25

[Seite 67]

Anforderungen (Spezifikationen) EUginius 2.0

TR	Technical requirement
UTF-8	Unicode Transformation Format – 8 Bits
W3C	World Wide Web Consortium
WFSR	Wageningen Food Safety Research
WSDL	Web Services Description Language
UID	Unique identifier – eindeutiger Identifikator von GVO
XÖV	XML in der öffentlichen Verwaltung
XML	Extensible Markup Language

66 29.07.2026 09:25

01b_Anhang_B Anforderungen_Lastenheft.pdf

Anhang B:

- Anforderungen_Lastenheft -

Neuentwicklung der EUginius-Webanwendung

("EUginius 2.0")

Version: 1.0

1. Einleitung

2. Projektmanagement

3. Technische Anforderungen

4. Funktionale Anforderungen

5. Nicht-funktionale Anforderungen

6. Prüfung, Lieferumfang und Abnahme

7. Abkürzungsverzeichnis