€¦ · Web viewImplementation Services for a new Records Management System for the Central Bank of Cyprus using OpenText Content ... based on security category

FORM 12

Tender 12/2017

Implementation Services for a new Records Management System for the Central Bank of Cyprus using OpenText Content Server

FUNCTIONAL REQUIREMENTS FOR CBC’S RECORDS MANAGEMENT SYSTEM

The Bank wishes to implement its functional requirements with out-of-the-box OpenText functionality from the already available OpenText modules, listed in Form 14. Tenderers are requested to indicate which requirements can be met with the already available modules by entering “YES” in the Compliance column and which requirements cannot be met, by entering “NO” in the Compliance column. For each requirement that cannot be met (“NO” in Compliance column), the Tenderers must specify in the Response/Comments column the means for satisfying these requirements (how they can be met), either through additional OpenText modules or by bespoke development. Tenders are also requested to indicate the corresponding cost in the Optional Services table of the Financial Proposal (Form 8).

Page 1 of 19

Requirement ComplianceYES/NO Tenderer Response/Comments

0 General Requirements0.1 The System must be compliant with the MoReq2010 specification0.2 The System must provide a unified repository of all records in the

CBC, with each organisational unit being able to manage its own records (through specified administrator roles).

0.3 The System must be user-friendly and provide multilingual support for content, system data, metadata, and searching.

0.4 The System must be able to be interfaced with other business systems

0.5 The System must maintain a complete audit trail of a record’s life-cycle

0.6 The system should support remote access and the ability for users to work off-line and then synchronise with the online system.

0.7 The System must support form-based generation of records0.8 The System must support the flexible use of workflows, either

formalised or adhoc for all stages in a record’s lifecycle (from creation to destruction). The workflow features must support different triggers, ability to assign and follow-up tasks, email alerts, etc.

0.9 The System must provide flexible reporting tools/capabilities1 Record Creation

1.1 Capture1.1.1 Support the capture of records created in native file

formats from commonly used software applications such as: Standard office applications (work processing,

spread-sheeting, presentation, simple databases) Email client applications Imaging applications

Page 2 of 19


1.1.2 Enable integration with business applications so that transactional records created by those applications can be captured within the electronic records management system.

1.1.3 Acquire metadata for each record and permanently link them to the record over time. For records created through business applications, allow for the automatic transfer of related metadata.

1.1.4 Support auto classification of records, allowing manual intervention on specific metadata by authorised users. Automatically enter the date and time of capture of each record as metadata elements linked to each record, as well as generate and store a unique record identifier. Allow the format of the unique identifier to be specified at time of configuration.

1.1.5 Allow for the specification of mandatory and optional metadata and the completion of metadata entry in stages (by different user roles). Allow entry of additional metadata by users if required.

1.1.6 Allow for the specification of different metadata per type of record

1.1.7 Allow for the capture of compound electronic records (records comprising more than one component) so that: The relationship between the constituent

components of each compound record is retained The structural integrity of each compound record is

retained Each compound record is retrieved, displayed and

managed as a single unit

Page 3 of 19


1.1.8 Be able to capture in bulk records exported from other systems, including capture of: Electronic records in their existing format, without

degradation of content or structure, retaining any contextual relationships between the components of any individual record

Electronic records and all associated records management metadata, retaining the correct contextual relationships between individual records and their metadata attributes

The structure of aggregations to which the records are assigned, and all associated records management metadata, retaining the correct relationship between records and aggregations

1.1.9 Be able to scan paper documents, either individually or in batches, separated by barcode separator sheets. The system must support automatic Optical Character Recognition (OCR) and full-text indexing of scans.

1.1.10 Allow the capture of all manifestations of an object as one record e.g. word document, image of the signed document (in pdf), OCR of scanned images.

1.1.11 The system must support drag and drop functionality for moving files into the repository.

1.2 Aggregation of records (e.g. folders)1.2.1 Should not impose any practical limit on the number of

records that can be captured in an aggregation, or on the number of records that can be stored in the electronic records management system.

1.2.2 Support the ability to assign records to multiple aggregations without their duplication.

Page 4 of 19


1.2.3 Allow for the automatic creation of record aggregations by external systems, when importing records.

1.2.4 Support the concept of open and closed volumes for electronic aggregations.

1.3 Hybrid (physical & electronic) records 1.3.1 Allow the presence of non-electronic records to be

reflected and managed in the same way as electronic records.

