[DE] MoReq & MoReq2 | Model Requirements for the Management of Electronic Records | 2009

8/14/2019 [DE] MoReq & MoReq2 | Model Requirements for the Management of Electronic Records | 2009

1/55

MoReq&

MoReq2

Dr. Ulrich Kampffmeyer

P R O J E C T C O N S U L TUnternehmensberatung Dr. Ulrich Kampffmeyer GmbH

Hamburg, August 2009


2/55

MoReq & MoReq2

Abstract

Die Abkrzung MoReq steht fr Model Requirements for the Management ofElectronic Records. MoReq ist der europische Standard fr das RecordsManagement. Herausgegeben wurde der von der Europischen Kommissionbeauftragte und gefrderte Standard vom DLM Forum. Seit Februar 2008 ist dieVersion MoReq2 gltig. MoReq2 umfasst nicht nur die Anforderungen an dasRecords Management sondern beinhaltet auch ein XML-Schema, einen Katalog mitTestszenarien und Testdaten sowie ein Zertifizierungsverfahren fr RecordsManagement Produkte. MoReq2 deckt den gesamten Lebenszyklus von Recordsvon ihrer Entstehung, Nutzung und Verwaltung bis zur Archivierung und Lschungab. Verschiedene europische Staaten haben MoReq2 bereits adaptiert und dieersten Records Management Produkte befinden sich in der Zertifizierung.

von Dr. Ulrich KampffmeyerGeschftsfhrer der PROJECT CONSULT Unternehmensberatung GmbH, HamburgMitglied der Geschftsfhrung des DLM Network EEIG, Worcester

Inhaltsverzeichnis

Einfhrung.....................................................................................................................4Abriss der MoReq Entwicklung.....................................................................................5DLM Forum................................................................................................................5DLM Forum und MoReq............................................................................................7MoReq2......................................................................................................................7

Aufbau und Struktur von MoReq2...............................................................................10Requirements...........................................................................................................12Test Framework.......................................................................................................13Zertifizierungsverfahren...........................................................................................15XML-Schema...........................................................................................................16Einordnung von MoReq2.........................................................................................18

Records Management Funktionen und Komponenten nach MoReq2........................18Chapter 1 Introduction........................................................................................19Chapter 2 Overview of ERMS Requirements.....................................................20Chapter 3 Classification Scheme.......................................................................23Chapter 4 Controls and Security........................................................................24Chapter 5 Retention and Disposition..................................................................25Chapter 6 Capturing Records.............................................................................27Chapter 7 Referencing........................................................................................29Chapter 8 Searching, Retrieval and Presentation..............................................31Chapter 9 Administrative Functions....................................................................32Kapitel 10 Optional Modules...............................................................................33

Chapter 11 Non-Functional Requirements.......................................................37Chapter 12 Metadata Requirements.................................................................39

Kunde: PROJECT CONSULT Projekt: RM Autor: Kff/KGThema: Records Management Topic: MoReq & MoReq2 Status:Datei: 26697074 Datum: 2009 Version: 1.0 PROJECT CONSULT GmbH 2009-12-20 Seite 2 von 55


3/55

Chapter 13 Reference model................................................................................40MoReq2 Anhnge....................................................................................................41

Aktuelles zu MoReq2 im Herbst 2009.........................................................................43Kritik an MoReq2.....................................................................................................43Aktivitten des DLM Forum......................................................................................43bersetzungen und Chapter 0..............................................................................43Adaption in Europa..................................................................................................44Nutzen von MoReq2................................................................................................44

Quellen........................................................................................................................46Quellen



4/55

EinfhrungBeim Thema Records Management handelt es sich um die Verwaltung wichtiger,

aufbewahrungswrdiger oder aufbewahrungspflichtiger Informationen ausGeschftsleben, Verwaltung und Gesellschaft. Die ISO Norm 15489 definiertRecords Management wie folgt:Field of management responsible for the efficient and systematic control of thecreation, receipt, maintenance, use and disposition of records, including processesfor capturing and maintaining evidence of and information about business activitiesand transactions in the form of records.1

Dabei geht es nicht nur um die sichere Archivierung von Informationsobjektensondern um effiziente Erschlieung und einfache Wiedernutzung von wichtigenInformationen mit Untersttzung von Software. Records Management betrifftVerwaltungen, Unternehmen, Organisationen und Gruppen ebenso wie

Privatpersonen. Records Management dient zur Schaffung von Transparenz desHandelns, zur Bewahrung von Informationen und zur Nachvollziehbarkeit derAktivitten in der globalisierten Informationsgesellschaft.Die Globalisierung und die grenzberschreitende elektronische Kommunikationmachen gemeinsame Standards unerllich. Dies gilt fr Schnittstellen, Formate undNachrichten aber ebenso fr Records Management als Nachweis derGeschftsttigkeit.Hier setzte die europische Kommission sehr frhzeitig an und schuf mit den ModelRequirements for the Management of Electronic Records - MoReq2 eine Leitlinie,die besonders internationalen oder international agierenden Behrden, Unternehmenund Organisationen einen verllichen Rahmen fr den Umgang mit elektronsichenInformationen schafft. Vom Anspruch und Umfang her kommt Moreq einem Standardoder einer Norm gleich.Die meisten ffentlichen Verwaltungen haben in den letzten 15 Jahren Vorgaben frdas elektronische Records Management aber auch fr die durch Software-untersttze Vorgangsbearbeitung geschaffen. Hierzu gehren Richtlinien wieDOMEA3 in Deutschland, GEVER4 in der Schweiz, ELAK5 in sterreich, TNA6 inEngland, DoD 5015.27 in den USA, VERS8 in Australien und viele andere. MoReqgeht als Spezifikation jedoch weit ber den Rahmen derjenigen Standards hinaus,die nur auf ein Land oder eine bestimmte Branche wie die ffentliche Verwaltung

1 ISO 15489-1:2001 Information and Documentation - Records Management Part 1 : General

2 MoReq Model Requirements for the Management of Electronic Records. MoReqSPECIFICATION. INsAR. Office for Official Publications of the European Communities, Luxembourg-Brssel, 2001.http://www.project-consult.net/Files/MOREQ1_EN.pdf3 http://www.bundesarchiv.de/service/behoerdenberatung/01664/index.html4 http://www.isb.admin.ch/themen/architektur/00078/index.html?lang=de5 http://www.digitales.oesterreich.gv.at/site/5286/default.aspx; Teil A, Funktionsbeschreibung:http://www.digitales.oesterreich.gv.at/DocView.axd?CobId=19396; Teil B, Leistungsverzeichnis:http://www.digitales.oesterreich.gv.at/DocView.axd?CobId=19397; Teil C, Vorkonfiguration fr denBund: http://www.digitales.oesterreich.gv.at/DocView.axd?CobId=193996 http://www.nationalarchives.gov.uk/documents/standard2005.pdf. Der Einsatz des TNA Standardsist in 2009 ausgelaufen und TNA soll gegebenenfalls durch MoReq2 oder eine adaptierte Version vonMoReq2 abgelst werden.7 Design Criteria Standards for Electronic Records ManagementSoftware Applications:http://www.dtic.mil/whs/directives/corres/pdf/501502std.pdf

8 http://www.archives.sa.gov.au/management/standards.html?friendly=print

http://www.project-consult.net/Files/MOREQ1_EN.pdfhttp://www.project-consult.net/Files/MOREQ1_EN.pdfhttp://www.bundesarchiv.de/service/behoerdenberatung/01664/index.htmlhttp://www.isb.admin.ch/themen/architektur/00078/index.html?lang=dehttp://www.digitales.oesterreich.gv.at/site/5286/default.aspxhttp://www.digitales.oesterreich.gv.at/DocView.axd?CobId=19396http://www.digitales.oesterreich.gv.at/DocView.axd?CobId=19397http://www.digitales.oesterreich.gv.at/DocView.axd?CobId=19399http://www.nationalarchives.gov.uk/documents/standard2005.pdfhttp://www.nationalarchives.gov.uk/documents/standard2005.pdfhttp://www.dtic.mil/whs/directives/corres/pdf/501502std.pdfhttp://www.dtic.mil/whs/directives/corres/pdf/501502std.pdfhttp://www.archives.sa.gov.au/management/standards.html?friendly=printhttp://www.project-consult.net/Files/MOREQ1_EN.pdfhttp://www.bundesarchiv.de/service/behoerdenberatung/01664/index.htmlhttp://www.isb.admin.ch/themen/architektur/00078/index.html?lang=dehttp://www.digitales.oesterreich.gv.at/site/5286/default.aspxhttp://www.digitales.oesterreich.gv.at/DocView.axd?CobId=19396http://www.digitales.oesterreich.gv.at/DocView.axd?CobId=19397http://www.digitales.oesterreich.gv.at/DocView.axd?CobId=19399http://www.nationalarchives.gov.uk/documents/standard2005.pdfhttp://www.dtic.mil/whs/directives/corres/pdf/501502std.pdfhttp://www.archives.sa.gov.au/management/standards.html?friendly=print


5/55

beschrnkt sind. MoReq hat einen universelleren Charakter und richtet sich anUnternehmen, Organisationen, ffentliche Verwaltung und im Prinzip auch anPrivatpersonen in ganz Europa. MoReq ist so die wichtigste Spezifikation frelektronisches Dokumenten- und Records-Management in Europa.

Mit dem im Februar 2008 verffentlichten MoReq2 Standard9

liegt nun mehr eineFassung der Anforderungen an das Records Management vor, die aktueller,vollstndiger und nachprfbarer ist als die meisten anderen Standards fr dieSchriftgutverwaltung. MoReq liefert im Gegensatz zu anderen Standards (wie z.B.ISO 15489) eine sehr detaillierte Anforderungsliste sowohl fr funktionaleAnforderungen an ein elektronisches und papierbasiertes Records Management-System, als auch fr die dazugehrigen elektronischen Vorgangsbearbeitungs- undDokumenten-Management-Systeme. MoReq schliet auch Richtlinien zurEinbindung von Anwendungs- und anderen Informationsmanagementsystemen ein.MoReq definiert nicht nur Anforderungen fr die Verwaltung und Aufbewahrung vonelektronischen Aufzeichnungen, sondern auch die Anforderungen andererelektronischer dokumentenbezogener Funktionen wie Workflow, E-Mail undElektronische Signaturen, die mit Records Management zusammenwirken mssen.Die Anforderungschecklisten von MoReq sind modular aufgebaut und stellen eine ArtSchablone fr die jeweiligen Anwendungsbereiche dar. In diesen Anforderungslistenwerden alle Anforderungen beschrieben und jede einzelne Funktion detailliertdefiniert. Darber hinaus wird fr jede Funktion spezifiziert, ob sie Pflicht oderWnschenswert ist. Neben der Beschreibung der Anforderungen enthlt MoReqeinen Katalog der Metadatenelemente, die zur Umsetzung der Anforderungenerforderlich sind. Komplettiert wird der Katalog durch ein XML-Schema.Zahlreiche europische Staaten haben MoReq und die aktualisierte FassungMoReq2 inzwischen adaptiert, zum Teil in die nationale Gesetzgebung

