What recordkeeping functionality do business systems need to provide? December 13, 2012
Functional requirements
http://www.flickr.com/photos/webatelier/5929855686/
Janet Knight and I were having a conversation the other day about what it is that recordkeeping systems are supposed to do. We were asking what are the functional requirements for recordkeeping that should be incorporated into business system design or development to support recordkeeping, or used to assess business systems from a recordkeeping perspective.
This is our first very drafty of a set of high level requirements. We would really love your comments, criticism and advice.
We would really like your advice on what types of functionality do you think need to be baked into systems, or considered at system development and implementation, to better support recordkeeping? What have we left out? Where do we need to be more specific? What makes sense in our list and what does not? What is feasible? What’s a priority? What other types of requirements sets do we need to consider? For example, what are statements that need to be included in contracts with cloud service providers? Shared service providers? Project collaborators? As usual, we would love your advice.
We have separated the requirements into three types – one that applies to the organisation, others that would be assessed at a whole of system level, and others that would be assessed against records themselves.
The whole list comes with the proviso that if a business system is not able to meet these requirements, records should be exported out of this environment and into an environment that is able to meet the requirements.
Here are our very initial suggestions, which are based in part on preliminary assessments of:
- ISO 16175
- ISO 15489
- the superseded but still lovely AS 4390
- State Records Standard on Full and Accurate Records, and
- the Pittsburgh Project’s Functional Requirements for Evidence in Recordkeeping
Organisational level requirement
Requirement: The organisation must commit to sustaining business information for as long as it is required
Explanation: Many business records will have a lifespan beyond the system in which they are created and managed.
To sustain business information, the organisation must be committed to migrating systems and the records they contain, or the export of long term value business records, along with their relevant metadata, into new business applications as and when required.
Plans for sustaining business information and migrating into new systems should be developed in conjunction with records staff.
System level requirements
Requirement: The system must create and keep defined records
Explanation: The system must be able to create and keep the records that are required to support and document the business performed within the system.
Records staff can help to define what these records are, in liaison with the system owner and relevant business staff.
Requirement: The system must be well documented
Explanation: Documentation of system configuration, metadata design, system customisation and enhancement must be documented and maintained.
This documentation is needed to understand and manage the information within the system and to assist with any necessary system migration or record export.
Requirement: The system must be migratable, or able to export records and their metadata as required
Explanation: Many business records will have a lifespan beyond the system in which they are created and managed.
To enable records and their supporting contexts to be carried forward into new operating environments, or to remove them from environments where they are not adequately protected and managed, systems must be able to be migrated or must be able to export records and their associated metadata.
Requirement: The system must support the metadata that is required for business and management purposes
Explanation: The system must support the metadata that the business needs for its operations. The system must also capture and support recordkeeping metadata which enables records to be managed and interpreted now and over time. Where possible, metadata should be system-generated.
Requirement: Where appropriate, the system must be able to implement appropriate security controls
Explanation: The system should incorporate safeguards to limit who can view or access records and their metadata. The system must also have the capacity to control the ability to perform specific processes, or to track actions that individuals or groups can take (e.g. viewing, printing, editing, copying, transmitting). Systems must not allow unauthorised modification of records or their metadata.
Requirement: Where appropriate, the system must enable the destruction of time-expired information
Explanation: The system needs to be able to destroy records and some associated metadata in a systematic, auditable and accountable way in line with business and legal requirements, while maintaining the accessibility, trustworthiness and useability of records with ongoing business relevance. No records should be able to be deleted or removed from the system without appropriate authorisation.
Requirement: The system must produce necessary reports
Explanation: The system needs to be able to produce reports that are required by the business or that are required to monitor information destruction storage and use.
Records level requirements
Requirement: Records must be accessible
Explanation: For the life of the system, the records required by the business must be able to be searched for and accessed by authorised staff. The system needs to be able to support full search functionality and support the metadata fields that staff will require for searching. The system also needs to make records available in useable, human-readable form. Note: Backups are not suitable systems for maintaining the accessibility of high risk or long term records.
Requirement: Records must be protected
Explanation: Staff need to be able to trust that the records they access will be authentic, well managed, accurate representations of the business performed. The system needs to capture fixed, point-in-time records and be able to protect these and track their use and management so that the integrity of the records is supported. The records and their metadata must not be altered, including during migration. Records must be protected from accidental or intentional damage and destruction from modification.
Requirement: Records must be meaningful
Explanation: Records must be able to be interpreted and used for ongoing business. The system must support the ability to capture and maintain relevant metadata that describes the business that the record documents, when the business was transacted and the staff involved. It needs to create connections between related records so that a complete picture of the business operations can be compiled, and enable records to be copied and reused for future business.
Requirement: Records must be maintained
Explanation: Records must be kept by the system for as long as they are needed by the business, and in accordance with legal requirements.
Dear Kate, I would suggest some editorial remarks:
There is “usual” terminology question: do you understand the term “migration” according to ISO 15489:2001 (that’s what I think) or according to ISO 30300:2011 (and possibly future edition of ISO 15489)? In the latter case, “conversion” might be more appropriate term.
IMHO export of records together with their metadata is a variant of migration, isn’t it?
IMHO it’s worth emphasizing that certain requirements may be met by using organizational measures (or combination of technology and organizational measures).
In system-level requirement 2, explanation – language could be improved: Now it says “Documentation … must be documented and maintained”. Do you actually mean documenting the documentation? :) IMHO it would be better to say “Documentation on… must be created and kept up-to-date” (note that maintaining documentation doesn’t automatically mean updating it).
System-level requirement 3 IMHO should be stronger. Migration/export might be possible, but at a huge cost and with great effort. Require, at least, the possibility to migrate with “reasonable” effort and expenses.
In system-level requirement 3, explanation, I would suggest to replace “records and their supporting contexts” with IMHO more understandable “records and their metadata”.
In system-level requirement 5, explanation, it says; “view or access records”. IMHO viewing is a form of access.
In system-level requirement 5, explanation, it says: “Systems must not allow unauthorized modification”. Strictly speaking, that’s wishful thinking – especially for business systems. More realistically, the systems should not allow such modifications to go undetected.
In system-level requirement 6, IMHO it would be beneficial (especially for the readership with IT background) to replace “time-expired information” with “information with expired retention periods”!
In the last one system-level requirement, explanation, insert missing comma in “destruction storage”. I would recommend to reorder: “storage, use and destruction”.
In record-level requirement 1, explanation, who do you mean by “full search functionality”?
In record-level requirement 2, explanation, there is humorous statement “The records and their metadata must not be altered, including during migration”. Poor wording, eh? :)
In record-level requirement 2, explanation, I would change “damage and destruction from modification” to simply “damage and destruction”.
With my best wishes,
Natasha Khramtsovsky
All common sense stuff.
Maybe I am biased (because I worked on their development), but some of the requirements you have identified are reflected in the National Archives of Australia’s Digital Continuity Principles [http://naa.gov.au/records-management/agency/digital/digital-continuity/principles/index.aspx]
Hi John – Nice to hear from you. Thanks for your comment and it’s a good point you make. It has been a little while since I looked at the NAA’s excellent Digital Continuity Principles but you are right, they reflect so much of what we are talking about here. Thanks for listing them as another important reference point. Cheers, Kate
Dear Natasha – thanks for these detailed, excellent comments. We want to revise our suggested list of recordkeeping functionality in the new year and will use all your recommendations to clarify and extend our list. Thank you! Best wishes, Kate