Victorian Electronic Records StrategyStage 2

Public Record Office Victoria

Initial Functional Specification Outline

11 June, 1998

Victorian Electronic Records Strategy: Stage 2 Initial Functional Specification Outline

1

CSIRO

1. IntroductionThese functional specifications are initial descriptions of specifications that are derived fromthe process maps and a developing understanding of electronic records archiving. We expectthat they will change as our understanding further develops. It is important also to note thatthese specifications are fairly comprehensive in nature and we would not expect that all ofthese specifications would need to be satisfied in all circumstances to achieve successfulelectronic records archiving.

The requirements have been organised into:• workflow requirements• document management requirements• records management requirements• archival requirements

It is important to note that this specification lists only those functions needed to supportarchiving, and not the many other purposes that documents and records have. It is alsoimportant to note that many current systems will support requirements from more than one ofthese categories, and that we are using these categories for explanatory purposes only.

2. Workflow RequirementsIn order to capture electronic records, mechanisms are needed to enable relevant records to bereliably obtained through the business processes. If the business process is supported by aworkflow system, this section lists the functions that the workflow system must support toimplement electronic records capture.

2.1 Encapsulation of Business ProcessThe workflow system encapsulates, implements, and possibly enforces the businessprocesses. This includes Record creation points etc.

2.2 Document Capture InterfaceThis provides a structured input mechanism for document capture.

2.3 Metadata Capture InterfaceThis provides a structured input mechanism for metadata capture.

2.4 NotificationNotifications may be generated when a new workflow is created or ends. Notifications may begenerated when documents change status, or if a document remains in a certain state for agiven period of time.

2.5 Record Creation FunctionalityThe workflow processes should automatically convert documents into records when required.

Victorian Electronic Records Strategy: Stage 2 Initial Functional Specification Outline

2

CSIRO

2.6 FormsThe workflow system may need to replicate existing agency forms. Individual workflows mayuse many different forms.

2.7 AuthorisationThe workflow system should support secure authorisation mechanisms.

2.8 Universal Unique Object NumberingCertain objects require identifiers that are unique across an agency, and effectively across allVictoria Government. This would apply to both files and documents.

2.9 Document TrackingDocuments that are part of the workflow system need to be tracked. This may includetracking individual documents, groups of documents, document versions etc.

2.10 Document Status TrackingThe status of documents within the workflow system needs to be tracked. Changes indocument status may trigger further workflow actions.

2.11 Automatic Metadata/Data GenerationWhere possible, probably as part of metadata capture, required metadata should beautomatically generated. This may be done from the document, the creating application, otherdocument metadata, EDMS or from the RMS.

2.12 Metadata ControlThis would be done using Thesauri and/or Pick List type functionality.

2.13 Document Linking/AssociationThe workflow system must support the ability to link or associate documents with otherdocuments or files.

2.14 Inclusion of Scanned Paper DocumentsThe workflow system must allow for storage of scanned paper documents, including relevantmetadata.

2.15 Inclusion of Office/Desktop DocumentsThe workflow system must allow for storage of electronic documents created byoffice/desktop products, including relevant metadata.

Victorian Electronic Records Strategy: Stage 2 Initial Functional Specification Outline

3

CSIRO

2.16 EDMS Integration CapabilitiesThe workflow system must be able to retrieve information (pick lists, metadata, documentsetc) from the EDMS system.

2.17 RMS Integration CapabilitiesThe workflow system must be able to retrieve information (pick lists, metadata, documentsetc) from the RMS system.

2.18 Retrieval of Records from the RMSThe workflow system may require access to records that have been stored in the RMS, andnot kept within the workflow system. The workflow system must be able to retrieve thesedocuments.

3. Document Management Requirements

3.1 Universal Unique Object NumberingCertain objects require identifiers that are unique across an agency, and effectively across allVictoria Government. This would apply to both files and documents.

3.2 Document StorageDocuments will need to be stored. Documents will be stored in their original format. It maybe necessary to store archival format as well.

3.3 Document Level Access LogsThe workflow system may need to log access by user to individual documents that are underit's control.

3.4 Document Level Access ControlIt should be possible to control access to a documents at several levels. To minimizemanagement overheads, it is necessary to control access to groups of documents (e.g. alldocuments in a department), while to allow for exceptions it is necessary to be able to specifyaccess controls to individual documents.