aufgenommen oder als Grundlage fr eigene Spezifikationen verwendet.

Abriss der MoReq EntwicklungDLM Forum

Die MoReq Model Requirements for the Management of Electronic Records wurdenauf Initiative des DLM Forum entwickelt.Der Startschuss fr die Grndung des DLM Forums fiel am 14. November 1991, alsder Europische Rat und die Kultusminister eine Resolution bezglich einheitlicherund koordinierter Archivierungsmanahmen verabschiedeten10. Diese Resulotion

verdeutlichte zum Einen die Relevanz von Archiven imEntscheidungsfindungsprozess im ffentlichen Sektor und zum Anderen dieBedeutung von Archiven fr das europische Kulturerbe. Dieser Beschluss

9 MoReq2 Model Requirements for the Management of Electronic Records. Update and Extension,2008. INsAR. Office for Official Publications of the European Communities, Luxemburg-Brssels,2008. Requirements http://www.project-consult.net/Files/MoReq2_body_v1_04.pdf; Appendix 9 Metadata model http://www.project-consult.net/Files/MoReq2_appendix_9_v1.04.pdf, XML Schemahttp://www.project-consult.net/Files/MoReq2_Schema_1.04.01.zip; Test framework obligatory moduleshttp://www.imbus.de/forschung/moreq/MoReq2_Testframework_core_V1.0.zip, Test frameworkoptional modules http://www.imbus.de/forschung/moreq/MoReq2_Testframework_optional_V1.0.zip,Survey oft he test framework http://www.project-

consult.net/Files/MoReq2_Survey_Test_Certification_Process_PROJECT_CONSULT.pdf10 OJ, 91/C 314/02

http://www.project-consult.net/Files/MoReq2_body_v1_04.pdfhttp://www.project-consult.net/Files/MoReq2_appendix_9_v1.04.pdfhttp://www.project-consult.net/Files/MoReq2_Schema_1.04.01.ziphttp://www.project-consult.net/Files/MoReq2_Schema_1.04.01.ziphttp://www.imbus.de/forschung/moreq/MoReq2_Testframework_core_V1.0.ziphttp://www.imbus.de/forschung/moreq/MoReq2_Testframework_optional_V1.0.ziphttp://www.project-consult.net/Files/MoReq2_Survey_Test_Certification_Process_PROJECT_CONSULT.pdfhttp://www.project-consult.net/Files/MoReq2_Survey_Test_Certification_Process_PROJECT_CONSULT.pdfhttp://www.project-consult.net/Files/MoReq2_body_v1_04.pdfhttp://www.project-consult.net/Files/MoReq2_appendix_9_v1.04.pdfhttp://www.project-consult.net/Files/MoReq2_Schema_1.04.01.ziphttp://www.imbus.de/forschung/moreq/MoReq2_Testframework_core_V1.0.ziphttp://www.imbus.de/forschung/moreq/MoReq2_Testframework_optional_V1.0.ziphttp://www.project-consult.net/Files/MoReq2_Survey_Test_Certification_Process_PROJECT_CONSULT.pdfhttp://www.project-consult.net/Files/MoReq2_Survey_Test_Certification_Process_PROJECT_CONSULT.pdf


6/55

veranlasste die Europische Kommission dazu, eine Expertengruppe aus Expertender Mitgliedsstaaten zusammenzustellen.Die Expertengruppe kompilierte einen Bericht ber die Situation und mglicheZusammenarbeit von Archiven, der schnell als Black Book11 bekannt wurde.Zwischen einigen hervorgehobenen Bereichen in dem Bericht, die dieExpertengruppe fr eine europaweite Koordination und Kooperation fr notwendigerachtete, wurde auch die Bedeutung der Verwaltung elektronischer Informationendeutlich. Dieser Bericht veranlasste den Europischen Rat am 17. Juni 1994 dazu,eine engere Kooperation im Bereich der Archivierung zu frdern12. Die Beschlssedes Rates unterlagen dabei einmal mehr der Erkenntnis, dass Archive einensignifikanten Teil zum europischen Kulturerbe beitragen. Die EuropischeKommission frderte eine Reihe von Initiativen, besonders die Gruppe derNationalarchive, die sich damals unter dem Namen DLM donns lisible parmachine13 als a multi-disciplinary forum to be held in the framework of theCommunity on the problems of the management, storage, conservation and retrievalof machine-readable data zusammengefunden hatte. In diesem Forum fanden sichsehr schnell neben Vertretern der Archive Reprsentanten aus der ffentlichenVerwaltung, von Anbieter von Archivierungslsungen, aus der Beratungsbranche,von Industrieverbnden und aus der Forschung zusammen. Die Gruppe gab sichselbst den Namen DLM Forum.Die Europische Kommission ist in die Entwicklung und den Ausbau des DLMForums und viele Aktivitten des Forums seit seiner Entstehung mit involviertgewesen. In enger Kooperation mit den Mitgliedsstaaten, wurde 1996 das erste DLMForum organisiert, 1999 das zweite. Bei diesen beiden Kongressveranstaltungen wardie Europische Kommission in Brssel der Gastgeber. Hieraus entwickelte sich einDreijahresrythmus fr die groen Tagungen des DLM Forum. 2002 fand das Forumin Barcelona14, Spanien, 2005 in Budpest, Ungarn, und 2008 in Toulouse15,

Frankreich, statt. Das DLM Forum trifft sich auerdem halbjhrlich jeweils in demeuropischen Staat, der die EU-Prsidentschaft innehat.

DLM Forum und MoReq

Bereits zwei Jahre nach Grndung des DLM Forum wurde im Jahr 1996 der Bedarfeiner Spezifikation fr Anforderungen an Systeme zur Verwaltung elektronischerDokumente und Archive als Projekt bei der Europischen Kommission angemeldet.1999 wurden die Anforderungen in Zusammenarbeit mit Vertretern derDokumentenmanagementindustrie konkretisiert16. Im Rahmen des so genannten IDA

11 Black Book Archive in der Europischen Union. Europische Kommission, 1994.12 OJ C235 23.8.94 S.313 Diese franzsischsprachige Bezeichnung fr maschinenlesbare Dokumente wurde 2002 zugunstendes Begriffes Document Lifecycle Management bei Beibehaltung des Logos und des Akronyms DLMaufgegeben.14 Proceedings of the DLM Forum 2002. @ccess and preservation of electronic information: bestpractices and solutions. INsAR. Office for Official Publications of the European Communities,Luxemburg-Brssels, 2002. http://www.PROJECT-CONSULT.net/files/DLM Conference 2002.pdf15 Les actes de la Ve confrence du DLM-Forum Tolouse. Archives de France, 2009, Vol. 1 et 2.http://www.archivesdefrance.culture.gouv.fr/static/2735;http://www.archivesdefrance.culture.gouv.fr/static/2768

16 DLM Forum 1999: DLM Message to the Industryhttp://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/dlm-message-to-industry-en.pdf;

Answer of the Document Management Industryhttp://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/ictindustryresponse-en.pdf;

http://www.project-consult.net/files/DLM%20Conference%202002.pdfhttp://www.archivesdefrance.culture.gouv.fr/static/2735http://www.archivesdefrance.culture.gouv.fr/static/2768http://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/dlm-message-to-industry-en.pdfhttp://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/ictindustryresponse-en.pdfhttp://www.project-consult.net/files/DLM%20Conference%202002.pdfhttp://www.archivesdefrance.culture.gouv.fr/static/2735http://www.archivesdefrance.culture.gouv.fr/static/2768http://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/dlm-message-to-industry-en.pdfhttp://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/ictindustryresponse-en.pdf


7/55

Programms (Interchange of Data between Administration) der EuropischenKommission wurde nach einer Ausschreibung in den Jahren 2000 und 2001 durchdas Beratungsunternehmen Cornwell MoReq verfat. Eine erste Verffentlichung inelektronischer Form erfolgte dann bereits 2001. Die heute hufig als MoReq1bezeichnete Spezifikation wurde unabhngig in 11 Sprachen bersetzt17 und hat sichin einer Reihe von europischen und auereuropischen Staaten etablieren knnen.

In Finnland und Dnemark gibt es Referenzdokumente, die verbindlich fr dieffentliche Verwaltung sind, und in Slowenien wurde MoReq als gesetzlicheGrundlage fr das Records Management der ffentlichen Verwaltung festgesetzt. Dierussische Records Management Guild empfiehlt 2006 die Nutzung von MoReq frdas Records Management in Russland.

MoReq2

Schon zum Zeitpunkt der Verffentlichung von MoReq im Jahr 2001 wurde diePlanung fr einen erweiterten Standard begonnen und auf dem DLM Forum inBarcelona konkretisiert. 2006 erfolgte eine Ausschreibung, die wiederum von derFirma Cornwell (heute Serco) gewonnen wurde. MoReq2 wurde in einem offenenVerfahren im Jahr 2007 entwickelt. Der Entwicklungsprozess wurde von derEuropischen Kommission in enger Zusammenarbeit mit dem DLM Forum und demMoReq2 Editorial Board berwacht. An der Erarbeitung beteiligten sich nahezu alleeuropischen Nationalarchive, alle namhaften Anbieter von Enterprise-Content-Management-, Records-Management-, Archivierungs- undDokumentenmanagement-Software sowie weit ber zweihundert Wissenschaftlerund Anwender aus allen Branchen weltweit18.

Die neue Version von MoReq bercksiichtigt die technologische Weiterentwicklungseit 2001. MoReq2 bezieht auerdem neue Standards und Best Practice ein, die inden letzten Jahren entwickelt worden sind. MoReq2 wurde zu dem so konzipiert, dasnahezu alle Anforderungen testbar sind. Hierfr wurde ein Test Frameworkentwickelt. Die Notwendigkeit von klar formulierten und testbaren Anforderungen hatzu vielen Abnderungen im Ausdruck und Wortlaut von MoReq2 im Vergleich mitdem ursprnglichen MoReq Dokument gefhrt, auch wenn die Inhalte gleichgeblieben sind.Letztendlich haben Problem emit bersertzungen der ersten Version von MoReqgezeigt, dass es notwendig ist, nationale Gegebenheiten in vorgegebener Struktur inMoreq zu integrieren. Aus diesem Grund enthlt MoReq2 das so genannte Kapitel

