Good morning,

              Module 2: Guidelines and Functional                 Adrian has given an overview of the proje...
Slide                                                                     •   Not all jurisdictions feel that they need a ...
Slide                                                                 The modules are into four main parts:
26            ...
Slide     Aggregation levels: 3 basic levels
31            of records aggregation                                         ...
Upcoming SlideShare
Loading in …5
×

RMAA Adelaide Bringing it all back home Slide Notes

385 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
385
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

RMAA Adelaide Bringing it all back home Slide Notes

  1. 1. Good morning, Module 2: Guidelines and Functional Adrian has given an overview of the project process but in Requirements for Electronic Records Management Systems order to give some context to the rationale for the Stephen Clarke, Senior Advisor development of module 2 is it necessary to look at the Digital Continuity Archives New Zealand international environment and the consultation process. There is nothing ground breaking or new in module 2 it is an attempt to rationalise at a non granular level what functional requirements are needed to implement an EDRMS successfully Slide We identified a plethora of standards for electronic 18 recordkeeping This example is the situation with metadata from university of Montreal Slide Although there a bewildering multiplicity of standards there 19 De Facto Global Standards? does seem to be an emerging suite of de facto standards • United States of America Department of Defense Design Criteria Standard for Electronic Records Management regionally and convergence is the current theme. Software Applications 5015.2 – 5015.3 was under development • European Union MoReq (Model Requirements for the Management of Electronic Records – MoReq2 was under development We need a united front when trying to influence the global • PROV’s Victorian Electronic Records Standard software market and a consistent message to enable – VERS was being reviewed practitioners in all jurisdictions to build a case for inmplementing software with records management functionality Slide In the European theatre MoReq2 is becoming the recognised 20 European Standards regional primary standard in e-recordkeeping. • Germany’s DOMEA Concept Requirement Catalogue Thw individual players if not giving up their jurisdiction • Norway’s NOARK 4 Norwegian Recordkeeping System: Functional Description and Specification of specific standard such as the UK are making their standards Requirements • National Archives of Denmark FESD-standard align with MoReq with Denmark being a recent example • United Kingdom The National Archives Requirements for Electronic Records Management Systems Slide The Asia Pacific region is no different in that it has taken a 21 Asia Pacific country or state specific approach. • The Republic of China (Taiwan) National Archives Administration Records Management Information System Validation Mechanism and Procedures • NAA’s Designing and Implementing Recordkeeping However it is interesting that Malaysia has adopted the ICA Systems (DIRKS) • Archives NZ’s Electronic Recordkeeping Systems wholesale. Standard (ERKSS) • South Australian EDRMS Functional Compliance This standard is ADRI approved so can we as RMers Requirements Specification (Adequate Records Management Standard) challenge our jurisdictions to move toward convergence and adopt a single Australasian standard?
  2. 2. Slide • Not all jurisdictions feel that they need a specifically 22 Mandatory with Compliance Testing? tailored testing regime as we can see from the • The standard was not intended to be a set of mandatory requirements European model • It was not intended to be part of a compliance testing regime • We felt a outcomes based standard was required • It was not intended to be exhaustive • The one existing standard that was not in this mould without a high level of complexity either was Archives New Zealand's ERKSS (although based largely on MoReq) • Having jurisdiction specific testing regimes would not prevent the adoption of this standard Slide • We identified the need for a single set of ‘standards’ Objectives 23 for electronic records in the international archives and • We identified the need for a single set of ‘standards’ for electronic records in the international archives and records community records community • The main driver is to communicate consistent messages to the global software market and the broader records • The main driver is to communicate consistent management community • This project would be a resource for jurisdictions who messages to the global software market and the have not yet developed their own national / state standards, or lack the resources do so broader records management community • We needed international agreement to achieve this • This project would be a resource for jurisdictions who have not yet developed their own national / state standards, or lack the resources do so • We need international agreement to achieve this Slide • It is not our intention to create a competing set of 24 Relationship with other standards requirements at the granular level with other • It is not our intention to create a competing set of requirements at the granular level with other standards, e.g. MoReq2, DoD 5015.2, etc. and this is standards, e.g. MoReq2, DoD 5015.2, etc. and this is why the functional requirements for the modules are pitched at a high level outcomes approach why the functional requirements for the modules are • The working group has proposed the development of the Modules as an ISO Standard/Technical Report, pitched at a high level outcomes approach through ISO TC 46/SC 11 – Balloting is underway • The working group has proposed the development of the Modules as an ISO Standard/Technical Report, through ISO TC 46/SC 11 • A modular approach to development was proposed with Modules 1 & 2 fast tracked and Module 3 to go through the usual development process. Slide Module 2: Guidelines and Functional We felt however that this work to set a global standard for 25 Specifications for ERMS EDRMS should be freely available especially to jurisdictions who are not well resourced both in terms of technical capability but also in time and economic resources. Not all standards are free and also some of them are so dense and complex that a high level of technical expertise is required. If this level of granularity is desired then the more complex products such as MoReq and DoD can be employed. The key point is we are all building on the same underlying principles.
  3. 3. Slide The modules are into four main parts: 26 Structure of module 2 • Part 1: Introduction – explains the scope, purpose, audience The modules are into four main parts: and structure of the document • Part 1: Introduction – explains the scope, purpose, audience and structure of the document • Part 2: Guidelines – provides an overview of the module’s • Part 2: Guidelines – provides an overview of the module’s conceptual basis and presents a high-level model. Describes key terms and concepts, and conceptual basis and presents a high-level model. Describes outlines the framework of Part 3: Functional requirements key terms and concepts, and outlines the framework of Part 3: Functional requirements Slide • Part 3: Functional requirements – provides a tabulation of 27 Structure of module 2 (cont.) the records management functional requirements and forms Part 3: Functional requirements – provides a tabulation of the records management functional the records management functional requirements for system requirements and forms the records management functional requirements for system assessment or assessment or procurement procurement • Part 4: Appendices – provides a glossary of key • Part 4: Appendices – provides a glossary of key terms, terms, additional readings and a sample checklist of requirements for reviewing an existing electronic records management system additional readings and a sample checklist of requirements for reviewing an existing electronic records management system Slide Module 2 articulates a set of functional requirements for 28 Purpose of Module 2 electronic records management systems, it: Module 2 articulates a set of functional requirements for electronic records management systems, it: • Explains processes and requirements for • Explains processes and requirements for identifying and managing records in electronic records identifying and managing records in electronic management systems records management systems • Sets requirements for records management functionality to be included in a design specification • Sets requirements for records management when building, upgrading or purchasing electronic records management systems software functionality to be included in a design specification when building, upgrading or purchasing electronic records management systems software Slide • Informs records management functional 29 Purpose of Module 2 requirements in the selection of commercially • Informs records management functional requirements in the selection of commercially available electronic available electronic records management records management systems systems • Gives a basis for reviewing records management functionality or assessing compliance of existing • Gives a basis for reviewing records electronic records management systems management functionality or assessing compliance of existing electronic records management systems Slide Part 3: Functional Requirements Part 3: Functional 30 Requirements The requirements are grouped according to the clusters The requirements are grouped identified in the high-level model: according to the clusters identified in the high-level model: • Create • Create • Maintain • Maintain • Disseminate • Administer • Disseminate • Administer
  4. 4. Slide Aggregation levels: 3 basic levels 31 of records aggregation 1. Hierarchical relationships of the processes that occur in business are reflected through a business being undertaken (a Business Classification Scheme) 2. Hierarchical relationships through descriptive standards and metadata relationships using metadata inheritance but also that the records may not be stored or arranged in this order with the EDRMS storage system. 3. These relationships are maintained through metadata not necessarily maintained in a tree structure. In the modern recordkeeping world individual records may have multiple relationships but is not necessary to make multiple copies within a highly structured one to one connection records may have many simultaneous interrelationships through its embedded metadata profiles. Slide Not thee as the ISO model of Shall etc. be felt this model Three Obligation levels 32 • The keywords ‘must’, ‘should’ and ‘may’ indicate the worked well for this approach as not all decisions in relative importance of each requirement. implementing RM are yes/no often they are conditional Must – requirements that use ‘must’ an absolute requirement for compliance with the requirement. Should – requirements that use ‘should’ may be ignored if a valid reason exists, but the full implications of this must be understood and carefully considered. May – requirements that use ‘may’ are truly optional and may be incorporated or omitted as appropriate. Slide Obligation levels example It is a requirement that all records must have a unique 33 identifier, however this excerpt from the section dealing with classification structure illustrates this concept Slide Appendix C: Self assessment tool Respondents wanted a self assessment tool so we added one 34 along with other appendices to support the requirements element.

×