3.5 Document Integrity AssuranceThe workflow system must be able to provide protection for the integrity of documents andmetadata that it holds in storage.

Victorian Electronic Records Strategy: Stage 2 Initial Functional Specification Outline

4

CSIRO

4. Records Management Requirements

4.1 Universal Unique Object NumberingCertain objects require identifiers that are unique across and agency, and effectively across allVictoria Government. Within this part of the system, this would apply to Files and Records.

4.2 File CreationAbility to create files.

4.3 Record StorageThis includes storage of the native/original document, and the document metadata.

4.4 Record Access LogsAs for documents.

4.5 Record Access ControlAs for documents.

4.6 Automatic Metadata/Data GenerationAs for documents.

4.7 Record Linking/AssociationAs for documents.

4.8 Management of Thesauri, Pick Lists, Agency RecordIdentification System, Universal Unique Object Numberingetc

All this data should be managed. This information may need to be transformed into findingaids.

4.9 Discovery FacilitiesRecords should be searched or browsed by record/file metadata, record content, and links.

4.10 Conversion of Records into Standard Format ElectronicRecords

Conversion of documents and metadata into Long Term Storage Format.

Victorian Electronic Records Strategy: Stage 2 Initial Functional Specification Outline

5

CSIRO

4.11 Reliability and RedundancySystem reliability and redundancy should be guaranteed using techniques such as RAID5,Transactional Database functionality, Backup, UPS, Clustering, Online spares.

5. Archival Requirements

5.1 ArchivingRecords and files must be converted to a format suitable for long term storage. The ArchiveSystem must indicate when it has taken responsibility for the preservation of a file or record(so that the RMS or EDMS can remove its copy of the file or record). If the file or record hasnot been written to Long Term Storage Media when responsibility is accepted, the ArchiveSystem must manage the file or record so that it cannot be lost.

5.2 Universal Unique Object NumberingCertain objects require identifiers that are unique across and agency, and effectively across allVictoria Government. This would apply to Files and eRecords.

5.3 Storage on Long Term Storage MediaWithin the Repository, electronic records must be written onto Long Term Storage Media.

5.4 Finding AidsThe Archival System must support the creation, storage, and use of finding aids. Finding Aidsdescribe the functions of agencies and the organisation of records within the agencies. FindingAids include information about the records (e.g. thesaurus, pick lists, data dictionaries).

5.5 DisposalThe Archival System must support the creation, storage, and use of disposal schedules. Theschedules will apply to files in the archive.

5.6 Access ControlThe Archival System must support access control on objects within the archive. This includesfiles, records, finding aid, disposal schedules, and the access control lists themselves. Allaccesses to files and records must be logged.

5.7 Electronic Record Storage in RepositoryThe system must be able to queue electronic documents in a secure way before they arewritten to the Long Term Storage Media. This may also include caching of documents forquick retrieval.

5.8 Electronic Record Linking/AssociationAs for documents.

Victorian Electronic Records Strategy: Stage 2 Initial Functional Specification Outline

6

CSIRO

5.9 Electronic Record Integrity AssuranceThe system must be able to provide proof (to some degree of confidence) that the record hasnot been altered since it was archived.

5.10 Electronic Record AccountabilityThe system must be able to provide proof (to some degree of confidence) who created therecord and when it was created.

5.11 Refresh of Long Term Storage MediaThis is the facility to copy archived records to new media. This protects against media decay,and allows the transfer of records to new technology. In many types of media (e.g. CDs) thisis also the only way to physically destroy disposed records (i.e. records that have beensentenced).

5.12 Explore Finding AidsProvide the ability to use finding aid to access records and files.

5.13 RenderingA document held in a record stored in long term format needs to be extracted and rendered asan image.

5.14 DisposalRecords need to be disposed of in accordance with sentencing information. This could befully automatic or support manual sentencing.

5.15 RecoveryArchival processes should be recoverable just from the long term storage media without theneed for any other system to be saved.

5.16 Record TransferCustody of records must be capable of being transferred from the repository where they werecreated to other repositories (e.g. from an agency repository to the PROV repository, or froman agency repository to an off site record storage location). The system must track transferredrecords.