Module 2 provides guidelines and functional requirements for electronic records management systems. It aims to rationalize at a high level what functional requirements are needed to implement an EDRMS successfully. The document structures the requirements according to clusters for creating, maintaining, disseminating and administering records. It also provides obligation levels for the requirements and includes appendices like a self-assessment tool to support the guidelines. The overall goal is to communicate consistent messages to the global software market about electronic records management.

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. 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. 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. 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.