0. Dieses ermglicht es den Mitgliedsstaaten, eigene nationale Anforderungen in dieSpezifikation aufzunehmen.Die aktuelle Version von MoReq2 wurde am 13.02.2008 verffentlicht und im Laufedes Jahres 2008 durch das Test- und Zertifizierungsverfahren fr Softwareproduktesowie ein XML Schema komplettiert19.

Conclusions of the DLM Forum 1999http://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/dlm-conclusions-en.pdf17 Tschechisch, Spanisch, Franzsich, Italienisch, Russisch, Portugiesisch, Slowenisch,Niederlndisch (Adaption), Brasilianisch, Kroatisch, Ungarisch. Eine deutsche bersetzung liegt nichtvor. Alle bersetzungen abrufbar unterhttp://moreq.niniel.org/quellen/18 Zum Prozess der Entstehung und zu den beteiligten Personen und Organsiationen siehe den

Vortrag von Ulrich Kampffmeyer im BBK Berlin, Januar 2009, Records Management & MoReq2:http://www.project-consult.net/Files/20090113_BKK_Records-Management_Kff_Handout.pdf

http://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/dlm-conclusions-en.pdfhttp://moreq.niniel.org/quellen/http://www.project-consult.net/Files/20090113_BKK_Records-Management_Kff_Handout.pdfhttp://ec.europa.eu/transparency/archival_policy/dlm_forum/doc/dlm-conclusions-en.pdfhttp://moreq.niniel.org/quellen/http://www.project-consult.net/Files/20090113_BKK_Records-Management_Kff_Handout.pdf


8/55

Die Vorteile von MoReq fr Anbieter liegen darin, dass sie ihre Produkte zuknftignur noch auf einen europischen Standard ausrichten mssen, und nicht mehr fr jedes Land einen eigenen Standard in der Implementierung zu bercksichtigenhaben.Anwender erhalten durch die einheitlichen Standards Records Management-Anwendungen, die als standardisierte, austauschbare und kompatible Produkte derAnbieter zur Verfgung stehen werden.Aus der Perspektive der Archive ist vor allem die Kompatibilitt, eine hohe Qualittder Onjekte und ihrer zugehrigen Metadaten bei der bergabe an dieLangzeitarchivierung und langfristige Stabilitt von Interesse.Wesentliche Fortschritte von MoReq2 sind die Schaffung einer flexibleren Struktur,die Erweiterung des Kernmoduls, die Schaffung neuer optionaler Module, dieEntwicklung eines MoReq Compliance Tests fr Softwareprodukte, die Ergnzungum eine lnderspezifische Einleitung (Chapter 0) und ein XML-Schema frObjektstruktur und Metadatenmodell.

Bei der Erstellung von MoReq2 wurden Ergnzungen aus relevantenQuelldokumenten wie z.B. der ISO 15489, der ISO 2308120 und der ISO 1472121sowie dem deutschen DOMEA Standard und der UK TNA 2002 Spezifikationbercksichtigt, sowie aktuelle Trends im Umfeld von ECM, ILM, Archivierung undDokumentenmanagement. MoReq2 beschftigt sich nicht nur mit dem Kernbereichdes Records Management sondern deckt auch den gesamten Entstehungs-,Nutzungs-, Archivierungs- und Aussonderungsbereich ab.MoReq2 zielt sowohl auf die ffentliche Verwaltung wie die Privatwirtschaft. DerMoReq2 Standard ist der Mastab fr alle Anwender, die elektronische undpapiergebundene Informationen systematisch verwalten und langfristig aufbewahrenmssen.

19 Die gedruckte Ausgabe in englischer Sprache basiert auf Version 1.03, die gltige elektronischeAusgabe hat die Versionsnummer 1.04. Alle MoReq2 Dokumente einschlielich ihrerVersionsgeschichte knnen von hrttp://www.MoReq2.de, dort http://moreq.niniel.org/quellen/,heruntergeladen werden20 ISO 23081-1:2006 - Information and documentation -- Records management processes --Metadata for records -- Part 1: Principles; ISO 23081-2:2009. Information and documentation --

Managing metadata for records -- Part 2: Conceptual and implementation issues21 ISO 14721:2003 OAIS - Open archival information system -- Reference model

http://moreq.niniel.org/quellen/http://moreq.niniel.org/quellen/http://moreq.niniel.org/quellen/


9/55

Der Standard adressiert elektronisches Records Management ebenso wie dieVerwaltung von hybriden Dokumenten. Er geht mit den optionalen Modulen weit berdas klassische Records Management und besonders ber dasSchriftgutmanagement deutscher Begriffsprgung hinaus.

Unabhngig von Tests und Zertifizierung fr Softwareprodukte definiert der Standardden aktuellen State-of-the-Art des Records Management und erlaubt jedemInteressierten selbst die Requirements und die Test-Cases fr eigene Projekte zunutzen. Darber hinaus kommt MoReq2 als Grundlage fr Lehre an Universittenund Hochschulen zum Einsatz.Im September 2009 war MoReq bereits in franzsischer, russischer, koreanischerund tschechischer bersetzung verfgbar22.MoReq schafft letztlich eine hohe Austauschfhigkeit, langfristige Sicherheit sowieeinheitliche Rahmenbedingungen fr die Entwicklung und den Einsatz von Systemenzum Dokumenten- und Records Management sowie zur elektronischen Archivierungim europischen Raum.

22 Alle elektronisch verfgbaren bersetzungen knnen von der URLhttp://moreq.niniel.org/quellen/heruntergeladen werden. Im September waren bersetzungen in deutsch, ungarisch und katalanisch

in Arbeit. Es gibt zwei konkurrierende russische bersetzungen. Weitere Sprachen sind angekndigt.Offizielle bersetzungen mssen durch die Europische Kommission lizensiert sein.



10/55

Aufbau und Struktur von MoReq2MoReq2 ist eine Spezifikation, die die Einsatzmglichkeiten einer guten, allgemeinen

elektronischen Records- Management-Anwendung, beschreibt23. Die MoReq2Requirements wurden am 13. Februar 2008 verffentlicht, die Testszenarien undanderen Teile der Spezifiaktion folgten etwas spter. MoReq2 ist bereits ohneAnhnge 200 Seiten stark. Die neun Anhnge umfassen noch einmal 100 Seiten unddie Testszenarien gehen weit ber 1000 Seiten hinaus.MoReq2 hat im Kernbereich 8 Anwendungsgebiete, die sich mit elektronischenRecords beschftigen. Diese Kerngebiete sind:

Create Erzeugung Capture bernahme und Erfassung Use Nutzung Preserve Archivierung, Langezeitarchivierung Transfer Verschieben, Migrieren Manage Verwaltung Store Speichern, Aufbewahrung Destroy - Vernichtung

MoRAbb. 1: MoReq2 acht Anwendungsgebiete

Diese Anwendungsgebiete sind vergleichbar mit anderen Konzepten fr DocumentLifecycle Management oder Enterprise Content Management24. So finden sich dieBegriffe Preserve, Capture oder Store zum Teil mit leicht anderer Bedeutungauch im ECM Konzept. Dort ist Records Management eine Komponente nebenBusiness Process Management, Web Content Management, Document

23 MoReq2 ist kostenlos erhltlich unter: www.moreq2.eu oder www.moreq2.de.24 Kampffmeyer, Ulrich: Dokumenten-Technologien Wohin geht die Reise? PROJECT CONSULT,

Hamburg, 2003, S. 51ff. Kampffmeyer, Ulrich: ECM Enterprise Content Management. PROJECTCONSULT, Hamburg, 2006, S. 6ff.



11/55

Management und Collaboration. Anders als bei den genannten Konzepten steht beiMoReq die Record im Vordergrund. Die meisten ECM Komponenten sind nurSatelliten in dem MoReq2 Records Management Modell.

Um den Kernbereich des Records Managements gruppen sich die optionalenModule. Diese beinhalten Case Management, Workflow, Langzeitarchivierung,hybrides Records Management, und andere Komponenten, die vor, parallel odernach der Nutzung im Records Management von Bedeutung sind. Fr alle gelten dasEntity Relationship Model und das Referenzmoddel fr die Metadaten. Chapter 0erlaubt Ergnzungen fr nationale Besodnerheiten ind en bersetzungen, dieallerdings den Grundstzen von MoReq2 nicht widersprechen drfen.

Abb. 2: MoReq2 Basic, Optional and Non-Functional Requirements

Das Moreq2 Dokument gliedert sich in vier Teile25: Requirements (Anforderungen) Anhang 9 Datenmodell (aus Platzgrnden nicht mit den Requirements

zusammen verffentlicht) Testszenarien und Testdaten XML-Schema

25 Alle Dokumente knnen unter folgender URL jeweils in der gltigen Version (derzeit 1.04)

heruntergeladen werden: http://moreq.niniel.org/quellen/. Ein offizielle Webseite des DLM Forum frMoReq2 existierte im September 2009 noch nicht.



12/55

Requirements

Die Requirements umfassen 235 Seiten und enthalten fast 800 Anforderungen.Diese Anforderungen sind nach funktional und nicht-funktional untzerschieden. DieTestbarkeit wird durch Y fr testbar und N fr nicht-testbar angegeben. Ferner

wird differenziert, ob es sich um ein obligatorisches Muss Kriterium (Formulierungmust) handelt oder nur um eine wnschenswerte Funktion (Formulierung shall).

Abb. 3: Aufbau der Requirements26

Das Inhaltsverzeichnis von MoReq2 umfat folgende Kapitel:

1. Introduction2. Overview of ERMS Requirements3. Classification Scheme and File Organisation4. Controls and Security5. Retention and Disposition6. Capturing Records and Declaring Records7. Referencing

8. Searching, Retrieval and Presentation9. Administrative Functions10. Optional Modules11. Non-Functional Requirements12. Metadata Requirements13. Reference Model (Anhang 9)

Die klassischen Records Management Funktionen sind als Kernmodule in derKapiteln 3 bis 9 zusammengefat. Kapitel 10 beinhaltet die optionalen Module:

10.1 Management of Physical (Non-electronic) Files and Records

26 http://www.project-consult.net/Files/MoReq2_body_v1_04.pdf.



13/55

