Your SlideShare is downloading. ×
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Ica Adri Module 2 Presentation Kl Stephen Clarke
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ica Adri Module 2 Presentation Kl Stephen Clarke

597

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
597
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Guidelines and Functional Requirements for Electronic Records Management Systems Stephen Clarke, Acting Manager Government Recordkeeping Programme Archives New Zealand
  • 2. ICA/ADRI Principles and Functional Requirements for Records in Electronic Office Environments project
    • We identified the need for a single set of ‘standards’ for electronic records in the international archives and records community
    • The main driver is to communicate consistent messages to the global software market and the broader records management community
    • 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
  • 3. International consultation
    • The modules were made available on both the ADRI and ICA websites
    • We asked our working group members (representing 11 nations) to raise the profile in their own jurisdictions and further afield
    • Exposure period from February to March 2008
    • The NAA took the lead in collating the comments
  • 4. Feedback on Exposure Drafts
    • We received 15 sets of comments from 7 countries:
    • Australia
    • (Public Record Office Victoria, Docbanq, Barbara Reed, Tasmania Department of Treasury and Finance, Tower Software, Productiv Corporation, Royal Hobart Hospital, Queensland Government Chief Information Office)
    • Canada (Delegation to ISO TC46/SC11)
    • Denmark (National Archives)
    • Japan (Japanese Standards Association)
    • New Zealand (Archives New Zealand and CIO)
    • South Africa (Marcelle Blasl, National Archives SA)
    • United States (ARMA International)
    • France (UNCFACT Working Group/EIC)
  • 5. Relationship with other standards
    • 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 why the functional requirements for the modules are pitched at a high level outcomes approach
    • 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.
  • 6. Module 2: Guidelines and Functional Specifications for ERMS
  • 7. Structure of module 2
    • The modules are into four main parts:
      • • Part 1 : Introduction – explains the scope, purpose, audience and structure of the document
      • • Part 2 : Guidelines – provides an overview of the module’s conceptual basis and presents a high-level model. Describes key terms and concepts, and outlines the framework of Part 3: Functional requirements
      • • Part 3 : Functional requirements – provides a tabulation of the records management functional requirements and forms the records management functional requirements for system assessment or procurement
      • • Part 4 : Appendices – provides a glossary of key terms, additional readings and a sample checklist of requirements for reviewing an existing electronic records management system
  • 8. Purpose of Module 2
    • Module 2 articulates a set of functional requirements for electronic records management systems, it:
      • Explains processes and requirements for identifying and managing records in electronic records management systems
      • Sets requirements for records management functionality to be included in a design specification when building, upgrading or purchasing electronic records management systems software
      • Informs records management functional requirements in the selection of commercially available electronic records management systems
      • Gives a basis for reviewing records management functionality or assessing compliance of existing electronic records management systems
  • 9.
    • The requirements are grouped according to the clusters identified in the high-level model:
      • Create
      • Maintain
      • Disseminate
      • Administer
    Part 3: Functional Requirements
  • 10. Aggregation levels: 3 basic levels of records aggregation
  • 11. Three Obligation levels
    • The keywords ‘must’, ‘should’ and ‘may’ that appear in the requirements in Part 3 indicate the relative importance of each requirement. These keywords are to be interpreted as follows:
      • • Must – requirements that use ‘must’ are necessary 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 before choosing a different course.
      • • May – requirements that use ‘may’ are truly optional and may be incorporated or omitted as appropriate.
  • 12. Obligation levels example
  • 13. Appendix C: Self assessment tool
  • 14. Online access to the modules
    • 1. Overview and Statement of Principles http://www.ica.org/en/node/38972
    • 2. Guidelines and Functional Requirements for Electronic Records Management Systems http://www.ica.org/en/node/38970
    • 3. Guidelines and Functional Requirements for Records in Business Systems
    • http://www.ica.org/fr/node/38968
  • 15.
    • Questions?
    [email_address]

×