Skip to end of banner
Go to start of banner

Erfassung mehrerer Signaturen (Version 2) - Anforderungsanalyse

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Auf dieser Seite werden die Anforderungen bezüglich der Erfassung mehrerer Signaturen beschrieben. 

Es ist eine angepasste Version von Erfassung mehrerer Signaturen - Anforderungsanalyse

Inhalt

Übersicht und Status

Status

PRÜFUNG IMPLEMENTER LISTE

Priorität

MITTEL

Kategorie

FUNKTION

Ersteller

D-MM

Beginn


Vorschlag SLUB Dresden

Beschreibung

  • Einem Datensatz sollen weitere Signaturen zugewiesen werden können.
  • Es sollen jedoch nicht die bestehenden Signatur-Felder (Signaturtyp, Signatur-Präfix, Signatur, Signatur-Suffix, Primär) wiederholt werden, wie in Erfassung mehrerer Signaturen - Anforderungsanalyse vorgeschlagen wurde. Dies hat erhebliche Auswirkungen auf die Verknüpfungen mit anderen Apps, ...  
    • Vergleiche: 
      (from Ann-Marie Breaux) Rather than making the existing call number field (and its various component fields) repeatable, could we consider adding a new repeatable field called alternate r previous call number? Might that be less disruptive than changing the existing field to repeatable?
      UXPROD-4334 - Getting issue details... STATUS
  • Stattdessen sollen zusätzliche wiederholbare Signatur-Felder definiert werden. Die neuen Felder können zum Beispiel unter der folgenden Bezeichnung zusammengefasst werden: 
    •  Weitere Signatur/en
  • Die internen technischen Bezeichnungen können den jeweiligen Anforderungen entsprechend gewählt werden. Im Front-End können die neuen Felder wie die vorhanden Signatur-Felder bezeichnet werden.    
    • Signaturtyp
    • Signatur-Suffix
    • Primär
  • Ebenen: Die neuen Felder von Weitere Signatur sollten in den folgenden Ebenen zur Verfügung stehen:
    • Item (Exemplar) 
    • Holding (Bestand)
  • Hauptsignatur: Die Werte der Felder Signatur und Weitere Signatur sollen mit maschineller Unterstützung ausgewechselt werden können:
    • Die Signatur (das bestehende Feld) ist immer die Hauptsignatur.
    • Die Hauptsignatur wird zum Beispiel in Folio in den Tabellen, oder in Katalogen angezeigt.
    • Eine Weitere Signatur kann bei Bedarf als Hauptsignatur angewendet werden.
      • Ein manuelles Tauschen der Werte in dem Feld Signatur und Feld Weitere Signatur soll vermieden werden. 
      • Stattdessen sollten die Werte durch eine Funktion "gewechselt" werden.
        • Die Funktion ist an jeder Weitere Signatur vorhanden und kann in Form eines Button ausgelöst werden. 
        • Durch die Funktion werden
          1. die Werte aus den Feldern der Weiteren Signatur in die Felder der Signatur übertragen. 
          2. die Werte aus den Feldern der Signatur in die Felder der  Weitere Signatur  übertragen. 
        • (Vorschlag) Bezeichnung Button:
  • Löschen: Jede Weitere Signatur soll einzeln mit allen zugehörigen Signaturfeldern gelöscht werden können.  
  • Indexierung: Alle Signaturen sollen im Signaturindex enthalten sein, damit man danach recherchieren kann.
  • Filter/Suche: Es soll eine Filtermöglichkeit implementiert werden, um die Treffermenge auf die Hauptsignaturen einzuschränken zu können. 
  • Exporte: Alle Signaturen sollen in Exporten enthalten sein, sofern sie nicht als "Anzeige im Discovery unterdrücken" ausgezeichnet sind. 


Entwurf

  • Auf die Erstellung eines Entwurfs wird verzichtet. 


Erstellte Jira-Tickets

Aktueller Stand

  • VORSCHLAG IN BEARBEITUNG: Der Vorschlag für die Anforderung wird noch bearbeitet und kann noch nicht in der D-Metadaten Management vorgestellt werden. 
  • VORSCHLAG FORMULIERT: Der Vorschlag für die Anforderung wurde formuliert und kann in der D-Metadaten Management vorgestellt werden. 
  • VORGESTELLT IN D-ERWERBUNG: Der Vorschlag für die Anforderung wurde in der Gruppe D-Metadaten Management vorgestellt.  
  • ANPASSUNG DES VORSCHLAGS: Der Vorschlag wurde nach der Vorstellung in der Gruppe D-Metadaten Management diskutiert sowie mit ähnlichen oder konkurrierenden Vorschlägen verglichen und gegebenenfalls angepasst. Die Gruppe D-Erwerbung ist mit dem Vorschlag einverstanden. 
  • PRÜFUNG IMPLEMENTER LISTE: Der Vorschlag wird hinsichtlich der Aufnahme in der Implementer Liste geprüft. 
  • PRIORISIERUNG: Der Vorschlag wird in der Gruppe D-Metadaten Management priorisiert. Je höher die Priorität gewählt wird, desto eher wird die Entwicklung angestrebt. 
  • VORSTELLUNG SIG ???: Der Vorschlag wird in der MM SIG vorgestellt. 
  • BEAUFTRAGUNG DER ENTWICKLUNG: Der Vorschlag wird mit den notwendigen Ressourcen in den Entwicklungsprozess eingebracht. 


Weitere Informationen

Vorstellungen

Funktionsanalyse

Relevante Anforderungsanalysen

  • -

Relevante Entwicklungen und Quellen

  • -

Relevante vorhandene Jira-Tickets

  • -



  • No labels