10.2 Disposition of Physical Records10.3 Document Management and Collaborative Working10.4 Workflow10.5 Casework10.6 Integration with Content Management Systems10.7 Electronic signatures10.8 Encryption10.9 Digital Rights Management10.10 Distributed Systems10.11 Offline and Remote Working10.12 Fax Integration10.13 Security Categories

Folgende Anhnge gehren zu den Requirements:

Appendix 1 Reference PublicationsAppendix 2 Development of this SpecificationAppendix 3 Use of this Specification in Electronic FormAppendix 4 AcknowledgementsAppendix 5 Correspondence to Other ModelsAppendix 6 Date ProcessingAppendix 7 Standards and Other GuidelinesAppendix 8 Changes from the Original MoReqAppendix 9 Metadata Model

Test Framework

Die imbus AG27 hatte im Rahmen des MoReq2-Projektes den Auftrag fr die

Erstellung der Testszenarien, Testkriterien und Testdaten erhalten.Die Testszenarien folgen in ihrem Aufbau der Struktur der MoReq2-Spezifikation. Siesind modular aufgebaut, so dass auch Einzelbereiche mit standardisiertenTestverfahren berprft werden knnen. Die Testszenarien konkretisieren darberhinaus die Anforderungen der Spezifikation, die teilweise allgemeiner gehalten sind.Zu den Testszenarien gehren auch entsprechende Testdaten, die dieNachvollziehbarkeit und Prfung der Tests sicherstellen.Das MoReq2 Test Frame Work ist in der jeweils gltigen Fassung auf den Webseitenvon imbus28, MoReq2.eu und MoReq2.de verffentlicht.

Die Testkataloge und Testdatenzusammenstellungen konkretisieren dabei die

Requirements. Allerdings gibt es auch eine Reihe von Requirements, die nichttestbar sind. Die Referenten erluterten die Hilfestellungen, die fr die Durchfhrungder Tests gegeben werden. So sind z.B. in den Testdaten die Eingangszustnde, dieVernderungen whrend des Tests und der Zustand am Ende des Tests angegeben.Die Tests sind dabei entsprechend den Kapiteln der Requirements gegliedert. JeKapitel gibt es optionale und Pflichtkriterien, die aus den Requirements abgeleitetsind. Fr die Records Management Kernmodule sind so z.B. rund 65% derAnforderungen Pflicht. Da das Testergebnis nur Bestanden oder Nicht Bestandenist, ist eine groe Stringenz und Eindeutigkeit des Ergebnisses gegeben. Imbus wies

27 http://www.imbus.de/startseite/28 http://www.imbus.de/forschung/moreq2/



14/55

darauf hin, dass die Tests nicht nur fr die Zertifizierung der Anbieterproduktegedacht sind, sondern von jedem Anwender auch fr die berprfung und den Testvorhandener oder zu beschaffender Lsungen verwendet werden knnen. Die Testssind vom Umfang her sehr aufwndig, jedoch einfach und schnell durchfhrbar29.Bei den Tests gibt es als Ergebnisse nur erfllt oder nicht erfllt.

Abb. 4: Testframework Material: Prozessbeschreibungen, Prfbgen, Testdaten30

Bei den Testmodulen im Kernbereich gibt es insgesamt 439 Testflle. Davon sind311 Testflle verpflichtend und 128 Testflle optional. Das Testdatenverzeichnisumfasst 254 Seiten.Bei den optionalen Testmodulen gibt es insgesamt 233 Testflle. Es sind 155Testflle verpflichtend und 78 Testflle optional. Das Testdatenverzeichnis umfasst131 Seiten.Insgesamt besteht das gesamte Testmaterial aus ca. 1200 Seiten.

29 Der erste erfolgreiche Test wurde mit der Fa. Fabasoft, Wien, durchgefhrt, die am 30.7.2009 dasMoreq2 Zertifikat fr ihre Software Folio erhielt.30 http://www.imbus.de/forschung/moreq2/



15/55

Abb. 5: Beispiel der Testfallstruktur mit Testbeschreibung, Ausgangsbedingungen,Testduchfhrung und Testergebnis.

Zertifizierungsverfahren

Die Zertifizierung von Softwareprodukten wird von akkreditierten Testcenternvorgenommen und gilt europaweit.Die Anbieter knnen entscheiden, ob sie ihre Produkte nur fr den Kernbereich desklassischen Records Management oder aber auch fr die optionalen Module prfenlassen wollen. Letztere sind von besonderem Interesse, da hier vorhandene sinnvolleZusatzfunktionalitt von den Anbietern ins Spiel gebracht werden kann, die nichtBestandteil des Records Management im engeren Sinn ist.Das Zertifizierungsverfahren hat drei Stufen.Nach einer Anmeldung durch den interessierten Software-Anbieter wird vomakkreditierten Testcenter und dem MoReq Governance Board geprft, ob der

Antragsteller grundstzlich die Voraussetzungen erfllt.Im zweiten Schritt wird eine Vorprfung durchgefhrt. Erst danach im dritten Schritterfolgt der umfangreiche Test auf der Systemumgebung, die vom Anbieter bereit zustellen ist. Nach bestandenem Test wird vom Testcenter das Zertifikat ausgestellt.Dieses weist aus, welche Komponenten gestestet worden sind und fr welcheVersion der Software das Zertifikat gilt.



16/55

Abb. 6: Beispiel fr einen MoReq2 Prfbericht

XML-Schema

Die MoReq2 XML-Schema definieren die Metadaten und die Strukturen der in derSpezifikation enthaltenen funktionalen Entitten wie Klassen, Rechte und derenZusammenhnge.

MoReq2 XML-Schema Entitten:MoReq2-Class.xsd Class entity definition

MoReq2-Component.xsd Componenet entity definitionMoReq2-Entity_Agent.xsd Entity Agent relationship definition.MoReq2-File.xsd File entity definitionMoReq2-Group.xsd Group entity definitionMoReq2-Record.xsd Record entity definitionMoReq2-Record_Redaction.xsd Record Redation definitionMoReq2-Record_Type.xsd Record Type definitionMoReq2-Retention_And_Disposition.xsd Retentional & disposition schedule definitionMoReq2-Role.xsd Role entity definitionMoReq2-Sub-File.xsd Sub-File entity definitionMoReq2-User.xsd User entity definitionMoReq2-Volume.xsd Volume entity definition

Das XML-Schema spezifiziert ein Standard Austauschformat. Es basiert auf demMetadatenmodell und erlaubt den Austausch von

Electronic Records Aggregationen (Akten, Klassen etc.) Klassifikations-Schemata

Das XML-Schema ist vorgesehen fr Software Unternehmen und vermutlich nichtsehr ntzlich fr andere Unternehmen.



17/55

Abb. 7: XML-Schema



18/55

Einordnung von MoReq2

Im des Records Management und der elektronsichen Archivierung existierenzahlreiche Standards. Hierbei ist zunchst zu bercksichtigen, dass dieverschiedenen Standards nur bestimmte Teilbereiche abdecken, PDF/A betrifft z.B.nur Formate bei Erzugung und Archivierung, die ISO 17421 OAIS nur das Modeleines idealen Archivsystems. MoReq2 deckt dagegen alle 8 definierten Kernbereicheab und inkorporiert zahlreiche andere Standards. Der nchst vergleichbare, ebenfallszertifizierbare Standard ist DoD 5015.2 in den USA, der aber nicht die gleicheVollstndigkeit wie MoReq2 besitzt.

Abb. 7: MoReq2: Einordnung und Abdeckung verschiedener Standards

Records Management Funktionen und Komponenten nachMoReq2

Die MoReq2 Spezifikation besteht im Kern aus mehreren Kapiteln zu denklassischen Records-Management-Funktionen. Zu den Grundmodulen gehrenKlassifikationsschema und Aktenplanaufbau, Suche und Darstellung, Aufbewahrungund Vernichtung, Sicherheit und Kontrolle, Erfassung und Indizierung sowie

administrative Funktionen. Ergnzt wird dieser Bereich durch optionale Module wieWorkflow, Digital Rights Management, Collaboration, Dokumentenmanagement,Archivierung (orientiert sich an der ISO 17421), Handhabung von physischen undhybriden Akten, Fax-Integration und andere Anwendungsfelder des EnterpriseContent Management. Wesentlicher Bestandteil sind auch die nichtfunktionalenAnforderungen wie Benutzerfreundlichkeit, Performanz, Verfgbarkeit und andere.Wesentliche Bestandteile der Spezifikation sind das Datenmodell (mitReferenzierung zu Dublin Core und ISO 23081) und das Referenzmodell fr dasKlassifikationsschema.In einem Kapitel 0 sollen zuknftig in den bersetzungen von MoReq2 dieBegrifflichkeit und die Einbettung in nationale Gegebenheiten aufgenommen

werden31. Die Spezifikation enthlt zustzlich Kennzeichnungen, ob eine funktionaleAnforderung testbar ist und ob sie zu den Pflichtvorgaben fr die Zertifizierunggehrt.Im Folgenden werden die Inhalte der einzelnen Kapitel nher vorgestellt.

Preface(Vorwort)

Chapter 1 Introduction

(Einleitung)

31 Ein Beispiel ist die franzsische bersetzung von MoReq2 mit einem sehr umfangreichen Chapter0: http://www.project-consult.net/files/MoReq2_FR.PDF



19/55

1.1 Background

1.2 Relationship between MoReq and MoReq2

1.3 Purpose and Scope of this Specification

1.4 What is an ERMS?Ein Electronic Rcords Management System nach MoReq hat primre undsekundre Anwendungszwecke. Die Anwendung fr die Verwaltung vonelektronischen Records wird als primrer Anwendungszweck bezeichnet.Die Verwaltung von physischen Objekten hingegen als sekundr.Fr die verschiedenen Informationsarten gibt es verschiedene Software-Systeme. So erfolgt beispielsweise die Verwaltung unstrukturierterInformationen aus Anwendungen wie der Textverarbeitung oder E-Mail-Systemen heraus. Es findet keine Verwaltung von strukturierten Datenaus anderen Anwendungen wie ERP-/HR-Systemen statt.

1.5 For what can this specification be used?

1.6 Intellectual property rights

1.7 Emphasis and Limitations of this Specification

1.8 Considerations for individual Member States (Chapter 0)Die lnderspezifische Einleitung erlaubt es jedem Land, einzelne eigeneAnforderungen hinzuzufgen wie z.B: Verweise auf nationale Standards

(z.B. BS 4783). Dies kann jedoch durch die bersetzungslizenz derEuropischen Kommission eingeschrnkt werden. Die Anforderungend esChapter 0 drfen nicht im Widerspruch zu den Requirementsstehen.Mgliche Inhalte des Kapitel 0 sind die bersetzung vonSchlsselbegriffen und Schlsselkonzepten, Auflistungnationaler rechtlicher und regulativer Anforderungen, nationale Standardsund Richtlinien zur Zugnglichkeit sowie nationale Quellen fr weitereInformationen.