1.3.2 Allow for the linking/correspondence of electronic record aggregations to physical record aggregations (or volumes). It is desirable for the system to keep a record sequence within a physical record aggregation so that it is easily located if required.

1.3.3 Allow a different records management metadata element set to be configured for non-electronic and electronic aggregations; non-electronic aggregation records management metadata must include information on the physical location of the non-electronic aggregation

1.3.4 Include features to control and record access to non-electronic aggregations, including controls based on security category, which are comparable with the features for electronic aggregations

1.3.5 Support tracking of non-electronic aggregations by the provision of request, check-out and check-in facilities that reflect the current location of the item concerned

1.4 Classification

Page 5 of 19


1.4.1 Support a uniform organisational classification scheme, with a hierarchical organisation of at least three levels that is centrally managed by an administrator role. Optionally support graphical navigation of the classification scheme.

1.4.2 Allow the inheritance of classification values from record aggregations.

1.4.3 Allow an electronic record or an aggregation of records to be reclassified, allowing for the capture of reasoning.

1.4.4 Support the security classification of records and aggregations based on a uniform organisational classification scheme. Security Classification can have a defined time validity period.

1.4.5 Support the automated application of a default value of “unclassified” to an aggregation or record not allocated any other security category.

1.4.6 Allow security classifications to be selected and assigned at a system level for All levels of record aggregations (including volumes) Individual records or compound records

1.4.7 The security classification of an aggregation is the maximum security classification of a record within the aggregation.

1.5 Versioning1.5.1 The System must provide the ability to maintain versions

of records and give them each their own unique identifier.

1.5.2 The System must enable one to one comparison or one to several comparison of record versions.

2 Record Maintenance2.1 Controls and security (managing authentic and reliable records)

Page 6 of 19


2.1.1 The System must ensure that records are maintained complete and unaltered. Amendments must be allowed only by System Administrators in exceptional cases, and any changes must be audited.

