Lastenheft
Lastenheft
Vergabeverfahren
„Lagerverwaltungssystem und Materialflussrechner
für ein automatisiertes Palettenlager“
ECA-2026-035
Seite 1 von 31
Lastenheft
Inhaltsverzeichnis
1 Zweck und Zielsetzung ..................................................................................................................... 4
2 Beschreibung des IST-Systems ......................................................................................................... 5
2.1 Lagerplatztypen ............................................................................................................................. 6
2.2 Ladehilfsmitteltypen ..................................................................................................................... 6
2.3 Einlagerung.................................................................................................................................... 6
2.4 Auslagerung................................................................................................................................... 6
2.5 Optimierungen .............................................................................................................................. 7
2.6 Betriebsarten................................................................................................................................. 7
2.7 Systemlandschaft .......................................................................................................................... 7
3 Anforderungen ................................................................................................................................ 8
3.1 Nicht funktionale Anforderungen ................................................................................................. 8
3.1.1 Allgemeine Anforderungen .................................................................................................... 8
3.1.2 Architektur .............................................................................................................................. 9
3.1.3 Informationssicherheit allgemein ........................................................................................... 9
3.1.4 Software für technische Anlagen ............................................................................................ 9
3.1.5 Leistungsparameter ......................................................................................................... 10
3.1.6 Interne Komponenten .......................................................................................................... 11
3.1.7 Containerisierung ............................................................................................................ 11
3.1.8 Logging ................................................................................................................................. 13
3.2 Funktionale Anforderungen ........................................................................................................ 13
3.2.1 Lagerprozesse ....................................................................................................................... 13
3.2.1.1 Einlagerung ............................................................................................................ 13
3.2.1.2 Auslagerung ............................................................................................................ 14
3.2.1.3 Umlagerung ............................................................................................................. 14
3.2.1.4 Durchlagerung ......................................................................................................... 15
3.2.2 Materialflusssteuerung / Transportsteuerung ..................................................................... 15
3.2.3 Lagerverwaltung ................................................................................................................... 16
3.2.4 Lager-Optimierung ................................................................................................................ 17
3.2.5 Graphische Benutzeroberfläche / UI .................................................................................... 19
3.2.6 Simulation ............................................................................................................................. 19
3.2.7 Bestandsdaten ...................................................................................................................... 20
4 Liefer- und Leistungsumfang ......................................................................................................... 21
4.1 Software-Lieferungen .................................................................................................................. 21
Seite 2 von 31
Lastenheft
4.2 Lizenzen ....................................................................................................................................... 22
4.3 Quellcode .................................................................................................................................... 22
4.4 Dokumentation, Schulungen und Gewährleistung ..................................................................... 23
5 Schnittstellen und Abhängigkeiten ................................................................................................ 25
5.1 Schnittstelle zur SPS .................................................................................................................... 25
5.2 Schnittstelle zu SAP ..................................................................................................................... 25
5.3 Logging ........................................................................................................................................ 26
6 Integrations- und Systemtest, Inbetriebnahme ............................................................................. 27
7 Verzeichnisse ................................................................................................................................. 30
7.1 Abbildungsverzeichnis ................................................................................................................. 30
7.2 Abkürzungsverzeichnis ................................................................................................................ 30
7.3 Kürzel für Anforderungen (IDs) ................................................................................................... 31
Seite 3 von 31
Lastenheft
1 Zweck und Zielsetzung
Dieses Lastenheft dient der Ausschreibung eines softwarebasierten Lagerverwaltungssystems (LVS) einschließlich Materialflussrechnerfunktionen (MFR) für das automatisierte Palettenlager (APL) der Bundesdruckerei (BDr).
Das Lastenheft beschreibt die fachlichen, funktionalen sowie nicht funktionalen Anforderungen der verschiedenen Stakeholder an das zu liefernde System.
Die Anforderungen in diesem Dokument sind nur so weit konkretisiert, wie sie für die Ausschreibung notwendig sind. Nach Ausschreibung, Vergabe und Projektstart werden die Anforderungen im Rahmen einer Feinspezifikation gemeinsam mit dem Auftragnehmer konkretisiert und detailliert.
Das neue LVS soll das bereits bestehende ablösen. Die hierfür erforderlichen Anforderungen und Rahmenbedingungen sind Bestandteil dieses Lastenheftes.
Nicht Gegenstand dieses Lastenheftes sind Anforderungen im Zusammenhang mit der Beschaffung von Hardware zur Bereitstellung des neuen LVS. Notwendige Hardware wird durch die Bundesdruckerei bereitgestellt.
Seite 4 von 31
Lastenheft
2 Beschreibung des IST-Systems
Das LVS ist für die Lagerverwaltung, Materialflusssteuerung und Lageroptimierung des APL verantwortlich. Transportaufträge wie Ein- und Auslagerungen werden allerdings von einem bestandsführenden SAP WM initiiert. Das LVS fungiert als Subsystem des SAP WM.
Alle Aktivitäten zum Ein- und Auslagern in das APL sowie zu einer bestandswirksamen Statusänderung des eingelagerten Materials werden immer über einen vom SAP erzeugten Transportauftrag initiiert. Eingaben der Bediener erfolgen hauptsächlich in Dialogen des SAP WM, die LVS-Software bietet hauptsächlich Dialoge zur Anzeige von Informationen und Überwachung der Transporte innerhalb des APL.
Auch die Stammdaten der Artikel werden ausschließlich im SAP WM verwaltet und per Schnittstelle ans LVS übertragen.
In der folgenden Abbildung 1 ist das APL als Querschnitt mit seinen Komponenten dargestellt.
Abbildung 1: Schematischer Querschnitt des APL
Komponenten und Aufbau des APL:
• 3298 Lagerplätze • 11 Fahrgassen in 5 Ebenen o Ebene 1: Fahrgassen 0 – 1 o Ebene 2: Fahrgassen 2 – 3 o Ebene 3: Fahrgassen 4 – 5 o Ebene 4: Fahrgassen 6 – 7 o Ebene 5: Fahrgassen 8 – 10 • 8 Vorzonen zum Ein- und Auslagern • 3 Shuttles zum Transportieren der Paletten • 1 Heberschacht mit 1 Heber zum Umsetzen der Shuttles in eine andere Fahrgasse
Die einzelnen Ebenen sind durch Brandschutzdecken voneinander getrennt. Mittels des Hebers werden die einzelnen Shuttles inkl. Europalette in eine andere Gasse transportiert und umgesetzt.
Das APL besitzt 8 Vorzonen an denen Paletten ein- und ausgelagert werden können. Diese sind in der Abbildung 1 mit den Buchstaben L1, L2, L3, L4, K1, S1, S3 und R1 bezeichnet.
Seite 5 von 31
Lastenheft
2.1 Lagerplatztypen
Die Lagerplätze des APL werden in folgende 6 Lagerplatztypen unterschieden und vom LVS verwaltet.
| Bezeichnung | Maximale Höhe in cm | maximale Tragkraft in kg |
|---|---|---|
| T1 | 110 | 500 |
| T2 | 150 | 500 |
| T3 | 190 | 500 |
| T4 | 110 | 1250 |
| T5 | 150 | 1250 |
| T6 | 190 | 1250 |
2.2 Ladehilfsmitteltypen
Bei der Einlagerung werden die Europaletten automatisch durch eine Höhen- und Gewichtskontrolle geprüft und in folgende Lagerplatztypen eingeteilt:
| Bezeichnung | Maximale Höhe in cm | maximale Tragkraft in kg |
|---|---|---|
| LHT-500-110 | <= 110 | <= 500 |
| LHT-500-150 | <= 150 | <= 500 |
| LHT-500-190 | <= 190 | <= 500 |
| LHT-1250-110 | <= 110 | 500 <= Gewicht <= 1250 |
| LHT-1250-150 | <= 150 | 500 <= Gewicht <= 1250 |
| LHT-1250-190 | <= 190 | 500 <= Gewicht <= 1250 |
2.3 Einlagerung
Einzulagernde Paletten müssen auf die Fördertechnik der Vorzone aufgesetzt und mit einem am Produktionsrechner (Windows-Betriebssystem) angeschlossenen Scanner abgescannt werden. Für die aufgesetzte Palette muss bereits zuvor ein Transportauftrag von SAP WM an die LVS-Software übertragen worden sein. Dies wird beim Abscannen des Barcodes der Palette vom LVS geprüft. Liegt kein Transportauftrag vor, wird dies dem Mitarbeiter angezeigt und er muss die Palette wieder von der Fördertechnik nehmen. Existiert ein gültiger Transportauftrag vom SAP für die Palette, wird die Palette zunächst durch eine Gewichts- und Konturenkontrolle gemessen und klassifiziert (siehe 2.2). Anschließend wird die Palette auf einem geeigneten Lagerplatz (siehe 2.1) eingelagert. Wurde die Palette erfolgreich ins APL eingelagert, wird sie mit einem IDOC ans SAP WM quittiert.
2.4 Auslagerung
Auslagerungen werden direkt über das SAP WM ausgelöst und angestoßen. Der Transportauftrag wird vom SAP an das LVS übertragen. Je nach verwendeter Auslagerungsstrategie (Vorgabe vom SAP, z.B. Palettenauswahl nach Material und Menge oder explizite Einzelpalette) sucht das LVS die genannte oder eine passende Palette nach Material und Menge und lagert diese an der vorgebeben Ziel-Vorzone aus. Die Auslagerung wird mit einem entsprechenden IDOC vom LVS ans SAP bestätigt. Als Letztes muss der Mitarbeiter die Auslagerung und Abnahme der Palette von der Fördertechnik im SAP quittieren. Damit ist der Auslagerungsvorgang abgeschlossen.
Seite 6 von 31
Lastenheft
2.5 Optimierungen
Das LVS nutzt derzeit verschiedene Optimierungsstrategien, um die Paletten im APL optimal zu lagern und zu positionieren. Durch eine optimierte Platzierung häufig benötigter Artikel in der Nähe der Zielzonen, werden die Durchlaufzeiten des Lagers verkürzt und die Gesamtleistung des APL verbessert. Die Lagerplatz-Optimierung dient der effizienteren Nutzung der Lagerplätze im APL sowie der Reduzierung von Wegzeiten und Suchaufwänden im operativen Betrieb.
2.6 Betriebsarten
Das bestehende System unterstützt vier verschiedene Betriebsarten für den Betrieb der technischen Anlage und Fördertechniken.
Im Automatikbetrieb erfolgen Transportaufträge sowie Materialflüsse vollständig systemgesteuert durch das Lagerverwaltungssystem bzw. die Materialflusssteuerung.
Im Handbetrieb können einzelne Anlagenkomponenten oder Bereiche unabhängig vom automatischen Betrieb manuell gesteuert werden.
Im Störungsbetrieb können betroffene Anlagenbereiche eingeschränkt oder nicht verfügbar sein. Das System muss in diesem Fall betroffene Komponenten entsprechend berücksichtigen.
Der Wartungsbetrieb dient der Durchführung von Service-, Prüf- oder Instandhaltungsarbeiten. Anlagen oder Anlagenteile können hierbei gezielt vom automatischen Betrieb ausgeschlossen werden.
2.7 Systemlandschaft
Die folgende Darstellung zeigt die Systemlandschaft des bestehenden Systems sowie die wesentlichen Kommunikationsbeziehungen zwischen den beteiligten Komponenten.
SAP
LVS / MFR
SPS Datenbank
Technische Anlagen
(Shuttles, Fördertechniken, Heber)
Seite 7 von 31
Lastenheft
3 Anforderungen
Die nachfolgend beschriebenen Anforderungen umfassen sowohl klassische Funktionen eines Lagerverwaltungssystems (LVS) als auch Funktionen eines Materialflussrechners (MFR). Aufgrund der engen funktionalen und technischen Verzahnung beider Bereiche erfolgt im Rahmen dieses Lastenheftes keine vollständige Trennung der Anforderungen zwischen LVS- und MFR-Funktionen.
Alle Anforderungen dieses Lastenhefts werden im Rahmen des Vergabeverfahrens hinsichtlich ihrer Verbindlichkeit klassifiziert. Die Einstufung erfolgt durch die Schlüsselwörter „MUSS“, „SOLL“ und „KANN“ gemäß der nachfolgenden Definition:
MUSS: Das Schlüsselwort „MUSS“ kennzeichnet zwingend zu erfüllende Anforderungen (Ausschlusskriterien). Die Nichterfüllung eines Muss-Kriteriums führt zum Ausschluss des Angebots vom weiteren Vergabeverfahren.
SOLL: Das Schlüsselwort „SOLL“ kennzeichnet gewichtete Anforderungen, deren Erfüllungsgrad in die Bewertung einfließt. Abweichungen sind zulässig, müssen jedoch im Angebot nachvollziehbar begründet werden und wirken sich auf die Bewertung aus.
KANN: Das Schlüsselwort „KANN“ kennzeichnet optionale oder ergänzende Anforderungen. Diese werden nicht im Sinne eines Ausschluss- oder Mindestkriteriums bewertet, können jedoch positiv in die Gesamtbewertung einfließen, sofern sie einen Mehrwert darstellen.
3.1 Nicht funktionale Anforderungen
3.1.1 Allgemeine Anforderungen
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_GEN-1 | Das System muss gewährleisten, dass sich die Komponenten bei jeglicher Kommunikation authentifizieren. | MUSS |
| REQ_GEN-2 | Das System muss für Serverapplikationen, falls vorhanden, das Betriebssystem Microsoft Windows Server 2025 unterstützen. | MUSS |
| REQ_GEN-3 | Wird im System RDBMS verwendet, soll PostgreSQL genutzt werden. | SOLL |
| REQ_GEN-4 | Der Einsatz anderer Datenbanktechnologien bedarf der Zustimmung der BDr. Der Auftragnehmer hat die Auswirkungen auf Betrieb, Administration, Lizenzierung, Monitoring, Backup und Wieder- herstellung darzulegen. | MUSS |
| REQ_GEN-5 | Das System muss dem Benutzer eine Möglichkeit zur Verfügung stellen, das Intervall für automatische Archivierungsläufe einzustellen. | MUSS |
| REQ_GEN-6 | Das System muss es ermöglichen, die Kommunikation der einzelnen Systemkomponenten untereinander zu verschlüsseln. | MUSS |
Seite 8 von 31
Lastenheft
REQ_GEN-7 Der Auftragnehmer muss das Erstellen und Liefern eines MUSS Pflichtenheftes, erstellt auf Basis dieses Lastenheftes, anbieten. Das Pflichtenheft muss unter anderem einen Meilensteinplan mit Terminen und Testkonzept enthalten.
3.1.2 Architektur
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_AR-1 | Die Softwarearchitektur der technischen Anlage muss dem „Referenzarchitekturmodell Industrie 4.0“ RAMI4.0 des VDE/CDI GMA-Fachausschuss Industrie 4.0 entsprechen. Abweichungen hiervon benötigen die Zustimmung der BDr. | MUSS |
| REQ_AR-2 | Alle Softwarebestandteile müssen in der CP Klassifizierung CP44 oder mindestens CP43 nach VDI CP-Klassifikation eingeordnet werden können. | MUSS |
3.1.3 Informationssicherheit allgemein
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_ITS-1 | Die anwendbaren Maßnahmen aus den BSI IT-Grundschutz- Katalogen für IT-Systeme in der Version zum Zeitpunkt der Angebotsabgabe müssen vom Auftragnehmer umgesetzt werden, respektive durch die BDr auf den gelieferten Komponenten umsetzbar sein. | MUSS |
| REQ_ITS-2 | Die Verwendung von lokalen Passwörtern DARF NICHT im Klartext erfolgen. Beispielsweise ist eine Verschlüsselung oder ein Hash zu wählen. | MUSS |
| REQ_ITS-3 | Bei lokalen Passwörtern muss der verwendete Algorithmus und deren Schlüssellänge mit der BDr abgestimmt werden. | MUSS |
| REQ_ITS-4 | Die Vorgaben des BSI IT-Grundschutz zu Authentifizierung und Verschlüsselung muss eingehalten werden. | MUSS |
| REQ_ITS-5 | Um Verfügbarkeit, Integrität und Vertraulichkeit der Geschäftsprozesse der BDr zu gewährleisten, müssen Sicherheitslücken behoben werden können. | MUSS |
| REQ_ITS-6 | Die Funktionsfähigkeit der gelieferten Komponenten muss nach Sicherheitsupdates gewährleistet sein. | MUSS |
| REQ_ITS-7 | Es muss der BDr ermöglicht werden, Schutz vor Schadsoftware auf allen Systemen zu installieren. | MUSS |
| REQ_ITS-8 | Hard- und Software muss mit aktivem zentral verwalteten Virenscanner uneingeschränkt funktional sein. | MUSS |
3.1.4 Software für technische Anlagen
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_SW-1 | Als Betriebssystem für Clients muss im Test- und Produktionszustand in der BDr Windows 11 IoT Enterprise LTSC 2024 64 Bit Enterprise verwendet werden. | MUSS |
| REQ_SW-2 | Alle zur technischen Anlage gehörige Software muss passend für dieses Betriebssystem gewählt bzw. entwickelt werden. | MUSS |
Seite 9 von 31
Lastenheft
| REQ_SW-3 | Die Installationen von Softwarekomponenten muss unter den Programmverzeichnissen von Microsoft erfolgen. Abweichungen hiervon benötigen die Zustimmung der BDr. | MUSS |
|---|---|---|
| REQ_SW-4 | Die Softwarekomponente DARF NICHT Schreibrechte auf Systemverzeichnisse von Windows zur Ausführung benötigen (Programmverzeichnisse, Windowsverzeichnis, etc.). | MUSS |
| REQ_SW-5 | In der BDr existieren strenge Richtlinien zur Sicherheit von IT- Systemen. Das Betriebssystem und die Softwareinstallation werden bei der BDR einer Härtung unterzogen. Die volle Funktion der Software muss in diesem gehärteten Umfeld gegeben sein. | MUSS |
| REQ_SW-6 | Zur Einrichtung der Software im gehärteten Umfeld muss Unterstützung in den Räumlichkeiten der BDr geleistet werden. | MUSS |
| REQ_SW-7 | ID- und Access-Management inkl. Rollen, notwendige Rechte muss durch den Auftragnehmer exakt spezifiziert werden. | MUSS |
| REQ_SW-8 | Zur Benutzer- bzw. Rollenverwaltung muss die gelieferte Software über eine Active-Directory-Anbindung verfügen. | MUSS |
| REQ_SW-9 | Eine Benutzerverwaltung der gelieferten Software, DARF NICHT ausschließlich lokal stattfinden. | MUSS |
| REQ_SW-10 | Die gelieferte Software DARF NICHT die Rechte eines Benutzers mit Administratorrechten erfordern. | MUSS |
| REQ_SW-11 | Die Protokollierung/Logging muss konfigurierbar gestaltet werden. | MUSS |
| REQ_SW-12 | Diese Konfigurationsparameter müssen mindestens sein: Loglevel, Speicherort, Größe, Aufbewahrungsdauer, Log-Rotation. | MUSS |
| REQ_SW-13 | Die Protokollierung/Logging in höchsten Level (bzw. Trace) kann schutzbedürftige (z.B. personenbezogene Daten, Passwort, Schlüssel, etc.) Daten enthalten. | KANN |
| REQ_SW-14 | Bei Protokollierung/Logging in Loglevel niedrigeres Trace, muss eine Protokollierung ohne schutzbedürftige Daten erfolgen. | MUSS |
| REQ_SW-15 | Die Protokollierung/Logging muss in Textform erfolgen. | MUSS |
3.1.5 Leistungsparameter
Das zu liefernde IT-System muss Prozesse mit annehmbarem Zeitaufwand bewältigen können. Dies muss auch bei stark gefüllten Datenbanken erbracht werden. Deshalb sind die folgenden Anforderungen sowohl bei wenig Datensätzen als auch bei vielen Datenbankeinträgen zu leisten.
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_PERF-1 | Das System muss für die Verarbeitung und Verwaltung der folgenden Datenmengen ausgelegt sein: • Journaldaten ≥ ca. 4 Millionen Datensätze • Buchungsdaten ≥ ca. 3 Millionen Datensätze • Archivdaten ≥ ca. 3 Millionen Datensätze • Auftragsdaten ≥ ca. 1 Million Datensätze Die angegebenen Datenmengen stellen die erwarteten Betriebsgrößen dar. Das System muss unter diesen Bedingungen die definierten Leistungsparameter einhalten. | MUSS |
| REQ_PERF-2 | Das System muss Rückmeldungen, wie beispielweise OK- Meldung, Fehler-Meldung, welche über die graphischen Userinterfaces der Client-Anwendungen an den User erfolgen, | MUSS |
Seite 10 von 31
Lastenheft
| innerhalb von 500ms erzeugt und an dem entsprechenden Userinterface ausgegeben haben. Funktionen innerhalb großer Datenbankbestände müssen innerhalb von 5000ms erfolgen. Dabei gewährleistet die BDr den notwendigen Durchsatz und Bandbreite der beteiligten Netzwerkkomponenten. | ||
|---|---|---|
| REQ_PERF-3 | Das System muss die in REQ_CMS-7 definierte Leistungsfähigkeit über die gesamte Betriebsphase dauerhaft gewährleisten. Der Auftraggeber ist berechtigt, den Nachweis der Leistungsfähigkeit jederzeit unter den in REQ_CMS-7 definierten Randbedingungen erneut zu verlangen. | MUSS |
3.1.6 Interne Komponenten
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_COMP-1 | Das IT-System muss mindestens eine Serverapplikation bereitstellen, die die zentralen Systemfunktionen verarbeitet und bereitstellt. | MUSS |
| REQ_COMP-2 | Die Serverkomponente muss den Betrieb in containerisierten Umgebungen unterstützen (siehe auch 3.1.7). | MUSS |
| REQ_COMP-3 | Die Client-Anwendung muss eine rollenbasierte Zugriffsteuerung unterstützen, bei der Funktionen abhängig von den zugewiesenen Berechtigungen für Benutzergruppen freigegeben oder eingeschränkt werden. | MUSS |
| REQ_COMP-4 | Die Client-Anwendung muss eine gleichzeitige Nutzung durch mehrere Benutzer unterstützen. | MUSS |
| REQ_COMP-5 | Das IT-System muss eine persistente Datenspeicherung in Form einer Datenbank bereitstellen (siehe auch REQ_GEN-3). | MUSS |
3.1.7 Containerisierung
Für den Betrieb der Serverkomponente in einer containerisierten Umgebung sind folgende Anforderungen zu erfüllen.
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_CON-1 | Die Software muss als OCI-Container-Image bereitgestellt werden und darf keinen WebLogic/Application Server voraussetzen. | MUSS |
| REQ_CON-2 | Die Software muss auf Red Hat OpenShift (supported Version des Betreibers) lauffähig sein. | MUSS |
| REQ_CON-3 | Die Anwendung muss OpenShift “restricted”/SCC-konform betrieben werden (Non-Root, keine Privileged Container). | MUSS |
| REQ_CON-4 | Container müssen als Non-Root laufen und keine festen UIDs voraussetzen (OpenShift vergibt UIDs dynamisch). | MUSS |
| REQ_CON-5 | Root-Filesystem muss read-only sein; Schreibzugriffe nur in definierte, gemountete Verzeichnisse. | MUSS |
| REQ_CON-6 | Konfiguration muss über ConfigMaps/Environment erfolgen; Secrets ausschließlich über OpenShift/Kubernetes Secrets oder angebundenen Secret-Manager. | MUSS |
| REQ_CON-7 | Deployment-Artefakte müssen OpenShift-kompatibel sein (Helm/Kustomize/YAML) inkl. Namespaces/Projects. | MUSS |
Seite 11 von 31
Lastenheft
| REQ_CON-8 | Exponierung nach außen muss via OpenShift Route (TLS) erfolgen (nicht via NodePort). | MUSS |
|---|---|---|
| REQ_CON-9 | Service-Definitionen müssen OpenShift/Kubernetes -Services nutzen; Ports/Protokolle sind dokumentiert. | MUSS |
| REQ_CON-10 | Readiness/Liveness/Startup Probes müssen implementiert sein. | MUSS |
| REQ_CON-11 | Ressourcen (CPU/RAM) müssen mit requests/limits definiert sein; Sizing-Empfehlungen sind anzugeben. | MUSS |
| REQ_CON-12 | Die Anwendung muss horizontal skalierbar sein; Skalierung über HPA/EDA (falls vorhanden) möglich. | MUSS |
| REQ_CON-13 | Rollouts müssen Rolling Updates unterstützen; Rollback muss möglich sein. | MUSS |
| REQ_CON-14 | Die Anwendung muss graceful shutdown unterstützen (SIGTERM) und definierte TerminationGracePeriod einhalten. | MUSS |
| REQ_CON-15 | Logging muss nach stdout/stderr erfolgen; Integration in OpenShift Logging Stack muss möglich sein. | MUSS |
| REQ_CON-16 | Metriken müssen bereitgestellt werden (z. B. /metrics Prometheus) und ins OpenShift Monitoring integrierbar sein. | MUSS |
| REQ_CON-17 | Netzwerkzugriffe müssen durch NetworkPolicies einschränkbar sein (Least Privilege). | MUSS |
| REQ_CON-18 | Container-Images müssen gebaut, signiert und gescannt werden. | MUSS |
| REQ_CON-19 | Die Nutzung von OpenShift ImageStreams und BuildConfigs ist optional. | KANN |
| REQ_CON-20 | Falls persistente Daten benötigt werden, muss die Anwendung PersistentVolumeClaims unter Verwendung von OpenShift- StorageClasses unterstützen. | MUSS |
| REQ_CON-21 | Applikations-User/Permissions innerhalb des Containers müssen so gestaltet sein, dass SCC keine Sonderfreigaben benötigt. | MUSS |
| REQ_CON-22 | Die Lösung muss mandanten- und umgebungsfähig sein (dev/test/prod) über Werte/Overlays (Helm values, Kustomize). | MUSS |
| REQ_CON-23 | Es muss eine Betriebsdokumentation OpenShift geben (Routes, Probes, Scaling, Logging, Monitoring, SCC/Policies, Troubleshooting). | MUSS |
| REQ_CON-24 | Build- und Runtime-Umgebung müssen getrennt sein. | MUSS |
| REQ_CON-25 | Runtime-Container dürfen keine Build-Werkzeuge, Package- Manager oder unnötigen Systemwerkzeuge enthalten. | MUSS |
| REQ_CON-26 | Das System muss eine Software Bill of Materials (SBOM) bereitstellen, die eine strukturierte Übersicht über die in der Software verwendeten Komponenten, Bibliotheken und Abhängigkeiten enthält. Die SBOM muss insbesondere eine Übersicht über die verwendeten Drittanbieter-Komponenten sowie deren Lizenzinformationen enthalten. Die SBOM muss in maschinenlesbaren Formaten (z.B. JSON, XAML) sowie in lesbaren Formaten (z.B TXT, HTML, PDF oder Markdown) exportierbar sein. | MUSS |
Seite 12 von 31
Lastenheft
3.1.8 Logging
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_LOG-1 | Das System muss eine zentrale Protokollierung von System- und Anwendungsereignissen anhand von Log-Dateien bereitstellen. Dabei müssen sowohl Fehlermeldungen als auch Informations- und Statusmeldungen erfasst werden. (Siehe auch Schnittstellen-Logging 5.3) | MUSS |
| REQ_LOG-2 | Die Protokollierung muss eine Nachvollziehbarkeit von Systemabläufen sowie eine Analyse von Fehlerzuständen ermöglichen. | MUSS |
| REQ_LOG-3 | Alle Log-Dateien müssen täglich verwaltet und archiviert werden. | MUSS |
| REQ_LOG-4 | Die Log-Einträge müssen mindestens folgende Informationen enthalten: • Zeitstempel • Art des Ereignisses (z.B. Fehler, Information) • Betroffene Systemkomponente oder Funktion inkl. detaillierten Informationen zu dem Ereignis | MUSS |
3.2 Funktionale Anforderungen
3.2.1 Lagerprozesse
3.2.1.1 Einlagerung
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_INB-1 | Das System muss die Einlagerung von Lagereinheiten (Euro- Palette) auf definierte Lagerplätze unterstützen. Nach dem Abscannen eines von SAP generierten Barcodes, muss ein geeigneter Lagerplatz (2.1) unter Berücksichtigung definierter Kriterien und der Messwerte der Palette (Gewicht und Höhe, siehe 2.2) vom LVS ermittelt werden. | MUSS |
| REQ_INB-2 | Das System muss Transportaufträge für die Fördertechniken, die drei Shuttles und den Heber erzeugen und diese an die angebundenen technischen Anlagen (SPS) übermitteln. | MUSS |
| REQ_INB-3 | Das System muss die Einlagerung der Paletten unter Berücksichtigung konfigurierbarer Einlagerungsstrategien ermöglichen. Hierbei sollen unterschiedliche Strategien (z.B. feste Lagerplätze, Pufferplätze, chaotische Lagerung, zonenbasierte Einlagerung) unterstützt werden. | MUSS |
| REQ_INB-4 | Die Einlagerung muss dokumentiert und im System jederzeit nachvollziehbar sein. | MUSS |
| REQ_INB-5 | Der Status der Palette und des Lagerplatzes muss nach der Einlagerung entsprechend aktualisiert werden. | MUSS |
| REQ_INB-6 | Das System muss nach Abschluss einer Einlagerung eine Rückmeldung an das SAP senden. Dabei müssen sowohl erfolgreiche als auch fehlerhafte Einlagerungen eindeutig quittiert werden. | MUSS |
| REQ_INB-7 | Das System muss die Wiedereinlagerung von Restmengen bei einer Teil-Auslagerung ermöglichen. | MUSS |
Seite 13 von 31
Lastenheft
3.2.1.2 Auslagerung
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_OUT-1 | Das System muss die Auslagerung von Lagereinheiten aus dem APL ermöglichen. | MUSS |
| REQ_OUT-2 | Das System muss Auslagerungen auf Basis von Aufträgen von SAP unterstützen. | MUSS |
| REQ_OUT-3 | Das System muss verschiedene Auslagerungsstrategien unterstützen: • FIFO • FEFO • Prioritätsbasiert • Direkte Anforderung von bestimmten Paletten nach LE- Nummer | MUSS |
| REQ_OUT-4 | Das System muss Transportaufträge für die Fördertechniken, die drei Shuttles und für den Heber erzeugen und diese an die angebundenen technischen Anlagen (SPS) übermitteln. | MUSS |
| REQ_OUT-5 | Das System muss in Ausnahme- bzw. Notfällen eine Auslagerung von Paletten ohne SAP ermöglichen. In diesem Fall muss die Auslagerung nach dem Vier-Augen-Prinzip erfolgen. Die Durchführung und Bestätigung der Auslagerung muss durch zwei voneinander unabhängige, berechtigte Benutzer erfolgen. | MUSS |
| REQ_OUT-6 | Das System muss die Auslagerung von Teilmengen ermöglichen und dabei den Lagerbestand entsprechend aktualisieren. Die entstandene Restmenge muss dann wieder eingelagert werden können, siehe Anforderung REQ_INB-7. | MUSS |
3.2.1.3 Umlagerung
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_INT-1 | Das System muss die Umlagerung von Ladeeinheiten zwischen Lagerplätzen unterstützen. | MUSS |
| REQ_INT-2 | Das System muss sowohl automatische Umlagerungen (z.B. im Rahmen von Optimierungen, siehe 3.2.4) als auch manuelle Umlagerungen durch berechtigte Benutzer unterstützen. | MUSS |
| REQ_INT-3 | Das System muss für Umlagerungen geeignete Ziel-Lagerplätze unter Berücksichtigung definierter Kriterien (z.B. Lagerplatztyp [2.1], Ladehilfsmitteltyp [2.2], Verfügbarkeit, Strategie) ermitteln. | MUSS |
| REQ_INT-4 | Das System muss den Lagerbestand sowie die Zuordnung von Ladeeinheiten zu Lagerplätzen im Zuge der Umlagerung automatisch und konsistent aktualisieren. | MUSS |
| REQ_INT-5 | Das System muss den Status der Umlagerungsaufträge verfolgen und transparent darstellen. | MUSS |
| REQ_INT-6 | Das System muss Umlagerungsstrategien unterstützen (z.B. Verdichtung, Freiräumen von Bereichen, Optimierung von Zugriffszeiten), die von einem berechtigten Benutzer konfiguriert werden müssen. | MUSS |
Seite 14 von 31
Lastenheft
| REQ_INT-7 | Das System muss sicherstellen, dass Umlagerungen und Optimierungen keine Konflikte mit laufenden Ein- oder Auslagerungsprozessen verursachen. | MUSS |
|---|---|---|
| REQ_INT-8 | Umlagerungs- und Optimierungsaufträge müssen gegenüber anderen Transportaufträgen nachrangig mit geringerer Priorisierung behandelt werden. | MUSS |
3.2.1.4 Durchlagerung
Durchlagerungen sind Einlagerungen auf speziell definierte Lagerplätze. Paletten, die sich auf Durchlagerungsplätzen befinden, können nur von berechtigten Benutzergruppen ausgelagert werden.
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_CD-1 | Das System muss die Definition von Durchlagerungsplätzen für berechtigte Benutzer ermöglichen. | MUSS |
| REQ_CD-2 | Durchlagerungen müssen auf definierte Lagerplätze eingelagert werden. | MUSS |
| REQ_CD-3 | Das System muss die Auslagerung von Durchlagerungen auf Basis von Aufträgen von SAP unterstützen. | MUSS |
| REQ_CD-4 | Durchlagerungsaufträge müssen vom System entsprechend gekennzeichnet werden. | MUSS |
3.2.2 Materialflusssteuerung / Transportsteuerung
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_TRN-1 | Das System muss eine Priorisierung von Transportaufträgen ermöglichen. | MUSS |
| REQ_TRN-2 | Priorisierte Aufträge müssen bevorzugt entsprechend ihrer Prio- Rangliste vom System abgearbeitet werden. | MUSS |
| REQ_TRN-3 | Die höchste Priorisierung muss nur von einem berechtigten Benutzer (z.B. Admin) gesetzt werden können. | MUSS |
| REQ_TRN-4 | Das System muss eine Priorisierung von Transportaufträgen unter Berücksichtigung ihrer Verweildauer in der Warteschlange unterstützen. Mit zunehmender Verweildauer muss die Priorität eines Transportauftrages automatisch erhöht werden, sodass ältere Transportaufträge bevorzugt abgearbeitet werden. Die Parameter zur Prioritätssteigerung müssen konfigurierbar sein. | MUSS |
| REQ_TRN-5 | Das System muss die Ausführung von Transportaufträgen unter Berücksichtigung von Priorität und operativer Effizienz steuern. Dabei soll das System in der Lage sein, Transportaufträge situationsabhängig zu optimieren, sodass eine effiziente Nutzung des APL gewährleistet wird. Hierbei dürfen Transportaufträge mit niedriger Priorität bevorzugt ausgeführt werden, sofern dies zu einer effizienteren Gesamtabwicklung führt. Eine dauerhafte Benachteiligung höher priorisierter Transportaufträge muss dabei vermieden werden. | MUSS |
| REQ_TRN-6 | Die Priorisierungen müssen von einem berechtigten Benutzer konfigurierbar sein. | MUSS |
Seite 15 von 31
Lastenheft
| REQ_TRN-7 | Das System muss die Anzahl gleichzeitig aktiver Shuttles je Ebene und Gasse begrenzen können, um einen sicheren und effizienten Betrieb zu gewährleisten. Die Einstellungen müssen konfigurierbar sein. | MUSS |
|---|---|---|
| REQ_TRN-8 | Das System muss betriebliche Einschränkungen bei der Transportplanung berücksichtigen. Dazu zählen alle Lagerkomponenten, die sich nicht im Automatikbetrieb befinden (Sperren, Wartungszustände oder Handbetrieb). | MUSS |
| REQ_TRN-9 | Das System muss in der Lage sein, mehrere Transportaufträge gleichzeitig und parallel auszuführen. Eine sequenzielle Abarbeitung darf nur erfolgen, wenn dies aufgrund von Ressourcenkonflikten, Sicherheitsanforderungen oder Einschränkungen der Lagerkomponenten nicht anders möglich ist. | MUSS |
| REQ_TRN-10 | Das System muss bei Ausfall oder Störung einzelner Lager- Komponenten den Betrieb in nicht betroffenen Bereichen aufrechterhalten. Transportaufträge, die nicht von der Störung betroffen sind, sind weiterhin auszuführen und abzuarbeiten. | MUSS |
3.2.3 Lagerverwaltung
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_WMS-1 | Das LVS muss berechtigen Benutzern (Admin) die Möglichkeit anbieten Lagerplätze mindestens den folgenden unterschiedlichen Verwendungstypen zuzuordnen: • Pufferplatz • Durchlagerungsplatz • Standard-Platz | MUSS |
| REQ_WMS-2 | Lagerplätze, die als Pufferplätze markiert sind, müssen wie folgt verwendet werden. Pufferplätze werden speziell nur für Einlagerungen verwendet und dienen als Zwischenpositionen im APL. Die Pufferplätze werden bevorzugt in den Gassen verwendet, in denen sich Einlagerungspunkte befinden. Bei einer Einlagerung werden die Paletten unabhängig von ihrer eigentlichen Zielzone zuerst auf den Pufferplätze eingelagert. Somit wird der Einlagerungsprozess erheblich beschleunigt und ermöglicht ein schnelles Einlagern von vielen Paletten in kurzer Zeit. Ein späterer Optimierungslauf ist dann zuständig für die Umlagerung dieser Paletten in die entsprechenden Zielzonen. | MUSS |
| REQ_WMS-3 | Die Lagerplatztypen (2.1) der vorhandenen Lagerplätze müssen jederzeit durch berechtigte Benutzer im LVS angepasst bzw. verändert werden können. | MUSS |
| REQ_WMS-4 | Lagerplätze müssen jederzeit durch berechtigte Benutzer hinzugefügt und gelöscht werden können. | MUSS |
Seite 16 von 31
Lastenheft
REQ_WMS-5 Das System muss die Sperrung von Lagerplätzen unterstützen. MUSS Gesperrte Lagerplätze dürfen nicht für automatische Prozesse (Einlagerung, Auslagerung, Umlagerung oder Optimierung) berücksichtig oder verwendet werden. Werden Transportaufträge mit Ladehilfsmitteln auf gesperrten Lagerplätzen erstellt, dürfen diese nicht ausgeführt werden. Es muss eine Meldung erfolgen.
3.2.4 Lager-Optimierung
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_OPT-1 | Das LVS muss Lager-Optimierungsläufe bereitstellen und ausführen, die zur Verbesserung der Lagerplatznutzung und der Effizienz der Lagerprozesse beitragen: • Reduzierung von Transportwegen • Verbesserung der Paletten-Zugriffszeiten • Konsolidierung von Beständen • Freiräumen von Sonderplätzen (z.B.: Pufferplätze, REQ_OPT-10) | MUSS |
| REQ_OPT-2 | Optimierungstransporte müssen immer nachrangig mit geringer Priorität gegenüber Ein- und Auslagerungen behandelt werden. Ein- und Auslagerungen haben immer Vorrang. Optimierungsfahrten dürfen nur ausgeführt werden, wenn sich keine aktiven Ein- oder Auslagerungen im System befinden. Ausnahmen bestehen, wenn aktive Ein- oder Auslagerungen aktuell durch Störungen oder Blockierungen nicht ausgeführt werden können. In diesem Fall können Optimierungsfahrten durchgeführt werden. | MUSS |
| REQ_OPT-3 | Das LVS muss folgende zeitgesteuerte Durchführungen der Lager-Optimierungen ermöglichen: • Planung von Lager-Optimierungen zu definierten Zeitpunkten • Lager-Optimierungen automatisch ausführen, wenn das System einen Optimierungsbedarf erkennt | MUSS |
| REQ_OPT-4 | Die Auswahl und Aktivierung der Optimierungstypen müssen von berechtigten Benutzern konfigurierbar sein. | MUSS |
| REQ_OPT-5 | Alle Optimierungsläufe müssen von berechtigten Benutzern manuell gestartet und auch gestoppt werden können. | MUSS |
| REQ_OPT-6 | Für alle Optimierungen müssen detaillierte grafische Übersichten vorhanden sein für: • Aktuelle Lagerauslastung • Verteilung der Lagerplatztypen • Optimierungspotenzial / Optimierungsbedarf • Freie und belegte Lagerplatzkapazitäten • Status eines Optimierungslaufes (Optimierungsgrad) • Start und Ende mit Datum/Uhrzeit | MUSS |
| REQ_OPT-7 | Durchgeführte Optimierungsläufe müssen für eine spätere Auswertung archiviert werden können. Die Dauer der Datenvorhaltung muss durch berechtigte Benutzer konfigurierbar sein. | MUSS |
Seite 17 von 31
Lastenheft
| REQ_OPT-8 | Die historischen Optimierungsläufe müssen als Datei-Export oder auch als Ausdruck zur Verfügung gestellt werden können. | MUSS |
|---|---|---|
| REQ_OPT-9 | Das LVS muss eine Einzelpaletten-Optimierung unterstützen. Einzelne Paletten müssen manuell von einem berechtigten Benutzer ausgewählt und in einer Liste gespeichert werden können. Diese ausgewählten Paletten werden individuell einer Ziel-Gasse im APL zugeordnet. Wird die Einzel-Optimierung gestartet, werden alle Paletten in die entsprechende Ziel-Gasse umgelagert. Ist die entsprechende Gasse vollständig belegt, muss das LVS entsprechend viele Plätze in der Gasse für die Einzel-Optimierung automatisch freiräumen. Wurden die Plätze freigeräumt, werden die Paletten aus der Liste entsprechend in die Ziel-Gasse umgelagert. Der Bearbeitungsstand aller Paletten in der Einzel-Optimierung muss in der Liste grafisch abgebildet werden. Können Paletten aus einem Grund nicht bearbeitet werden, muss das ebenfalls in der Liste grafisch abgebildet werden. Berechtigte Benutzer müssen Paletten zu jeder Zeit aus der Liste hinzufügen und wieder entfernen können. | MUSS |
| REQ_OPT-10 | Das LVS muss die Pufferplatz-Optimierung unterstützen (siehe auch REQ_WMS-2). Paletten auf den Pufferplätzen werden nur zwischengelagert. Der Optimierungslauf transportiert die sich auf den Pufferplätzen befindlichen Paletten in die jeweiligen definierten Zielzonen der Artikel. | MUSS |
| REQ_OPT-11 | Das System muss die Bereitstellung eines Backuplagers zur Ab- sicherung des Betriebs im Notfall unterstützen. Hierzu muss das System ermöglichen, definierte Artikel und Zielmengen für das Backuplager festzulegen. Das System muss anschließend sicherstellen, dass die definierten Zielbestände im Backuplager automatisch aufgefüllt werden, sofern Entnahmen erfolgen. Paletten im Backuplager müssen jederzeit für Auslagerungen verfügbar sein. Das Backuplager soll beim Ausfall des Lagers eine manuelle Versorgung der wichtigsten Artikel sicherstellen. Die detaillierte Ausgestaltung der Backuplager-Funktionen ist im Rahmen der Umsetzung gemeinsam mit dem Auftragnehmer festzulegen. | MUSS |
Seite 18 von 31
Lastenheft
3.2.5 Graphische Benutzeroberfläche / UI
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_GUI-1 | Neben der Server-Komponente muss das System eine Client- Anwendung (Desktop- oder Web-Anwendung) zur Steuerung, Eingabe und Nutzung des LVS bereitstellen. | MUSS |
| REQ_GUI-2 | Die Client-Anwendung muss eine rollenbasierte Zugriffsteuerung unterstützen, bei der Funktionen abhängig von den zugewiesenen Berechtigungen für Benutzergruppen freigegeben oder eingeschränkt werden. | MUSS |
| REQ_GUI-3 | Die Client-Anwendung muss eine gleichzeitige Nutzung durch mehrere Benutzer unterstützen. | MUSS |
| REQ_GUI-4 | Das System muss eine grafische Übersicht zur Visualisierung des Lagerzustands bereitstellen. In dieser Darstellung sollen die relevanten Systemkomponenten (z.B. Shuttles, Heber, Vorzonen, Gassen) sowie Transportaufträge übersichtlich abgebildet werden. | MUSS |
| REQ_GUI-5 | Wird eine grafische Übersicht geliefert, müssen betroffene Komponenten bei Störungen oder Abweichungen ihren Status visuell ändern (z.B. durch Hervorhebung oder Blinken). | MUSS |
| REQ_GUI-6 | Die grafische Darstellung muss unabhängig von der Client- Anwendung betrieben werden können und für eine dauerhafte Anzeige auf einem separaten Monitor geeignet sein. | MUSS |
3.2.6 Simulation
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_SIM-1 | Das System muss eine isolierte Komponente „LVS Simulator“ enthalten. Der LVS Simulator wird in einer separaten Testumgebung betrieben, um beispielsweise neue Software-Lieferungen, Funktionen und Abläufe vor einer Produktivsetzung vollständig testen zu können. | MUSS |
| REQ_SIM-2 | Der LVS Simulator muss eine Excel-Eingangsdatei mit Transportdaten (Artikelstamm, Ausgangsbestand, Materialfluss, APL-Status) entgegennehmen, um auf dieser Basis die Simulation durchzuführen. Für den Aufbau der Excel-Datei stellt die BDr eine Spezifikation zur Verfügung. | MUSS |
| REQ_SIM-3 | Der LVS Simulator muss eine grafische Benutzeroberfläche (GUI) beinhalten, in der die Transportbewegungen- und Lagerabläufe visualisiert werden. | MUSS |
| REQ_SIM-4 | Der LVS Simulator muss eine zusätzliche grafische Benutzeroberfläche (GUI) beinhalten, in der die Transportbewegungen auf den 8 Fördertechniken visualisiert werden. | MUSS |
| REQ_SIM-5 | Der AN gewährleistet, dass die Simulationssoftware auch nach Beendigung des Vertragsverhältnisses kostenfrei für Test-, Vergleichs- und Validierungszwecke weiter genutzt werden kann. Der Auftraggeber ist berechtigt, die eingeräumten Nutzungsrechte auch durch von ihm beauftragte Dritte ausüben zu lassen, soweit dies zur Durchführung von Prüfungen, Vergleichen, Validierungen, Wartungs- oder Unterstützungsleistungen erforderlich ist. | MUSS |
Seite 19 von 31
Lastenheft
3.2.7 Bestandsdaten
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_DAT-1 | Die Daten des bestehenden Systems müssen vor Beginn des Systemabnahmetests (SAT) vollständig und konsistent in die Datenbank des neuen Systems migriert werden. | MUSS |
| REQ_DAT-2 | Das neue System muss die übernommenen Daten vollständig hinsichtlich aller Anforderungen dieses Lastenheftes verarbeiten können. | MUSS |
Seite 20 von 31
Lastenheft
4 Liefer- und Leistungsumfang
4.1 Software-Lieferungen
Softwarelieferungen an die BDr unterliegen den Vorgaben des Configuration Managements. Die nachfolgende Abbildung 2 beschreibt den einzuhaltenden Workflow einer Software-Lieferung.
Abbildung 2 – Software-Lieferungen
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_REL-1 | Die Softwarelieferung muss über den offiziellen Prozess der BDr und DARF NICHT über alternative Wege (z.B. via Mail) erfolgen. | MUSS |
| REQ_REL-2 | Die Vorgaben der Softwarelieferungen müssen für jeden Softwareliefergegenstand berücksichtigt werden. Beispiele: • Updates • Firmware • Treiber • Konfigurationsdateien | MUSS |
| REQ_REL-3 | Die Softwarelieferung muss Release Notes nach BDr-Vorgabe enthalten. Die BDr stellt dem Auftragnehmer ein Vorlagedokument der Release Notes auf Anfrage zur Verfügung. | MUSS |
| REQ_REL-4 | Die Softwarelieferung muss versioniert sein. | MUSS |
| REQ_REL-5 | Die Versionsnummer muss eindeutig sein. | MUSS |
| REQ_REL-6 | Die Versionsnummer einer SW-Komponente DARF NICHT wiederholt genutzt werden. | MUSS |
| REQ_REL-7 | Die Versionsnummer DARF NICHT Leer- und Sonderzeichen enthalten. | MUSS |
| REQ_REL-8 | Die Versionsnummer soll dreistellig, mit Punkt getrennt sein. Hauptversion, Nebenversion und Revisionsnummer. | SOLL |
| REQ_REL-9 | Die Softwarelieferung muss Installationsanweisungen enthalten. | MUSS |
| REQ_REL-10 | Die Softwarelieferungen müssen einzeln installierbar sein. | MUSS |
| REQ_REL-11 | Die Softwarelieferung DARF NICHT als Image geliefert werden. | MUSS |
| REQ_REL-12 | Der Installationsvorgang muss ohne Internetzugang erfolgen. | MUSS |
| REQ_REL-13 | Jede für die volle Funktionalität der technischen Anlage benötigte Software muss der BDr übergeben werden. | MUSS |
Seite 21 von 31
Lastenheft
| REQ_REL-14 | Auf Anforderung muss nach inkrementellem Update, ein vollständiges Installationspaket, mit integrierten Updates geliefert werden. Sodass die Installation der inkrementellen Updates vermieden werden kann. | MUSS |
|---|---|---|
| REQ_REL-15 | Bei inkrementellen Lieferungen muss ein Rollback-Verfahren beschrieben sein. | MUSS |
| REQ_REL-16 | Alle benötigten Informationen zu Weiterverwendbarkeit, Anpassungsnotwendigkeiten und Übertragung von Konfigurationsdaten bei einem Releasewechsel müssen in der Installationsanleitung enthalten sein. | MUSS |
| REQ_REL-17 | Der Auftragnehmer muss ein aktuelles ER-Diagramm zu jeder Datenbank erstellen und liefern. | MUSS |
4.2 Lizenzen
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_LIC-1 | Sofern die angebotene Software einem Lizenzmodell unterliegt, müssen sämtliche für den Betrieb erforderlichen Lizenzen, Nutzungsrechte und lizenzpflichtige Komponenten Bestandteil des Angebots und der Lieferung sein und detailliert und vollständig dargestellt werden. | MUSS |
| REQ_LIC-2 | Für Produktiv-, Test- und Simulationsumgebungen dürfen keine zeitlich oder funktional eingeschränkten Testlizenzen eingesetzt werden. | MUSS |
| REQ_LIC-3 | Ein Hardware-Dongel DARF NICHT genutzt werden. | MUSS |
| REQ_LIC-4 | Die angebotene Software muss mit zeitlich unbefristeten Nutzungsrechten betrieben werden. | MUSS |
| REQ_LIC-5 | Ein Lizenzierungsverfahren, das Internetzugang benötigt, DARF NICHT genutzt werden. | MUSS |
4.3 Quellcode
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_SRC-1 | Der Auftragnehmer muss die stets aktuelle technische Dokumentation des Quellcodes mit - Beschreibungen der internen Systemstruktur anhand von o Klassen- und Sequenzdiagrammen o Statusmodellen - Prozess- und Ablaufbeschreibungen - Schnittstellenbeschreibungen beim Notariat hinterlegen. | MUSS |
| REQ_SRC-2 | Der Auftragnehmer muss dem Auftraggeber im Falle von Insolvenz oder Geschäftsaufgabe den notariell hinterlegten Quellcode vollständig überlassen. | MUSS |
| REQ_SRC-3 | Der Auftragnehmer muss den Betrieb im Falle einer Geschäftsübernahme zu gleichbleibenden Konditionen sicherstellen. | MUSS |
Seite 22 von 31
Lastenheft
| REQ_SRC-4 | Der Auftragnehmer muss jede produktiv freigegebene Softwareversion innerhalb eines Quartals nach ihrer Bereitstellung in der vereinbarten Quellcode-Hinterlegung (REQ_SRC-1) aktualisieren. Versionsstand und Änderungen müssen dabei stets nachvollziehbar dokumentiert sein. | MUSS |
|---|---|---|
| REQ_SRC-5 | Der Auftragnehmer muss die vollständige technische Dokumentation aller relevanten Schnittstellen, Datenmodelle und Customizing-Möglichkeiten zur Sicherstellung der langfristigen Wartbarkeit, Weiterentwicklung und Interoperabilität der Lösung während der Vertragslaufzeit bereitstellen. | MUSS |
4.4 Dokumentation, Schulungen und Gewährleistung
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_DOC-1 | Die Dokumentation für die verwendeten Softwarekomponenten inkl. Treiber, Komponenten von Drittherstellern, zusätzliche Windowskomponenten etc. muss 21 Tage vor dem SAT vorliegen. Bestandteil der Dokumentation sind: • Softwarename • Hersteller • Versionsnummer • Lizenzinfos • Installationspfad • Zugriffsrechte auf sämtliche benötigte Verzeichnisse • Verwendete Kommunikationsprotokolle (TCP/IP, UDP) und die dazugehörenden Portnummern | MUSS |
| REQ_DOC-2 | Die Bedienungsanleitung für die Benutzer muss zum Factory Acceptance Test (FAT) vorliegen. | MUSS |
| REQ_DOC-3 | Die separate Bedienungsanleitung für die Administratoren muss zum FAT vorliegen. | MUSS |
| REQ_DOC-4 | Die separate Bedienungsanleitung für den „LVS-Simulator“ muss zum FAT vorliegen. | MUSS |
| REQ_DOC-5 | Die Installationsanleitungen für alle Systemkomponenten müssen 21 Tage vor dem SAT vorliegen. | MUSS |
| REQ_DOC-6 | Die Anleitungen für die Parametrierung des Systems muss zum SAT vorliegen. | MUSS |
| REQ_DOC-7 | Eine graphische Übersicht über die Struktur und Abhängigkeiten der Datenbankobjekte mit ergänzender textueller Erklärung muss zum FAT vorliegen. | MUSS |
| REQ_DOC-8 | Eine grobe, graphische Übersicht über die interne Systemstruktur der Klassen, deren Aufgaben und deren Kommunikationsbeziehungen, mit ergänzender textueller Erklärung muss zum FAT vorliegen. | MUSS |
| REQ_DOC-9 | Die Dokumentation muss im Dateiformat PDF/A geliefert werden. | MUSS |
| REQ_DOC-10 | Das Angebot des Auftragnehmers muss zu folgenden Themen Schulungen enthalten: • Funktionalität und Ablauf der Software • Systembedienung • Fehlererkennung und -behebung | MUSS |
Seite 23 von 31
Lastenheft
| Die Schulungen müssen durch fachliche Experten mit sehr guten Kommunikationsfähigkeiten auf Deutsch in B2-Niveau erbracht werden. | ||
|---|---|---|
| REQ_DOC-12 | Der Auftragnehmer muss bei jeder neuen Softwareversion sicherstellen, dass diese mit aktuellen Sicherheitsupdates unter Berücksichtigung der Vorgaben des Auftraggebers und der eingesetzten Software kompatibel ist. | MUSS |
| REQ_DOC-13 | Alle genannten Bedienungsanleitungen und Installationsanleitungen in 4.4 müssen in deutscher Sprache in B2- Niveau erstellt werden. | MUSS |
Seite 24 von 31
Lastenheft
5 Schnittstellen und Abhängigkeiten
Im Rahmen der Ausschreibung werden keine detaillierten Schnittstellenspezifikationen bereitgestellt. Diese werden dem Auftragnehmer nach Zuschlagserteilung zur Verfügung gestellt. Die bestehenden Schnittstellen sind Grundlage für die Integration in die angebotene Lösung.
5.1 Schnittstelle zur SPS
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_PLC-1 | Das System muss eine Schnittstelle zur Speicherprogrammierbaren Steuerung (SPS) bereitstellen. Über die Schnittstelle müssen insbesondere folgende Funktionen unterstützt werden: • Übermittlung von Transportaufträgen an die Fördertechnik • Übermittlung von Transportaufträgen an die Shuttles • Empfang von Statusmeldungen der Anlagenkomponenten (z.B. Wartung, Störung, Handbetrieb, …) • Rückmeldungen/Quittierungen zu ausgeführten Transportaufträgen | MUSS |
| REQ_PLC-2 | Der Datenaustausch zwischen LVS und SPS muss bidirektional erfolgen und eine sofortige Verarbeitung ermöglichen. | MUSS |
| REQ_PLC-3 | Die bestehende Schnittstelle zur SPS ist im Rahmen der Lösung weiter zu nutzen. Der Auftragnehmer hat die vorhandene Schnittstelle zu analysieren und in die Lösung zu integrieren. Anpassungen sind auf das notwendige Maß zu beschränken und müssen vorher mit der BDR abgesprochen werden. | MUSS |
| REQ_PLC-4 | Das System kann die technische Grundlage für eine spätere Erweiterung um Funktionen zur direkten SPS-Ansteuerung bereitstellen. | KANN |
| REQ_PLC-5 | Der AN kann optional ein Konzept zur späteren Integration der SPS- Steuerung bereitstellen. Hierbei sind die erforderlichen Erweiterungen, Abhängigkeiten und Randbedingungen zu beschreiben. | KANN |
5.2 Schnittstelle zu SAP
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_SAP-1 | Das System muss eine Schnittstelle zum SAP-System zum Austausch von Stammdaten und Bewegungsdaten bereitstellen. Über die Schnittstelle müssen insbesondere folgende Daten ausgetauscht werden: • Artikelstammdaten • Lagerbestände • Transport- und Buchungsdaten | MUSS |
| REQ_SAP-2 | Der Datenaustausch zwischen LVS und SAP muss bidirektional erfolgen und eine sofortige Verarbeitung ermöglichen. | MUSS |
Seite 25 von 31
Lastenheft
REQ_SAP-3 Die bestehende Schnittstelle zum SAP ist im Rahmen der Lösung MUSS weiter zu nutzen. Der Auftragnehmer hat die vorhandene Schnittstelle zu analysieren und in die Lösung zu integrieren. Anpassungen sind auf das notwendige Maß zu beschränken und müssen vorher mit der BDR abgesprochen werden.
5.3 Logging
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_LOG_IF-1 | Für die Schnittstelle zur SPS müssen alle gesendeten und empfangenen Nachrichten in einer separaten Log-Datei protokolliert werden. | MUSS |
| REQ_LOG_IF-2 | Für die Schnittstelle zu SAP müssen alle gesendeten und empfangenen Nachrichten im einer separaten Log-Datei protokolliert werden. | MUSS |
| REQ_LOG_IF-3 | Alle Log-Dateien müssen täglich verwaltet und archiviert werden. | MUSS |
| REQ_LOG_IF-4 | Die Log-Einträge müssen mindestens folgende Informationen enthalten: • Zeitstempel • Art des Ereignisses (z.B. Fehler, Information) • Betroffene Systemkomponente oder Funktion inkl. detaillierten Informationen zu dem Ereignis | MUSS |
Seite 26 von 31
Lastenheft
6 Integrations- und Systemtest, Inbetriebnahme
| ID | Anforderung | Klassifizierung |
|---|---|---|
| REQ_CMS-1 | Der Auftragnehmer muss die nachfolgend beschriebenen Test- und Abnahmephasen unterstützen: • Factory Acceptance Test (FAT): Der FAT dient dem Nachweis, dass die vertraglich vereinbarten Funktionen des Systems erfüllt werden. Der FAT erfolgt unter Verwendung der in Abschnitt 3.2.6 beschriebenen Simulation. Die hierfür erforderliche Simulations- umgebung ist vom Auftragnehmer bereitzustellen. • Site Acceptance Test (SAT): Nach erfolgreichem Abschluss des Factory Acceptance Tests (FAT) wird am realen System ein Site Acceptance Test (SAT) durchgeführt. Hierfür müssen die Projektleitung sowie qualifizierte Softwareentwickler des Auftragnehmers während der Durchführung des SAT vor Ort anwesend sein • Leistungsnachweis: Nach erfolgreichem SAT wird der Leistungsnachweis gemäß REQ_CMS-7 erbracht. Eine Vor-Ort-Anwesenheit des Auftragnehmers ist hierfür nicht erforderlich, sofern der Auftraggeber diese nicht aufgrund festgestellter Mängel ausdrücklich verlangt. Der erfolgreiche Abschluss des FAT ist Voraussetzung für die Durchführung des SAT. Der erfolgreiche Abschluss des SAT ist Voraussetzung für den Leistungsnachweis gemäß REQ_CMS-7. | MUSS |
| REQ_CMS-2 | Das Angebot der Auftragnehmer soll für die Inbetriebnahme in der Produktivumgebung eine Rollback-Strategie enthalten. Mit dieser Strategie soll es den Administratoren der BDr möglich sein, innerhalb von zwei Stunden von den neuen Server- und Clientapplikationen auf die alten, derzeit bestehenden Applikationen zu wechseln. | SOLL |
| REQ_CMS-3 | Die Projektarbeiten müssen spätestens zwei Tage nach Zuschlagserteilung beginnen. | MUSS |
| REQ_CMS-4 | Die Lieferung muss bis spätestens 9 Monate nach Zuschlagserteilung erfolgen. | MUSS |
| REQ_CMS-5 | Die Inbetriebnahme im Testbetrieb muss spätestens innerhalb von 10 Monaten nach Zuschlagserteilung abgeschlossen sein. | MUSS |
| REQ_CMS-6 | Die Inbetriebnahme im Produktivbetrieb muss bis spätestens 12 Monate nach Zuschlagserteilung abgeschlossen sein. | MUSS |
Seite 27 von 31
Lastenheft
| REQ_CMS-7 | Die Leistungsfähigkeit des Systems wird anhand der erfolgreichen Ausführung der in diesem Lastenheft definierten Transportaufträge unter den spezifizierten Betriebsbedingungen nachgewiesen. Hierfür sind mindestens 150 Transportaufträge innerhalb von 24 Stunden erfolgreich auszuführen. Der Nachweis erfolgt stufenweise. Die jeweils nächste Stufe darf erst nach erfolgreichem Abschluss der vorherigen Stufe begonnen werden. 1. Stufe - Tagesnachweis Der Nachweis gilt als erbracht, wenn mindestens 150 Transportaufträge innerhalb eines Tages (24h) erbracht werden. Wird der Tagesnachweis erbracht, wird mit Stufe 2 (Wochennachweis) fortgefahren. Wird der Tagesnachweis nicht erbracht, sind maximal zwei Nachbesserungsversuche zulässig. 2. Stufe - Wochennachweis Der Nachweis gilt als erbracht, wenn die definierten täglichen Transportaufträge (Stufe 1) über 5 aufeinanderfolgende Betriebstage (Montag – Freitag) erbracht werden. Wird der Wochennachweis erbracht, wird mit Stufe 3 (Langzeitnachweis) fortgefahren. Wird der Wochennachweis nicht erbracht, muss nachgebessert werden und erneut mit Stufe 1 begonnen werden. 3. Stufe – Langzeitnachweis Der Nachweis gilt als erbracht, wenn die definierten Transportaufträge (Stufe 2) über einen Zeitraum von vier aufeinanderfolgenden Wochen erbracht werden. Wird der Langzeitnachweis erbracht, gilt die Inbetriebnahme als bestanden. Wird der Langzeitnachweis nicht erbracht, muss nachgebessert werden und erneut mit Stufe 1 begonnen werden. | |
|---|---|---|
| REQ_CMS-8 | Während des Abnahmezeitraums muss ein qualifizierter Softwareentwickler des Auftragsnehmers im definierten Zeitraum verfügbar sein, um erforderliche Anpassungen an der Software durchführen zu können. Die Art der Verfügbarkeit (vor Ort oder remote) ist im Vorfeld mit der BDr abzustimmen. | MUSS |
Seite 28 von 31
Lastenheft
| REQ_CMS-9 | Das System muss für einen kontinuierlichen Betrieb (24 Stunden pro Tag, 7 Tage pro Woche) ausgelegt werden. Das System gilt als verfügbar, wenn es sich im Automatikbetrieb befindet und die spezifizierten Transportfunktionen ausführen kann. Die Verfügbarkeit muss für jeden Kalendermonat nachgewiesen werden und berechnet sich wie folgt: Betriebszeit −Ausfallzeit Verfügbarkeit = * 100% Betriebszeit Betriebszeit Zeitraum, in dem das System für den operativen Betrieb (24/7) vorgesehen ist, abzüglich vereinbarter geplanter Wartungs- und Servicezeiten. Ausfallzeit Zeit ungeplanter Unterbrechungen, in denen das System keine Transportaufträge im Automatikbetrieb ausführen kann. Geplante Wartungs- und Servicezeiten werden nicht als Ausfallzeit gewertet. Die Verfügbarkeit des Systems muss im Produktivbetrieb in jedem Kalendermonat mindestens 99% betragen. Zusätzlich müssen die Server- und Clientapplikationen so ausgelegt werden, dass eine durchgehende Bedienung, Überwachung und Steuerung des Systems im Produktiv- und Testbetrieb gewährleistet ist. | MUSS |
|---|---|---|
| REQ_CMS-10 | Im Rahmen der Abnahme ist durch geeignete Testfälle nachzuweisen, dass alle spezifizierten Funktionen entsprechend den Anforderungen vorhanden, fehlerfrei und funktionsfähig sind. | MUSS |
| Betriebszeit | Zeitraum, in dem das System für den operativen Betrieb (24/7) vorgesehen ist, abzüglich vereinbarter geplanter Wartungs- und Servicezeiten. |
|---|---|
| Ausfallzeit | Zeit ungeplanter Unterbrechungen, in denen das System keine Transportaufträge im Automatikbetrieb ausführen kann. Geplante Wartungs- und Servicezeiten werden nicht als Ausfallzeit gewertet. |
Seite 29 von 31
Lastenheft
7 Verzeichnisse
7.1 Abbildungsverzeichnis
Abbildung 1: Schematischer Querschnitt des APL
Abbildung 2 – Software-Lieferungen
7.2 Abkürzungsverzeichnis
Abkürzung Bedeutung
AD Active Directory
AG Auftraggeber
AN Auftragnehmer
APL automatisiertes Palettenlager
BDr Bundesdruckerei
ER-Diagramm Entity-Relationship-Diagramm
FAT Factory Acceptance Test
FEFO First Expired, First Out
FIFO First In, First Out
IDOC Intermediate Document, Datenformat für Datenaustausch mit SAP)
LE Lagereinheit (hier Euro-Palette)
LVS Lagerverwaltungssystem
MFR Materialflussrechner
RDBMS Relational Database Management System
SAT Site Acceptance Test
SPS Speicherprogrammierbaren Steuerung
Seite 30 von 31
Lastenheft
7.3 Kürzel für Anforderungen (IDs)
Kürzel Bedeutung
AR Architektur (Architecture)
CD Durchlagerung (Cross Docking)
COMP Interne Komponenten (Components)
CMS Inbetriebnahme (Commissioning)
CON Containerisierung (Container)
DOC Dokumentation (Documentation)
GEN Allgemein (Generell)
GUI Graphische Benutzeroberfläche (Graphical User Interface)
IBN Inbetriebnahme (
INB Einlagerung (Inbound)
INT Umlagerung (Internal Movement)
INV Bestandsdaten (Inventory)
ITS Informationssicherheit (Information Security)
LIC Lizenzen (Licenses)
LOG Logging
LOG IF Logging Schnittstelle (Interface)
OPS Sicherer Betrieb (Operation Security)
OPT Optimierung (Optimization)
OUT Auslagerung (Outbound)
PERF Leistungsparameter (Performance)
PLC SPS (Programmable Logic Controller)
REL Software-Lieferungen (Release)
SAP SAP (ERP-System)
SRC Quellcode (Source Code)
SIM Simulation
SW Software
TRN Transportsteuerung (Transport)
WMS Lagerverwaltung (Warehouse Management)
Seite 31 von 31