1.9 Using this Specification

1.10 Organisation of this Specification

1.11 Compliance Testing

1.12 Mandatory and Desirable Requirements

1.13 Comments on this SpecificationZweck und Zielsetzung der Spezifikation:Ziel der Spezifikation ist es, die funktionalen Anforderungen fr dieVerwaltung von Records in einem ERMS (Electronic RecordsManagement System) zusammenzufassen, die sowohl fr die ffentliche

Verwaltung als auch fr Unternehmen von Bedeutung sind.



20/55

Zweck der Spezifikation ist die Untersttzung der Anwender bei derEinfhrung oder Bewertung von ERMS-Systemen.In-Scope, also innerhalb des definierten Aufgabenbereiches derSpezifikation, ist die Identifikation und Kurzbeschreibung nicht-funktionalerEigenschaften. Damit sind die Kurzbeschreibung engzusammenhngender Anforderungen wie Dokumentenmanagement unddie elektronische Verwaltung von physischen Objekten gemeint.Im Gegensatz dazu werden verwandte Themen wie Digitalisierung undandere Formen der Erstellung von Records, die Einfhrung eines ERMSin der Praxis und Plattform- oder Sektor-spezifische Anforderungen Out-of-Scope verwendet.Die Grundannahme der Spezifikation ist, dass die Nutzer eines ERMSneben Administratoren, Records Managern oder Archivaren auchnormale Bro- und Betriebsmitarbeiter sind, die das ERMS im Rahmenihrer tglichen Arbeit nutzen.

Chapter 2 Overview of ERMS Requirements

(berlick ber die ERMS Requirements)

2.1 Key TerminologySchlsselbegriffe

administrative role Administratorrolleauthoritativerecord

aussagekrftiges Record

capture Erfassungcase Vorgangcase file Fallakteclass Klasseclassification Klassifikationclassificationscheme

Klassifikationssystem

file plan Aktenplancomponent Komponentedocument Dokumentelectronic record aufbewahrungspflichtige Aufzeichnung in elektronischer FormERMS Electronic Records Management Systemmetadata Metadatenrecord aufbewahrungspflichtige Aufzeichnungfile Ordner, Aktesub-file Unterordner, Unterakteuser role Anwenderrollevolume Band

2.2 Key Concepts: HauptkonzepteBei einem Record handelt es sich um Information, die erzeugt, empfangenund bewahrt wird, um als Nachweis einer Organisation oder Person beirechtlichen Verpflichtungen oder zum Nachvollzug einer geschftlichenHandlung zu dienen (ISO 15489-1). Der Record entspricht eineraufbewahrungspflichtigen bzw. aufbewahrungswrdigen Aufzeichnung. Erkann eines oder mehrere Dokumente umfassen und auf jedem Medium in jedem Format gespeichert werden. Ein Record kann aus mehreren

Komponenten bestehen und sowohl Kontext- als auch



21/55

Strukturinformationen enthalten. Er zeichnet sich durch seineUnvernderbarkeit aus.Aber: Nicht jedes Dokument ist ein Record! Jedes Dokument kann inmehreren Records erscheinen.

authoritative record (aussagekrftiges Record)Eine wichtige Rolle spielt dabei die Authentizitt. Es muss nachweisbarsein, dass es sich tatschlich darum handelt, was es zu sein vorgibt.Auerdem muss es tatschlich von demjenigen erstellt worden sein, dervorgibt, es erstellt oder bermittelt zu haben. Es muss zur angegebenenZeit tatschlich erstellt oder bermittelt worden sein.Neben der Authentizitt ist die Zuverlssigkeit ein wichtiges Merkmal. EinRecord kann als verlssliche Grundlage herangezogen werden, da seinInhalt eine glaubwrdige, vollstndige und genaue Wiedergabe der in ihmnachgewiesenen Transaktionen, Aktivitten oder Tatsachen ist.Der Record zeichnet sich des Weiteren durch seine Integritt (vollstndigund unverndert) und Benutzbarkeit (kann nachgewiesen, wiederaufgefunden, dargestellt und verstanden werden) aus.

electronic file (Elektronischer Ordner, elektronische Akte)Der elektronische Ordner wird analog zu den Ordnern in der Papierweltverwendet und angelegt. Es handelt sich dabei um eine Sammlungelektronischer Records. Es handelt sich dabei um einen virtuellen Ordner,der keinen Inhalt hat und nur Metadaten und Attribute der zugewiesenenRecords und Unterordner enthlt.

sub-file (Unterordner, Unterakte, Mappe, Register)In den Unterordnern erfolgt eine intellektuelle Einteilung nach inhaltlichenKriterien. Dies ist auch bei den elektronischen Ordnern sinnvoll. Es dientder Verbesserung der Navigation und der Verwaltung von Records mit

unterschiedlichen Aufbewahrungsanforderungen. volume (Band)

Es erfolgt eine automatische Aufteilung nach vordefinierten Richtlinien, dieauf den ueren Eigenschaften der Ordner, wie beispielsweise Gre,Anzahl der enthaltenen Records und Zeitraum, basiert. Dies ist auch imRahmen der elektronischen Welt sinnvoll, um die Remote-Arbeit zuuntersttzen und die Offline-Nutzung von Records zu gewhrleisten.

classification scheme (Klassifikationssystem)Dabei handelt es sich um die Reprsentation der Ablagestruktur und dieErstellung einer hierarchischen Ordnung. Dies kann durch die effektive,stabile und eindeutige Organisation von Records, die weite Verbreitung in

Europa und die Kompatibilitt zu MoReq1 gerechtfertigt werden.Bei einem Aktenplan (file plan) handelt es sich um eine konkrete Ausprgung eines Klassifikationssystems fr einen spezifischen Anwendungsfall. In der ISO 15489 werden die BegriffeKlassifikationssystem und Aktenplan allerdings synonym verwendet.

class (Klasse)Dabei handelt es sich zum Einen um einen Teilbereich der Hierarchie, derdurch eine Linie, die von irgendeinem Punkt der Hierarchie zu allendarunterliegenden Ordnern verluft, dargestellt wird:

entspricht den Begriffen Gruppe oder Serie entspricht einem Ast des Hierarchiebaums eine Klasse kann andere Klassen enthalten.



22/55

Zum Anderen ist es eine Bezeichnung fr alle Ordner, Records etc., dieeiner Klasse zugewiesen sind. Das begriffliche Klassenkonzept ist hierleider nicht eindeutig.

user and administrative roles (Anwender und Administratoren Rollen)Als Nutzer kann jeder bezeichnet werden, der die Berechtigung hat, mitdem ERMS zu arbeiten. Eine Rolle entspricht dem Nutzerprofil:

Verantwortlichkeiten Funktionale Rechte Von mehreren Nutzern geteilt

Administratoren (adminstrative roles) verwalten die Records selbst undbetrachten Records als Entitten, unabhngig von Inhalt oderGeschftszusammenhang. Sie verwalten des Weiteren Hardware,Software und Speicher fr das ERMS und die Sicherung und Performanzder Lsung.Anwender (Uder roles) nutzen die Records und fgen gegebenenfallsDokumente hinzu. Sie suchen und finden Records und interessieren sichin erster Linie fr den Inhalt der Records und weniger fr die Verwaltung.

2.3 Entity-Relationship ModelSiehe hierzu besonders Anhang 9.

Chapter 3 Classification Scheme

(Klassifikationsschema)

3.1 Configuring the Classification Scheme (Einrichtung der Klassifikationssystematik)

Eigenschaften des Klassifikationsschemas sind die hierarchischeReprsentation von Ordnern und Records in Klassen und die unbegrenzteAnzahl der Hierarchielevel.Die Verwaltung wird in Identifizieren, Titel und Beschreibungstextunterteilt. Falls ein formales MoReq2 XML-Schema verffentlicht wird,muss das ERMS in der Lage sein, Records gem dieses Schemas zuimportieren und zu exportieren.Eine Besonderheit bei der Entwicklung eines Klassifikationsschemas istdie direkte Zuordnung von Records zu Klassen. Eine Klasse kann dabeieine Mischung von Klassen, Records und Ordnern enthalten. Ordnerknnen auf jeder Ebene der Hierarchie angesiedelt sein. Ordner und

Klassen drfen jedoch nicht in einer Klasse nebeneinander existieren.

3.2 Classes and Files (Klassen und Ordner)Eigenschaften der Klassen und Ordner sind die ffnen- und Schlie-Funktion. In geschlossenen Klassen und Ordnern ist keine Ablagemglich. Gem ISO 2788 muss kontrolliertes Vokabular alsbeschreibende thematische Bezeichnung verwendet werden.

3.3 Volumes and Sub-Files (Bnde und Unter-Ordner)Jeder Ordner besteht aus mindestens einem Unterordner. Bei nur einemUnterordner ist die Transparenz fr den Anwender gewhrleistet.



23/55

Es gibt Verwaltungsregel. Die beispielsweise besagen, dass alleUnterordner eines offenen Ordners immer geffnet sind und alleUnterordner eines geschlossenen Ordners immer geschlossen sind.Die Vorlagen fr die Unterordnerstruktur sind auf Klassenebeneanwendbar und es erfolgt eine automatische Erstellung bei der Anlageeines neuen Ordners. Die Vorlagen sind vorrangig fr die Case-Management-Umgebungen gedacht.Unterordner knnen in Bnde aufgeteilt werden. Dies untersttzt dieautomatisierte Verwaltung. Es wird ausschlielich der jngste Bandgeffnet und die automatische Schlieung erfolgt nach konfigurierbarenKriterien.Bnde und Unterordner knnen als deaktivierbares Feature auf beliebigenEbenen des Klassifikationssystems verwendet werden.

3.4 Maintaining the Classification Scheme (Pflege des Klassifikationsschemas)Bei Pflege des Klassifikationssystems gibt es einige Besonderheiten. Sobringt eine Verschiebung von Klassen innerhalb desKlassifikationssystems eine Verschiebung aller zugeordneten Records mitsich. Eine Kopie von Klassen innerhalb des Klassifikationssystems istebenso mglich wie die Erstellung von Querverweisen zwischen denOrdnern. Mehrfacheintrge sind mglich fr:

ein Record in unterschiedlichen Klassen, Ordnern ohne Duplikation des Dokumentes Umsetzung nicht spezifiziert Pointer als eine Mglichkeit

