Anforderungskatalog_V1
| Lfd. Nr. | Zusammenfassung | Beschreibung der Anforderung | Antwort des Bieters | Wertung | Unnamed: 5 | Unnamed: 6 | Unnamed: 7 | Erläuterung/Bemerkungen |
|---|---|---|---|---|---|---|---|---|
| Wichtigkeit | Kategorie | Maximale Punktzahl | erreichte Punktzahl | bei Antwort "teilweise" Erläuterung erforderlich! | ||||
| 1.0 | 1 Ausleihe | |||||||
| 2.0 | Zweigstellenverwaltung | Das System verfügt über eine Zweigstellenverwaltung mit eindeutiger Zweigstellenkennzeichung. | k.o. | |||||
| 3.0 | Zweigstellenverwaltung | Es werden Zweigstellen und mindestens zwei Fahrbibliotheken verwaltet | 5 | 100/50/0 | 500 | |||
| 4.0 | Zweigstellenverwaltung | Selbstverbucher und Rückgabeautomaten können Zweigstellen zugeordnet werden. | 5 | 100/50/0 | 500 | |||
| 5.0 | Zweigstellenverwaltung | Öffnungstage und Schließtage müssen für jede Zweigstelle definierbar und frei anpassbar sein. | 5 | 100/50/0 | 500 | |||
| 6.0 | Zweigstellenverwaltung | Das System soll die Öffnungstage für mehrere Jahre verwalten, um inkonsistenzen über den Jahreswechsel zu vermeiden, mindestens jedoch Vorjahr, laufendes Jahr und Folgerjahr. | 5 | 100/50/0 | 500 | |||
| 7.0 | Zweigstellenverwaltung | Die Zweigstellenverwaltung verfügt für mehrere Fahrbibliotheken über eine konfigurierbare Touren- und Haltestellenverwaltung. | 5 | 100/50/0 | 500 | |||
| 8.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Alle mit dem Ausleihvorgang verbundenen Funktionen müssen unterstützt werden. Hierzu zählen mindestens: Ausleihe, Rückgabe, Verlängerung, Mahnung, Leihfristberechnung, unterschiedliche Ausgabeorte, interner Leihverkehr zwischen den Zweigstellen. | k.o. | |||||
| 9.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Ausleih-, Bestell-, Verlängerungs- und Mahnparameter müssen für jede Zweigstelle konfigurierbar sein. | k.o. | |||||
| 10.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Die Leihfristberechnung muss auf Grundlage der definierten Öffnungstage, oder anderer Parameter der Zweigstellenverwaltung, flexibel konfigurierbar sein. | k.o. | |||||
| 11.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Es kann, zum Beispiel für Fahrbibliotheken, ein Leihfristende mit fixen Fälligkeitsdatum vergeben werden. | 5 | 100/50/0 | 500 | |||
| 12.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Die Leihfristverlängerung soll für das gesamte Benutzerkonto oder einzelne ausgeliehene Medien möglich sein. | 5 | 100/50/0 | 500 | |||
| 13.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Die Leihfristverlängerung soll durch den Fachanwender im Client und durch die Kunden an allen Endgeräten (Benutzerkonto, Automaten) durchgeführt werden. | 5 | 100/50/0 | 500 | |||
| 14.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | einzelne Medien — mindestens vorgemerkte, überfällige und zurückgerufene — sollen nicht durch den Entleiher selbst verlängert werden, sondern nur durch einen Fachanwender. | 5 | 100/50/0 | 500 | |||
| 15.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Die Leihfrist kann in Abhängigkeit konfigurierbarer Parameter automatisch verkürzt werden, mindestens bei Rückruf eines Mediums oder Vorliegen mehrerer Bestellungen für einen Titel/ein Exemplar. | 3 | 100/50/0 | 300 | |||
| 16.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Bei Überschreitung der Leihfrist müssen Mahnungen erzeugt werden - konfigurierbar entsprechend der Ausleihordnung bzw. der Mahnparameter. | k.o. | |||||
| 17.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Für die Ausleihe sollen verschiedene Standorte und/oder Ausgabeorte, zum Beispiel Lesesaal, konfiguriert werden. | 5 | 100/50/0 | 500 | |||
| 18.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Im Zuge des Ausleihvorgangs können provisorische Titelaufnahmen bzw. Exemplare erstellt werden (Kurztitelaufnahme). Diese werden vom System gekennzeichnet. Bei der Rückbuchung gibt es einen entsprechenden Hinweis. | 3 | 100/50/0 | 300 | |||
| 19.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Die Ausleihmöglichkeit mehrerer Exemplare eines Titels ist möglich. | 5 | 100/50/0 | 500 | |||
| 20.0 | Ausleihe, Rückgabe, Verlängerung, Mahnung | Bei der Rückgabe soll bestehende Vormerkungen auf den Titel/das Exemplar automatisch erkannt werden. Notwendige Transporte zu anderen (Abhol-)Standorten werden sofort erkannt und angezeigt. | 5 | 100/50/0 | 500 | |||
| 21.0 | Gruppenausleihe | Das System soll die Möglichkeit der Gruppenausleihe, mindestens bei Klassensätzen, bieten. Mehrere Exemplare eines Titels können auf ein gemeinsames Gruppenkonto verbucht werden. (OPTION im LV) | 5 | 100/50/0 | 500 | |||
| 22.0 | Gruppenausleihe | Einzelne Medien können aus der Verknüpfung der Gruppenausleihe gelöst werden. Alle oder einzelne Medien einer Gruppenausleihe können verlängert und individuell zurückgebucht werden. (OPTION im LV) | 3 | 100/50/0 | 300 | |||
| 23.0 | Benutzerdatenverwaltung | Das System muss über eine eigene Benutzerdatenverwaltung verfügen. Benutzerdaten können angelegt, kopiert, verändert und gelöscht werden. Berechtigungen gemäß Bibliothekssatzung müssen zugewiesen werden können. | k.o. | |||||
| 24.0 | Benutzerdatenverwaltung | Für alle im Benutzerdatensatz relevanten Änderungen soll eine Historie geführt werden. Die Historie kann in Abhängigkeit vom Vorgang für eine konfigurierbare Zeit nachvollzogen werden. | 5 | 100/50/0 | 500 | |||
| 25.0 | Benutzerdatenverwaltung | Das System muss unterschiedliche Benutzergruppen zur Abbildung verschiedener Ausleihkonditionen laut Bibliothekssatzung und für Statistikzwecke verwalten. Pro Benutzergruppe können Standardausgabeort, Ausleih-, Statistik- und Gebührengruppe konfiguriert werden. Neben Benutzergruppen für Kunden ist es auch möglich spezielle Benutzergruppen für Fachanwender einzurichten, mindestens Dienstkonten oder dienstliche Benutzergruppen. | 5 | 100/50/0 | 500 | |||
| 26.0 | Benutzerdatenverwaltung | Der Benutzerdatensatz soll in allen Standardworkflows im Bereich der Ausleihe zur Verfügung stehen. Eine Suche nach dem Datensatz mit Stichworten bzw. Namensbestandteilen ist möglich. Auch kann der Benutzerdatensatz über die Ausweisnummer aufgerufen werden. | 5 | 100/50/0 | 500 | |||
| 27.0 | Benutzerdatenverwaltung | Es sollen automatisierbare und konfigurierbare Batch-Import- und Export-Routinen für Benutzerdaten zur Verfügung stehen. Es ist möglich, beim Import über die Schnittstelle definierte Bereiche des Benutzerdatensatzes unabhängig voneinander zu aktualisieren. | 5 | 100/50/0 | 500 | |||
| 28.0 | Benutzerdatenverwaltung | Benutzerdatensätze müssen vom Mitarbeitenden manuell gelöscht oder inaktiv gesetzt werden können, wenn der Benutzer entlastet ist. | k.o. | |||||
| 29.0 | Benutzerdatenverwaltung | Löschprozeduren sind automatisierbar und konfigurierbar. Zur Überprüfung werden konfigurierbare Protokolldateien erzeugt. | 5 | 100/50/0 | 500 | |||
| 30.0 | Benutzerdatenverwaltung | Die Felder in den Benutzerstammdaten sollen konfigurierbar sein. Für jedes Feld kann Pflichtfeld bzw. Plausibilitätsprüfung konfiguriert werden. Jedem Nutzer können mehrere Adressen zugewiesen werden. | 5 | 100/50/0 | 500 | |||
| 31.0 | Benutzerdatenverwaltung | Ausweisgebühr und -gültigkeit müssen in Abhängigkeit von der Benutzergruppe automatisch gesetzt werden. | k.o. | |||||
| 32.0 | Benutzerdatenverwaltung | Eindeutige Ausweisnummern/Benutzernummern müssen automatisch oder in Abbhängigkeit von der Benutzergruppe, ggf. mit Prüfziffern, generiert werden. Sie können numerisch oder alphanumerisch sein. | k.o. | |||||
| 33.0 | Benutzerdatenverwaltung | Das System soll vorgegebene Ausweisnummern bzw. Benutzernummern entsprechend festgelegter Nummernkreise oder in Abhängigkeit von der Benutzergruppe, ggf. mit Prüfziffern, verarbeiten können. Sie können numerisch oder alphanumerisch sein. | 5 | 100/50/0 | 500 | |||
| 34.0 | Benutzerdatenverwaltung | Ein Wechsel zwischen den Verfahren vorgegebener und automatisch vergebener Ausweisnummern bzw. Benutzernummern kann ohne Auswirkungen auf bereits vorhandene Benutzerdatensätze möglich sein. Umnummerierungen sind nach Verfahrenswechsel möglich. | 3 | 100/50/0 | 300 | |||
| 35.0 | Benutzerdatenverwaltung | Bei der Benutzerdatenaufnahme muss eine Dublettenprüfung stattfinden. | k.o. | |||||
| 36.0 | Benutzerdatenverwaltung | Für die Benutzerdatenaufnahme soll abhängig von der Benutzergruppe Plausibilitätsprüfungen konfiguriert werden. MIndestens bei: Überprüfung des Geburtsdatums bei Minderjährigen, Vorliegen von Pflichtfeldern (mindestens Geburtsdatum, Adresse), syntaktische Korrektheit von E-Mail-Adressen und Postleitzahlen. | 5 | 100/50/0 | 500 | |||
| 37.0 | Benutzer- und Exemplarsperren | Benutzerkonten müssen mit manuellen oder automatischen Sperren entsprechend der durch die Bibliothek definierten Sperrgründe versehen werden können. | k.o. | |||||
| 38.0 | Benutzer- und Exemplarsperren | Sperren sollen manuell von Fachanwendern aufgehoben werden können. | 5 | 100/50/0 | 500 | |||
| 39.0 | Benutzer- und Exemplarsperren | Exemplare sollen mit einer Ausleihsperre versehen werden können. | 5 | 100/50/0 | 500 | |||
| 40.0 | Benutzer- und Exemplarsperren | Bei einer Benutzer- oder Exemplarsperre sollen Datum und Sperrgrund gespeichert werden. Optional können weitere Informationen hinterlegt werden. | 5 | 100/50/0 | 500 | |||
| 41.0 | Gebührenverwaltung | Das System soll eine vollständige Medienersatzbearbeitung bereitstellen (Verlustbuchung, Gebühren, Ersatzbeschaffung anstoßen, Ersatzexemplar einarbeiten, Dokumentation/Status). Es ist möglich finanziellen Ersatz und physischen Medienersatz zu verwalten. | 5 | 100/50/0 | 500 | |||
| 42.0 | Gebührenverwaltung | Unterschiedliche Gebührenarten müssen konfiguriert und verwaltet werden können. | k.o. | |||||
| 43.0 | Gebührenverwaltung | Die Gebührenanzeige soll sämtliche Kontextinformationen anzeigen, um die Zuordnung zu einem Ausleihvorgang nachzuvollziehen. | 5 | 100/50/0 | 500 | |||
| 44.0 | Gebührenverwaltung | Einzelne Gebührenpositionen können aufsummiert werden. | 5 | 100/50/0 | 500 | |||
| 45.0 | Gebührenverwaltung | Gebühren müssen manuell oder automatisiert (mindestens Kassenautomat und Zahlungsverkehrsterminal) eingenommen werden können. Sie müssen storniert oder erlassen werden können. | k.o. | |||||
| 46.0 | Gebührenverwaltung | Ein Grund für die Stornierung oder den Erlass soll erfasst werden. | 5 | 100/50/0 | 500 | |||
| 47.0 | Gebührenverwaltung | Teilzahlungen und Teilerlasse von Gebühren soll möglich sein. Die Zahlart soll erfasst werden und auswertbar sein. | 5 | 100/50/0 | 500 | |||
| 48.0 | Gebührenverwaltung | Für Fachanwender sollen Berechtigungen für Storno und Erlasse nach Höhe der Beträge eingerichtet werden können. | 5 | 100/50/0 | 500 | |||
| 49.0 | Gebührenverwaltung | Das System muss die Konfiguration, Erzeugung und Verwaltung von Gebührenbescheiden und Gebührensperren unterstützen. | k.o. | |||||
| 50.0 | Gebührenverwaltung | Als letzte Erinnerungsstufe sollen automatisch Leistungsbescheide, die auch alle bereits angefallenen Mahn- und Bearbeitungsgebühren enthalten, mit Buchungszeichen nach Vorgabe der Stadt Leipzig generiert werden. | 5 | 100/50/0 | 500 | |||
| 51.0 | Gebührenverwaltung | Ein Gebührenguthaben für Vorausbezahlungen soll eingerichtet werden können, bzw. ist für Fernleihen vorhanden. | 5 | 100/50/0 | 500 | |||
| 52.0 | Gebührenverwaltung | Im Rechtemanagement soll das 4-Augenprinzip bei Stornierungen technisch implementiert sein. | 5 | 100/50/0 | 500 | |||
| 53.0 | Gebührenverwaltung | Mahngebühren und Säumnisgebühren soll konfiguriert werden. | 5 | 100/50/0 | 500 | |||
| 54.0 | Gebührenverwaltung | Kulanzfristen bis zur Erstellung bzw. Fälligkeit von Mahngebühren und Säumnisgebühren sollen definiert werden können (Karenztage). | 5 | 100/50/0 | 500 | |||
| 55.0 | Vormerkungen und Bestellungen | Frei verfügbare Medien müssen im Endnutzerkatalog bestellt und vorgemerkt werden können. | k.o. | |||||
| 56.0 | Vormerkungen und Bestellungen | Für entliehene Medien muss es eine Vormerkfunktion im Endnutzerkatalog geben. | k.o. | |||||
| 57.0 | Vormerkungen und Bestellungen | Fachanwender sollen Bestellungen und Vormerkungen über die Arbeitsoberfläche auslösen. | 5 | 100/50/0 | 500 | |||
| 58.0 | Vormerkungen und Bestellungen | Die Bestell- und Vormerkfunktion soll für alle Medientypen und Nutzergruppen konfiguriert werden. | 5 | 100/50/0 | 500 | |||
| 59.0 | Vormerkungen und Bestellungen | Sind bestellte oder vorgemerkte Medien aus einer anderen Zweigstelle, soll die Bestellung oder Vormerkung einen Zweigstellenversand auslösen. Der Zweigstellenversand produziert Meldungen welche die Transportlogistik unterstützt (z. B. Ausdruck von Bestellungen am Standort des Mediums oder elektr. Transportbücher). | 5 | 100/50/0 | 500 | |||
| 60.0 | Vormerkungen und Bestellungen | Die Vormerkreihenfolge und Bereitstellungsfristen sollen konfigurierbar sein. Die Einstellungen können durch Fachanwender geändert werden. | 5 | 100/50/0 | 500 | |||
| 61.0 | Floating Collections und Bestandsverlegung | Das System kann für einen konfigurierbaren Zeitraum die Verwaltung von "Floating Collections" unterstützen. | 5 | 100/50/0 | 500 | |||
| 62.0 | Floating Collections und Bestandsverlegung | Eine Verwaltung der Bibliotheksstandorte, die Floating Collections unterstützen, soll möglich sein. Das System unterstützt Bestandsverlegungen durch die Möglichkeit der Stapelverarbeitung für Exemplare (Änderung des Standortes im Exemplarsatz). | 5 | 100/50/0 | 500 | |||
| 63.0 | Floating Collections und Bestandsverlegung | Für Exemplare, die zum Zeitpunkt der Bestandsverlegung ausgeliehen sind, soll bei der Rückgabe automatisch ein Transportzettel zum neuen Standort erzeugt werden. | 5 | 100/50/0 | 500 | |||
| 64.0 | Historisierung von Ausleihdaten | Das System muss die Protokollierung von Ausleihvorgängen sowie Datenänderungen mit konfigurierbarer Speicherdauer ermöglichen. | k.o. | |||||
| 65.0 | Historisierung von Ausleihdaten | Der Zugriff auf erstellte Benachrichtigungsschreiben soll im System für eine konfigurierbare Dauer nachgehalten werden. | 5 | 100/50/0 | 500 | |||
| 66.0 | Historisierung von Ausleihdaten | Für alle in der Ausleihe relevanten Vorgänge und Daten soll eine Historie eingeführt werden können, bsp. für Ausleihvorgänge, Gebührenzahlungen. Die Historie kann in Abhängigkeit vom Vorgang für eine konfigurierbare Zeit nachvollzogen werden. | 5 | 100/50/0 | 500 | |||
| 67.0 | Historisierung von Ausleihdaten | Es soll konfigurierbar sein, ob und für welchen Zeitraum eine Ausleihistorie zu Benutzerdatensätzen und/oder eine personenbezogenen Ausleihhistorie (Ausleihen/ Rückgaben) zu Exemplardatensätzen geführt wird. | 5 | 100/50/0 | 500 | |||
| 68.0 | Fernleihe | Es steht ein Fernleihmodul, oder andere Funktion, zur Verfügung um aktive und passive Fernleihvorgänge durchzuführen bzw. zu unterstützen | 5 | 100/50/0 | 500 | |||
| 69.0 | Fernleihe | Es sollen Auswertungen der Fernleihe nach Vorgaben der Deutschen Bibliotheksstatistik erstellt werden können mit (mindestens) diesen Angaben: - Bestellungen im nehmenden (passiven) Leihverkehr - Bestellungen im gebenden (aktiven) Leihverkehr. | 5 | 100/50/0 | 500 | |||
| 70.0 | 2 Medienauswahl und Erwerbung | |||||||
| 71.0 | Erwerbungsarten | Das System soll eine integrierte und medienbruchfreie Verwaltung aller in der Bibliothek vorkommenden Medienarten unterstützen (u.a. gedruckt, elektronisch, digital). | 5 | 100/50/0 | 500 | |||
| 72.0 | Erwerbungsarten | Die Erwerbungsart "Kauf" für Einzelbestellungen und fortlaufende Ressourcen (Abonnements und Fortsetzungen) muss unterstützt werden | k.o. | |||||
| 73.0 | Erwerbungsarten | Die Erwerbungsart "Kauf" unterstützt den Erwerb von Monographien, lfd. Zeitschriften und Zeitungen, mehrbändige Werke, Reihen, Serien. | 5 | 100/50/0 | 500 | |||
| 74.0 | Erwerbungsarten | Die Erwerbungsart "kostenloser Zugang/unverlangte Lieferung" für Einzelbestellungen, Abonnements und Fortsetzungen muss unterstützt werden | k.o. | |||||
| 75.0 | Erwerbungsarten | Die Erwerbungsart "kostenloser Zugang/unverlagte Lieferung" unterstützt mindestens die Erwerbung von geschenkten Medien. | 5 | 100/50/0 | 500 | |||
| 76.0 | Erwerbungsarten | Die Verwaltung von integrierenden Ressourcen (z. B. Loseblattsammlungen) kann unterstützt werden. | 3 | 100/50/0 | 300 | |||
| 77.0 | Erwerbungsarten | Die Verwaltung von Einzelheftbestellungen soll unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 78.0 | Erwerbungsarten | Die Erwerbungsart "Standing Order / Approval Plan" muss unterstützt werden. | k.o. | |||||
| 79.0 | Erwerbungskonfiguration | Die Konfiguration von Workflows für Erwerbungsparameter (mindestens Bestellart, Geschäftsgang, Etat, Lieferantendaten, Währung, Adressen, Status) soll bibliotheksspezifisch konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 80.0 | Erwerbungskonfiguration | Das Bibliothekssystem soll über ein integriertes Erwerbungsmodul mit Lieferanten- und Etatsteuerung verfügen. | 5 | 100/50/0 | 500 | |||
| 81.0 | Erwerbungskonfiguration | Der Erwerbungsgeschäftsgang soll konfiguriert werden können. | 5 | 100/50/0 | 500 | |||
| 82.0 | Erwerbungskonfiguration | je nach Erwerbungsart kann der Erwerbungsgeschäftsgang mindestens folgende Aspekte abdecken: (Vor-)Auswahl zur Bestellung, inkl. Übermittlung an den Lieferanten / Rechnungsprüfung / Inventarisierung / Eingangsbearbeitung, Erfassung statistischer Daten | 3 | 100/50/0 | 300 | |||
| 83.0 | Erwerbungskonfiguration | Das System soll vollautomatisierte Erwerbungsprozesse auf der Basis von Datenimporten (Titel-, Exemplar- und Erwerbungsdaten) von Lieferanten oder aus anderen Quellen unterstützen. | 5 | 100/50/0 | 500 | |||
| 84.0 | Erwerbungskonfiguration | Erwerbungsdaten und Bestellsätze werden auch im XML-Format angeboten. | 5 | 100/50/0 | 500 | |||
| 85.0 | Erwerbungskonfiguration | Das Erwerbungsmodul soll den Export von Bestelldatensätzen von- und zu den Lieferanten als elektronisches Verfahren unterstützen. | 5 | 100/50/0 | 500 | |||
| 86.0 | Erwerbungs - und Metadatenverknüpfung | Die Verknüpfung von bibliographischen Metadaten und Erwerbungsdaten soll über eine Verknüpfung mit einem Erwerbungsdatensatz erfolgen. Dabei können differenzierte, bibliotheksspezifisch konfigurierbare Exemplarstatus gesetzt werden. Anders strukturierte Lösungen, die diese Funktion wiedergeben, sind möglich. | 5 | 100/50/0 | 500 | |||
| 87.0 | Erwerbungs - und Metadatenverknüpfung | Das System soll die Erfassung von Medienbestellungen mit direkter oder integrierter Schnittstelle zur Katalogisierung und Erschließung unterstützen, um eine Vor- oder Parallel- katalogisierung der bestellten Titel zu ermöglichen. Für verschiedene Medienarten ist die Erfassung anpassbar. | 5 | 100/50/0 | 500 | |||
| 88.0 | Erwerbungs - und Metadatenverknüpfung | Das System kann die automatische Verarbeitung elektronischer Rechnungen in im Buchhandel gängigen Datenformate einschließlich der korrekten Zuordnung von Rechnungs- und Bestelldaten ermöglichen. | 3 | 100/50/0 | 300 | |||
| 89.0 | Erwerbungs - und Metadatenverknüpfung | Kurztitelaufnahmen im Erwerbungsprozess sollen unterstützt werden (Bestellkatalogisate). | 5 | 100/50/0 | 500 | |||
| 90.0 | Erwerbungsgeschäftsgang | Die Integration einer automatisierten Übernahme von Erwerbungs- und Katalogdaten aus Fremdsystemen soll unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 91.0 | Erwerbungsgeschäftsgang | Der Geschäftsgang soll die Medienauswahl per Anschaffungsvorschlag, Profildienst, Approval Plan, PDA und gleichrangige Verfahren enthalten. | 5 | 100/50/0 | 500 | |||
| 92.0 | Erwerbungsgeschäftsgang | Die Erwerbung von Mehrfachexemplaren und -abonnements muss unterstützt werden. | k.o. | |||||
| 93.0 | Erwerbungsgeschäftsgang | Datensätze müssen grundsätzlich löschbar sein, mindestens Bestellungen, (Teil-)lieferungen, Abonnements, Hefte und Rechnungen. | k.o. | |||||
| 94.0 | Erwerbungsgeschäftsgang | Ein Geschäftsgang für die Stornierung von Bestellungen (fest, laufend, Abonnement) soll unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 95.0 | Erwerbungsgeschäftsgang | Ein Geschäftsgang für die Rücksendung von Medien zum Lieferanten ist vorhanden. | 5 | 100/50/0 | 500 | |||
| 96.0 | Erwerbungsgeschäftsgang | Für alle Geschäftsgänge muss es eine konfigurierbare Etatüberwachung ab Eingabe der Bestelldaten bereitgestellt werden. | k.o. | |||||
| 97.0 | Erwerbungsgeschäftsgang | Es existiert eine Dublettenkontrolle für das Anlegen von Bestellungen | k.o. | |||||
| 98.0 | Mahnwesen | Nicht fristgerecht gelieferten Medien sollen sowohl individuell als auch automatisiert gemahnt werden. Dies gilt auch für Teilmengen. Die Anzahl der Mahnungen ist unbegrenzt. | 5 | 100/50/0 | 500 | |||
| 99.0 | Mahnwesen | Die Mahnfunktion soll pro Lieferant, Bestellung, Abonnement aktiviert oder deaktiviert werden. | 5 | 100/50/0 | 500 | |||
| 100.0 | Mahnwesen | Mahnungserstellung und -versand sollen konfigurierbar sein: automatisch und mit manueller Kontrolle. | 5 | 100/50/0 | 500 | |||
| 101.0 | Mahnwesen | Nicht fristgerecht gelieferte Medien sollen im Rahmen des Hefteinganges manuell (per Email) reklamiert werden können. Mahnfristen und Intervalle sind nachträglich änderbar. | 5 | 100/50/0 | 500 | |||
| 102.0 | Mahnwesen | Die Mahnhistorie soll abgebildet werden. Dies gilt sowohl auf Titel- wie auch auf Heftebene. | 5 | 100/50/0 | 500 | |||
| 103.0 | Elektronische Ressourcen (ERM) | Der Erwerbungsvorgang für E-Ressourcen, Online-Medien und Datenbanken (Etatverwaltung, Lizenzart, Laufzeit) kann abgebildet werden. | 3 | 100/50/0 | 300 | |||
| 104.0 | Elektronische Ressourcen (ERM) | Der automatisierte Import sowie Löschung von Metadaten erworbener E-Ressourcen, Online-Medien und Datenbanken (Katalogdaten Neuerwerbungen, zu löschende Medien) soll möglich sein. | 5 | 100/50/0 | 500 | |||
| 105.0 | Elektronische Ressourcen (ERM) | Zugriffs- und Zugangskontrolle (Login) zu den E-Ressourcen, Online-Medien und Datenbanken soll möglich und auf Ebene der Benutzergruppen konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 106.0 | Lieferanten- und Anbieterdatenverwaltung | Das System muss über eine eigene Lieferantendatenverwaltung verfügen. | k.o. | |||||
| 107.0 | Lieferanten- und Anbieterdatenverwaltung | Die Lieferantendatenverwaltung umfasst mindestens Lieferanten-, Verlags-, sowie weiteren Anbieterdaten (z.B. Plattformen). | 5 | 100/50/0 | 500 | |||
| 108.0 | Lieferanten- und Anbieterdatenverwaltung | Ein Lieferantendatensatz soll mindestens folgende Kontaktdaten enthalten: Name, Kürzel, Typ, Adresse, Telefon, E-Mail-Adresse, Ansprechpartner, Kundennummer(n). Kontaktdaten können bei Bedarf mehrfach erfasst werden und können auf Ebene des Standorts/der Zweigstelle zugeordnet werden. | 5 | 100/50/0 | 500 | |||
| 109.0 | Lieferanten- und Anbieterdatenverwaltung | Im Lieferantendatensatz soll die Ablage von zusätzlichen Informationen in Form von Dateien, E-Mail-Verkehr etc. möglich sein. Notizfelder stehen zur Verfügung. Die mit einem Lieferantendatensatz verknüpften Bestellungen und Rechnungen können adhoc aufgelistet und als Datei exportiert werden. | 5 | 100/50/0 | 500 | |||
| 110.0 | Lieferanten- und Anbieterdatenverwaltung | Ein Lieferantendatensatz soll mindestens folgende Rabatt- und Lieferinformationen enthalten: Rabatt, Versandkosten, sowie Servicevereinbarungen. | 5 | 100/50/0 | 500 | |||
| 111.0 | Lieferanten- und Anbieterdatenverwaltung | Ein Lieferantendatensatz soll mindestens folgende Rechnungsinformationen enthalten: Rechnungs- und Lieferadresse, Steuernummer, Währung(en), MwSt., ggf. Kontoinformationen. | 5 | 100/50/0 | 500 | |||
| 112.0 | Termin- und Fristüberwachung | Das System soll für alle Termine und Fristen ein Benachrichtigungsmanagement bieten (Mahnschreiben, Kontroll- und Hinweislisten, Meldungen, etc.). | 5 | 100/50/0 | 500 | |||
| 113.0 | Termin- und Fristüberwachung | Termine sowie Fristen sollen im System erfasst und kontrolliert werden, mindestens für Verlängerungen, Rückmeldungen, Abbestellungen, Testzugänge. | 5 | 100/50/0 | 500 | |||
| 114.0 | Steuern und Gebühren | Gutschriften müssen abgebildet und verwaltet werden. | k.o. | |||||
| 115.0 | Steuern und Gebühren | Steuern sollen im System abgebildet werden. | 5 | 100/50/0 | 500 | |||
| 116.0 | Verwaltung des internen Medienetats | Eine Verwaltung des internen Medienetats mit umfassenden Suchmöglichkeiten muss vorhanden sein. | k.o. | |||||
| 117.0 | Verwaltung des internen Medienetats | Etats können angelegt, kopiert, bearbeitet und gelöscht werden. | 5 | 100/50/0 | 500 | |||
| 118.0 | Verwaltung des internen Medienetats | Die Struktur des internen Medienetats soll sich hierarchisch abbilden und anzeigen lassen. Haushaltsstufen können frei konfiguriert werden. | 5 | 100/50/0 | 500 | |||
| 119.0 | Verwaltung des internen Medienetats | Es soll keine Begrenzung der Anzahl von Etats geben. Diese können konfiguriert werden. | 5 | 100/50/0 | 500 | |||
| 120.0 | Verwaltung des internen Medienetats | Bei Übermittlung einer Bestellung an den Lieferanten sollen die entsprechenden Haushaltsmittel in der internen Etaverwaltung gebunden werden. Bestellpreisänderungen (auch Währungskursanpassungen) wirken sich automatisch auf die Mittelbindungen aus. | 5 | 100/50/0 | 500 | |||
| 121.0 | Verwaltung des internen Medienetats | Etatmittel sollen bei Stornierung und Löschung automatisch erhöht werden. Etatmittel werden bei Inventarisierung automatisch reduziert und als Ausgaben erfasst. | 5 | 100/50/0 | 500 | |||
| 122.0 | Verwaltung des internen Medienetats | Bestellsummen sollen bei Bestellung auf verschiedene Haushaltsstellen aufgeteilt werden können, wahlweise prozentual oder absolut. | 5 | 100/50/0 | 500 | |||
| 123.0 | Verwaltung des internen Medienetats | Es soll die Möglichkeit geben, einzelne Kostenstellen zu schließen und zu öffnen. | 5 | 100/50/0 | 500 | |||
| 124.0 | Verwaltung des internen Medienetats | Ein Transfer von Mitteln zwischen einzelnen Haushaltsstellen im internen Etat soll möglich sein. | 5 | 100/50/0 | 500 | |||
| 125.0 | Jahresabschluss | Inventarisierung und Rechnungsprüfung soll für alle Medienarten möglich sein, auch Online-Medien (Inventarverzeichnis für Medienzugänge) | 5 | 100/50/0 | 500 | |||
| 126.0 | Jahresabschluss | Der Zeitraum des Haushaltsjahres (Fiskalisches Jahr) soll konfigurierbar sein. Das System kann mit mehreren offenen Haushaltsjahren arbeiten. | 5 | 100/50/0 | 500 | |||
| 127.0 | Jahresabschluss | Das System muss einen Jahres-/Haushaltsabschluss unterstützen. | k.o. | |||||
| 128.0 | Jahresabschluss | Offene und gebundene Haushaltsmittel werden in das neue Haushaltsjahr übertragen. Dies gilt insbesondere auch für verlängerungspflichtige Medien. Bei der Übertragung besteht die Möglichkeit, eine Kostenanpassung vorzunehmen. | 5 | 100/50/0 | 500 | |||
| 129.0 | Jahresabschluss | Zu erwartende, prozentuale Kostensteigerungen fortlaufender und integrierender Ressourcen (Abonnements, Fortsetzungen, Datenbanken Loseblattausgaben) sollen kalkuliert und als Mittelbindung im neuen Haushaltsjahr berücksichtig werden können. | 5 | 100/50/0 | 500 | |||
| 130.0 | Finanzcontrolling, Berichtswesen | Bei fortlaufendem Bezug einer Ressource sollen die Kosten in einer Historie nach Jahren dokumentiert werden. Eine Unterscheidung zwischen Publikationsjahr und Haushaltsjahr ist möglich. | 5 | 100/50/0 | 500 | |||
| 131.0 | Finanzcontrolling, Berichtswesen | Die mit Kostenstellen verknüpften Rechnungsdaten und Bestellungen sollen aufgelistet exportiert werden können. | 5 | 100/50/0 | 500 | |||
| 132.0 | Finanzcontrolling, Berichtswesen | Haushaltsdaten müssen auch nach Jahresabschluss eingesehen werden können. Der Zeitraum ist konfigurierbar. | k.o. | |||||
| 133.0 | Finanzcontrolling, Berichtswesen | Berichte über die Etatausgaben pro Lieferant und Kostenstelle sollen erstellt und als Datei ausgegeben werden können. | 5 | 100/50/0 | 500 | |||
| 134.0 | Einzel- und Sammelbestellungen | Das System muss die Erfassung von Einzel- und Sammelbestellungen unterstützen. | k.o. | |||||
| 135.0 | Einzel- und Sammelbestellungen | Das System muss die Erfassung von Sofortbestellungen zur unmittelbaren Lieferung unterstützen. | k.o. | |||||
| 136.0 | Einzel- und Sammelbestellungen | Bestellungen sollen angelegt, kopiert, bearbeitet, storniert und gelöscht werden können. | 5 | 100/50/0 | 500 | |||
| 137.0 | Einzel- und Sammelbestellungen | Eine differenzierte Suche nach Bestellungen soll möglich sein. | 5 | 100/50/0 | 500 | |||
| 138.0 | Einzel- und Sammelbestellungen | Der Bestelldatensatz soll mindestens folgende Lieferanteninformation enthalten: Lieferantenname, Lieferantenkürzel, Kostenstellenbevollmächtigter, Besteller, bestellende Zweigstelle/Standort, Kommentarfeld. | 5 | 100/50/0 | 500 | |||
| 139.0 | Einzel- und Sammelbestellungen | Statusänderungen an Erwerbungsdatensätzen sollen nachvollziehbar sein (Historie). | 5 | 100/50/0 | 500 | |||
| 140.0 | Einzel- und Sammelbestellungen | Der Bestellstatus soll im Onlinekatalog abgebildet werden. | 5 | 100/50/0 | 500 | |||
| 141.0 | 3 Katalogisierung und Metadatenmanagement | |||||||
| 142.0 | Katalogisierungsrichtlinie RDA | Für Katalogisierung und Erschließung aller Medien gilt als Standard das Regelwerk RDA und muss vom Bibliothekssystem unterstützt werden. | k.o. | |||||
| 143.0 | Katalogisierungsrichtlinie RDA | Die kooperative Katalogisierung im Verbundkatalog K10plus muss unterstützt werden. Eine Datenübernahme per Schnittstelle ist möglich. | k.o. | |||||
| 144.0 | Katalogisierungsrichtlinie RDA | Workflows für die kooperative deutsche Normdatenverwaltung (GND) sollen unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 145.0 | Katalogisierungsrichtlinie RDA | Workflows für die kooperative Katalogisierung von Zeitschriften (ZDB, EZB) können unterstützt werden. | 3 | 100/50/0 | 300 | |||
| 146.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Bibliografische Metadaten (Titel-, Lokal- und Exemplardaten) müssen erstellt und verwaltet werden können. Kurztitelaufnahmen müssen erstellt werden können. Das System muss sicherstellen, dass Titeldaten mit verknüpften Lokal-, Exemplar- oder Bestelldaten nicht ohne Prüfung gelöscht werden. Ebenso muss es verhindern, dass Exemplardaten mit verknüpften Ausleihdaten gelöscht werden. | k.o. | |||||
| 147.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Digitaler und physischer Bestand der Bibliothek sollen als unterschiedliche Exemplare unter einer gemeinsamen Titelaufnahme aufnehmbar sein. | 5 | 100/50/0 | 500 | |||
| 148.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Titeldatensätze können zu Fremddigitalisaten verlinkt und im Onlinekatalog dargestellt werden. | 3 | 100/50/0 | 300 | |||
| 149.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Auf Titelebene sollen unterschiedliche Berechtigungen für Korrekturen/Löschungen vergeben werden. | 5 | 100/50/0 | 500 | |||
| 150.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Die Katalogisierung soll musikalische Besetzungen, Gattungen, Sammlungen und Altbestände abbilden. | 5 | 100/50/0 | 500 | |||
| 151.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Der Lokaldatensatz soll mindestens folgende Informationen enthalten: Zweigstelle/Standort, Notation bzw. Grundsignatur, Bestandsangaben für Zeitschriftendaten, Notiz- und Bemerkungsfelder, weitere überregionale Informationen (mindestens Fernleihkennzeichen). | 5 | 100/50/0 | 500 | |||
| 152.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Der Exemplarsatz soll mindestens folgende Informationen enthalten: Zweigstelle/Standort, mind. zwei Signaturen (Magazinsignatur, Signatur im Präsenzbereich), Mediennummer, Zugangsnummer, Exemplar- und Geschäftsgangstatus, (temporärer) Exemplartyp, Anzahl Teile, Notiz- und Bemerkungsfelder. | 5 | 100/50/0 | 500 | |||
| 153.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Das System soll recherchierbare Provenienzmerkmale der Exemplare zu verzeichnen. | 5 | 100/50/0 | 500 | |||
| 154.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Das System soll eine unbegrenzte Anzahl von Exemplarsätzen zu einem Titeldatensatz ermöglichen. | 5 | 100/50/0 | 500 | |||
| 155.0 | Verwaltung Titel-, Lokal- und Exemplardaten | Eine differenzierte Suche nach Lokal- und Exemplarinformationen muss möglich sein. | k.o. | |||||
| 156.0 | Verwaltung von Normdaten | Anwenderspezifische Normdateien und Schlagwortdateien müssen erstellt, importiert und verwaltet werden können. | k.o. | |||||
| 157.0 | Verwaltung von Normdaten | Der Import und Export von überregionalen Normdaten aus der GND kann über den eindeutigen Identifier GND-ID erfolgen. Dies umfasst auch Updates und Löschungen. | 3 | 100/50/0 | 300 | |||
| 158.0 | Import und Export Metadaten | Konfigurierbare Import- und Exportroutinen für Titel-, Lokal- und Exemplardaten müssen zur Verfügung stehen. | k.o. | |||||
| 159.0 | Import und Export Metadaten | Massendatenimporte und Datenaktualisierungen sollen sich effizient verwalten lassen. Bei Datenimport findet eine automatische Dublettenprüfung statt. | 5 | 100/50/0 | 500 | |||
| 160.0 | Import und Export Metadaten | Datenexporte sollen möglich sein für: den gesamten Datenbestand, ein definierbares Set von Datensätzen, einzelne Datensätze oder Datensätze eines definierbaren Zeitintervalls. Das Zielformat kann definiert werden. | 5 | 100/50/0 | 500 | |||
| 161.0 | Validierung und Normalisierung | Validierungs- und Normalisierungsroutinen sollen bei der Verarbeitung von Metadatensätzen angewendet werden. | 5 | 100/50/0 | 500 | |||
| 162.0 | Metadateneditor | Für das Erstellen, Bearbeiten und Löschen von bibliografischen Metadaten (Titel-, Lokal- und Exemplardaten) soll ein Metadateneditor die Format- und Feldstruktur (Felder, zwei Indikatoren, Unterfelder) von MARC 21 und MARCXML abbilden. | 5 | 100/50/0 | 500 | |||
| 163.0 | Metadateneditor | Das Erfassungsformat kann durch formularbasierte Eingabefelder vom MARC 21-Austauschformat entkoppelt werden. | 3 | 100/50/0 | 300 | |||
| 164.0 | Metadateneditor | Das RDA-Toolkit kann im Metadateneditor zur Verfügung sgestellt werden. Weitere Richtlinien oder Dokumentationen können bei Bedarf integriert werden. | 3 | 100/50/0 | 300 | |||
| 165.0 | 4 Auswertungen und Dashboards | |||||||
| 166.0 | Auswertungen_Berichte, Checklisten | Das System soll wiederkehrende Dokumente, Auswertungen (Standardberichte und Standardchecklisten, etc.) als Vorlagen oder Muster zur Verfügung stellen. | 5 | 100/50/0 | 500 | |||
| 167.0 | Auswertungen_Berichte, Checklisten | Das System soll die Möglichkeit bieten, dass die vorhandenen standardisierten Vorlagen (Berichte, Auswertungen, Checklisten) an die Bedürfnisse des Bereichs angepasst werden können. | 5 | 100/50/0 | 500 | |||
| 168.0 | Auswertungen_Standarddashboards | Das System soll Standarddashboards zur Verfügung stellen. | 5 | 100/50/0 | 500 | |||
| 169.0 | Auswertungen_Standarddashboards | Das System soll die Möglichkeit bieten, dass die vorhandenen standardisierten Dashboards an die Bedürfnisse des Bereichs angepasst werden können. | 5 | 100/50/0 | 500 | |||
| 170.0 | Abbildung der Vorgaben der Deutschen Bibliotheksstatistik (DBS) | Die Anforderungen der Deutschen Bibliotheksstatistik (DBS) müssen erfüllt werden. Alle für die DBS erforderlichen Daten können im System gespeichert und ausgewertet werden. | k.o. | |||||
| 171.0 | Abbildung der Vorgaben der Deutschen Bibliotheksstatistik (DBS) | Das Bibliothekssystem kann die Daten zur Abbildung der DBS per Schnittstelle automatisiert an das HBZ übermitteln | 3 | 100/50/0 | 300 | |||
| 172.0 | Frei definierbare Statistiken und Berichte für Anwender | Alle Stornierungen sollen dauerhaft protokolliert werden und auswertbar sein. | 5 | 100/50/0 | 500 | |||
| 173.0 | Frei definierbare Statistiken und Berichte für Anwender | Das System stellt Auswertungsmöglichkeiten für Bezahlvorgänge zur Verfügung. | 5 | 100/50/0 | 500 | |||
| 174.0 | Statistik und Berichtswesen Metadatenmanagement | Die Nutzung des Bestandes soll auf Exemplar- und/oder Titelebene ausgewertet werden können. | 5 | 100/50/0 | 500 | |||
| 175.0 | Frei definierbare Statistiken und Berichte für Anwender | Anhand bibliotheksspezifischer Parameter, mindestens Zweigstellen, Standorte, Signaturen, Benutzergruppen, Materialart oder frei definierbarer Felder sollen über die DBS hinaus Statistiken und Berichte erstellt werden können. | 5 | 100/50/0 | 500 | |||
| 176.0 | Frei definierbare Statistiken und Berichte für Anwender | Das Statistiktool des BMS soll auch in der Lage sein, Statistiken für e-Medien und Websitenutzung zu verarbeiten. | 5 | 100/50/0 | 500 | |||
| 177.0 | Frei definierbare Statistiken und Berichte für Anwender | Eine statistische Auswertung des Webfrontend (mindestens OPAC) soll über eine Benutzeroberfläche verfügbar, frei konfigurierbar und auswertbar sein. Bitte geben Sie die Auswertungsmöglichkeiten an. | 5 | 100/50/0 | 500 | |||
| 178.0 | Frei definierbare Statistiken und Berichte für Anwender | Standardvorlagen für regelmäßig zu erstellende Statistiken und Berichte sollten gespeichert und nachgenutzt werden können. | 5 | 100/50/0 | 500 | |||
| 179.0 | Statistik und Berichtswesen Metadatenmanagement | Das System kann Bestands- und Benutzungsstatistiken generieren. Diese können auf Anforderung jederzeit und automatisiert als Monats- oder Jahresstatistiken erstellt werden. | k.o. | |||||
| 180.0 | Statistik und Berichtswesen Metadatenmanagement | Es soll möglich sein, Berichte über offene Gebühren der Benutzer zu erstellen. Autorisierten Mitarbeitenden soll es möglich sein, Berichte über gemahnte Benutzer zu erstellen. | 5 | 100/50/0 | 500 | |||
| 181.0 | Statistik und Berichtswesen Metadatenmanagement | Das System soll Betriebsstatistiken über alle Ausleihvorgänge, nach Zeiteinheiten (Stunde, Tag, Monat, Jahr), nach Benutzergruppe, Medientypen usw. erstellen. Ausgewertete Facetten und Ausgabeart sollen nach Möglichkeit konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 182.0 | Statistik und Berichtswesen Metadatenmanagement | Das automatisierte Abholen und Verarbeiten von Nutzungsstatistiken im COUNTER-Standardformat soll über SUSHI-Schnittstellen (NISO-Standard Z39.93) möglich sein. | 5 | 100/50/0 | 500 | |||
| 183.0 | 5 Dateneingabe u. -verarbeitung | |||||||
| 184.0 | Löschfunktion | Mit dem System verarbeitete personenbezogene Daten müssen nach Zweckerledigung und Ablauf von Löschfristen gelöscht oder anonymisiert werden können. | k.o. | |||||
| 185.0 | Löschfunktion | Das Löschen von kompletten Datensätzen sollte grundsätzlich nur durch autorisierte User (Fachanwender mit Berechtigung/Fachadministrator) erfolgen können. | 5 | 100/50/0 | 500 | |||
| 186.0 | Lösch-/Anonymisierungsfunktion | Das System soll Löschung/Anonymisierungs-Funktionen bereitstellen (Fristüberwachung/-vergabe, Löschfunktion). | 5 | 100/50/0 | 500 | |||
| 187.0 | Datenschutzerklärung | Das System soll ein Muster einer standardisierten Datenschutzerklärung vorhalten und diese je User/Fall strukturiert abspeichern können. | 5 | 100/50/0 | 500 | |||
| 188.0 | Einwilligung in die Datenerfassung/-speicherung | Das System soll ein Muster zur standardisierten Datenerfassung/-speicherung vorhalten und diese je User/Fall strukturiert abspeichern können. | 5 | 100/50/0 | 500 | |||
| 189.0 | Einwilligung in die Datenerfassung/-speicherung | Das Muster zur standardisierten Datenerfassung/-speicherung soll vom User mit einer digitalen Signatur unterzeichnet werden können (z. B. Personalausweisfunktion). | 5 | 100/50/0 | 500 | |||
| 190.0 | 6 Ausgabeoptionen und Druck | |||||||
| 191.0 | Printausgabe - Dokumente | Das System muss fähig sein, sämtliche Dokumente über eine Druckfunktion ausgeben zu können. | k.o. | |||||
| 192.0 | PDF-Generierung - Dokumente | Das System soll fähig sein, sämtliche Dokumente per PDF-Generierung (PDF-Druckausgabe) ausgeben zu können. Das kann auch über auf dem System installierte PDF-Druckdienste erfolgen. | k.o. | |||||
| 193.0 | Etikett-Funktion | Das System soll eine Etiketten-Druckfunktion enthalten, in der u.a. Etiketten inhaltlich und nach Größenvorgaben individuell erstellt werden können. | 5 | 100/50/0 | 500 | |||
| 194.0 | Manuelle Bearbeitung vor Druckausgabe | Das System soll die manuelle Bearbeitung aller Angaben in Formularen vor dem Druck ermöglichen. | 5 | 100/50/0 | 500 | |||
| 195.0 | Corporate Design der Stadt Leipzig | Sämtliche Ausdrucke und Schreiben, die im Rahmen der Geschäftsgänge erzeugt werden, sollen hinsichtlich der Inhalte und auszugebenden Felder gemäß der lokalen Präferenzen (https://markenportal.leipzig.de/) konfigurierbar sein. Dies gilt auch für Quittungsdrucke, Signaturschilder, Barcode-Etiketten. | 5 | 100/50/0 | 500 | |||
| 196.0 | Druckausgabe Datenimport und -export | Eine zentrale Druckersteuerung soll ermöglichen, dass Systemdrucker standort- und aufgabenspezifisch konfiguriert werden können (Erwerbung, Fernleihe, Katalogisierung). | 5 | 100/50/0 | 500 | |||
| 197.0 | Druckausgabe Datenimport und -export | Ausdrucke von Quittungen an Kassenautomaten und Selbstverbuchungstechnologie sollten möglich sein. | 5 | 100/50/0 | 500 | |||
| 198.0 | Druckausgabe Datenimport und -export | Sämtliche Ausdrucke und Schreiben, die im Rahmen der Geschäftsgänge erzeugt werden, sollen hinsichtlich Corporate Design und Typographie gemäß der lokalen Präferenzen (https://markenportal.leipzig.de/) konfigurierbar sein. Diese sollen nach Zweigstelle/Standort differenziert gestaltet werden können. | 5 | 100/50/0 | 500 | |||
| 199.0 | Druckausgabe Datenimport und -export | Die Druckausgabe soll sowohl einzeln/sofort oder als Sammlung erfolgen. | 5 | 100/50/0 | 500 | |||
| 200.0 | Druckausgabe Datenimport und -export | Nummernkreise sollen auch als Barcode gedruckt werden, mindestens Ausweisnummern und Exemplarbarcodes. | 5 | 100/50/0 | 500 | |||
| 201.0 | Druckausgabe Datenimport und -export | Alle Ausdrucke sollen auch digital versendet und abgelegt werden können. Bitte geben Sie die unterstützten Dateiformate und Übertragungswege an. | 5 | 100/50/0 | 500 | |||
| 202.0 | Interne und externe Kommunikation/Brief/Mail/Messaging | Für die externe Kommunikation müssen verschiedene Versandarten und Ausgabeformate unterstützt und konfiguriert werden können. Dabei werden mindestestens E-Mail und Briefe unterstützt. | k.o. | |||||
| 203.0 | Interne und externe Kommunikation/Brief/Mail/Messaging | Die Nachrichten sollen an frei konfigurierbare Gruppen von Bibliotheksbenutzern addressiert werden können. Der Versand erfolgt über eine verschlüsselte Anbindung an den E-Mail-Server und per bcc. | 5 | 100/50/0 | 500 | |||
| 204.0 | Interne und externe Kommunikation/Brief/Mail/Messaging | Für die interne Kommunikation sollen zu einzelnen Vorgängen Mitarbeitende untereinander im System via Nachricht oder E-Mail kommunizieren können. Diese können erfasst, bearbeitet und gelöscht werden. | 5 | 100/50/0 | 500 | |||
| 205.0 | Benachrichtigungsschreiben und Mitteilungen | Funktionalitäten zum Kommunikationsmanagement im Erwerbungsprozess sollen vorhanden sein, z. B. für Anfragen, Bestellungen, Mahnschreiben, Rückmeldungen der Lieferanten, der Benutzer und/oder der Fachbereiche. | 5 | 100/50/0 | 500 | |||
| 206.0 | Benachrichtigungsschreiben und Mitteilungen | Standard-Benachrichtigungsschreiben für die Kommunikation zu Ausleihe und Fernleihe sollen vorhanden sein. | 5 | 100/50/0 | 500 | |||
| 207.0 | Benachrichtigungsschreiben und Mitteilungen | Standard-Benachrichtigungsschreiben für die Kommunikation mit Lieferanten und anderen Anbietern sollen zur Verfügung stehen, mindestens jedoch für Bestellung, Mahnung, Stornierung, Abonnement-Kündigung. | 5 | 100/50/0 | 500 | |||
| 208.0 | Benachrichtigungsschreiben und Mitteilungen | Für Benachrichtigungen sollen gängige, möglichst offen dokumentierte Ausgabeformate unterstützt werden. (z. B. Open Document Format) | 5 | 100/50/0 | 500 | |||
| 209.0 | Abbildung der Vorgaben der Deutschen Bibliotheksstatistik (DBS) | Statistiken und Berichte sollen mindestens auf folgende Weisen ausgegeben werden können: online (HTML), Druck, Versand per E-Mail, Export in Tabellenkalkulation (CSV, XLSX). Die Ausgabeformate sollen flexibel konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 210.0 | Ausleihe und Fernleihe Quittungen und Bestellzettel | Kunden und Bibliothekspersonal sollen über das Bibliothekssystem für Ausleihen, Rückgaben, Bestellungen, Gebühren und Aktionen eine Quittung bzw. Bestellzettel erhalten. | 5 | 100/50/0 | 500 | |||
| 211.0 | Ausleihe und Fernleihe Quittungen und Bestellzettel | Druck und Erzeugen von Fernleihzetteln sowie Quittungen soll möglich sein. | 5 | 100/50/0 | 500 | |||
| 212.0 | Ausleihe und Fernleihe Quittungen und Bestellzettel | Quittungsdrucke für Endkunden müssen unterstützt werden, mindestens Ausleih-, Rückgabe-, Transport-, Gebührenquittung, Reservierungs-/ Bereitstellungszettel. Die Inhalte sind konfigurierbar (mindestens standortspezifisch). | 5 | 100/50/0 | 500 | |||
| 213.0 | Ausleihe und Fernleihe Quittungen und Bestellzettel | Die Ausgabe von Quittungen soll entweder manuell angestoßen werden oder erfolgt automatisiert. Dies ist pro Quittungsart konfigurierbar. | 5 | 100/50/0 | 500 | |||
| 214.0 | Ausleihe und Fernleihe Quittungen und Bestellzettel | Änderungen an den Druck-Einstellungen, mindestens das Unterdrücken des Quittungsdrucks und die Wahl des Druckers, sollten pro Ausleihsitzung vorgenommen werden können. | 5 | 100/50/0 | 500 | |||
| 215.0 | Ausleihe und Fernleihe Quittungen und Bestellzettel | Der Druck gängiger Bestellzettel soll unterstützt werden, mindestens für Magazin-, Freihand-, Fernleih-, Kopienbestellung. Die Inhalte sind konfigurierbar (mindestens nach Ausgabeort und nach Benutzergruppe). | 5 | 100/50/0 | 500 | |||
| 216.0 | Ausleihe und Fernleihe Quittungen und Bestellzettel | Die Ausgabe von Bestellzetteln soll entweder manuell angestoßen werden oder erfolgt automatisiert aufgrund konfigurierbarer Parameter: Zeitpunkt (Tage, Uhrzeiten), Vorgang. Die Reihenfolge für den Ausdruck der Bestellzettel ist konfigurierbar. | 5 | 100/50/0 | 500 | |||
| 217.0 | Ausleihe und Fernleihe Quittungen und Bestellzettel | Die unterschiedlichen Drucker einzelner Bereiche sollen anhand konfigurierbarer Parameter angesteuert werden (Signatur, Medienstandort). | 5 | 100/50/0 | 500 | |||
| 218.0 | Erwerbung | Das Drucken von Signaturenetiketten, Medienbarcodes und Zetteln zur interne Weiterverarbeitung soll möglich sein. Die Ausgabe kann sowohl einzeln/sofort oder als Sammlung erfolgen. | 5 | 100/50/0 | 500 | |||
| 219.0 | Erwerbung | Im Zuge der Inventarisierung sollen verschiedene Druckoptionen zur Verfügung stehen, mindestens Signaturenetiketten, Medienbarcodes, Laufzettel (Stapeldruck, Sofortdruck). | 5 | 100/50/0 | 500 | |||
| 220.0 | Erwerbung | Integrierte RFID-Etikettendrucker zum Druck der Medininformationen auf das RFID-Label und Codierung des Labels in einem Arbeitsschritt sollen unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 221.0 | Erwerbung | Umlaufzettel für Zeitschriftenhefte sollen sowohl ad-hoc, wie auch automatisiert beim Hefteingang gedruckt werden. | 5 | 100/50/0 | 500 | |||
| 222.0 | Erwerbung | Beim Hefteingang sollen verschiedene Druckoptionen zur Verfügung stehen, mindestens Signaturenetiketten, Medienbarcodes, Laufzettel (Stapeldruck, Sofortdruck). | 5 | 100/50/0 | 500 | |||
| 223.0 | Automaten | Kunden sollen an den Automaten für Ausleih- und Rückgabevorgänge, Gebühren Quittungen drucken können. | 5 | 100/50/0 | 500 | |||
| 224.0 | Automaten | Kunden sollen an den Automaten erstellte Belege an die im Benutzerkonto hinterlegte E-Mail-Adresse senden können. | 5 | 100/50/0 | 500 | |||
| 225.0 | Automaten | Die Inhalte für den Quittungsdruck aus dem Bibliotheksmanagementsystem sollten konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 226.0 | 7 Usability und Frontend | |||||||
| 227.0 | Ergonomie | Das Vokabular der Benutzeroberfläche soll an lokale Gegebenheiten anpassbar sein (Feldbenennungen). | 5 | 100/50/0 | 500 | |||
| 228.0 | Ergonomie | Neben der reinen Mausbedienung soll für häufig benötigten Funktionen in allen Anwenderbereichen der Einsatz von Funktionstasten/Hotkeys ermöglicht werden, insbesondere im Kontext der Ausleihtheke. | 5 | 100/50/0 | 500 | |||
| 229.0 | Ergonomie | Einzelne Elemente, Funktionen oder Felder sollen in der Benutzeroberfläche hinzugefügt oder ausgeblendet werden können. | 5 | 100/50/0 | 500 | |||
| 230.0 | Ergonomie | Die Benutzeroberfläche soll für mobile Endgeräte optimiert sein. | 5 | 100/50/0 | 500 | |||
| 231.0 | Sprachen | Die Software (min. Katalog und Website) muss vollständig in deutscher und englischer Sprache angeboten werden. Bei Übersetzungen ins Deutsche ist auf korrekte Übersetzung zu achten (Fach-Terminologie). | k.o. | |||||
| 232.0 | Sprachen | Die Software soll neben Deutsch und Englisch weitere Sprachen unterstützen. | 5 | 100/50/0 | 500 | |||
| 233.0 | OPAC - Online-Katalog | Die Webanwendung muss unter allen in Deutschland gängigen Internet-Browsern (Chrome, Firefox, Edge) in den zur Ausschreibungsveröffentlichung aktuellen Versionen betriebsfähig sein. | k.o. | |||||
| 234.0 | OPAC - Online-Katalog | Die Webanwendung muss unter allen in Deutschland zur Ausschreibungsveröffentlichung aktuellen Internet-Browsern (Chrome, Firefox, Safari, Edge) für mobile Endgeräte betriebsfähig sein. | k.o. | |||||
| 235.0 | OPAC - Online-Katalog | Die Webanwendung soll über ein Content Management System frei konfigurierbar sein. | 3 | 100/50/0 | 300 | |||
| 236.0 | OPAC - Online-Katalog | Die Webanwendung soll die Vorgaben zum visuellen Erscheinungsbild der Stadtverwaltung Leipzig (https://markenportal.leipzig.de/) umsetzen. Das bedeutet vor allem die Verwendung vorgegebener Farben und Schriften. | 5 | 100/50/0 | 500 | |||
| 237.0 | OPAC - Online-Katalog | Die Benutzeroberfläche soll intuitiv und leicht zu bedienen sein. | 5 | 100/50/0 | 500 | |||
| 238.0 | OPAC - Online-Katalog | Die Webanwendung muss eine umfangreiche Recherche nach Titel-, Bestands- und Exemplardaten über einer moderne Suchoberfläche ermöglichen. Die Eigenschaften sind detailliert zu beschreiben. | k.o. | |||||
| 239.0 | OPAC - Online-Katalog | Die Treffermenge soll durch Filterung (Facetten) eingegrenzt werden können. Für die Suchergebnisse stehen unterschiedliche Sortierungsmöglichkeiten zur Verfügung, minestens Relevanz-Ranking, Erscheinungsjahr, Verfasser oder Titel (wahlweise in auf- oder absteigender Reihenfolge). | 5 | 100/50/0 | 500 | |||
| 240.0 | OPAC - Online-Katalog | Die Filterung und Sortierung nach Standort des Mediums (Bibliotheksstandort, Datenbank) soll möglich sein. | 5 | 100/50/0 | 500 | |||
| 241.0 | OPAC - Online-Katalog | Die Webanwendung soll über konfigurierbare Schnittstellenlösungen Inhalte regelbasiert importieren und exportieren können (z.B. News, Termine, Medienempfehlungen). Die Lösungen zum Datenaustausch sind anzugeben. | 5 | 100/50/0 | 500 | |||
| 242.0 | OPAC - Online-Katalog | Die Anzeige von im Erwerbungsgeschäftsgang befindlichen Medien (Statusinformationen wie bestellt, vermisst) und von Lizenzinformationen (E-Ressourcen) soll konfiguriert und im Katalog angezeigt werden können. | 5 | 100/50/0 | 500 | |||
| 243.0 | OPAC - Online-Katalog | Der Zugang zu Online-Angeboten direkt aus dem Katalog heraus soll per Einmalanmeldung (single sign-on) möglich sein. | 5 | 100/50/0 | 500 | |||
| 244.0 | OPAC - Online-Katalog | Das Login in das Benutzerkonto soll mit mehreren Identifiern, mindestens jedoch mit E-Mail-Adresse oder Benutzernummer, möglich sein. | 5 | 100/50/0 | 500 | |||
| 245.0 | OPAC - Online-Katalog | Vormerkungen und Bestellungen von Medien sollen im Online-Katalog integriert und konfigurierbar sein. Verfügbarkeitszeitpunkt und alternative Nutzungsmöglichkeiten werden abgebildet. | 5 | 100/50/0 | 500 | |||
| 246.0 | OPAC - Online-Katalog | Deeplinks und Permalinks auf Katalogeinträge sollen angeboten werden. | 5 | 100/50/0 | 500 | |||
| 247.0 | OPAC - Online-Katalog | Bookmark-, Share- und Recommend-Funkionen sollen angeboten werden. | 5 | 100/50/0 | 500 | |||
| 248.0 | OPAC - Online-Katalog | Bestände von Online-Angeboten und Datenbanken (mindestens Onleihe) müssen direkt in die Treffermenge integriert werden und sind filterbar. | k.o. | |||||
| 249.0 | OPAC - Online-Katalog | Es sollen weitere Datenbanken und Online-Angebote in den OPAC integriert werden können. Bitte bennenen. | 5 | 100/50/0 | 500 | |||
| 250.0 | OPAC - Online-Katalog | Das Passwort für das Login zum Benutzerkonto muss durch die Endanwender (Bibliotheksbenutzende) selbstständig zurückgesetzt werden können. | k.o. | |||||
| 251.0 | Benutzerselbstbedienung | Über die Selbstbedienungsfunktionalität muss der Benutzer lesenden Zugriff auf sein Benutzerkonto haben: auf alle Ausleihen inklusive Abholorte, Fernleihen, Vormerkungen, offene Gebühren | k.o. | |||||
| 252.0 | Benutzerselbstbedienung | Die entliehenen digitalen Medien/Lizenzen sollen im Benutzerkonto abgebildet werden. Digitale Ausleihen und physischen Ausleihen können einfach und "auf einen Blick" gemeinsam verwaltet werden. | 5 | 100/50/0 | 500 | |||
| 253.0 | Benutzerselbstbedienung | Die Kunden sollen auf das Benutzerkonto und die Selbstbedienungsfunktionen an Terminals oder Automaten zugreifen können. Das System stellt die entsprechenden Schnittstellen bereit. | 5 | 100/50/0 | 500 | |||
| 254.0 | Benutzerselbstbedienung | Über die Selbstbedienungsfunktionalität soll der Benutzer Zugriff auf seine Stammdaten haben. Art und Umfang der angezeigten Daten sowie Zugriffsrechte (lesen/schreiben/löschen) sollen durch die Bibliothek konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 255.0 | Benutzerselbstbedienung | Sämtliche Zugriffe des Benutzers auf sein Konto müssen passwortgeschützt sein. Alle Zugriffe erfolgen mindestens SSL-verschlüsselt. | k.o. | |||||
| 256.0 | Benutzerselbstbedienung | Benutzende können sich online in der Bibliothek anmelden, ihre Daten verifizieren (mindestens Nachweis über elektronischen Personalausweis/eID), die Benutzungsgebühr bezahlen und einen digitalen Bibliotheksausweis erhalten. Die Stammdaten werden durch die Bibliothek festgelegt. Das Verfahren muss rechtssicher sein und die aktuellen Normen für Online-Vertragsschlüsse erfüllen. (Option im LV) | 3 | 100/50/0 | 300 | |||
| 257.0 | Benutzerselbstbedienung | Bei Medienersatz kann der Verlust online von den Bibliothekskunden gemeldet werden. | 3 | 100/50/0 | 300 | |||
| 258.0 | Dienstrecherche | Die Software muss über eine modulübergreifende, suchmaschinenbasierte Dienstrecherche verfügen (interne Katalogrecherche). Die Treffermenge kann durch Filterung (Facetten) eingegrenzt werden. Es wird eine Standard-Indexierung und -Facettierung angeboten. Für die Suchergebnisse stehen unterschiedliche Sortierungsmöglichkeiten zur Verfügung. | k.o. | |||||
| 259.0 | Dienstrecherche | Recherche nach Musikdrucken, Provenienzen und Altbeständen durch normierte Sucheinstiege soll möglich sein. | 5 | 100/50/0 | 500 | |||
| 260.0 | Dienstrecherche | Die Recherchefunktion soll sowohl die sogenannte "Einfache Suche" (Einfeldsuche) als auch die "Erweiterte Suche" (Expertensuche) umfassen. Die Expertensuche beinhaltet die Verknüpfung von Indizes und Suchbegriffen. Die Recherchefunktion bietet Trunkierung sowie eine Phrasensuche an. | 5 | 100/50/0 | 500 | |||
| 261.0 | Dienstrecherche | Bei der Suche nach einer ISBN-10 kann auch die entsprechende ISBN-13 gefunden werden und umgekehrt. | 3 | 100/50/0 | 300 | |||
| 262.0 | Dienstrecherche | Für ausgewählte Indizes, (z.B. Normdaten und Signaturen), soll eine Browse-Funktion für das Blättern in den Index-Einträgen angeboten werden. | 5 | 100/50/0 | 500 | |||
| 263.0 | Usability; Bedienbarkeit | Das System soll durch strukturierte Datenerfassung die Möglichkeit bieten, die Eingabe innerhalb eines bildschirmorientierten Eingabebereiches so lange zu verändern, bis sie endgültig bestätigt oder verworfen wird. | 5 | 100/50/0 | 500 | |||
| 264.0 | Usability; Bedienbarkeit | Das System soll in den Erfassungsmasken enthaltene Abkürzungen, Verschlüsselungen oder Fremdwörter für die User verständlich darstellen (z.B. Unterstützung mittels einer Hilfefunktion). | 5 | 100/50/0 | 500 | |||
| 265.0 | Usability; Bedienbarkeit | Ein einheitliches Hilfesystem soll für den User in allen Modulen / Verfahrensbestandteilen verfügbar sein. | 5 | 100/50/0 | 500 | |||
| 266.0 | Usability; Bedienbarkeit | Durch eine kontextsensitive Hilfe-/Assistentenfunktion soll die Programmnutzung für alle Bearbeitungsmasken unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 267.0 | Usability; Bedienbarkeit | Innerhalb der Hilfe soll die Suche über einen Index möglich sein. | 5 | 100/50/0 | 500 | |||
| 268.0 | Usability; Bedienbarkeit | Selbsterklärende Fehlermeldungen sollen angezeigt werden. | 5 | 100/50/0 | 500 | |||
| 269.0 | Usability; Bedienbarkeit | Hilfetexte sollten an die lokalen Bedürfnisse der Einrichtung angepasst werden können. | 5 | 100/50/0 | 500 | |||
| 270.0 | Usability; Bedienbarkeit | Der Hilfetext soll downloadbar und/oder speicherbar sein. | 5 | 100/50/0 | 500 | |||
| 271.0 | Usability; Bedienbarkeit | Das System soll während der Bearbeitung den Usern den jeweiligen Bearbeitungskontext auf dem Bildschirm erkennen und somit wissen lassen, in welchem Bearbeitungsschritt er sich befindet und wie er zu vorherigen beziehungsweise folgenden Bearbeitungsschritten kommt. | 5 | 100/50/0 | 500 | |||
| 272.0 | Usability; Bedienbarkeit | Das System soll den Usern die Möglichkeit bieten, Sachverhalte nachvollziehbar und wirklichkeitstreu eingeben und wiedererkennbar abspeichern zu können. Für einen sachverständigen Dritten ist erkennbar, dass das Verfahren einen bestimmten Sachverhalt verarbeiten kann. | 5 | 100/50/0 | 500 | |||
| 273.0 | Usability; Bedienbarkeit | Das System soll die Fachterminologie abbilden und einhalten. | 5 | 100/50/0 | 500 | |||
| 274.0 | Usability; Bedienbarkeit | Das System muss den Usern bei Löschaktionen einen Warnhinweis und eine Abbruchmöglichkeit bieten können. | k.o. | |||||
| 275.0 | Usability; Bedienbarkeit | Das System soll dem User Fehlermeldungen verständlich auf dem Bildschirm anzeigen können. | 5 | 100/50/0 | 500 | |||
| 276.0 | Usability; Bedienbarkeit | Das System soll dem User bei erfolgreicher Aktivität eine Erfolgsmitteilung, bei nichterfolgreicher Aktivität eine Fehlermeldung ausgeben können. | 5 | 100/50/0 | 500 | |||
| 277.0 | Usability; Bedienbarkeit | Das System soll in seiner Gesamtheit so ausgestaltet sein, dass alle User die Möglichkeit haben das System zu verstehen und zu erkennen wie man eigenständig mit dem System umgehen kann. | 5 | 100/50/0 | 500 | |||
| 278.0 | Usability; Barrierefreiheit | Die Anforderungen der Web Content Accessibility Guidelines (WCAG) 2.1, der europäischen Richtlinie EU 2016/2102, der europäischen Norm EN 301 549 V3.2.1 und der deutschen Verordnung BITV 2.0 sollen erfüllt werden. | 5 | 100/50/0 | 500 | |||
| 279.0 | Usability; Barrierefreiheit | Das System soll dem User die Möglichkeit bieten die Schriftgröße, insbesondere für Anwender mit Sehschwäche, individuell anpassen zu können. | 5 | 100/50/0 | 500 | |||
| 280.0 | Usability; Barrierefreiheit | Das System soll für den User gut strukturierte Texte enthalten, welche Sehbehinderte und Blinde mit technischer Hilfe lesen und ausgeben können. | 5 | 100/50/0 | 500 | |||
| 281.0 | Usability; Fehlervermeidung | Das System soll durch implementierte Workflows und Logikprüfungen in der Vorgangsbearbeitung die Fehlervermeidung bestmöglich unterstützen. | 5 | 100/50/0 | 500 | |||
| 282.0 | Usability; Fehlervermeidung | Das System soll den Anwendern konstruktive Plausibilitätsprüfungen (z.B. "Geburtsdatum fehlt") und nicht prohibitive (z.B. "Falsche Eingabe") anbieten können. | 5 | 100/50/0 | 500 | |||
| 283.0 | Usability; Ästhetik | Das System soll dem User die Möglichkeit bieten Farbkombinationen, Schriftarten und die Schriftgröße individuell anpassen zu können (z. B. Bildschirmdarstellung und Fehlermeldungen farblich veränderbar). | 5 | 100/50/0 | 500 | |||
| 284.0 | Usability; Ästhetik | Das System soll dem User eine einheitliche Dialogführung (z.B. für Druck, Hilfe usw.) über alle Module, etc. zur Verfügung stellen können. | 5 | 100/50/0 | 500 | |||
| 285.0 | Usability; Ästhetik | Das System soll dem User aufgabenbezogene Erfassungsmasken zur Verfügung stellen können. | 5 | 100/50/0 | 500 | |||
| 286.0 | Usability; Ästhetik | Das System soll dem User die Pflichtfelder ausweisen. | 5 | 100/50/0 | 500 | |||
| 287.0 | Usability; Ästhetik | Das System soll dem User die Möglichkeit bieten nur notwendige und nicht bereits vorhandenen Daten eingeben zu können. | 5 | 100/50/0 | 500 | |||
| 288.0 | Usability; Ästhetik | Das System soll dem User das Bewegen mittels Tabulatortaste zwischen den Eingabefeldern als Möglichkeit zur Verfügung stellen. | 5 | 100/50/0 | 500 | |||
| 289.0 | 8 Schnittstellen und Interoperabilität | |||||||
| 290.0 | Benutzerdaten und Authentifizierung | Der Zugriff auf Online-Angebote für Nutzende kann automatisch begrenzt werden, wenn das Konto z. B. wegen nicht bezahlter Gebühren gesperrt ist. | 5 | 100/50/0 | 500 | |||
| 291.0 | Datenimport und -export Erwerbungsdaten | Verknüpfungen zu E-Abonnements (Parallel-Abonnements, Kombi-Abonnements usw.) können abgebildet werden. | 3 | 100/50/0 | 300 | |||
| 292.0 | Datenimport und -export Erwerbungsdaten | Pflichtfelder im Lieferantendatensatz sollen konfigurierbar sein. | 3 | 100/50/0 | 300 | |||
| 293.0 | Datenimport und -export Erwerbungsdaten | Das Datenmodell für die Verwaltung elektronischer Ressourcen sollte erweiterbar sein (mindestens um neue Ressourcentypen, neue Lizenzmodelle). | 5 | 100/50/0 | 500 | |||
| 294.0 | E-Payment | Alle Gebühren müssen online bezahlt werden können. Die Voraussetzungen des §312j BGB ("Buttonlösung") werden erfüllt. | k.o. | |||||
| 295.0 | E-Payment | Die Integration der Bezahlplattform für öffentliche Verwaltungen ePayBL mit den Komponenten ePayBL-Kern, ePayBL-Konnektor, ePayBL-Paypage muss gewährleistet sein. | k.o. | |||||
| 296.0 | E-Payment | Gebührenhöhe, Gebührensperren, Bezahlvorgang und Freischaltung sollte für den Kunden einheitlich, medienbruchfrei und nachvollziehbar sein. | 5 | 100/50/0 | 500 | |||
| 297.0 | E-Payment | Mit erfolgter Zahlung muss die Verbuchung im Benutzerkonto sofort und synchron erfolgen und im Bibliotheksmanagementsystem umgesetzt werden. | k.o. | |||||
| 298.0 | Verbundkatalogisierung, Fernleihe | Das System sollte NCIP (Z39.83) für die Integration von Fernleihsystemen unterstützen, welche die folgenden Standardprotokolle verwenden: ISO10160/10161 und ANSI/NISO z39.83 (NCIP). | 5 | 100/50/0 | 500 | |||
| 299.0 | Linked Data | Katalogdaten und Digitalisate sollen über Persistente Identifier verfügen. | 5 | 100/50/0 | 500 | |||
| 300.0 | Metadaten | Neben MARC21 und Dublin Core sollten weitere gängige Austauschformate für bibliographische Daten unterstützt werden, mindestens MODS, METS, ONIX, KBART, BIBFRAME (noch in Entwicklung). | 5 | 100/50/0 | 500 | |||
| 301.0 | Dateneingabe | Vorgegebene und anpassbare Eingabeformulare sollen die manuelle Dateneingabe, -übernahme und -korrektur unterstützen. Datenfelder sollen hinzugefügt oder ausgeblendet werden können. Vorbelegungen durch Standardwerte können definiert werden. | 5 | 100/50/0 | 500 | |||
| 302.0 | Dateneingabe | Bemerkungs- und Notizfelder sollen lange Formate (z.B. BLOB) unterstützen und nicht auf wenige Zeichen beschränkt sein. | 5 | 100/50/0 | 500 | |||
| 303.0 | Dateneingabe | Dateneingaben können als Entwurf gespeichert werden. | 3 | 100/50/0 | 300 | |||
| 304.0 | Dateneingabe | Datensätze können als Grundlage für einen neuen Datensatz kopiert und angepasst werden. | 3 | 100/50/0 | 300 | |||
| 305.0 | unterstützte Zeichensätze | Das System muss durchgängig Unicode (mindestens UTF-8) unterstützen. | k.o. | |||||
| 306.0 | unterstützte Zeichensätze | Das System sollte Unicode auch von rechts nach links (z.B. in Hebräisch) unterstützen. | 5 | 100/50/0 | 500 | |||
| 307.0 | SAP-Anbindung | Alle buchungsrelevanten Vorgänge zur Verwaltung des internen Medienetats können automatisiert mit dem ERP-System SAP ausgetauscht werden. Die Schnittstellenbeschreibung zur Einrichtung des Datenaustauschs sind dieser Ausschreibung angefügt. (Anlage 3 - BAPI-PO) | 3 | 100/50/0 | 300 | |||
| 308.0 | SAP-Anbindung | Alle Katalog- und Exemplarinformationen sollten konfiguriert und exportiert werden können. | 5 | 100/50/0 | 500 | |||
| 309.0 | SAP-Anbindung | Zugangs- und Abgangsbuchungen, die für die Anlagenbuchhaltung der Stadt Leipzig relevant sind, sollen nach Vorgabe des ERP-System SAP abgebildet und exportiert werden können. Die Datensätze sollen vollständig konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 310.0 | SAP-Anbindung | Für Zahlvorgänge an Kassenautomaten, Selbstverbuchern und Online-Zahlungen muss das System IDAT erzeugen und automatisiert an das ERP-System SAP übermitteln können. Der Datenaustausch muss über die MDAT/IDAT-Schnittstelle stattfinden. (siehe Anlage 1 und 2 - Schnittstellenbeschreibung MDAT/IDAT und BDAT). | k.o. | |||||
| 311.0 | SAP-Anbindung | Für Zahlvorgänge muss das System eine MDAT zur Anlage eines Geschäftspartners und BDAT zur Anlage des SEPA-Lastschriftmandates erzeugen und automatisiert an das ERP-System SAP übermitteln können. GP- und VG-Nummern müssen übergeben und vorhandene wiederverwendet werden. Der Datenaustausch muss über die MDAT/IDAT-Schnittstelle stattfinden. (siehe Anlage 1 und 2 - Schnittstellenbeschreibung MDAT/IDAT und BDAT) | k.o. | |||||
| 312.0 | SAP-Anbindung | Vertragsgegenstands- und Geschäftspartnernummern (GP- und VG-Nummern) sollen bei MDAT Buchungen übergeben und vorhandene wiederverwendet werden. (siehe Anlage Schnittstellenbeschreibung MDAT/IDAT und BDAT). | 5 | 100/50/0 | 500 | |||
| 313.0 | SAP-Anbindung | Alle Zahl- und Übermittlungsvorgänge sollten rechtssicher protokolliert werden. Die Protokollierung sollte konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 314.0 | SAP-Anbindung | Die Auswertung und Überprüfung der Übermittlungsvorgänge sowie Fehlermeldungen sollen auf der Fachanwender-Benutzeroberfläche abgebildet werden. | 5 | 100/50/0 | 500 | |||
| 315.0 | RFID-Vollintegration | Die Verbuchung mit RFID-Technologie muss für alle Prozessschritten der Erwerbung, Erschließung und Medienausleihe im Bibliotheksmanagementsystem integriert sein. | k.o. | |||||
| 316.0 | RFID-Vollintegration | RFID-Endgeräte der Firmen Bibliotheca und Feig sollten möglichst ohne Zusatzsoftware im Bibliotheksmanagementsystem verwendbar sein. | 5 | 100/50/0 | 500 | |||
| 317.0 | RFID-Vollintegration | Selbstverbuchungstechnik (Selbstverbuchungsautomat, Rückgabeautomat, Sortieranlage) muss per Schnittstelle (SIP2 oder NCIP ) direkt an das Bibliotheksmanagementsystem angebunden und konfigurierbar sein. | k.o. | |||||
| 318.0 | RFID-Vollintegration | Die Verbuchung mehrerer Medien gleichzeitig (Stapelverbuchung) soll zuverlässig gewährleistet sein. | 5 | 100/50/0 | 500 | |||
| 319.0 | RFID-Vollintegration | Die RFID-Technologie muss die Mediensicherung über Sicherungsgates ermöglichen. Die Medien müssen bei Ausleihe und Rückgabe während der Verbuchung automatisch entsichert bzw. gesichert werden. | k.o. | |||||
| 320.0 | RFID-Vollintegration | Die Benutzerauthentifizierung mit RFID-Ausweisen nach ISO 14443 an Selbstverbuchungsautomaten und für die Zutrittskontrolle zu Bibliotheksräumen sollte unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 321.0 | RFID-Vollintegration | RFID-Ausweise nach ISO 14443 sollten aus dem BMS heraus mit Nutzerdaten bespielt und bedruckt werden können. | 5 | 100/50/0 | 500 | |||
| 322.0 | Applikationsanbindung | Das System muss Schnittstellen für den Datenaustausch sowie Programmierschnittstellen für die Anbindung von Fremdsoftware (APIs) zur Verfügung stellen. Die Schnittstellen müssen verhindern, dass durch fremden Code Sicherheitslücken geöffnet oder Fehlfunktionen des Gesamtsystems verursacht werden. Der Anbieter stellt eine Schnittstellendokumentation zur Verfügung. | k.o. | |||||
| 323.0 | Applikationsanbindung | Das System soll eine frei nutzbare authentifizierte REST-API für den Datenaustausch und für die Anbindung von Fremdsoftware bereitstellen. | 5 | 100/50/0 | 500 | |||
| 324.0 | Applikationsanbindung | Die REST-API soll nach OpenAPI 3.0 (mindestens aber 2.0) dokumentiert sein. | 5 | 100/50/0 | 500 | |||
| 325.0 | Applikationsanbindung | Die REST-API soll den Lese- bzw. Schreibzugriff gemäß Rechten und Rollen des Nutzers beschränken. | 5 | 100/50/0 | 500 | |||
| 326.0 | Applikationsanbindung | Das System soll die Verknüpfung mit Konnektoren / Schnittstellen auch zur Verbindung mit proprietären Schnittstellen vorsehen. Die vorhandenen Verbindungsmöglichkeiten sind aufzulisten. | 5 | 100/50/0 | 500 | |||
| 327.0 | Applikationsanbindung | Eine Unterstützung und kontinuierliche Weiterentwicklung moderner und neuer Schnittstellen, die die Interoperabilität mit modernen Webtechnologien sicherstellen, sollte gewährleistet sein. | 5 | 100/50/0 | 500 | |||
| 328.0 | Applikationsanbindung | Das System muss entweder den vollen Funktionsumfang der NCIP-Schnittstelle oder der SIP2-Schnittstelle nutzen können. | k.o. | |||||
| 329.0 | Applikationsanbindung | Selbstbedienfunktionen (vormerken, bestellen, verlängern, stornieren) sowie das Abfragen von Kontoinformationen auf der Weboberfläche sollten über offengelegte, dokumentierte Schnittstellen unterstützt werden (z.B. REST-API). | 5 | 100/50/0 | 500 | |||
| 330.0 | Applikationsanbindung | Das System sollte Verfügbarkeitsabfragen (Standort, Signatur, Exemplartyp, Ausleihstatus) über offengelegte, dokumentierte Schnittstellen (z. B. REST-API) unterstützen. | 5 | 100/50/0 | 500 | |||
| 331.0 | Applikationsanbindung | Die Bestände von externen Datenquellen (mindestens Onleihe und Overdrive) müssen per Schnittstelle angebunden werden. Die Bestände sind durch die Benutzenden über die Weboberfläche (OPAC) vollständig durchsuchbar und entleihbar. | k.o. | |||||
| 332.0 | Applikationsanbindung | Die Bestände weiterer Online-Dienste sollen per Schnittstelle angebunden werden. Die Bestände sind durch die Benutzenden über die Weboberfläche (OPAC) vollständig durchsuchbar und entleihbar. Bitte geben Sie Datenbanken und Online-Angebote an, die angebunden werden können. | 5 | 100/50/0 | 500 | |||
| 333.0 | Applikationsanbindung | Benutzerdaten von in Leipzig gemeldeten Nutzenden müssen per VOIS.MESO-Schnittstelle (MesoWebService43, https://partner.vois.org/webservice/mws43/apidocs/index.html) oder REST-API mit den Bürgerdaten des städtischen Melderegisters während des Anmeldevorgangs und nach Bedarf lesend abgeglichen werden. Wenn das System diese Funktion nicht nativ zur Verfügung stellt, muss die Funktion spätestens bis zur Produktivsetzung bereitgestellt werden. | k.o. | |||||
| 334.0 | Applikationsanbindung | Das System sollte Authentifizierung gegen Verzeichnisdienste über gängige Verfahren, mindestens mit Shibboleth, LDAP und Microsoft Identity Integration Server unterstützen. | 3 | 100/50/0 | 300 | |||
| 335.0 | Applikationsanbindung | Die Bestände von externen Datenquellen können in die Fachnutzersicht der Client-Oberfläche integriert werden und werden in den Geschäftsgängen berücksichtigt. Bitte geben Sie Datenbanken und Online-Angebote an, die integriert werden können. | 3 | 100/50/0 | 300 | |||
| 336.0 | Datenimport und -export Erwerbungsdaten | Der Import und Export von Erwerbungsdaten (mindestens Titeldaten, Bestell- und Rechnungsdaten, Benachrichtigungen, Mahnungen) soll unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 337.0 | Datenimport und -export Erwerbungsdaten | Import und Export von Erwerbungsdaten sollte auf Basis von standardisierten und in Bibliotheken üblichen Austauschformaten unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 338.0 | Datenimport und -export Erwerbungsdaten | Beim Import von Erwerbungsdaten sollen Bestellungen automatisch angelegt werden. Diese Funktion soll mindestens auf Zweigstellenebene konfigurierbar sein. | 5 | 100/50/0 | 500 | |||
| 339.0 | Datenimport und -export Erwerbungsdaten | Rechnungsdaten sollen manuell importiert werden können. | 5 | 100/50/0 | 500 | |||
| 340.0 | Datenimport und -export Erwerbungsdaten | Metadaten zu allen über PDA erhältlichen Titeln eines Anbieters können in die Datenbank importiert und/oder in den Endnutzerkatalog (OPAC) eingebunden werden können. Die Titeldaten können (z. B. mit einem Abrufzeichen) für das Erwerbungsprofil, für die spätere Selektion und ggf. Makulierung, gekennzeichnet werden. | 3 | 100/50/0 | 300 | |||
| 341.0 | Datenimport und -export Erwerbungsdaten | Der automatisierte Import von Zeitschriftenheften auf Basis des SISAC und/oder UPC Standards kann unterstützt werden. | 3 | 100/50/0 | 300 | |||
| 342.0 | Datenimport und -export Erwerbungsdaten | Die mit einem Lieferantendatensatz verknüpften Bestellungen und Rechnungen sollten adhoc aufgelistet und als Datei exportiert werden können. | 5 | 100/50/0 | 500 | |||
| 343.0 | Datenimport und -export Erwerbungsdaten | ERM - Verwaltung elektronischer Ressourcen: Das System kann standardisierte Schnittstellen zum Import und Export von Lizenzen und Entitlements (Einzellizenzen und Paketlizenzen) in geeigneten Standardaustauschformaten, automatisiert/per Batch oder manuell enthalten. Benennen Sie die verfügbaren Schnittstellen. | 3 | 100/50/0 | 300 | |||
| 344.0 | Verbundkatalogisierung | Das System sollte Metadatensätze (Titel-, Bestands-, Normdaten) aus einer externen Datendatenbank (z. B. Verbundkatalog K10plus, Normdatenbank) in Echtzeit in das System herunterladen (Neuzugang, Änderung, Löschung). | 5 | 100/50/0 | 500 | |||
| 345.0 | Verbundkatalogisierung | Das System kann Schnittstellen zum Upload von Metadatensätzen (Titel-, Bestands-, Normdaten) aus dem System in Echtzeit in eine externe Datenquelle (z. B. Verbundkatalog K10plus, Normdatenbank) bereitstellen (Neuzugang, Änderung, Löschung). | 3 | 100/50/0 | 300 | |||
| 346.0 | Verbundkatalogisierung, Fernleihe | Das System kann Fernleihen per SLNP-Schnittstelle (Simple Library Network Protocol) durchführen. | 3 | 100/50/0 | 300 | |||
| 347.0 | Linked Data | Das System sollte Digitalisate abbilden und für Linked Data Portale bereitstellen / anbinden. | 5 | 100/50/0 | 500 | |||
| 348.0 | Linked Data | Das System kann Schnittstellen zum Export in RDF und JSON-LD zur Verfügung stellen | 3 | 100/50/0 | 300 | |||
| 349.0 | Metadaten | Etablierte, standardisierte bibliothekarische Metadatenformate für Dateneingabe, Datenimport, Datenexport und Recherche müssen vollständig unterstützt werden, mindestens jedoch das Metadatenformat MARC21. | k.o. | |||||
| 350.0 | Metadaten | Das System muss über eine standardisierte Schnittstelle (mindestens Z39.50, besser SRU) zur Abfrage von Titel-, Bestands- und Exemplardaten durch externe bibliographische Informationssysteme verfügen. | k.o. | |||||
| 351.0 | Metadaten | Das System sollte SRU/SRW für den Metadatenaustausch unterstützen. | 5 | 100/50/0 | 500 | |||
| 352.0 | Metadaten | Das System sollte OAI-PMH für den Metadatenaustausch unterstützen. | 5 | 100/50/0 | 500 | |||
| 353.0 | Dateneingabe | Eine Dateneingabe nach dem aktuellen Stand der Technik muss unterstützt werden, mindestens mittels RFID- und Barcode-Scannern. Die eingelesenen Daten müssen v. a. im Bereich der Ausleihe und Erwerbung weiterverarbeitet werden können. Die Dateneingabe muss auch manuell erfolgen können. | k.o. | |||||
| 354.0 | Dateneingabe | Für das Erstellen, Bearbeiten und Löschen von bibliografischen Metadaten (Titel-, Lokal- und Exemplardaten) soll ein konfigurierbarer Metadateneditor in einem geeigneten Erfassungsformat zur Verfügung stehen. Das Eingabeformat ist vollständig mit MARC21 kompatibel und erweiterbar hinsichtlich neuer Anforderungen. | 3 | 100/50/0 | 300 | |||
| 355.0 | Dateneingabe | Das RDA-Toolkit sollte in den Metadateneditor eingebunden werden können. Weitere Richtlinien oder Dokumentationen können bei Bedarf integriert werden. | 3 | 100/50/0 | 300 | |||
| 356.0 | Netzplan_Userzulassung über LDAP | Das System kann eine Userzulassung über Lightweight Directory Access Protocol (LDAP) unter Verwendung der Mitarbeiter-Daten aus der Active Directory (AD) zulassen. | 3 | 100/50/0 | 300 | |||
| 357.0 | Netzplan_Anmeldung am System | Die Anmeldung am System kann per AD-Synchronisierung und per Single Sign On erfolgen. | 3 | 100/50/0 | 300 | |||
| 358.0 | Netzplan_Identitätsverwaltung der User | Es soll die zentrale Identitätsverwaltung aller User durch den Anbieter gewährleistet werden. | 5 | 100/50/0 | 500 | |||
| 359.0 | Netzplan_Nutzung im Home-Office | Das System muss aus dem Home-Office aufgerufen und bedient werden können. | k.o. | |||||
| 360.0 | 9 Kassenverwaltung und Berichte | |||||||
| 361.0 | Kassenverwaltung | Das Bibliotheksmanagementsystem kann auch als Kassensystem eingesetzt werden. Gemäß § 87 Absatz 2 Sächsischer Gemeindeordnung i. V. m. § 6 SächsKomKBVO dürfen für die automatisierte Ausführung der Kassengeschäfte und anderer Geschäfte im Bereich des Finanzwesens sächsischer Kommunalverwaltungen nur Programme verwendet werden, die von der Sächsischen Anstalt für kommunale Datenverarbeitung (SAKD) zugelassen sind. Der Anbieter kann die Zertifizierung übernehmen. Soweit das Verfahren nicht dem aktuellen Prüfbereich der SAKD unterliegt, kann der Anbieter die Umsetzung der Anforderungen des § 6 Absatz 1 Nr. 2–10 SächsKomKBVO dokumentieren. | 3 | 100/50/0 | 300 | |||
| 362.0 | Kassenverwaltung | Für Kassen und Gebühren soll ein differenziertes Berechtigungskonzept vorhanden sein, welches für die Mitarbeitenden eine Trennung der Berechtigung für Kasseneinnahmen, Storno, Erlass und Niederschlagung vorsieht. | 5 | 100/50/0 | 500 | |||
| 363.0 | Kassenverwaltung | Das System muss Onlinebezahlungen, Zahlungen an Kassenautomaten und an EC-Terminals unterstützen. Für die Datenübertragung stellt das System Schnittstellen bereit. | k.o. | |||||
| 364.0 | Kassenverwaltung | Für Zahlungen über Kassenautomaten und EC-Terminals sowie Zahlungen an den Personalarbeitsplätzen muss das System die automatische Generierung eines Beleges unterstützen. | k.o. | |||||
| 365.0 | Berichte | Für jede Zahlung müssen mindestens Datum, Uhrzeit, Benutzernummer, Zweigstelle, kassierende Person/Kennung, Betrag, Zahlart und Gebührenart gespeichert werden. Die Speicherdauer ist konfigurierbar. | k.o. | |||||
| 366.0 | Berichte | Kassenauswertungen müssen über einen frei wählbaren Zeitraum möglich und konfigurierbar sein, mindestens jedoch in den Kriterien Benutzernummer, Gebührenhöhe, kassierende Person/Kennung, Zweigstelle, Zahlart, Gebührenart. | k.o. | |||||
| 367.0 | Berichte | Pro Arbeitstag und pro Arbeitsplatz muss ein Kassenprotokoll für die Kassenprüfung erstellt werden können. | k.o. | |||||
| 368.0 | Berichte | Kassenrelevante Vorgänge sollen archiviert werden. Für die Dokumentation der Ein- und Ausgabenbuchung wird ein Kassenbuch geführt. Pro Arbeitstag und pro Arbeitsplatz kann ein Kassenprotokoll für die Kassenprüfung erstellt werden. | 5 | 100/50/0 | 500 | |||
| 369.0 | Berichte | Eine Auswertung aller innerhalb des Verfahrens erzeugten und nach Vorgabe der Stadt Leipzig konfigurierten Buchungszeichen mit den dazugehörigen Buchungsinformarionen soll für beliebige Zeiträume erzeugt werden können. | 5 | 100/50/0 | 500 | |||
| 370.0 | Berichte | Auswertungen über Einnahmen nach der Art der einzelnen Zahlvorgänge sollen innerhalb eines beliebigen Zeitraumes, gruppiert nach Monaten, Quartalen oder Jahren möglich sein. | 5 | 100/50/0 | 500 | |||
| 371.0 | Berichte | Über das Kassen-Soll sollen Auswertungen für einen frei wählbaren Zeitraum und anhand verschiedener Gebührenarten (Benutzungsgebühr (Jahr/Monat), Vormerkgebühr, Versäumnisgebühr etc.) möglich sein. | 5 | 100/50/0 | 500 | |||
| 372.0 | Kassenbuchfunktion | Die manuelle Annahme von Zahlungen in bar oder mittels Zahlungsverkehrsterminal soll in einem Kassenbuch dokumentiert werden. | 5 | 100/50/0 | 500 | |||
| 373.0 | Kassenbuchfunktion | Das Kassenbuch soll den täglich Kassenanfangs- und Kassenendbestand unter Berücksichtigung des Wechselgeldes ausweisen. | 5 | 100/50/0 | 500 | |||
| 374.0 | Kassenbuchfunktion | Das Kassenbuch sollte eine Kassensturzfunktion aufweisen. | 5 | 100/50/0 | 500 | |||
| 375.0 | Kassenbuchfunktion | In der Gebührenkasse sollen sich verschiedene Leistungen inklusive HKR-Eigenschaften anlegen lassen. | 5 | 100/50/0 | 500 | |||
| 376.0 | Kassenbuchfunktion | Bei der Hinterlegung von Parametern für die einzelnen Gebühren können sich auch frei nutzbare Parameter eingeben lassen, die es der Stadt Leipzig ermöglichen, die Kassenschnittstelle mit den Informationen zu bedienen, die für eine automatisierte Verbuchung im SAP erforderlich sind. | 3 | 100/50/0 | 300 | |||
| 377.0 | Kassenbuchfunktion | Sämtliche Gebühren sollen sich bei den einzelnen Leistungen detailliert voreinstellen, im Bearbeitungsprozess entsprechend der Anzahl der in einem Kundenkontakt durchgeführten Schritte zusammenstellen und in einem Vorgang zusammenfassen lassen. | 5 | 100/50/0 | 500 | |||
| 378.0 | Kassenbuchfunktion | Mehrere Leistungen sollen einer Person zugeordnet werden können (Warenkorbfunktion). | 5 | 100/50/0 | 500 | |||
| 379.0 | Kassenbuchfunktion | Es sollen alle gängigen Zahlarten möglich sein, mindestens die folgenden - Bar - Giro-/Debit-/Kreditkarte | 5 | 100/50/0 | 500 | |||
| 380.0 | Kassenbuchfunktion | Ein Vorgang soll mit der Zahlungsabwicklung im System enden. | 5 | 100/50/0 | 500 | |||
| 381.0 | Kassenbuchfunktion | Die Gebührenkasse soll alle Prozessschritte zur Verwaltung der Barkassen von der Ausgabe des Handvorschusses bis zum Kassenabschluss abbilden. | 5 | 100/50/0 | 500 | |||
| 382.0 | Kassenbuchfunktion | Jede Kasse (jede/r Nutzende hat eine) soll im Rahmen eines Tagesabschlusses einzeln abzuschließen sein. (Abgleich Kassen-Ist und Kassen-Soll) | 5 | 100/50/0 | 500 | |||
| 383.0 | Kassenbuchfunktion | Bei Eingabe des Kassen-Ist kann das Kassen-Soll ausgeblendet werden. | 3 | 100/50/0 | 300 | |||
| 384.0 | Kassenbuchfunktion | Der Tagesabschluss kann mindestens folgende Informationen enthalten: Name Amt/Zweigstelle, Abrechnungstag, Namen des Nutzers, Anzahl und Höhe der verbuchten und stornierten Vorgänge je Zahlart, Zahlungsverkehrsterminal-ID. | 3 | 100/50/0 | 300 | |||
| 385.0 | Kassenbuchfunktion | Der Tagesabschluss kann die Vorgänge summiert je Leistung darstellen. | 3 | 100/50/0 | 300 | |||
| 386.0 | Kassenbuchfunktion | Ein erfolgter Tagesabschluss soll über folgende Kritierien im System recherchierbar sein - Nutzer - Datum des Tagesabschlusses von bis - Zahlungsverkehrsterminal-ID - Bezeichnung der Zweigstelle | 5 | 100/50/0 | 500 | |||
| 387.0 | Kassenbuchfunktion | Mehrere Tagesabschlüsse je Standort sollten in einem Sammelabschluss zusammengefasst werden können. | 5 | 100/50/0 | 500 | |||
| 388.0 | Kassenbuchfunktion | Im Rahmen des Sammelabschlusses sollte die Safebag-Nummer als Pflichtfeld eingegeben werden können. | 5 | 100/50/0 | 500 | |||
| 389.0 | Kassenbuchfunktion | Der Sammelabschluss soll mindetsens folgende Informationen enthalten: Name Amt/Zweigstelle, Abrechnungszeitraum, Name Nutzer, Anzahl und Höhe der verbuchten und stornierten Vorgänge je Zahlart. Fehlbeträge sollen extra ausgewiesen sein. | 5 | 100/50/0 | 500 | |||
| 390.0 | Kassenbuchfunktion | Ein Nutzer sollte an einem Tag mehrere Tagesabschlüsse vornehmen können. | 5 | 100/50/0 | 500 | |||
| 391.0 | Kassenbuchfunktion | Kassiervorgänge je Nutzer ohne Tagesabschluss sollen ermittelbar sein. | 5 | 100/50/0 | 500 | |||
| 392.0 | Kassenbuchfunktion | Der Tagesabschluss eines Nutzers soll durch einen anderen Nutzer möglich sein. | 5 | 100/50/0 | 500 | |||
| 393.0 | Kassenbuchfunktion | Die Übergabe und Übernahme von Barkassenbeständen zwischen Nutzern soll digital quittierbar sein. | 5 | 100/50/0 | 500 | |||
| 394.0 | Kassenbuchfunktion | Ein erfolgter Sammelabschluss soll über folgende Kritierien ermittelbar sein - Nutzer - Datum des Sammelabschlusses von bis - Safebagnummer - Bezeichnung der Zweigstelle | 5 | 100/50/0 | 500 | |||
| 395.0 | Kassenbuchfunktion | Hardwareschnittstelle: Die Anbindung von Zahlungsverkehrsterminals (EC-Geräte) per Ethernet (TCP/IP), RS232, USB Slave/Host sollte unterstützt werden. | 5 | 100/50/0 | 500 | |||
| 396.0 | Kassenbuchfunktion | Der Zahlvorgangs soll automatisch an das Terminal übergeben werden, damit der Betrag nicht manuell eingegeben werden muss und ein automatisierter Kassenschnitt im Rahmen des Tagesabschluss erstellt werden kann | 5 | 100/50/0 | 500 | |||
| 397.0 | Kassenbuchfunktion | Die Berechtigungen für Tages- und Sammelabschlüsse sollen über das integrierte Rollen- und Berechtigungskonzept regelbar sein. | 5 | 100/50/0 | 500 | |||
| 398.0 | Kassenbuchfunktion | Es sollen jeweils Rollen für Mitarbeiter (Tagesabschluss), Kassenverantwortliche (Sammelabschluss der Tagesabschlüsse) und Kassen-Administratoren definierbar sein. | 5 | 100/50/0 | 500 | |||
| 399.0 | Kassenbuchfunktion | Den Rollen sollen spezifische Rechte zuordnenbar sein, mindestens die uneingeschränkte Nutzung der Suchfunktion nach Belegen oder die Bestätigung von Stornos. | 5 | 100/50/0 | 500 | |||
| 400.0 | Kassenbuchfunktion | Für jeden Geschäftsvorfall soll ein Beleg (Quittung) ausgestellt werden. Die Belege sollen die gesetzlich bestimmten Mindestangaben enthalten. | 5 | 100/50/0 | 500 | |||
| 401.0 | Kassenbuchfunktion | Der Quittungsdruck soll die jeweilige Buchung abschließen und erzeugt automatisch einen Beleg über die Einnahme. Alternativ soll mit Abschluss der Buchung automatisch eine Quittung für den Einzahler erzeugt werden. | 5 | 100/50/0 | 500 | |||
| 402.0 | Kassenbuchfunktion | Alle Belege und Abschlüsse sollen digital und revisionssicher gespeichert werden und sie sollen durchsuchbar und nachdruckbar sein. Alternativ muss eine revisionssichere Übergabe an enaio automaitisiert möglich sein. | 5 | 100/50/0 | 500 | |||
| 403.0 | Kassenbuchfunktion | Die Suche von Buchungen soll über die Suchfelder - Belegnummer, - Namen der Person - Bezeichnung der Zweigstelle - Buchungszeichen SAP möglich sein. | 5 | 100/50/0 | 500 | |||
| 404.0 | Kassenbuchfunktion | Der Ausdruck der Kundenbelege für EC-Zahlungen sollten direkt auf der Quittung möglich sein bzw. sollten die Informationen des EC-Belegs auf der Quittung abgebildet werden. Der separate Druck des EC-Belegs auf Thermopapier entfällt somit. | 5 | 100/50/0 | 500 | |||
| 405.0 | Kassenbuchfunktion | Die Händlerbelege für EC-Zahlungen sollten im Verfahren direkt digital gespeichert werden können und idealerweise mit den dazugehörigen Quittungen verknüpft werden, sodass Quittung und EC-Beleg als ein Vorgang auffindbar sind. | 5 | 100/50/0 | 500 | |||
| 406.0 | Kassenbuchfunktion | Der Kassenschnittbeleg des EC-Geräts sollte ebenfalls digital im System gespeichert werden können. Somit entfällt eine physische Ablage der EC-Belege. | 5 | 100/50/0 | 500 | |||
| 407.0 | Kassenbuchfunktion | Der Kassenschnittbeleg sollte in dem Tagesabschluss integriert sein. | 5 | 100/50/0 | 500 | |||
| 408.0 | Kassenbuchfunktion | Über den Kassenschnittbeleg soll auf die einzelnen Transaktionen/Vorgänge abgesprungen werden können. | 5 | 100/50/0 | 500 | |||
| 409.0 | Kassenbuchfunktion | Das System soll alle aufzeichnungspflichtigen Geschäftsvorfälle und anderen Vorgänge einzeln, vollständig, richtig, zeitgerecht und geordnet aufzeichnen. Das System soll über eine nach BSI (Bundesamt für Sicherheit in der Informationstechnik) geprüfte und zertifizierte Sicherheitseinrichtung (§ 146a Abs. 1 Sätze 2ff. AO) verfügen. | 5 | 100/50/0 | 500 | |||
| 410.0 | Kassenbuchfunktion | Die Schnittstellen sollen je Sammelabschluss übergeben werden. Die Durchführung des Sammelabschlusses bewirkt die Übergabe der Schnittstelle bzw. die Freigabe der Buchungen für die Schnittstelle. Jeder Sammelabschluss soll einzeln übergeben werden. | 5 | 100/50/0 | 500 | |||
| 411.0 | Kassenbuchfunktion | Null-Buchungen ( = Vorgang in Höhe von 0,00 Euro) sollen nicht in die Schnittstelle übergeben werden. | 5 | 100/50/0 | 500 | |||
| 412.0 | Kassenbuchfunktion | Für jede Zahlart soll das Zahlungsverteilungskonto (Feld 32 "SAKNR") der ZSTP individuell festgelegt werden können. | 5 | 100/50/0 | 500 | |||
| 413.0 | Kassenbuchfunktion | In das Feld 20 "ITEM_TEXT" soll die Safebag-Nummer des jeweiligen Sammelabschlusses oder die Terminal-ID des Zahlungsverkehrsterminals der ZSTP übernommen werden. | 5 | 100/50/0 | 500 | |||
| 414.0 | Kassenbuchfunktion | Das Datum des Sammelabschluss soll in Feld 19 "NET_DATE" der ZSTP übergeben werden. | 5 | 100/50/0 | 500 | |||
| 415.0 | Kassenbuchfunktion | Summierung Die einzelnen Geschäftsvorfälle sollen wie folgt in der ZSTP summiert werden 1. Zahlungsverteilungskonto (Feld 32 "SAKNR") 2. Vertragsgegenstandsnummer (Feld 11 "PSOBKEY") 3. Positionstext (Feld 20 "ITEM_TEXT") | 5 | 100/50/0 | 500 | |||
| 416.0 | Kassenbuchfunktion | Summierung Die einzelnen Geschäftsvorfälle sollen wie folgt in der IDAT summiert werden 1. Vertragsgegenstand (Feld 11 "PSOBKEY") 2. Sachkonto (Feld 32 "SAKNR") 3. Finanzposition (Feld 33 "POSID") 4. Kostenstelle (Feld 30 "KOSTL") 5. Auftragsnummer (Feld 31 "AUFNR") 6. Steuerkennzeichen (Feld 18 "TAX_CODE") | 5 | 100/50/0 | 500 | |||
| 417.0 | 10 Datenschutz und Sicherheit in der Informationstechnik kurz DSuSI | |||||||
| 418.0 | DSuSI_Allgemein | Das System muss in der Lage sein, die Einhaltung der Regelungen der Verordnung (EU) 2016/679 DSGVO, in der jeweils aktuellen Fassung, vollumfänglich zu gewährleisten. | k.o. | |||||
| 419.0 | DSuSI_Allgemein | Das System muss in der Lage sein, die Einhaltung der definierten "Standards und Anforderungen" des Bundesamts für Sicherheit in der Informationstechnik (BSI) (insbesondere der Mindeststandards nach § 4 Abs. 2 SächsISichG), in der jeweils aktuellen Fassung, vollumfänglich zu gewährleisten und dem Stand der Technik zu entsprechen. | k.o. | |||||
| 420.0 | DSuSI_Mandantenfähigkeit | Das System muss mandantenfähig sein. Insbesondere bedeutet dies die Trennung von Datenverarbeitungen anderer Stellen sowie der Datenverarbeitungen, die der Auftraggeber ggf. für eigene Zwecke durchführt, ist durch geeignete technische und organisatorische Maßnahmen gewährleistet. Den Datenbestand des Auftraggebers betreffende Transaktionen sind nicht von Daten anderer Kunden oder des Auftragnehmers abhängig. Andere Kunden des Auftragnehmers können weder lesend noch schreibend auf Daten des Auftraggebers zugreifen (und umgekehrt). Zugriffsrechte und Konfigurationseinstellungen können unabhängig von anderen Kunden oder auftragnehmereigenen Datenverarbeitungen umgesetzt werden. | k.o. | |||||
| 421.0 | DSuSI_Datenschutzzertifikat | Für das System soll ein anerkanntes Zertifikat für den Datenschutz (z.B. Datenschutzgütesiegel von ULD oder EuroPriSe) vorliegen. | 5 | 100/50/0 | 500 | |||
| 422.0 | DSuSI_Webanwendung-Zertifikat | Der Auftragnehmer muss für Bereitstellung und Betrieb des angebotenen Lösungssystems ein Informationssicherheitsmanagementsystem (ISMS) betreiben. Zielanforderung bis T3 ist eine gültige ISO-27001-Zertifizierung auf Basis von IT-Grundschutz (gem. BSI Standard 200-1, 200-2, 200-3, 200-4 + IT Grundschutz-Kompendium), deren Geltungsbereich sämtliche für Bereitstellung und Betrieb des angebotenen Lösungssystems relevanten Prozesse, Ressourcen und Leistungen (Hostingdienstleistung, Anwendung, Betrieb, Support, IAM, Logging, Incident Management, Schnittstellen, Softwareentwicklung) umfasst und den Schutzbedarf der im Rahmen des Auftrags verarbeiteten Informationen abdeckt. Die Zertifizierung ist während der gesamten Vertragslaufzeit (ohne zusätzliche Kosten für die Auftraggeberin) aufrechtzuerhalten und regelmäßig nachzuweisen. Zulässiger Übergangspfad Liegt die Zertifizierung gem. Zielanforderung für den vollständigen relevanten Scope für Bereitstellung und Betrieb zum Zeitpunkt der Angebotsabgabe (T1) noch nicht vor, kann der Nachweis der Zielanforderung über folgenden Übergangspfad erbracht werden: | k.o. | |||||
| 423.0 | DSuSI_Webanwendung-Zertifikat | T1 – Zeitpunkt der Angebotsabgabe durch den Bieter Der Bieter hat den vorgesehenen Gesamtscope sowohl für Bereitstellung als auch Betrieb des angebotenen Lösungssystems darzustellen und T1.i. ) kann entweder bereits eine bestehende ISO-27001-Zertifizierung auf Basis von BSI IT-Grundschutz für den vollständigen relevanten Scope nachweisen. | k.o. | |||||
| Oder T1.ii. ) sofern nur ein Teil, aber noch nicht der vollständige Scope für Bereitstellung oder Betrieb gemäß Zielanforderung zertifiziert ist, muss der Bieter einen prüfbaren Mindeststand, also einen Absicherungs- bzw. Zertifizierungsplan, für den vollständigen relevanten Scope vorlegen (insb. auch bereits initiierte Schritte nachzuweisen). Dieser Mindeststand muss v.a. umfassen: a) grundsätzlicher Nachweis eines bereits implementierten Informationssicherheitsmanagementsystems (idealerweise bereits entsprechend ISO/IEC 27001 aufgebaut); b) Scope festgelegt; c) Gap-Analyse gegenüber den Anforderungen der Zielanforderung durchgeführt; d) Maßnahmenplan zur Lückenschließung erstellt; e) Verantwortlichkeiten benannt; f) Vorgehensweise inkl. organisatorische und technische Maßnahmen, geplanten Zielnachweis und Meilensteine festgelegt, g) Ressourcen/Budget freigegeben. Die verbindlich benannte, geplante Vorgehensweise muss spätestens unverzüglichen ab Zuschlag umgesetzt werden. | ||||||||
| Hinweise zu T1: Bereits bestehende Zertifizierungen von vertragskonform eingebundenen Dienstleistern (Unterauftragnehmer) können für den jeweils tatsächlich abgedeckten Teil des Scopes bzw. in der Gap-Analyse berücksichtigt werden. Der Bieter hat die entsprechende Zertifizierung und deren Geltungsbereich nachzuweisen sowie die Abgrenzung zum verbleibenden Scope und seinen eigenen Leistungen darzustellen. Besonders belastbar zum Nachweis geeigneter ISMS-Strukturen sind beispielsweise durchgeführter bzw. verbindlich terminierte interne ISMS-Audits bzw. ein Auftrag, Vertrag, eine Auftragsbestätigung oder verbindliche Terminvereinbarung mit einer für ISO/IEC 27001 akkreditierten Zertifizierungsstelle. | ||||||||
| DSuSI_Webanwendung-Zertifikat | T2 – Beginn der Produktivsetzung Sofern ein Teil des vollständig relevanten Scopes zum Zeitpunkt T1 noch nicht vollständig zertifiziert war, muss für diesen Teil bis spätestens zur Produktivsetzung (Produktivsetzung: Verarbeitung produkiver Daten) der Nachweis des Testats einer Basisabsicherung nach BSI-IT-Grundschutz-Methodik erbracht werden. Verbleibende Abweichungen nach einem internen Audit bzw. vergleichbarer Prüfung sind zu dokumentieren. Ein verbindlicher Weg/Nachweis der eingeleiteten weiteren Vorgehensweise zur Erlangung der ISO-27001-Zertifizierung auf Basis von IT-Grundschutz (d.h. Erreichen der Zielanforderung) bis T3, muss dargelegt werden. | k.o. | ||||||
| DSuSI_Webanwendung-Zertifikat | T3 – Vorlage der Zertifizierung Für den vollständigen relevanten Scope ist der Nachweis einer vorliegenden, gültigen ISO-27001-Zertifizierung auf Basis von BSI IT-Grundschutz spätestens 12 Monate nach T2 endgültig zu erbringen. | k.o. | ||||||
| DSuSI_Webanwendung-Zertifikat | Die in T2 und T3 geforderten Nachweise stellen verbindliche vertragliche Meilensteine im Rahmen des Umsetzungsprojekts dar. Werden die jeweils geschuldeten Nachweise nicht fristgerecht erbracht, ist die Auftraggeberin jeweils berechtigt, für die Dauer des Verzugs eine EVB-IT-entsprechende Vertragsstrafe in Höhe von 0,2 % des Auftragswertes der jeweils betroffenen Leistung je Werktag des Verzugs, insgesamt jedoch höchstens 5% des Gesamtauftragswertes zu verlangen. Die rechtzeitige Erbringung des Nachweises nach T3 stellt eine wesentliche Vertragspflicht dar. Wird die gemäß T3 geschuldete ISO-27001-Zertifizierung auf Basis von BSI-IT-Grundschutz nicht spätestens 12 Monate nach Produktivsetzung nachgewiesen, ist die Auftraggeberin unbeschadet sonstiger vertraglicher und gesetzlicher Rechte insbesondere berechtigt, den Vertrag aus wichtigem Grund zu kündigen. Die Vertragsstrafe lässt die Verpflichtung des Auftragnehmers zur vollständigen Erfüllung der Anforderungen unberührt. Die Geltendmachung weitergehender gesetzlicher oder vertraglicher Rechte bleibt vorbehalten. | k.o. | ||||||
| Hinweis: Detailerkärungen sind im Angebot mit Verweis auf diese Anforderung vorzunehmen. Der Bieter hat insbesondere den Gesamtscope der für die Bereitstellung und den Betrieb eingesetzten Prozesse, Ressourcen und Leistungen sowie die Abgrenzung zu durch Dienstleister (Unterauftragnehmer) erbrachten und ggf. zertifizierten Leistungen darzustellen. Es darf keine Lücke zwischen dem Scope der Zertifizierung von Unterauftragnehmern, bspw. des Betreibers, und dem Scope ihrer Zertifizierung auftreten. | ||||||||
| 423.0 | DSuSI_Verschlüsselung allgemein | Das System muss in der Lage sein, die Einhaltung der Empfehlungen vom Bundesamts für Sicherheit in der Informationstechnik (BSI) hinsichtlich der verwendeten Verschlüsselungsalgorithmen und der Schlüssellängen (TR-02102), in der jeweils aktuellen Fassung, vollumfänglich zu gewährleisten. | k.o. | |||||
| 424.0 | DSuSI_Schutzbedarf | Das System einschließlich der zu erbringenden Leistungen, müssen den Sicherheitsstandards hinsichtlich der Vertraulichkeit, Datenintegrität, Authentizität bzgl. des festgelegten normalen Schutzbedarfs entsprechen. | k.o. | |||||
| 425.0 | DSuSI_Schutzbedarf normal - Verschlüsselung | Das System muss in der Lage sein, eine Transport- und Inhaltsverschlüsselung zu gewährleisten. | k.o. | |||||
| 426.0 | DSuSI_Autorisierungskomponente | Die zentrale Autorisierungskomponente verwaltet die Zugriffsrechte. Sicherheitskritische Parameter wie Passwort, Benutzer-Kennung systemintern müssen sicher verwaltet werden. Beispielsweise: Wenn Passwörter verwendet werden, müssen diese zugriffssicher (serverseitig) gespeichert werden, z.B. mittels Einweg-Verschlüsselung und zugriffssicher übertragen werden. | k.o. | |||||
| 427.0 | DSuSI_Autorisierungskomponente | Das System muss in der Lage sein, User gegenüber dem System geeignet zu authentifizieren. Beschreiben Sie das eingesetzte Verfahren | k.o. | |||||
| 428.0 | DSuSI_Autorisierungskomponente | Zugriffskontrollen müssen serverseitig umgesetzt sein. | k.o. | |||||
| 429.0 | DSuSI_Autorisierungskomponente | Bei Erstanmeldung eines Users soll ein Einmalpasswort vergeben werden können. | 5 | 100/50/0 | 500 | |||
| 430.0 | DSuSI_Autorisierungskomponente | Sichere Passwörter gemäß der Passwort-Richtlinie der Stadtverwaltung Leipzig sind bei einer Anmeldung mit Benutzername und Passwort zu erzwingen. | k.o. | |||||
| 431.0 | DSuSI_Autorisierungskomponente | Das System soll die Möglichkeit bieten, bei Eingabe des Passwort, dass Passwort nicht anzuzeigen. | 5 | 100/50/0 | 500 | |||
| 432.0 | DSuSI_Autorisierungskomponente | Jeder Benutzer muss sein eigenes Passwort jederzeit ändern können. | k.o. | |||||
| 433.0 | DSuSI_Autorisierungskomponente | Das System muss in der Lage sein, im Fehlerfall in einen sicheren Zustand zu fallen. | k.o. | |||||
| 434.0 | DSuSI_Autorisierungskomponente | Das System soll auch einen geeigneten Abmeldemechanismus zu Verfügung stellen. | 5 | 100/50/0 | 500 | |||
| 435.0 | DSuSI_Autorisierungskomponente | Unter der Bedingung der User hat einen erfolglosen Anmeldeversuch (Benutzername und Passwort), soll das System eine Fehlermeldung ohne nähere Einzelheiten generieren. | 5 | 100/50/0 | 500 | |||
| 436.0 | DSuSI_Autorisierungskomponente | Unter der Bedingung der User hat mehrere erfolglose Anmeldeversuche (Benutzernamen und Passwort) muss nach definierten Regeln reagiert werden (z.B. nach dreimaliger falscher Eingabe müssen die Zugangsdaten gesperrt werden und nach dem 4-Augenprinzip darf nur eine berechtigte Benutzergruppe die Zugangsdaten entsperren bzw. die Möglichkeit für neue Zugangsdaten eröffnen). | k.o. | |||||
| 437.0 | DSuSI_Autorisierungskomponente | Unter der Bedingung es werden systemkritische Funktionen benutzt (z.B. Ändern von Passwörtern, Löschen kompletter Datenbestände, Einsichtnahme von Protokolldaten), soll das System den User erneut authentifizieren (z.B. Haken oder erneute Authentisierung). | 5 | 100/50/0 | 500 | |||
| 438.0 | DSuSI_Autorisierungskomponente | Eine Mehrfaktorauthentisierung sollte implementiert sein (z. B. TOTP, Passkey) und kann optional eingesetzt werden | 5 | 100/50/0 | 500 | |||
| 439.0 | DSuSI_Rechtemanagement | Unter der Bedingung es sind Zugriffe auf Hintergrundsysteme (Datenbanken, Webservices etc.) erforderlich, soll das System die Möglichkeit bieten, dass der User angepasste Rechte (Minimalprinzip) erhält und ausschließlich über definierte Zugänge (Systeme) bzw. Schnittstellen Zugriff erlangt. | 5 | 100/50/0 | 500 | |||
| 440.0 | DSuSI_Rechtemanagement | Das System muss in der Lage sein, je nach Vorgabe durch den (Fach)Administrator sicherzustellen, dass User nur solche Aktionen durchführen können, für die sie über ausreichende Berechtigungen verfügen. | k.o. | |||||
| 441.0 | DSuSI_Automatisierter Abruf personenbezogener Daten | Beim automatisierter Abruf von personenbezogener Daten (Melderegister) muss das System die gesetzlichen Vorgaben zur Protokollierung umsetzen. Hinweis: Dies schließt die Nachprüfbarkeit der Rechtmäßigkeit von Abrufen und die eindeutige Zuordnung der abrufenden Nutzer ein. | k.o. | |||||
| 442.0 | DSuSI_Betroffenenrechte | Das System muss in der Lage sein, die Betroffenenrechte und Informationspflichten zu gewährleisten, insbesondere Auskunft, Einschränkung der Verarbeitung, Löschung. | k.o. | |||||
| 443.0 | DSuSI_Webanwendung - Schutz vor automatisierten Zugriffen | Das System muss Sicherheitsmechanismen implementieren, die die Webanwendung vor automatisierten Zugriffen schützt. Hinweis: Dabei wird berücksichtigt, wie sich diese auf die Nutzungsmöglichkeiten der berechtigten Konten auswirken. | k.o. | |||||
| 444.0 | DSuSI_Datenübertragung | Das System muss sicherstellen, dass alle vertrauliche Daten ausschließlich über transportverschlüsselte Verbindungen nach dem Stand der Technik (z. B. TLS 1.2 oder höher) übertragen werden. Vertrauliche Informationen, insbesondere Zugangsdaten und Tokens, dürfen nicht in URL-Parametern, Query-Strings oder anderen ungeschützten Metadaten übertragen werden. | k.o. | |||||
| 445.0 | DSuSI_Zweckbindung von Daten und Datensparsamkeit | Das System muss sicherstellen, dass Datenflüsse auf das für die Anwendungsnutzung erforderliche Maß beschränkt sind. Ergänzung: Es findet nur die Datenverarbeitung statt, die zur Erledigung der vom Auftraggeber vorgegebenen Nutzungszwecke erforderlich ist. | k.o. | |||||
| 446.0 | DSuSI_Datenübertragung | Eine Kommunikation mit Hintergrundsystemen muss verschlüsselt erfolgen. | k.o. | |||||
| 447.0 | DSuSI_Informationspflichten | Die Umsetzung eines Impressums muss unterstützt werden. | k.o. | |||||
| 448.0 | DSuSI_Eingabevalidierung und Ausgabekodierung | Das System muss gewährleisten, dass Ausgabedaten nach dem aktuellen Stand der Technik so kodiert werden, dass schadhafter Code auf dem Zielsystem nicht ausgeführt werden kann. | k.o. | |||||
| 449.0 | DSuSI_Datenbankanbindung | Das System soll beim Einsatz von Datenbanksystemen, Anfragen an Datenbanken über Views und Prozeduren ausführen. | 5 | 100/50/0 | 500 | |||
| 450.0 | DSuSI_Datenbankanbindung | Das System soll nach jeder SQL-Anweisung den Fehlerstatus bei der Ergebnisprüfung berücksichtigen. | 5 | 100/50/0 | 500 | |||
| 451.0 | DSuSI_Datenbankanbindung | Das System muss Verfahren zur Überwachung von Integritätsbedingungen zur Verfügung stellen, die semantische unsinnige Datenbankzustände verhindern. | k.o. | |||||
| 452.0 | DSuSI_Patchmanagement | Unter der Bedingung, dass für das System Installations-, Update- oder Patchdateien vorhanden sind, müssen diese mit Checksummen oder digitalen Signaturen bereitgestellt werden. | k.o. | |||||
| 453.0 | DSuSI_Upload-Funktion | Das System muss Upload-Funktionen zur Verfügung stellen, bei denen der Dateityp der am Server zu speichernden Datei dem erwarteten Dateityp entspricht. | k.o. | |||||
| 454.0 | DSuSI_Upload-Funktion | Das System muss beim Upload die Dateitypen eingeschränken können. | k.o. | |||||
| 455.0 | DSuSI_Upload-Funktion | Das System muss die maximalen Größen einer zu generierenden Datei einschränken können. | k.o. | |||||
| 456.0 | DSuSI_Upload-Funktion | Das System muss die Dateitypen und Dateigrößen überprüfen und im Negativfall eine Fehlermeldung ausgegeben. | k.o. | |||||
| 457.0 | DSuSI_Upload-Funktion | Das System muss automatisch gewährleisten, dass Dateizugriffe nur in vorgegebenen Pfaden und mit vorgegebenen Rechten möglich sind. | k.o. | |||||
| 458.0 | DSuSI_Upload-Funktion | Das System muss zu veröffentlichende Dateien vorher auf Schadprogramme prüfen. | k.o. | |||||
| 459.0 | DSuSI_Löschfunktion | Das System muss Löschfunktionen zur Verfügung stellen. | k.o. | |||||
| 460.0 | DSuSI_Löschfunktion | Personenbezogene Daten müssen nach Zweckerledigung unwiederbringlich gelöscht werden können, wenn keine Rechtsgrundlage vorhanden ist, die die weitere Verarbeitung erlaubt. | k.o. | |||||
| 461.0 | DSuSI_Löschfunktion | Die Speicherdauer von Informationen/Daten muss mit Berücksichtigung der Datenschutzbedingungen konfigurierbar sein. | k.o. | |||||
| 462.0 | DSuSI_Protokollfunktion | Das System muss fähig sein, die Protokollierungsvorgaben entsprechend BSI-Grundschutz (OPS 1.1.5, OPS.1.1.2.A11 ) umzusetzen. | k.o. | |||||
| 463.0 | DSuSI_Protokollfunktion | Konfigurationsänderungen müssen protokolliert werden. Der letzte Bearbeiter eines Datensatzes wird angezeigt. Dies erfolgt datenschutzkonform. Vorherige Versionen eines Datensatzes lassen sich durch einen Fachadministrator wiederherstellen. | k.o. | |||||
| 464.0 | DSuSI_Protokollfunktion | Das System muss in der Lage sein, dass Protokolldaten nur von berechtigten Usern einsehbar sind und ausgewertet werden können. | k.o. | |||||
| 465.0 | DSuSI_Protokollfunktion | Das System soll in der Lage sein, Protokolldaten zum protokolliertem Ereignis nach Vorgaben zu filtern und unnötige Protokolldaten bei der Auswertung auszusortieren. | 5 | 100/50/0 | 500 | |||
| 466.0 | DSuSI_Protokollfunktion | Das System muss in der Lage sein, vorhandene Protokolldaten je nach Zweckerfüllung zu generieren u.a.: * fehlerhafte als auch erfolgreiche sicherheitsrelevante Ereignisse * bei Authentisierung: Benutzer-Kennung, Datum, Uhrzeit, Erfolg, * bei der Zugriffskontrolle: Benutzer-Kennung, Datum und Uhrzeit, Erfolg, Art des Zugriffs, was wurde wie geändert, gelesen, geschrieben, * Durchführung von Administratortätigkeiten (Einrichten von Benutzern, Erstellung von Rechteprofilen, Anpassen von Parametern), * Auftreten von funktionalen Fehlern. | k.o. | |||||
| 467.0 | DSuSI_Protokollfunktion | Das System soll administrative Tätigkeiten (Einrichten/Ändern von Benutzern und Berechtigungen, Anpassung von Sicherheitsparametern etc.) serverseitig protokollieren. | 5 | 100/50/0 | 500 | |||
| 468.0 | DSuSI_Protokollfunktion | Das System muss verhindern, dass Unberechtigte Protokollierung deaktivieren können und die Protokolldaten einsehen oder modifizieren können. | k.o. | |||||
| 469.0 | DSuSI_Protokollfunktion | Das System muss in der Lage sein, für Protokolldaten Löschfristen abzubilden und umzusetzen. | k.o. | |||||
| 470.0 | DSuSI_Webanwendung als Software as a Service | Für den "normalen" Schutzbedarf der Daten, müssen die Regelungen (Mindestanforderungen) der EVB-IT Cloud AGB umgesetzt werden. | k.o. | |||||
| 471.0 | DSuSI_Webanwendung - Sitzungsidentifikatoren | Das System muss in der Lage sein, Sitzungsidentifikatoren (wie Session-IDs) nutzerbezogen zu generieren und auf einem vertraulichen Kanal zu übertragen. | k.o. | |||||
| 472.0 | DSuSI_Webanwendung -Sitzungsidentifikatoren | Werden Sitzungsidentifikatoren (wie Session-IDs) nutzerbezogen generiert, müssen diese bei Abmeldung oder bei definierter Inaktivität des Nutzers ungültig werden und bei erneuter Anmeldung neu vergeben werden. | k.o. | |||||
| 473.0 | DSuSI_Webanwendung - Externe Bibliotheken | Wird im Rahmen des Entwicklungs- und Implementierungsprozesses der Anwendung auf externe Bibliotheken zurückgegriffen, müssen diese aus vertrauenswürdigen Quellen bezogen und deren Integrität sichergestellt werden. | k.o. | |||||
| 474.0 | DSuSI_Webanwendung - Weiterleitungsfunktionen | Werden Weiterleitungsfunktionen (Webanwendung) verwendet, müssen diese ausreichend eingeschränkt sein, sodass ausschließlich auf vertrauenswürdige Webseiten weitergeleitet wird. Falls die Vertrauensdomäne verlassen wird, muss die Webanwendung darüber informieren. | k.o. | |||||
| 475.0 | DSuSI_Webanwendung | Die Webanwendung muss durch Direktiven gewährleisten, dass clientseitig keine schützenswerten Daten zwischengespeichert werden. | k.o. | |||||
| 476.0 | DSuSI_Webanwendung | Die Anwendung soll verhindern, dass vertrauliche Daten vom Webbrowser unerwartet gespeichert werden. | 5 | 100/50/0 | 500 | |||
| 477.0 | DSuSI_Webanwendung | Die Dateien mit den Quelltexten der Anwendung müssen vor unerlaubten Abrufen geschützt werden. | k.o. | |||||
| 478.0 | DSuSI_Webanwendung | Es muss sichergestellt werden, dass Webseiten, Rückantworten und Fehlermeldungen der Anwendungen keine Informationen enthalten, die Angreifenden Hinweise geben, wie Sicherheitsmechanismen umgangen werden können. | k.o. | |||||
| 479.0 | DSuSI_Webanwendung | Zum Schutz vor Clickjacking, Cross-Site-Scripting und anderen Angriffen müssen geeignete HTTP-Response-Header gesetzt werden. Es müssen mindestens die folgenden HTTP-Header verwendet werden: Content-Security-Policy, Strict-Transport-Security, Content-Type, X-Content-Type-Options sowie Cache-Control. Die verwendeten HTTP-Header sind auf die Webanwendung abgestimmt und so restriktiv wie möglich. | k.o. | |||||
| 480.0 | DSuSI_Webanwendung | Es soll das http Only-Flag für alle Cookies verwendet werden, auf die nicht mittels Javascript zugegriffen werden soll und es werden Secure-Flag von allen Cookies verwendet, die vertrauliche Informationen enthalten. Zudem soll das Attribut SameSite für Cookies gesetzt werden. | 5 | 100/50/0 | 500 | |||
| 481.0 | DSuSI_Webanwendung | Zum Schutz vor Denial-of-Service (DoS)-Angriffen sollen ressourcenintensive Operationen vermieden werden. Falls ressourcenintensive Operationen notwendig sind, dann sind diese besonders abgesichert. Zudem soll ein möglicher Überlauf von Protokollierungsdaten überwacht und verhindert werden. | 5 | 100/50/0 | 500 | |||
| 482.0 | DSuSI_Webanwendung - Schwachstellenmanagement | Die Webanwendungen und Webservices sollen regelmäßig auf Sicherheitsprobleme hin überprüft werden. Insbesondere werden regelmäßig Revisionen durchgeführt. Die Ergebnisse werden nachvollziehbar dokumentiert, ausreichend geschützt und vertraulich behandelt. Abweichungen wird nachgegangen. | 5 | 100/50/0 | 500 | |||
| 483.0 | DSuSI_Webanwendung - Datenverarbeitung | Die Datenverarbeitung darf ausschließlich in der EU / im EWR oder einem Land, für das ein Angemessenheitsbeschluss gem. Art. 45 DSGVO vorliegt erfolgen, auch im Hinblick auf das Recht eines Bestimmungsdrittlands, soweit der Auftragsverarbeiter oder ein von diesem eingesetzter Unterauftragnehmer diesem Recht unterliegt. | k.o. | |||||
| 484.0 | DSuSI_generische KI-Modelle | Unter der Bedingung das System nutzt generische KI-Modelle, muss die Umsetzung des generischen KI-Modells maximal in der Risikoklasse 2 nach EU KI-VO eingestuft sein. Je nach Risikoklasse sind die entsprechenden Pflichten umzusetzen. | k.o. | |||||
| 485.0 | 11 Rollen- u. Rechtemanagement kurz RoReM | |||||||
| 486.0 | RoReM_Userzulassung über LDAP | Das System kann die Fachanwender gegen Active Directory (Microsoft) authentifizieren. | 3 | 100/50/0 | 300 | |||
| 487.0 | RoReM_gleichzeitiger Zugriff mit Schreib- und Leserecht | Das System kann fähig sein gleichzeitig einen Schreib- und einen Lesezugriff (Rechte) auf eine/n Akte/Vorgang/Fall zu gewähren. | 3 | 100/50/0 | 300 | |||
| 488.0 | RoReM_Rollen- und Berechtigungen | Unter der Bedingung, dass im System einem User eine oder mehrere Rollen zugewiesen sind, soll der User über alle Rechte verfügen, die in der/den Rolle/n gebündelt sind. | 5 | 100/50/0 | 500 | |||
| 489.0 | RoReM_Signatur | Das System soll auf Basis der Authentifizierungsdaten des Users eine individuelle Signatur des Users erzeugen können. | 5 | 100/50/0 | 500 | |||
| 490.0 | RoReM_Dateneingabe | Vorbelegungen in Eingabeformularen können in Abhängigkeit der Rolle eines Mitarbeitenden definiert werden. | 3 | 100/50/0 | 300 | |||
| 491.0 | RoReM_Übertragung Lese- und Bearbeitungsrechte | Lese- und Bearbeitungsrechte für Vorgänge sollen auf andere User ggf. statusbezogen übertragbar sein._x000D_ Abgeschlossene Vorgänge sollen ohne Änderung im System erhalten bleiben, wenn die Rechte auf offene Vorgänge eines (deaktivierten) User auf andere (aktive) User übertragen werden. | 5 | 100/50/0 | 500 | |||
| 492.0 | RoReM_User-Account-Mehrfachzuordnung von Rollen | Unter der Bedingung das System stellt einem User einen User-Account zur Verfügung, sollte das System eine Mehrfachzuordnung von Rollen erlauben. | 5 | 100/50/0 | 500 | |||
| 493.0 | RoReM_Administration und Pflege von Parametern und Stammdaten | Das System soll die Möglichkeit der Administration und Pflege von Parametern und Stammdaten, Recherchen, Berichten, etc. bieten_x000D_. | 5 | 100/50/0 | 500 | |||
| 494.0 | RoReM_Mandantenfähigkeit | Alle Mandanten sollen über die Möglichkeiten für voneinander getrennte Datenhaltungen (Bestands-, Benutzer, Ausleih-, Erwerbungsdaten) sowie individuelle Konfigurationen (Ausleihe, Haushalt) verfügen. Einzelne Datenbereiche können von den Mandanten bei Bedarf auch gemeinsam genutzt und zentral konfiguriert werden (Titel, Benutzer). | 5 | 100/50/0 | 500 | |||
| 495.0 | RoReM_Mandantenfähigkeit | Rollen und Rechte sollen sowohl mandantenspezifisch als auch mandantenübergreifend konfiguriert werden. Damit ist z. B. die ausschließliche Sicht auf Daten der eigenen Institution gewährleistet, der Zugriff auf Daten fremder (ggf. übergeordneter) Institutionen kann unterbunden oder erlaubt werden. | 5 | 100/50/0 | 500 | |||
| 496.0 | RoReM_Rollentrennung | Das System muss in der Lage sein Administrations- und Nutzerbetrieb zu trennen. | k.o. | |||||
| 497.0 | RoReM_Vertretungsfunktion | Das System muss in der Lage sein Administrations- und Nutzerbetrieb im Zusammenhang mit den Vertreterrechten abzubilden. | k.o. | |||||
| 498.0 | RoReM_Vertretungsfunktion | Das System muss sicherstellen, dass die Vertretung nur von berechtigten Usern festgelegt und überprüft werden darf. | k.o. | |||||
| 499.0 | RoReM_Rollen- und Berechtigungen | Das System muss in der Lage sein, Rollen zu erstellen und Gruppenrechte zu vergeben. | k.o. | |||||
| 500.0 | RoReM_Rollen- und Berechtigungen | Die Autorisierungskomponente muss gewährleisten, dass User nur Aktionen durchführen können, zu denen sie berechtigt sind. Hinweis: Dabei werden alle von der Autorisierungskomponente verwalteten Ressourcen berücksichtigt und Berechtigung vor Ausführung der Aktion geprüft. | k.o. | |||||
| 501.0 | RoReM_User-Account | Das System muss die Möglichkeit zur Verfügung stellen, dass ein User mehrere User-Accounts haben kann. | k.o. | |||||
| 502.0 | RoReM_ausschließliches Schreibrecht | Unter der Bedingung, dass ein User mit Schreibrecht eine/n Akte/Vorgang/Fall aufgerufen hat, muss das System fähig sein diese/n Akte/Vorgang/Fall für einen zweiten User mit Schreibrecht zu sperren. | k.o. | |||||
| 503.0 | 12 Lizenzmanagement kurz LiM | |||||||
| 504.0 | Lizenzmodell | Das System muss fähig sein mindestens 150 Fachanwendern gleichzeitig Zugriff via Schreibrecht (Concurrent-User) zu gewähren. | k.o. | |||||
| 505.0 | Lizenzmodell | Das System muss fähig sein, unbegrenzten gleichzeitigen Zugriff für Endanwender (Katalog, Benutzerkonto) via Schreibrecht (Concurrent-User) zu gewähren. | k.o. | |||||
| 506.0 | Lizenzen Administration | Dem Bereich sollen mindestens 10 Lizenzen zur Fachadministration (Benutzerverwaltung etc.) zur Verfügung gestellt werden. | 5 | 100/50/0 | 500 | |||
| 507.0 | Lizenzmodell-erweiterbar | Sollten sich die Rahmenbedingungen ändern, muss das System hinsichtlich der Lizenzen (Concurrent-User) anpassbar sein. | k.o. | |||||
| 508.0 | Lizenzen und Zertifikate | Die Software muss inklusive aller notwendigen Lizenzen und Zertifikate bereitgestellt werden. | k.o. | |||||
| 509.0 | Lizenzen und Zertifikate | Der Anbieter muss für die Aktualisierung und Gültigkeit aller für den Betrieb des Bibliotheksmanagementsystems erforderlichen Lizenzen und Zertifikate verantwortlich sein. | k.o. | |||||
| 510.0 | Lizenzen und Zertifikate | Für alle verwendeten fremden Programmbibliotheken müssen die für die Nutzung erforderlichen Lizenzen und Zertifikate vorliegen. Dies muss organisatorisch abgesichert sein, auch bei Updates und Upgrades der Programmbibliotheken. | k.o. | |||||
| 511.0 | Lizenzen und Zertifikate | Der Anbieter sollte Drittanbietern die für den Betrieb angebundener Software und Endgeräte erforderlichen Lizenzen und Zertifikate bereitstellen und ggf. erforderliche Lizenzen und Zertifikate von Drittanbietern in die eigenen Systeme einbinden. | 5 | 100/50/0 | 500 | |||
| 512.0 | 13 Migration, Hosting und Systemkonfiguration | |||||||
| 513.0 | Cloud-Betrieb, Saas | Die Software muss als Cloud-System und Software-as-a-Service (SaaS) implementiert werden. | k.o. | |||||
| 514.0 | Cloud-Betrieb, Saas | Im Rahmen des Cloud-Betriebs muss ein Vertrag zu Auftragsdatenverarbeitung, Datenschutzrichtlinien und Service Level Agreements (SLA) mit dem Anbieter abgeschlossen werden, der auch alle Subunternehmer einschließt. Die gesetzlichen Anforderungen für eine Auftragsdatenverarbeitung gemäß Art. 28 DSGVO müssen eingehalten werden. | k.o. | |||||
| 515.0 | Cloud-Betrieb, Saas | Die Eigentumsverhältnisse der Unternehmen / Anbieter, die die Cloud betreiben, bzw. SaaS anbieten, müssen dokumentiert werden. Es gibt es eine stets aktuelle Dokumentation von Serverstandorten und Lagerorten von Backups. | k.o. | |||||
| 516.0 | Cloud-Betrieb, Saas | Ein vollständiger Datenexport der gesamten Datenbank in nachnutzbaren Standardaustauschformaten muss technisch möglich sein, so dass die Daten in ein Fremdsystem importierbar sind. Dies wird vertraglich garantiert (insbesondere bei Vertragsbeendigung) und funktional abgebildet, sodass die Bibliothek auch selbstständig einen Datenexport durchführen kann. | k.o. | |||||
| 517.0 | Dokumentation | Der Anbieter / die Entwicklergemeinschaft muss Zugriff auf eine vollständige Softwaredokumentation sowie weitere Produktionformationen in deutscher Sprache gewährleisten. | k.o. | |||||
| 518.0 | Dokumentation | Für die Systemkonfiguration und Administration müssen ausführliche Anleitungen vorliegen, die mit jedem Release mitgeführt und aktualisiert werden. | k.o. | |||||
| 519.0 | Systemkonfiguration | Das System muss grundsätzlich konfigurierbar sein. Die Konfiguration zeigt sofortige Wirkung. Das System wird mit einem Set von Voreinstellungen ausgeliefert. | k.o. | |||||
| 520.0 | Systemkonfiguration | Jede Zweigstelle / jeder Standort muss separat konfiguriert werden können, diese Einstellungen müssen nicht global einheitlich sein. | k.o. | |||||
| 521.0 | Systemkonfiguration | Die Systemkonfiguration muss über eine Browser-basierte graphische Benutzeroberfläche erfolgen. Die Benutzeroberfläche für die Konfiguration ist intuitiv und leicht zu bedienen. | k.o. | |||||
| 522.0 | Systemkonfiguration | Die Dateneingabe für die Konfiguration muss Validierungsroutinen durchlaufen, mindestens jedoch Prüfung auf Pflichtfelder und Vermeidung der Löschung betriebsnotwendiger Daten. | k.o. | |||||
| 523.0 | Systemkonfiguration | Der Import und Export von Konfigurationsdaten soll möglich sein. Beim Import können definierte Felder vor dem Überschreiben geschützt werden. | 5 | 100/50/0 | 500 | |||
| 524.0 | Systemkonfiguration | Der Client-Rechner soll über den Browser auf das System zugreifen. Sofern zusätzliche Software auf dem Client installiert werden muss (z.B. Browser-Plugins), ist diese mit den für das Betriebssystem (bzw. Browser) üblichen Verfahren kryptographisch abgesichert. Der Client müss unter allen in Deutschland gängigen Internet-Browsern (Chrom, Firefox, Edge) in den derzeit gängigen Versionen. | 5 | 100/50/0 | 500 | |||
| 525.0 | Systemkonfiguration | Das System soll so skalierbar sein, dass die Performance bei wachsender Last (z.B. weitere Mandanten) aufrechterhalten werden kann. Insbesondere ist die Datenbank skalierbar. | 5 | 100/50/0 | 500 | |||
| 526.0 | Zugänglichkeit des Quellcodes | Der Quellcode soll hinterlegt und bei Insolvenz und eingestellter oder unzureichender Weiterentwicklung nutzbar sein. | 5 | 100/50/0 | 500 | |||
| 527.0 | Zugänglichkeit des Quellcodes | Das System soll Open Source sein. | 5 | 100/50/0 | 500 | |||
| 528.0 | Systemmonitoring | Alle Prozesse den Softwarebetrieb, die Softwareanwendung und die Schnittstellen betreffend müssen in Protokolldateien protokolliert und bei Bedarf ausgewertet werden können. | k.o. | |||||
| 529.0 | Systemmonitoring | Alle Prozesse den Serverbetrieb, die Serverleistung und die Serververbindung betreffend müssen protokolliert und bei Bedarf ausgewertet werden. | k.o. | |||||
| 530.0 | Systemmonitoring | Datenbankänderungen müssen protokolliert und bei Bedarf ausgewertet werden. | k.o. | |||||
| 531.0 | Systemmonitoring | Für Protokolldaten müssen Löschfristen festleg- und umsetzbar sein. | k.o. | |||||
| 532.0 | Systemmonitoring | Der Mindestumfang, den das Produkt protokollieren kann, ist parametrisierbar. | k.o. | |||||
| 533.0 | Systemmonitoring | Es können sowohl fehlerhafte als auch erfolgreiche sicherheitsrelevante Ereignisse protokolliert werden (Kann optional entwickelt werden): • bei Authentisierung: Benutzerkennung, Datum, Uhrzeit, Erfolg • bei der Zugriffskontrolle: Benutzerkennung, Datum und Uhrzeit, Erfolg, Art des Zugriffs, was wurde wie geändert, gelesen, geschrieben, • Durchführung von Administratortätigkeiten (Einrichten von Benutzern, Erstellung von Rechteprofilen, Anpassen von Parametern) • Auftreten von funktionalen Fehlern | 3 | 100/50/0 | 300 | |||
| 534.0 | Systemmonitoring | Administrative Tätigkeiten (Einrichten von Benutzern, Erstellung von Rechteprofilen, Anpassen von Parametern) müssen serverseitig protokolliert werden. | k.o. | |||||
| 535.0 | Systemmonitoring | Die Protokollierung darf von Unberechtigten nicht deaktivierbar sein. Die Protokolle selbst dürfen für Unberechtigte weder lesbar noch modifizierbar sein. Der Zugriff muss auf autorisierte Personen beschränkt sein. | k.o. | |||||
| 536.0 | Verfügbarkeit | Der Anbieter muss eine unterbrechungsfreie Nutzung der Software garantieren. Jobs, die während Netzwerkausfallzeiten oder Verbindungsverlust zum Server hätten laufen sollen, müssen zu einem späteren Zeitpunkt wieder aufgenommen werden, ggf. automatisch. | k.o. | |||||
| 537.0 | Verfügbarkeit | Die technischen Anforderungen „Zuverlässigkeit“, „Verfügbarkeit“ und „Sicherheit“ müssen vom Anbieter entsprechend der Definition in der Leistungsbeschreibung ausgelegt werden. | k.o. | |||||
| 538.0 | Verfügbarkeit | Die Aktualisierung der Daten in Echtzeit muss in allen Bereichen gegeben sein. Das gilt auch für den internen Suchindex und die Schnittstellen. | k.o. | |||||
| 539.0 | Verfügbarkeit | Für Netzwerkausfälle und sonstige Verbindungsverluste zum Server soll eine Notverbuchung bzw. Offline-Verbuchung zur Verfügung stehen, die Ausleihen und Rückgaben verarbeiten kann. Nach Beendigung der Ausfallzeit sollen die offline erstellten Daten in der richtigen Reihenfolge und ohne Informationsverlust in das System zurückgespielt werden. | 5 | 100/50/0 | 500 | |||
| 540.0 | Anwendergruppe | Der Anbieter soll organisatorisch die Arbeit nationaler und internationaler Nutzergruppen (Meetings, Konferenzen) unterstützen und stellt ein Verfahren zur Umsetzung der daraus entstehenden Vorschläge bereit. | 5 | 100/50/0 | 500 | |||
| 541.0 | Anwendergruppe | Der Anbieter kann dem Kunden Kommunikationswerkzeuge für Fehlermeldungen und/oder das Melden von Erweiterungswünschen einzelner Funktionen/Features (z.B. Mailinglisten, Online-Foren, Wikis, Ticketsystem, Chaträume) sowie allgemeine Informationen und für die Kommunikation untereinander anbieten. | 3 | 100/50/0 | 300 | |||
| 542.0 | Migrationskonzept | Bei der Migration müssen alle relevanten Bestands-, Bewegungs-, Benutzer- und Erwerbungsdaten des Altsystems importiert werden. Der Anbieter stellt sicher, dass der Datenbankstand des Altsystems im neuen System abgebildet wird. | k.o. | |||||
| 543.0 | Migrationskonzept | Der Anbieter muss im Einführungsprojekt ein Installations- und Migrationskonzept vorlegen und führt alle Arbeiten und Abstimmungen durch. Der Anbieter muss nach Bevollmächtigung durch den Auftraggeber die Kommunikation mit dem Anbieter des Altsystems führen und alle erforderlichen Maßnahmen für eine erfolgreiche Migration durchführen. | k.o. | |||||
| 544.0 | Migrationskonzept | Der Anbieter muss regelmäßige Projekttreffen und Abstimmungen mit dem Auftraggeber und weiteren Projektbeteiligten organisieren. Die Abstimmungen werden nachvollziehbar und für die Projektbeteiligten einsehbar dokumentiert. | k.o. | |||||
| 545.0 | Migrationskonzept | Der Anbieter muss eine vollständige Dokumentation der Migrations- und Installationsarbeiten führen. Die Dokumentation kann in digitaler Form mit einer Dokumentations- oder Projektmanagementsoftware erfolgen. Der Auftraggeber hat jederzeit Zugriff auf die Dokumentation. | k.o. | |||||
| 546.0 | Schulungskonzept | Der Anbieter muss begleitend zur Einführung der neuen Bibliotheksmanagmentsoftware Schulungen für die Anwender und Administratoren des Bibliotheksmanagementsystems durchführen. Der Anbieter legt dafür im Einführungsprojekt ein Schulungskonzept vor. | k.o. | |||||
| 547.0 | Schulungskonzept | Der Anbieter muss sicherstellen, dass die Anwender auf allen Anwendungsebenen zum Going Live des Bibliotheksmanagementsystems sicher mit dem Bibliotheksmanagementsystem in den Kernbereichen Ausleihe, Erwerbung und Erschließung umgehen. | k.o. | |||||
| 548.0 | Schulungskonzept | Der Anbieter muss umfangreiches Schulungsmaterial zur Verfügung stellen und qualifiziert die Mitarbeitenden im Umgang mit den bereitgestellten Informations- und Hilfsangeboten (Hilfe zur Selbsthilfe). | k.o. | |||||
| 549.0 | Schulungskonzept | Nach dem Going Live soll der Anbieter für 6 Monate zusätzliche Ressourcen zur Unterstützung der Mitarbeitenden und Nachkonfiguration des Systems im laufenden Betrieb bereitstellen (feste Ansprechpartner, Priorisierung im Support). | 5 | 100/50/0 | 500 | |||
| 550.0 | Vor-Ort-Schulung - Administratoren | Eine Administratoren Vor-Ort-Schulung für 6 Mitarbeitende muss Bestandteil des Angebotes sein. | k.o. | |||||
| 551.0 | Vor-Ort-Schulung - User | Eine intensive Vor-Ort-Schulung für 30 Multiplikatoren muss Bestandteil des Angebotes sein. | k.o. | |||||
| 552.0 | Vor-Ort-Schulung - Nachschulung | Es sollte grundsätzlich die Möglichkeit der Vor-Ort-Nachschulung gegeben sein (nicht Bestandteil dieses Angebots). | 5 | 100/50/0 | 500 | |||
| 553.0 | Online-Schulung - User | Eine Fachanwender Online-Schulung für 140 Mitarbeitende in den Kernbereichen Ausleihe, Erwerbung und Erschließung muss Bestandteil des Angebotes sein. | k.o. | |||||
| 554.0 | Online-Schulung - Nachschulung | Es sollte grundsätzlich die Möglichkeit der Online-Nachschulung gegeben sein (nicht Bestandteil dieses Angebots). | 5 | 100/50/0 | 500 | |||
| 555.0 | Vor-Ort-Schulung_Testdatenbank | Die Schulung an der Software soll mit einer mitgelieferten Testdatenbank (ohne anwendereigenen Datenpool) möglich sein. | 5 | 100/50/0 | 500 | |||
| 556.0 | Tests | Es muss im Vorfeld der Produktivsetzung, Tests mit allen Systemen durchgeführt werden, welche über Schnittstellen mit dem System kommunizieren. | k.o. | |||||
| 557.0 | Einführungssupport | Es soll vor, während und nach der Produktivsetzung einen Ansprechpartner geben, der für Startprobleme zeitnah zur Verfügung steht. | 5 | 100/50/0 | 500 | |||
| 558.0 | Anleitungen_Handbücher_Konzepte | Es müssen folgende Dokumentationen mindestens in digitaler Form, verständlich und vorzugsweise in deutscher Sprache, zur Verfügung stehen (downloadbar/abspeicherbar) und relevanten Änderungen im System fortgeschrieben werden: * Rollen-/Rechtedokumentation (generell) * Netzplan (generell) * Servicebeschreibung (generell) * Patch- und Änderungsmanagementdokumentation (generell) * Löschkonzept (generell) * Schnittstellendokumentation (in Abhängigkeit der Gestaltung des Systems) * Datenim- und/oder Exportdokumentation (in Abhängigkeit der Gestaltung des Systems) Hinweis: Netzplan ist eine Dokumentation über die Komponenten des Systems und ihre Verbindungen (Schnittstellen, Weitergabe von Daten). | k.o. | |||||
| 559.0 | Anleitungen_Handbücher_Konzepte | Es soll folgende Dokumentation mindestens in digitaler Form, verständlich und vorzugsweise in deutscher Sprache, zur Verfügung stehen (downloadbar/abspeicherbar) und bei relevanten Änderungen im System fortgeschrieben werden: * Datenschutz- und Informationssicherheitskonzept Hinweis: Kann ein vollständiges Datenschutz- und Informationssicherheitskonzept nicht zur Verfügung gestellt werden, müssen jedoch mindestens die nachfolgend geforderten Dokumentationen zur Verfügung gestellt werden, da diese zur Erstellung eines Datenschutz- und Informationssicherheitskonzept erforderlich sind. | 5 | 100/50/0 | 500 | |||
| 560.0 | Sonderanpassungen | Sonderanpassungen (Abweichung vom Standard) des Kernsystems sollen möglich sein. Sonderprogrammierungen für Softwareerweiterungen oder Anforderungen für spezielle Module können auf Projektbasis geprüft und umgesetzt werden. | 5 | 100/50/0 | 500 | |||
| 561.0 | 14 Softwarepflege, -weiterentwicklung und Wartung | |||||||
| 562.0 | Aktualisierung der Software | Updates und Fehlerbehebungen (Hotfix) zur Versionspflege müssen in regelmäßigen Abständen ausgeliefert werden. Sicherheitsrelevante Updates werden unverzüglich ausgeliefert. | k.o. | |||||
| 563.0 | Aktualisierung der Software | Updates und Fehlerbehebungen sind Inklusivleistungen und müssen vom Anbieter durchgeführt werden. | k.o. | |||||
| 564.0 | Aktualisierung der Software | Bei der Versionspflege muss der Live-Betrieb weiter gewährleistet werden. Die Downtime des Bibliotheksmanagementsystems ist zu vermeiden. Wartungsfenster werden außerhalb der Geschäftszeiten eingerichtet. | k.o. | |||||
| 565.0 | Aktualisierung der Software | Der Zeitpunkt von notwendigen Wartungsarbeiten muss dem Auftraggeber rechtzeitig (mindestens 1 Woche im Voraus) angekündigt werden. | k.o. | |||||
| 566.0 | Aktualisierung der Software | Es muss durch den Auftragnehmer die Notwendigkeit von Updates/Patches zeitnah (innerhalb drei Monaten) angezeigt werden, wenn eine für die Anwendungsnutzung erforderliche Komponente eines anderen Herstellers lebenszyklusbedingt nicht mehr mit Sicherheitsupdates versorgt wird und die Nutzung einer entsprechend unterstützten Version Anpassungen am Produkt erfordert. Entsprechende Updates/Patches müssen rechtzeitig bereitgestellt werden. | k.o. | |||||
| 567.0 | Aktualisierung der Software | Sicherheitskritische Updates und Patches, von durch/für das IT-Verfahren verwendeten Softwarekomponenten anderer Anbieter müssen nach der Veröffentlichung durch den Auftragnehmer freigegeben werden. Die Freigabe ist innerhalb von zehn Arbeitstagen zu erteilen. | k.o. | |||||
| 568.0 | Aktualisierung der Software | Bei einer Umsetzung als Webanwendung/Webservice müssen die Komponenten regelmäßig auf Sicherheitsprobleme hin überprüft werden, insbesondere durch regelmäßige Revisionen, deren Ergebnisse nachvollziehbar dokumentiert, ausreichend geschützt und vertraulich behandelt werden. | k.o. | |||||
| 569.0 | Systemkritische Updates/Patches | Unter der Bedingung im System werden Programmfehler oder Schwachstellen erkannt (z.B. in einer Webanwendung), müssen zeitnah getestete Updates/Patches bereitgestellt werden (z.B. bei kritischen Schwachstellen in der Regel innerhalb von 1 Monat nach Bekanntwerden des Fehlers/der Schwachstelle). | k.o. | |||||
| 570.0 | Updates/Patches nach Ende des Lebenszykluses | Unter der Bedingung, dass das System vom Hersteller lebenszyklusbedingt nicht mehr mit Sicherheitsupdates versorgt wird und die Nutzung einer entsprechend unterstützten Version Anpassungen im System erfordert, ist durch den Auftragnehmer die Notwendigkeit von Updates/Patches innerhalb von drei Monaten anzuzeigen und zeitnah bereitzustellen. | k.o. | |||||
| 571.0 | Weiterentwicklung, Release-Cycle | Die Software muss auf Basis regelmäßiger Updates bzw. Releases weiterentwickelt werden. Damit wird die Bereitstellung neuer Funktionen und/oder Features, sowie die Behebung von Sicherheitslücken und/oder Fehlern garantiert. Es wird gewährleistet, dass die bereitgestellte Lösung für die Dauer der Leistungserbringung dem Stand der Technik entspricht. | k.o. | |||||
| 572.0 | Weiterentwicklung, Release-Cycle | Releases müssen in den Lizenzgebühren enthalten sein. Die Einspielung von Releases ist eine Inklusivleistung und wird vom Anbieter durchgeführt. | k.o. | |||||
| 573.0 | Weiterentwicklung, Release-Cycle | Bei Versionswechsel muss der Live-Betrieb gewährleistet werden. Die Downtime des Bibliotheksmanagementsystems ist zu vermeiden. Wartungsfenster werden außerhalb der Geschäftszeiten eingerichtet. | k.o. | |||||
| 574.0 | Weiterentwicklung, Release-Cycle | Releases sollen mit Vorlaufzeit und Informationen zu inhaltlichen (technischen/funktionalen) Änderungen angekündigt werden. | 5 | 100/50/0 | 500 | |||
| 575.0 | Weiterentwicklung und Pflege | Im Rahmen des Pflegevertrages muss eine ständige Pflege und Weiterentwicklung der Software bei gesetzlichen und technischen Änderungen erfolgen. | k.o. | |||||
| 576.0 | Support | Der Anbieter / die Entwicklergemeinschaft muss über eine zentrale Kontaktmöglichkeit per Mail und eine telefonische Hotline für Fehlermeldungen, Service- und Supportanfragen verfügen. | k.o. | |||||
| 577.0 | Support | Der Verlauf der Anfragen und Entwicklungsstände muss über ein Ticketsystem verwaltet und für den Kunden nachvollziehbar in einer Projektmanagement-Software online geführt werden. | k.o. | |||||
| 578.0 | Support | Deutschsprachige Ansprechpartner im Support müssen zur Verfügung stehen. | k.o. | |||||
| 579.0 | Support | Auf Serviceanfragen muss werktags innerhalb von maximal 24 Stunden reagiert werden. Betriebsverhindernde Vorfälle müssen sofort, spätestens jedoch werktags innerhalb von 12 Stunden bearbeitet werden. | k.o. | |||||
| 580.0 | Support | Der Anbieter kann eine Entwicklungsumgebung zur Verfügung stellen, in welcher Neuentwicklungen, Komponenten und Einstellungen getestet werden können. | 3 | 100/50/0 | 300 | |||
| 581.0 | Testsystem | Es muss ein Testsystem zur Verfügung gestellt werden. | k.o. | |||||
| 582.0 | Wartung_Verträge | Die als Anlage übergebene Vertragsentwürfe müssen akzeptiert werden. In die Entwürfe werden nach der Zuschlagserteilung noch die konkreten Angaben zum Angebot (Produktname, Preise, usw.) von der Auftraggeberin aufgenommen. | k.o. | |||||
| 583.0 | Wartung_Formulare | Im Rahmen des Pflegevertrages soll der Auftragnehmer die gebräuchlichen Formulare/Vorlagen (z.B. bei Gesetzesänderungen) immer auf dem aktuellen Stand halten. | 5 | 100/50/0 | 500 | |||
| 584.0 | Wartung_Rechtsgrundlagen | Im Rahmen des Pflegevertrages sollen Anpassungen der Inhalte nach relevanten Gesetzesänderungen im System durch den Auftragnehmer vorgenommen werden. Diese Anpassungen sollen kurzfristig nach Beschlussfassung oder spätestens mit einem Update im Laufe eines Vierteljahres erfolgen. | 5 | 100/50/0 | 500 | |||
| 585.0 | Wartung_Datenübertragung | Beim Auftreten von Programmfehlern müssen zwecks Fehlersuche und -behebung (insbesondere bei Fernwartung) keine vertraulichen Daten an den Auftragnehmer übermittelt werden. | k.o. | |||||
| k.o. = Ausschlusskriterien | 195 | 0 |
Konfiguration
| Unnamed: 0 |
|---|
| Angaben des Anbieters |
| Anforderung wird erfüllt |
| Anforderung teilweise erfüllt |
| Anforderung wird nicht erfüllt |
| Anforderung wird erfüllt |
| Anforderung wird nicht erfüllt |