2.1.2 Be able to close a volume of an electronic aggregation automatically on fulfilment of specified criteria to be defined at configuration, including at least: Volumes delineated by an annual cut-off date (e.g.

end of the calendar year, financial year or other defined annual cycle

The passage of time since a specified event (for example, the most recent addition of an electronic record to that volume

The number of electronic records within a volume2.1.3 Allow an administrator to lock or freeze aggregations to

prevent relocation, deletion, closure or modification when circumstances require, for example, pending legal action. Likewise, the administrator will be able to open volumes that have been previously closed, either automatically or manually.

2.1.4 Restrict access to system functionality according to a user’s role and strict system administration controls. Unauthorised access attempts must be logged.

2.1.5 Allow user level administrators to set up user profiles and allocate users to groups. Users must be able to be a member of more than one group.

Page 7 of 19


2.1.6 Allow user level administrators to attach to the user profile attributes that determine the features, records management metadata fields, records or aggregations to which the user has access. The attributes of the profile will: Restrict user access to specific records or

aggregations Restrict user access according the user’s security

clearance Restrict user access to particular features (for

example, read, update and/or delete specific records management metadata fields)

Deny access after a specified date2.1.7 Allow access permission security categorisation to be

assigned At group level (be able to set up group access to

specific aggregations, record classes security or clearance levels)

By organisational role At user level In combination(s) of the aboveCertain roles (e.g. Governor, Internal Auditor) will be allowed access to all records in the CBC

2.2 Tracking record movement2.2.1 Provide a tracking feature to monitor and record

information about the location and movement of both electronic and non-electronic aggregations

Page 8 of 19


2.2.2 Record information about movements including Unique identifier of the aggregation or record Current location as well as a user-defined number of

previous locations (locations should be user-defined) Date item sent/moved from location Date item received at location (for transfers) User responsibility for the move (where appropriate)

2.3 Management of electronic and non-electronic records2.3.1 Include features to control and record access to non-

electronic aggregations, including controls based on security category, which are comparable with the features for electronic aggregations

2.3.2 Support tracking of non-electronic aggregations by the provision of request, check-out and check-in facilities that reflect the current location of the item concerned

2.3.3 Where hybrid aggregations are to be transferred, exported or destroyed, the electronic records management system should require the administrator to confirm that the non-electronic part of the same aggregations has been transferred, exported or destroyed before transferring, exporting or destroying the electronic part.

2.4 Retention, migration and disposal2.4.1 All records are retained for a specific retention period, as

indicated in the bank-wide filing and retention plan. All records in an aggregation have a uniform retention period which is applied on the aggregation level.

Page 9 of 19


2.4.2 The System must provide automated functionality that allows for: Reporting and examining records to be destroyed Alerts to users/administrators for the disposition

process triggers Initiation of the disposition process, with the

following alternative actions:o Retain indefinitelyo Present for review at a future dateo Destroy at a future dateo Transfer at a future date

Disposition of record aggregations as a single action Recording any deletion or disposal action in the

process metadata2.4.3 Allow the administrator to manually or automatically

lock or freeze records disposition processes (freeze for litigation or legal discovery purposes, freedom of information purposes, etc.)

2.4.4 The System must allow the administrator to maintain disposal authorities (e.g. State Archives, CBC Archives, etc.) as well as disposal examiner roles for each record aggregation (or groups thereof).

2.4.5 The System must support the review process by presenting electronic aggregations to be reviewed, with their records management metadata and disposal authority information, in a manner that allows the reviewer to browse the contents of the aggregation and/or records management metadata efficiently

Page 10 of 19


2.4.6 Produce a disposal authority report for the administrator that identifies all disposal authorities that are due to be applied in a specified time period, and provide quantitative reports on the quantity and types of records covered.

2.4.7 Provide a well-managed process to transfer records and related metadata to another system or to a third party organisation and support migration process (e.g. State Archives)

2.4.8 Be able to transfer or export an aggregation (at any level) in one sequence of operations so that The content and structure of its electronic records

are not degraded All components of an electronic record (when the

record consists of more than one component) are exported as an integral unit including any technical protection measures

All links between the record and its records management metadata are retained

All links between electronic records, volumes and aggregations are retained

This facility is required for the transfer of records to the State Archives, if/when required.

2.4.9 Retain copies of all electronic aggregations and their records that have been transferred, at least until such time as a successful transfer is confirmed.

2.4.10 Have the ability to retain records management metadata for records and aggregations that have been destroyed or transferred.

Page 11 of 19


2.4.11 Require the administrator to confirm that the non-electronic part of the same aggregations has been transferred, exported or destroyed before transferring, exporting or destroying the electronic part.

3 Dissemination3.1 Search, retrieve and render

3.1.1 The search interface should be intuitive and user-friendly, with multi-language support.

3.1.2 Provide a flexible range of functions that operate on the metadata related to every level of aggregation and on the contents of the records through user-defined parameters for the purpose of locating, accessing and retrieving individual records or groups of records and/or metadata

3.1.3 Allow all record and aggregation records management metadata, and text content (where they exist) to be searchable

3.1.4 Allow the user to set up a single search request with combinations of records management metadata and/or record content

3.1.5 Allow administrators to configure and change the search fields to: Specify any element of record, volume and

aggregation records management metadata, and optionally full record content, as search fields

Change the search field configuration

Page 12 of 19


3.1.6 Provide searching tools for: Free-text searching of combinations of record and

aggregation records management metadata elements and record content

Boolean searching of records management metadata elements

3.1.7 Provide a “wild card” searching of records management metadata that allows for forward, backward and embedded expansionExample the search term ‘proj*’ might retrieve ‘project’ or ‘PROJA’; the term ‘C*n’ would retrieve ‘Commission’

3.1.8 Allow searching within a single aggregation or across more than one aggregation

3.1.9 Display the total number of search results on a user’s screen and allow the user to then display the results list, or refine the search criteria and issue another request

3.1.10 Allow records and aggregations featured in the search results list to be selected, then opened (subject to access controls) by a single click or keystroke

3.1.11 Never allow a search or retrieval function to reveal to a user any information (records management metadata or record content) that the access and security settings are intended to hide from that user

3.1.12 Allow users to save and re-use queries3.1.13 One example of a pre-defined search/view is what the

CBC calls a Float File. This is a collection of records (per period) declared by Departments to be included in the Float File (using a flag indicator) or by applying certain predefined rules (e.g. outgoing correspondence of non routine nature) that are made available to the CBC’s management team for information (fyi).

Page 13 of 19


3.1.14 Provide display formats configurable by users or administrators for search results, including such features and functions as: Select the order in which the search results are

presented Specify the number of search results displayed on

the screen Set the maximum number of search results Save the search results Choose which records management metadata fields

are displayed in search result lists3.2 Internal Circulation

3.2.1 In order to avoid duplication of records, the internal circulation shall be in the form of links to stored records. A simple automation of granting read only access to internal addressees is required, with the ability of recipients to store the respective links in their own aggregations for reasons of completeness.

3.2.2 Records disseminated internally via links should be copy-pasted and saved-as enabled.

3.3 Rendering: printing3.3.1 Provide the user with flexible options for printing records

and their relevant records management metadata, including the ability to print a record(s) with records management metadata specified by the user.

3.3.2 Allow the printing of records management metadata for an aggregation

Page 14 of 19


3.3.3 Allow the user to be able to print out a summary list of selected records (for example, the contents of an aggregation), consisting of a user-specified subset of records management metadata (for example, title, author, creation date) for each record

3.3.4 Allow the user to print the results list from all searches.4 Administration

4.1 Administration4.1.1 Provide back-up facilities so that records and their

records management metadata can be recreated using a combination of restored back-ups and metadata

4.1.2 Provide recovery and rollback facilities in the case of system failure or update error, and must notify the administrator of the results

4.1.3 Allow the administrator to make bulk changes to the classification scheme, ensuring all records management metadata and metadata data are handled correctly and completely at all times, in order to make the following kinds of organisational change: Division of an organisation unit into two Combination of two organisational units into one Movement or re-naming of an organisational unit Division of a whole organisational unit into two units

4.1.4 Support the set-up of departmental administrator roles, responsible to manage departmental record structures and roles.

4.2 Reporting

Page 15 of 19


4.2.1 Provide flexible reporting facilities for the administrator. They must include, at a minimum the ability to report the following: Numbers of aggregations, volumes and records Transaction statistics for aggregations, volumes and

records Activity reports for individual users

4.2.2 Allow the administrator to report on metadata, based on selected: Aggregations Volumes Record objects Users Time periods File formats and instances of each format

4.2.3 Be able to produce a report listing aggregations, structured to reflect the classification scheme, for all or part of the classification scheme

4.2.4 Allow the administrator to report on metadata, based on selected: Security categories User groups Other records management metadata

4.2.5 Provide reporting tools for the provision of statistics to the administrator on aspects of activity using the classification scheme, including the numbers of electronic aggregations (including volumes) or records created, closed or deleted within a given period, by user group or functional role

Page 16 of 19


4.2.6 Provide facilities for pre-defined reports as well as ad-hoc reports configured by users/administrators. An example of pre-defined reports are correspondence registers kept by organisational unit (incoming, outgoing).

4.2.7 Support reporting and analysis tools for the management of retention and disposal authorities by the administrator, including the ability to List all disposal authorities List all aggregations to which a specified disposal

authority is assigned List the disposal authority(s) applied to all

aggregations below a specified point in the hierarchy of the classification scheme

Identify, compare and review disposal authorities (including their contents) across the classification scheme

Page 17 of 19

APPENDIX: Metadata

Indicative required metadata for CBC records

Classification access (access restrictions)Confidentiality classification (pre-defined confidentiality levels)Record creator (auto filled)Author/sender (person’s/organisation’s name /synonym)Owner Organisational UnitCreated on (date)Date on the documentDate of receipt (for incoming records)Abstract/DescriptionFormat (e.g. paper, electronic, book, cd)Size (pages, volume)LanguageTitleUnique document identifier/ Registration number (auto generated)AddresseeOriginating unit or departmentAssigned person/case workerType of document (e.g. email, fax, paper mail, internal note, contract)Filing classification (code, title) from a predefined hierarchical structureKeyword/case fileLinks to other related recordsVersionsLegal retention (code, expiry date)Action after retentionValue (info, routine, admin, legal, financial)Location (physical format)Event logFloat file indicator (see Req. 3.1.13)Personal data indicator

Indicative required metadata for CBC aggregations (electronic and physical folders)

Classification access (access restrictions)Confidentiality classification (pre-defined confidentiality levels)Aggregation creator (auto filled)TitleOwner organisational unitCreated on (date)Abstract/DescriptionFormat (e.g. paper, electronic, book, cd)Size (pages, volume)Aggregation status (Active, SemiActive, Closed, Frozen, etc)Closure dateAggregation identifier/ number (auto generated)Filing classification (code, title) from a predefined hierarchical structure

Page 18 of 19

Keyword/case fileLinks to other related aggregationsLegal retention (code, expiry date)Personal data processAction after retentionLocation (physical format)Event log

Page 19 of 19

Documents

€¦ · Web viewImplementation Services for a new Records Management System for the Central Bank of Cyprus using OpenText Content ... based on security category