Chapter 4 Controls and Security(Kontrolle und Sicherheit)

4.1 Access (Zugang, Zugriff)Beim Zugang und Zugriff werden rollen- und gruppenbasierteZugangsrechte unterschieden. Es gibt verschiedene Ebenen derZugriffsbeschrnkung:

Ordner oder Records Klassen des Klassifikationssystems Sicherheitsfreigabe des Anwenders ausgewhlte Funktionen (z.B. lesen, schreiben, update etc.) spezielle Elemente der Metadaten Abhngig von festgelegtem Datum

Es gibt ein integriertes Netzwerk-Log-On und die Verwaltung von Gruppenund Usern erfolgt auch in separater Directory Management Software.Bei der Suche mssen die Berechtigungen bercksichtigt werden. DerZugriff kann ber die Metadatensuche oder Navigation erfolgen. Eswerden dann Alternativen fr den Umgang mit Objekten angezeigt, fr diekeine Zugriffsberechtigung vorliegt:

Anzeige des Titels und anderer Metadaten Anzeige des Titels, des Entittentyps (Klasse, Record, etc.),

Erstellungsdatum und

Owner



24/55


25/55

Es werden so genannte Pflicht-Inhalte und Soll-Inhalte unterschieden. DiePflichtinhalte sind unter anderem: Aufbewahrungsfrist und Auslseereignis (intern / extern) oder Aussonderungszeitpunkt

Aussonderungsmanahme UrsacheSoll-Inhalte zeichnen sich aus durch: Beschreibung Anordnung: Spezifikation der Begrndung fr die Regelung, i.d.R.

Hinweis auf ein Gesetz oder eine UnternehmenspolicyMgliche Aussonderungsmanahmen sind die langfristige Aufbewahrung,die Anzeige und berprfung, das automatische Lschen, das Lschennach der Autorisierung durch einen Administrator und der Transfer in einArchiv oder ein anderes Repository.

Konflikt-Management

Bei mehreren widersprchlichen Regelungen fr ein Objekt kann esKonflikte geben. Im Rahmen des Konflikt-Managements werdenautomatische Benachrichtigungen fr diesen Fall versand. Dadurch wirdein automatisiertes Konflikt-Management mglich. Diese administrativeEntscheidung ist nicht verpflichtend, muss jedoch konfigurierbar sein.

Disposal Holds / Legal HoldsAussonderungssperren stellen im Falle unerwarteter Ereignisse sicher,dass die spezifizierten Records nicht entsprechend der Aussonderungsregeln ausgesondert werden. Dies kann beispielsweisentig sein, wenn Records als Beweise in einem Rechtsstreit bentigtwerden. Die Aussonderungssperre darf aber keine Aufbewahrungsfrist an

der Ausfhrung hindern und muss fr jedes Objekt, das der Sperreunterliegt, verhindern, dass es gelscht oder ausgesondert wird.Eine Anwendung als Massenoperation ist mglich und es kann eineparallele Gltigkeit mehrerer Aussonderungssperren fr ein Objekt geben.Sie sind ein Kriterium, das die Suche und Reporting beeinflussen kann.

5.2 Review of Disposition Actions (Prfung und Freigabe von Vernichtungsaktionen)Eine berprfung der Aussonderungsmanahmen kann auf Grund einerautomatischen Benachrichtigung erfolgen. Diese Benachrichtigung enthltInformationen zu allen Aufbewahrungs- und Aussonderungsregeln, die ineinem bestimmten Zeitraum in Kraft treten. Eine Untersttzung dieses

berprfungsprozesses kann durch die Anzeige der Entitten,zugehrigen Metadaten und zugewiesenen Regeln erfolgen. EineNavigation in und zwischen den Ordnern ist ebenso mglich wie einWechsel zur Metadatenansicht fr Ordner und Records. Es erfolgt eineBenachrichtigung bei der Lschung von verlinkten Objekten.

5.3 Transfer, Export and Destruction (Transfer, Export und Lschung)Bei dem Transfer geht es um die berfhrung von Records in ein anderesSystem. Zunchst erfolgt dabei der Export einer Kopie mit allenzugehrigen Metadaten und Audit Trails. War dieser Export erfolgreich,werden die Originale im Ursprungssystem gelscht.



26/55

Bei dem Export werden komplette Einheiten, Ordner oder Records fr einanderes System kopiert. Die Records bleiben dabei im Quellsystemerhalten.Beim Lschen kommt es zu der Aufbewahrung des Metadaten-Stub.Aufzubewahrende Metadatenelemente des Stubs sind:

Lsch- oder Transferdatum Vollstndiger Klassifikationspfad (fully qualified classification

code) Titel Beschreibung Verantwortlicher Nutzer Grund fr die Lschung oder den Transfer

Chapter 6 Capturing Records

(Erfassung von Records)

6.1 Capture (Erfassung)Dabei handelt es sich zum einen um die Erfassung zusammengesetzterDokumente. Es geht um die Erhaltung der strukturellen Integritt und derBeziehung zwischen den Elementen. Beispiele sind Webseiten miteingebetteten Grafiken oder Textdokumente in Verbindung mitTabellenkalkulation.Zum anderen geht es um die nderung von Records bei der Erfassung.Die Anzeigbarkeit muss sichergestellt werden und eine Aufzeichnung imAudit Trail erfolgt. Die bernahme des Dateiformats in die Metadaten

erfolgt automatisch. MetadatenEs erfolgen eine automatische Metadaten-Extraktion bei ein- undausgehenden Dokumenten: Datum des Dokuments Empfnger Weitere Empfnger (Kopie) Betreff Verfasser Interne Referenz (unser Zeichen)

und eine Validierung der Metadaten: nach den Regeln des MoReq2 Metadaten-Modells Untersttzung fr Prfsummen-Algorithmen (check digit algorithms) Bereitstellung einer API zur Algorithmus-Einbindung ausreichendDie Speicherung von Records bei fehlenden Pflicht-Metadaten erfolgttemporr. Es sollten Schlagwrter angegeben werden und einkontrolliertes Vokabular verwendet werden.Weitere Funktionen sind die Erfassung eines Dokuments mit mehrerenVersionen (Deklaration aller Versionen als Record oder einer bestimmtenVersion als Record oder jeder Version als individuelles Record), die

untersttzte Klassifizierung (Vorschlge auf Basis der Inhalte, Metadaten,hufigsten Klassen) und Ad-hoc Workflows (berprfen und Akzeptieren



27/55

eines Dokumentes vor der Erfassung, Dokumentation und Begrndungder Entscheidung).Vermeidung von Mehrfach-Ablage und Inkonsistenzen ist mglich, da eineWarnung bei der Doppelerfassung auftritt. Zu identifizierende Metadatensind dabei Titel, Datum, Autor oder Adressat. Es gibt keine Vorgaben frdie Identifizierung von E-Mails. Die Zugriffsrechte werden bercksichtigt.Auerdem gibt es eine Warnung bei Erfassung eines unvollstndigen oderinkonsistenten Records.

6.2 Bulk importing (Massenimport)Bei dem Massenimport geht es um die berfhrung und Erfassung vonRecords aus anderen Systemen mit der Untersttzung frStapelverarbeitung, regelbasierte, automatische Erfassung und dieValidierung zu Erhaltung der Datenintegritt. Auerdem geht es um dieVerwaltung von Input-Queues und den Mit-Import der Audit Trails. Dabeierfolgt keine bernahme in das eigene Audit Trail. Es gibt eine separateAblage.

6.3 Email Management (E-Mail-Verwaltung)Das E-Mail-Management befasst sich mit der E-Mail-Archivierung von ein-und ausgehenden E-Mails. Es sind eine automatisierte Erfassung aller E-Mails und Anhnge, eine regelbasierte Erfassung und eine manuelleErfassung mglich.Im Rahmen des E-Mail-Managements geht es des Weiteren um dieIntegration der Erfassungsfunktionalitt in die E-Mail-Appliaktion(Drag&Drop von E-Mails aus dem E-Mail-Client) und den Erhalt derHeader-Informationen. AttachementsBei E-Mails mit Attachement werden unterschieden:

E-Mail Nachricht ohne Anhang E-Mail Nachricht mit Anhang in einem Record als verbundene

Komponenten E-Mail Nachricht und Anhnge als einzelne Records Automatische Verknpfung Nur die Anhnge als einzelne Records

Die Erfassung mehrerer E-Mails in einer Operation ist ebenso mglich wiedie automatische Erfassung zusammengehriger E-Mails. Automatische Metadatenerfassung

Bei der automatischen Metadatenerfassung werden die automatischeMetadaten-Extraktion und die Erfassung des Adressfeldes des Headersals Metadaten unterschieden. Kennzeichen der automatischenMetadaten-Extraktion sind:

Versanddatum / Versandzeit Alle Empfnger Alle Kopie-Empfnger Betreffzeile als Titel (Standard) Absender Eingebettete elektronische Signatur Zertifikat des Service Providers



28/55

Die Erfassung des Adressfeldes des Headers als Metadaten zeichnet sichdurch den optionalen Anzeigenamen und das adress-Spec-Feld aus.

6.4 Record Types (Record Typen, Record Klassen)Recordstypen beschreiben Eigenschaften, die nicht imKlassifikationssystem definiert werden:

spezielle Metadaten Attribute Retention Anforderungen Zugriffskontrollen Arten von Dokumenten Pflichtangabe fr jeden Record Definition von default-Werten (Standardtyp)

6.5 Scanning and Imaging (Scannen und Bildverarbeitung)Die Integration einer Scan-Lsung ermglicht monochromes und farbigesScannen. Es sind verschiedene Speicherformate wie beispielsweise TIFF,JPEG, PDF/A, mglich und es werden unterschiedliche Auflsungenuntersttzt. Eine Speicherung ist sowohl in Farbe als auch in Graustufenmglich. Weitere Merkmale sind die OCR/ICR Funktionalitt, Korrektur,Nachindizieren, Qualittssicherung und Massenscanverfahren. DieVerwaltung von Scan-Parametern fr Dokumenttypen und die Annotationsuntersttzung sind kennzeichnend fr Scannen undBildverarbeitung. OCRBei der OCR und Formularverarbeitung stellen Bild und OCR Text einenRecord dar. Der Text besteht dabei eher aus Metadaten als das er eineigener Record ist. Der Text ist fr den Anwender nicht zwingend

einsehbar.Bei der Formularverarbeitung gibt es die automatischeMetadatenerfassung und die automatische Klassifikation an Handerkannter Metadaten. ProtokollierungProtokollierungsdetails einer Scan-Session knnen sein:

Anwender Login Workstation-Identifikation Zeit und Dauer Session-Identifier Stapel-Identifier Anzahl der Dokumente Anzahl der gescannten Bilder Anzahl der gescannten Bilder nach dem Lschen von leeren

Seiten (bei automatischer Lschung leerer Seiten)

Chapter 7 Referencing

(Referenzierung)

7.1 Classification Codes (Klassifizierungskennzeichner)Bei der Erstellung oder Erfassung von

Klasse Ordner



29/55

Unterordner Band Record Komponente

erfolgt eine Zuweisung von Klassifikationskennzeichen. Eine Eindeutigkeitder vollqualifizierten Klassifikationskennzeichen (Fully-QualifiedClassification code) ist innerhalb der Hierarchie verpflichtend. EinKlassifikationskennzeichen ist ein Metadatenelement.Erstellung und Formate erfolgen ber eine automatische Generierung undZuweisung durch autorisierte Anwender oder durch externe Applikation.Es ist keine nachtrgliche Modifikation durch Anwender oder externeApplikation mglich.Die konfigurierbare Formatspezifikation ist fr jede Hierarchieebenedefinierbar und es gibt vollqualifizierte Klassifikationskennzeichen. EineVerkettung von Klassifikationskennzeichen wird durch Sonderzeichengetrennt.

7.2 System Identifiers (Systemseitig erzeugte eindeutige Identifizierungscodes)Identifizierung und ReferenzierungKennzeichen der Identifizierung und Referenzierung sind das SystemIdentifier, das fr die Verwendung der Software erforderlich ist, und dasKlassifikationskennzeichen (Classification Code), das der hierarchischeBezeichner fr Entitten der Klassifikationsschema-Hierarchie frAnwender ist.Zuweisung bei Erstellung:

Klassifikationsschema Klasse Ordner Unterordner Band Record Auszug eines Records Aufbewahrungs- und Aussonderungsregel Dokument

Eine Eindeutigkeit innerhalb der Klassifikationsschema-Hierarchie und derERMS-Instanz sind wichtig. Die Eindeutigkeit wird durch die Verwendungvon global eindeutigen Systemkennzeichen erreicht. Es gibtbeispielsweise die Prferenz:

UUID-Algorithmus ISO/IEC 9834-8 und ITU-T Rec. X.667 GUID (Globally Unique ID)

Andere Anstze sind DOI Digital Object Identifier System und URNUniform Ressource Name.Die Speicherung erfolgt als Metadatenelement.

Chapter 8 Searching, Retrieval and Presentation

(Suche, Abfrage und Prsentation)

8.1 Search and Retrieval (Suchen und Finden)



30/55

Suche und Abfrage gibt es fr Records, jede Zusammenfassung vonRecords (Klasse, Ordner, Unterordner, Band) und die zugehrigenMetadaten. Bekannte Suchtechniken sind die Metadatensuche(uneingeschrnkte Kombinationsmglichkeiten), die inhaltsbasierteSuche, die Schlagwortsuche und die Schlsselwrtersuche mitListenauswahl.Wichtige Funktionen sind:

Verfeinerungs-Funktion (Refine Search) Boolsche Operatoren Platzhalter (Wild Cards) Einschrnkung der Suche auf Ordner oder andere

Zusammenfassungen Thesaurus, gem Standards (ISO 2788, ISO 5964) Angabe von Zeitintervallen, auch natrlich-sprachig Anzeige der Anzahl der gefundenen Objekte Speichern und Verffentlichung von Suchanfragen

8.2 Presentation: Displaying Records (Bildschirmanzeige)Eine Darstellungsmglichkeit ist die Anzeige von Records. Dabei werdender Inhalt oder Metadaten per Mausklick oder Tastendruck angezeigt oderdie Anzeige von Records erfolgt aus Suchanfragen ohne Laden externerApplikationen heraus. Hier ist beispielsweise die Integration eines Viewer-Paketes denkbar.

8.3 Presentation: Printing (Drucken)Es sind Kopien aller druckbaren Records mit Metadaten, anderenadministrativen Informationen und die Festlegung von default-Metadaten

fr Ausdrucke mglich. Es knnen alle oder auch nur ausgewhlteMetadaten eines Objektes gedruckt werden. Ein Sammeldruck allerRecords einer Klasse, Ordner, Unterordner, Band ist ebenso mglich.Fr die Administratoren gibt es folgende Mglichkeiten des Ausdruckes:

Alle oder ausgewhlte administrative Parameter Aufbwahrungs- und Aussonderungsplne Ordnerbestand Alle oder einen Teil der Audit Trails Eine Liste der Inhalte aller geregelten Vokabularien Alle oder Teile des Klassifikationsschemas

8.4 Presentation: Other (andere Formen der Ausgabe)Andere Formen der Darstellung knnen nicht-druckbare Records und dieAusgabe auf geeigneten Medien wie beispielsweise Audio, Video oderspezielle Webseiten sein.

Chapter 9 Administrative Functions

(Administrative Funktionen)

9.1 General Administration (allgemeine Administration)Die Systemadministration ist fr das Management von Systemparametern

zustndig, also fr das System-Management und die System-Konfiguration. In den Bereich der Systemadministration fllt auerdem die



31/55

Benutzeradministration und sie ist sowohl verantwortlich fr die Vergabevon Funktionen an Anwender und Rollen als auch fr die Vergabe vonRollen an Anwender. Des Weiteren ist die berwachung desSpeicherplatzes und der Speichermedien diesem Bereich zuzuordnen. nderungen am KlassifikationssystemBei Massennderungen am Klassifikationssystem sind die Sicherung derVollstndigkeit und Korrektheit der Metadaten und Daten des Audit Trailsund folgende nderungsmglichkeiten Aufteilen einer Klasse in zwei neue Klassen Zusammenfhren von zwei Klassen Verschieben von Klassen Umbenennen von Klassen nderungen an den Zugriffsrechten nderungen der Aufbewahrungs- und Aussonderungsregeln

zu bercksichtigen.

9.2 Reporting (Berichterstellung)Es werden verschiedene Report-Typen unterschieden:

Management-Reports Statistische Reports Ad-hoc Reports Periodische Reports.

Als Darstellungsformen sind der Ausdruck, die Bildschirmanzeige und dieSpeicherung in elektronischer Form mglich.Die Funktionen des Reportings sind das Sortieren und Filtern, dieZusammenfassung, die grafische Aufbereitung und die Speicherung von

Reportanfragen zur Wiederverwendung.Die Inhalte des Reportings definieren sich ber die Anzahl und den Ortvon Ordnern, Unterordnern und Bnden (auch sortiert nachZugangsbeschrnkungen und Sicherheitsmarkierungen). Auerdemwerden die Records nach Dateiformat und Version sortiert und in denelektronischen Ordnern, Unterordnern und Bnden nach Gre oderSpeicherort abgelegt.Beim Reporting gibt es Quoten fr die Erfassung und Retrieval vonRecords, fr die Erstellung von neuen Klassen und Ordnern und fr denverbrauchten und freien Speicherplatz. Kennzeichnend sind auerdem dieAudit Trails, die Aussonderungsprozesse und die Export-Vorgnge.

9.3 Changing, Deleting and Redacting Records (ndern, Lschen und Redigierenvon Records)

Lschen kann entweder im Sinne von Zerstrung stattfinden oder imSinne von Aufbewahrung. Dabei erfolgt beim Lschen ein Eintrag in denMetadaten des Records, dass dieser aus der Kontrolle des Records-Managements entfernt wurde.Beim Lschen handelt es sich um eine Ausnahmefunktion, die einerstrengen Kontrolle der Lsch-Rechte unterliegt. Eine Dokumentationerfolgt im Audit Trail. Der Lsch-Schutz fr erfasste Records istkonfigurierbar.

Beim so genannten Redigieren werden Auszge aus bestehendenRecords ausgeblendet oder sensible Informationen entfernt. Es erfolgt



32/55

eine automatische Deklaration des Records und eine Klassifikationderselben Aggregation wie die Vorlage. Bei der Auszug-Erstellung sindeinige Informationen anzugeben:

Grund Sicherheitskategorie Optional: Aggregation zur Ablage einer Kopie des Auszugs

Kapitel 10 Optional Modules

(Optionale Module)Die Anforderungen in den optionalen Modulen beschreiben Funktionen,die in ein ERMS integriert werden knnen. Sie mssen imZusammenhang mit den Kernanforderungen betrachtet werden und einebedarfsabhngige Implementierung ist zu prfen.

10.1 Management of Physical (Non-electronic) Files and Records (Verwaltung nicht-elektronischer Ordner und Records)

Die integrierte Verwaltung nicht-elektronischer Records erfolgt in Records-Repositories. Nicht-elektronische Records knnen papierbasierteRecords, Records auf Microfiche oder Audio-Bndern oder digitaleRecords auf portablen Medien wie CD oder DVD sein. Auerdem zhlenPhysische Records, also alle Records auerhalb des ERMS dazu. Diessind beispielsweise eine CD mit Bildern, die nicht vom ERMS als einzelneRecords betrachtet werden oder eine CD mit Bildern, von denen jedesvom ERMS als Record betrachtet wird. Dies ist dann aber kein physischerRecord, sondern ein austauschbares Medium.Bei der Verwaltung von physischer Records kommt es zu einer

Festlegung von Klassen, Ordnern, Unterordnern oder Bnden, die als physische Container existieren. Es erfolgt einer Erweiterung derMetadaten um beispielsweise den Aufbewahrungsort oder die Informationber das Format des Containers oder Records. Fr eine sptereNachverfolgung von physischen Records sollten Angaben zumAufbewahrungsort, dem Verwahrer und dem Check-in/Check-out gemachtwerden. Auerdem gibt es eine Auswahlliste fr den Aufbewahrungsortund eine Erinnerung fr die Rckgabe. Es werden Barcodes, RFID etc.untersttzt und der Ausdruck von Labels fr die physischen Ordner undRecords ist mglich.

10.2 Disposition of Physical Records (Vernichtung physischer Aufzeichnungen)Die Aussonderung von Papier-Records vollzieht sich analog zurAussonderung von elektronischen Records. Es gibt eine Benachrichtigungbei Transfer, Export oder Lschen einer Entitt, die mit einem odermehreren physischen Records assoziiert ist.

10.3 Document Management and Collaborative Working(Dokumentenmanagement und kollaboratives Arbeiten)

Begriffsklrung EDMS / ERMSElectronic Document Management

SystemAn EDMS

Electronic Records Management

SystemAn ERMS



33/55

allows documents to be modified prevents records from being modifiedallows documents to exist in severalversions

allows a single final version of a recordtoexist

may allow documents to be deleted by

their owners

prevents records from being deleted

except In certain strictly controlledcircumstances

may include some retention controls must include rigorous retentioncontrols

may include a documentstorage structure, which may be underthe control of users

must include a rigorous recordarrangement structure (theclassificationscheme) which is maintained by anadministrative role

is intended primarily to supportday-to-day use of documents forongoing business

may support day-to-day working, but isprimarily intended to provide a securerepository for business records

AnforderungenUnter einem Dokument wird ein Objekt verstanden, das noch nicht alsRecord im ERMS deklariert wurde. Die integrierte Speicherung vonDokumenten und Records erfolgt in denselben Klassen und Ordnern, dieSpeicherung von Entwurfsversionen und finale Versionen in derselbenAggregation. Es gibt eine eindeutige, unterscheidende KEnnzeichnungvon Records und Dokumenten und eine Untersttzung der Records-Deklaration fr Dokumente als Massenoperation.Bei dem Versions-Handling werden drei Punkte unterschieden. Bei demCheck-in/Check-out mit Versionierung handelt es sich um einen nahtlosen

bergang vom EDMS ins ERMS und die Erfassung eines Dokumentes mitmehreren Versionen. Dabei kann es sich nur um die aktuellste Version,eine vom Anwender festgelegte Version, alle Versionen als ein einzigerRecord oder alle Versionen als einzelne, verknpfte Records handeln. Auerdem sind die Untersttzung fr eine Versionskontrolle und einpersnlicher Arbeitsbereich fr den Anwender zu nennen.

10.4 Workflow (Workflow, Geschftsprozessmanagement [Vorgangsbearbeitung])Im Workflow und Geschftsprozessmanagement gibt es vordefinierteWorkflows, Ad-hoc Workflows und Standards. Letztere ermglichen eineKompatibilitt mit dem WfMC Workflow Management Coalition Reference

Model und den Export in ein Standard-XML-Schema.Die Anwender Untersttzung ist durch ein grafisches Interface zurDefinition, Pflege und Bearbeitung, eine Auswahlliste fr Workflow-Schritte, eine Auswahl der Teilnehmer nach Name, Rolle oderOrganisationseinheit, das Speichern von Workflows fr dieWiederverwendung und letztendlich durch die automatischeVersionsverwaltung gekennzeichnet.Wichtige Funktionen sind:

Benachrichtigung fr Postkorb-Eingang Wiedervorlage (tickler) Benachrichtigungsfunktionalitt

berwachung des Workflowfortschritts Auflistung von zugewiesenen Arbeitsanweisungen



34/55

Bedingte Verzweigung des Workflow anhand vonAnwendereingaben oder Systemdaten

Priorisierung von Elementen in der Warteschlange Rendezvous-Verarbeitung Automatisiertes Starten von Workflows z.B. fr Record-Typen

10.5 Casework (Fallbearbeitung, [Vorgangsbearbeitung])Unter einer Fallakte werden Ordner zu einer oder mehreren strukturiertenTransaktionen, die das Ergebnis eines konkreten Prozesses oder einerkonkreten Aktivitt sind. Strukturierte Transaktionen folgen vorgegebenenRegeln und einem konsistenten Prozess. Sie werden in vielen Instanzenhnlicher Transaktionen wiederholt.Die vorhersagbare Ablagestruktur ist gekennzeichnet durch die Abbildungin Unterordnerstruktur und sie ist meist Vorlagen-basiert. Die Vorgangs-und Fallbearbeitung bentigen in der Regel kein stark strukturiertesKlassifikationssystem und sind oft abhngig von Workflows.

Beispiele fr Fallakten sind Ordner mit Records ber Regulative berwachung Regulative berwachung Reklamations- und Beschwerde-Management Passausstellung Untersuchung eines Vorfalls Personalbestand

10.6 Integration with Content Management Systems (Integration mit Web ContentManagement Systemen (CMS/WCM))

Charakteristische Funktionen eines CMS/WCM sind die Verffentlichungvon Informationen (Webseiten, Portale), das Management vonInformationen aus verschiedenen Quellen und die Umformatierung vonInformationen. Auerdem zeichnet es sich durch das Verbinden derverschiedenen Versionen, Darstellungsformen und bersetzungen einesDokumentes und das Management der Komponenten eines Dokumentesaus.Im Rahmen der ERMS-Integration erfolgt der Transfer von Kopien vonRecords inklusive einiger Metadaten in ein CMS, die Erfassung vonInhalten aus dem CMS und die Erfassung einer oder mehrerer Webseitenals Records.

10.7 Electronic signatures (Elektronische Signatur)Die Kernpunkte im Bereich der Elektronischen Signatur sind:

Erfassung und ggf. Verifizierung von elektronischen Signaturenzum Erfassungszeitpunkt

Speicherung von zugehrigen elektronischen Zertifikaten Speicherung von Details der Certification Service Providers Verifikations-Metadaten fr elektronisch signierte Records Standard-basiertes Interface (z.B. XKMS XML Key Management

Spec) Sicherstellung der Erhaltung der Integritt von Records mit

elektronischen Signaturen



35/55


36/55

10.13 Security Categories (Sicherheits- /Zugriffsschutz-Kategorien)Es gibt die Verwaltung von Sicherheitskategorien undSicherheitsfreigaben, die ber die Zugangskontrollen hinaus gehen. DieZuordnung zu den Sicherheitskategorien erfolgt zu den Klassen, Ordnern,Unterordnern, Bnden oder einzelnen Records. Unterkategorien solltensich dabei einem kontrollierten Vokabular fr die Benennung bedienenund sich mindestens eine Unterkategorie mit einer mindestensfnfstufigen Zugriffshierarchie bedienen.

Chapter 11 Non-Functional Requirements

(Nicht-funktionale Anforderungen)Die Non-Functional Requirements sind kein Teil des Zertifizierungstests.Sie sind lediglich als Leitfaden gedacht.

11.1 Ease of Use (Benutzerergonomie, Einfachheit der Benutzerfhrung)Beispielanforderungen fr die Benutzerfreundlichkeit sind:

Eingeschrnkte Anzeige des Klassifikationsschemas fr dieNutzer

Kontext-sensitive Online-Hilfe Grafische, navigierbare Anzeige des Klassifikationsschemas in

hierarchischer Form Aussagekrftige Fehlermeldungen Gleichzeitige Anzeige mehrerer Records Anpassung der Oberflche durch den Anwender Liste der Metadatenelemente zur Dateneingabe Enge Integration mit dem E-Mail-System Favoriten-Funktion Einfache Erreichbarkeit von hufig ausgefhrten Aktionen

11.2 Performance and Scalability (Performanz und Skalierbarkeit)Zur Performanz und Skalierbarkeit zhlen angemessene Antwortzeiten,einzuhaltende Maximalzeiten fr Suchanfragen, Maximalzeiten fr dieAnzeige der ersten Seite, Speichergre, Benutzerzahlen, Erweiterbarkeitbei laufendem Betrieb usw.

11.3 System Availability (Systemverfgbarkeit)Hierzu gehren

Angabe der Verfgbarkeitszeiten Angabe der max. akzeptierten Ausfallzeiten etc.

11.4 Technical Standards (technische Standards)Technische Standards erfordern weitere Angaben fr weitere Anforderungen durch den Benutzer. Die Angaben knnen aus denBereichen Hardwareumgebung, Betriebssytemumgebung,Softwarearchitektur der Arbeitsplatzrechner, Benutzeroberflche,relationale Datenbank und Schnittstelle, Netzwerkprotokoll und-betriebssystem, Standards fr den Informationsaustausch und APIs und

Developer-Kits stammen.



37/55

11.5 Legislative and Regulatory Requirements (rechtliche und regulative Vorgaben)Im Rahmen der rechtlichen und regulativen Anforderungen kommt es zulokalisierungen in Kapitel 0. Beispaielanforderungen dafr sind dieKonformitt mit Standards zur juristischen Zuverlssigkeit und Beweiskraftvon elektronischen Dokumenten, die Konformitt mit der RecordsManagement-Gesetzgebung, keine Verletzung von Anforderungen an dendeutschen Datenschutz oder die Informationsfreiheit und Compliance mitbranchenspezifischen regulative Anforderungen, Richtlinien oder Codes ofPractice.

11.6 Outsourcing and Third Party Management of Data (Outsourcing)Outsourcing und externe Datenverwaltung findet unter anderem durchexterne Service-Anbieter, Application Service Provider oderVertragsanforderungen nach ISO 15801 (Service Level Agreements) statt.Im Rahmen des Outsourcings und der externen Datenverwaltung kommtes des Weiteren zur Bestimmung der Details des Transports von Records.

11.7 Long Term Preservation and Technology Obsolescence (Langzeitarchivierungund technische Veralterung)

Unter Langzeit versteht man in der Regel Zeitrume von mehr als 10Jahren. Es sind mehrere Jahrzehnte oder sogar Jahrhunderte mglich.Die Risiken sind der Verfall der Speichermedien, die Veralterung derHardware und Formate und die detaillierten Angaben in ISO 18492. Eswerden zustzliche Metadaten fr die Langzeitarchivierung bentigt. Diessind Daten zur technischen Umgebung, Software fr Erstellung undDarstellung und die ISO 14721 OAIS Open Archive System referencemodel als Richtlinie.

11.8 Business ProcessesProzessorientierte Funktionen der Anwendung ermglicht ein einfachesInitiieren einer Funktion eines Prozesses. Es ist keine Neueingabe vonbereits eingegebenen Daten notwendig und am Ende der Funktion erfolgtdie Wahl des Anwenders. Er kann sich zwischen dem Abbruch desOriginalprozesses und dem Wiedereinstieg in den originalen Prozessentscheiden. Die Integration aller Fhigkeiten eines eventuellvorhandenen Thesaurus ist mglich.

Chapter 12 Metadata Requirements(Metadaten Anforderungen)

12.1 Principles (Prinzipien; siehe die Diagramme)Das Metadatenmodell beinhalt folgende Entitten:

Classification Scheme Class File Sub-file Volume Record

Record Extracts Metadata Stubs



38/55

Record Type Component Rendition Retention and Disposition Schedule Disposal Hold

12.2 General Metadata Requirements (Allgemeine Metadaten Anforderungen)Generelle Anforderungen an Metadaten sind unter anderem, dass es eineunbegrenzte Anzahl von Metadaten-Elementen gibt und die Nutz

Documents

[DE] MoReq & MoReq2 | Model Requirements for the Management of Electronic Records | 2009