Records/Document/Information Management (RDIM): Integrated Document Management System for the Government of Canada
Request for Proposal (RFP) Software Requirements

Developed by the Interdepartmental RDIM RFP Sub-Committee, Shared Systems Program, Treasury Board Secretariat

Information Management Standards and Practices Division National Archives of Canada

May 1996

Table of Contents
1. 2. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 GENERAL FUNCTIONAL REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Objectives of the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Guiding Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4 Summary of Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.5 Who, What, When, Where, Why, How . . . . . . . . . . . . . . . . . . . . . . . . 6 2.6 Profile Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 DETAILED FUNCTIONAL REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . 3.1 Receipt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Create New/Reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Transmission/Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 System Maintenance - System Administration . . . . . . . . . . . . . . . . . . . . 3.11 Workflow Management - System Administration . . . . . . . . . . . . . . . . . . USEABILITY REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Workflow & Process Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Bilingualism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Training and User Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Functional Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TECHNOLOGY REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Tool sets and Application Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 New Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Application Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Data Sharing & Application Integration . . . . . . . . . . . . . . . . . . . . . . . 5.6 Technology Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Additional Information Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12 12 13 14 16 17 18 18 19 20 20 21 21 22 22 23 23 24 26 26 26 26 27 27 28 30

3.

4.

5.

APPENDIX A- Glossary of Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.

INTRODUCTION

Document management is defined as a system for controlling the capture (when created or received), classification (cataloguing), storage, retrieval, revision, sharing and reuse, protection and disposition of documents. Documents include electronic and non-electronic objects. Electronic objects include products of word processors, e-mail, imaged material, etc. Non-electronic objects include paper, documentation, photographs, maps, artwork, realia, etc. The Electronic Work Environment (EWE) Management Board was established in July 1994 to provide guidance and direction in respect of office automation domains in the Government of Canada. Document and records management was determined to be a key operational priority of the Board. Accordingly, an interdepartmental steering committee was established to provide leadership and guidance for planning, evaluating, and implementing a system for document and records management based on a common requirements statement. The following highlights the findings and recommendations of the committee. There was general agreement that systems currently utilized do not fully meet today’s operational requirements. As well, it became clear during the investigation of requirements that the ideal electronic solution would be a document management system that would contain the necessary records management functionality. There was unanimous consensus to acquire document management software for the Government of Canada. The new software should permit the automated transmission, processing and management of documents within a department, among departments and among offices across Canada. In addition, it is desirable that the software support public access as determined by departments. The ideal software should encompass more than traditional document and records management: the ideal software product would extend to the management of realia, multimedia and the treatment of information as objects. In this RFP, e-mail messages, word processing files, spread sheet files, images, realia, voice and video files are all considered to be objects. There is a need to manage "classified" documents in the federal government. Accordingly, it would be desirable for the software to enable this as well. Responses to a Request for Information (RFI) from the software industry has confirmed the availability and viability of a common shared software for document management. This document sets out the requirements and evaluation criteria for acquiring a government shared software for document management through the federal government’s formal Request for Proposal (RFP) process.

1

2. 2.1

GENERAL FUNCTIONAL REQUIREMENTS Objectives of the System

The objectives of the system are as follows: (1) To provide a means for the user to facilitate the processes of capturing, receiving, storing, organizing, sharing, retrieving, re-using, protecting and disposing of information in an electronic environment regardless of format and without geographic or organizational barriers. To provide authorized access by the public to records, information and objects stored by the federal government. To meet legislative and policy requirements. To operate in an effective, efficient and economical manner. Guiding Principles

(2) (3) (4) 2.2

The underlying principles of the system include the following: (1) Information management is not limited to a single discipline, rather, it involves program areas, libraries, records management and other areas of activity in the organization. Information is a corporate resource to be shared and enriched. Do it once, do it right, re-use it. Do the work where it most makes sense, as early as possible in the process. The status quo is unacceptable. The process of records/document/information management is as invisible and unobtrusive as possible to the user. The integrity (completeness, accuracy and reliability) of the original object is maintained.

(2) (3) (4) (5) (6) (7)

2

2.3

Assumptions

The assumptions which were made in developing this RFP are as follows: (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) 2.4 Information management forms an integral part of a department s business plans. The benefit of increased access to information justifies the investment in its management. People want to share information. There exists at least a LAN and preferably a department-wide network. The technology is operational on a wide variety of platforms, and can interface, interoperate and connect with a wide variety of systems. The interface is a Graphical User Interface (GUI). People are willing to change their work processes if necessary, and steps will be taken to aid in the transition. Retraining of staff will be provided as required. The focus is on enhancing the business delivery and associated processes. The software will support activities such as Business Process Re-engineering (BPR). The system is available to users at the workstation. The system is user friendly and intuitive. The system accommodates information regardless of media and format. Summary of Key Features

This summary highlights the main features required by users/records managers/systems administrators/government employees in the records/document/information software. (1) (2) The software uses the concept of managing and controlling an object and not managing and controlling a file. (See APPENDIX A for definitions of object and file.) The software is primarily for and available to the knowledge worker/end user and is user-friendly and intuitive. The software also provides the tools required by the 3

records management community. (See Section 2.7. Roles for User, Records Management, Network Manager and IT Specialist roles.) (3) Screen layouts, templates, official language of choice (one software for both languages), fields, etc. are easily configurable by system administrators and users or groups of users are able to choose which fields are displayed. The software has the ability to integrate and interconnect with other systems, including other repositories, databases, etc. to search, retrieve, view, extract, and re-use information. The software must interconnect with various platforms, operating systems, and software, including groupware. Vendors will indicate ability to handle mark-up languages (SGML, HTML etc.), the means used for conversion, and file formats (TIFF, PCX, etc.). The software supports multi-media in that it accepts input in a variety of formats, e.g. electronically, paper, voice and video, and allows output on the variety of media and formats. The software automatically stores objects on creation and on receipt (auto-file and autosave), with an optional override to this feature at the user and departmental levels. The software automatically generates and fills in a profile for every object stored. Profile fields are automatically completed by the software which extracts and inserts profile information from the objects and/or from other systems. The user may also input to the profile and override information which has been automatically filled in. Profile information is automatically updated as changes are made to objects. Profile fields have certain configurable characteristics attached to them, including mandatory or not mandatory, editable or not editable, fixed list of choices, defaultable, displayed or not displayed, scrollable, expandable, configurable, queryable, unlimited length, automatically updated as object is changed, etc. Profiles may be retained for longer than the corresponding object as required. The profiles are updated to reflect the disposition of the object. The software is able to handle both a central repository configuration and distributed and replicated repositories, or both as required by the department. The software permits conversion of objects to newer versions of the native software (preferably automatically converted upon upgrading) as well as to different software (preferably automatically converted upon opening). The software may retain the objects in their native format and software version, with an option to convert, as long as they maintain readability and editability. The software may also contain a viewer, for example, the portable document format (PDF). 4

(4)

(5)

(6) (7)

(8) (9) (10)

(11)

The software accommodates a generic classification scheme. Classification of the objects is performed automatically by the software, based on user (creator and/or recipient of the object) information established in the software, e.g., department/program/activity/sub-activity/RC code. Information such as RC code is automatically drawn from existing coding structures in other systems, with an option to override by the user. The software must also be able to accommodate other classification structures required by individual departments. The software has full text retrieval capability. Profile fields are text retrievable as well as object contents. The software is based on the concept of access privileges rather than the need for different directories or drives, i.e. personal space, shared space, corporate space, etc. Access privileges are based on user profiles, including security classification of users and Responsibility or Cost Centre Codes, and can be assigned to individuals or work groups. Information such as user security level is automatically drawn from other security databases. Authorized public access must be accommodated as well, e.g. through a special RC code. No unauthorized access is permitted (additional control with use of password).Profile information is defaulted to unlimited access to all Government of Canada employees, with an override feature at the departmental level and, should the department decide, at the distributed repository level, at the same time respecting Access to Information and Privacy (ATI&P) considerations. The software supports multi-level approval stages of objects and transactions and electronic authorization and tracking (who has what, when) based on pre-defined work flow rules and processes. An audit trail of actions is created dynamically and easily accessible upon request. The software supports these capabilities across geographical and organizational boundaries. The software provides a method of final validation to uniquely identify and/or render a version finalized (authorized). Security, backup/recovery, data protection, etc. capabilities ensure information and system integrity. The software permits automatic disposition, security downgrades, updating of essential records, etc. based on pre-determined periods of time and pre-approved actions, with optional notification/confirmation to user, and an override capability. The software permits global processing (i.e. additions, modifications, transfers or deletions) of changes to any profile fields or of any actions (e.g. global transfer of a group of objects, etc.). With such global capacity comes such features as a confirm message before the actions are taken, an interrupt function, length of time reporting, and an undo function. The software updates the database as soon as the global processing action occurs, and an audit trail of all actions is kept. 5

(12) (13)

(14)

(15) (16)

(17)

2.5

Who, What, When, Where, Why, How

The software will be used by a wide variety of clients, incorporates many types and media of objects, is available at all times and across geographical locations and serves a variety of purposes. The following describes the who, what when where, why and how of the required system: WHO uses the software? End users, line workers, Ministers' offices, deputy ministers, senior officials, managers, creators, recipients, records staff, library staff, correspondence units, mail room staff, informatics staff, the public, publishers, newspapers, National Archives, out-sourced storage facilities, private sector customers, media, libraries, etc. WHAT information is managed by the software? Information created or received in the conduct of federal government business regardless of format, i.e. paper, electronic, e-mail, images (optical and magnetic), microfiche, CD, CD ROM, diskettes, video, voice, fax, drawings, photos, slides, posters, tapes, calendars, forms, transactions, directories, policies, briefing notes, speeches, maps, charts, schedules, audio tapes, databases, tables, spreadsheets, certificates, letters, reports, memos, general correspondence, books, magazines, newspapers, glossies, bulletin boards, directives, etc. WHEN does information get captured? When saved, received, sent, forwarded, at point of creation, at a business transaction, when the user decides, etc., according to pre-established criteria developed in departments on when an object becomes a record, and, therefore, is captured. WHERE is the software used? At or from any geographical location, offsite storage, National Archives, Internet, libraries, private companies, desktop/PC, LAN, server, databases, records offices, filing cabinets, shelves, home, removable media (e.g. diskettes), airports, hotels, boardrooms, etc. WHY have the software? To facilitate access, prevent unauthorized access, locate information, distribute, disseminate, transmit, gain knowledge, let people know what information is available, enable use/re-use, enhance program delivery, facilitate decision making, improve client services, better meet the requirements of the public, information sharing, meet 6

legislative requirements, provide information for history / research, aid in retention/disposition. HOW does the software import/export information? Links (integration), pointers, channel/filter, fax, EDI, scan paper (OCR/ICR), bit map, CD Rom, cassettes, diskettes, disks, voice-mail, e-mail, electronically, manually (keyboarding), databases, tapes, microfilm, etc. Also, the document management software must provide a seamless integration with related applications (i.e., imaging) and databases. This integration should permit the end user to retrieve information from these applications and databases and, from the end user’s perspective, these multiple databases should appear as one system. 2.6 Profile Fields

The following list of profile fields are examples of fields that may be required to be able to identify/retrieve an object. It should be pointed out that the end user will normally only see a small sub-set of these fields when they view their profile screen. The software must permit the user to view all the profile fields on demand. Also, additional profile fields may be required by some departments. Profile fields are automatically filled in by the software which extracts and inserts profile information from the objects and/or from other systems. The software must complete as many fields as possible. Fields have certain configurable characteristics attached to them, including mandatory or not mandatory, editable or not editable, fixed list of choices, defaultable, displayed or not displayed, scrollable, expandable, configurable, queryable, unlimited length, automatically updated as object is changed, etc. In some cases, it may be desirable to be able to assign certain profile field information at as high a level as possible (or at any level) in the hierarchical structure (department/program/activity/sub-activity/RC). This profile information is then automatically attributed to the objects under that level of the structure. The software automatically completes as much information as possible. OBJECT TITLE Formal title OBJECT DESCRIPTION Further description of the subject of the object, if necessary DEPARTMENT IDENTIFIER Code assigned to every department in the Government of Canada PROGRAM/ACTIVITY/SUB-ACTIVITY/RC TITLE Titles as set forth in the departmental OPF or main estimates PROGRAM/ACTIVITY/SUB-ACTIVITY/RC IDENTIFIER 7

Codes as part of the financial codes linking to the OPF or equivalent VERSION NUMBER/DATE Version information, and/or links to original and other versions LINKS TO OTHER OBJECTS/ATTACHMENTS Links between electronic and non-electronic objects, links between objects and attachments, etc. OBJECT TYPE Letter, memo, report, etc. MEDIUM Electronic, CD, paper, video, sound, etc. APPLICATION SOFTWARE/VERSION/PLATFORM Name of original software version, update, date of update, platform information, etc. DATE OF OBJECT Date appearing on object DATE CREATED DATE SENT DATE RECEIVED TO RECEIVED BY FROM CREATED BY CIRCULATE TO MULTI-LEVEL APPROVALS Names, dates kept of all approvals AUTHORIZATION/DATE Electronic signature or equivalent, including name and date C.C. TO SECURITY Multi-Level, including Protected I, II and III, Confidential, Secret, Top Secret DOWNGRADE DATE Date on which object should be reviewed for downgrading of security level ESSENTIAL STATUS Categories 1, 2 and 3 ESSENTIAL RECORD LOCATION Location of Essential Records Storage Site UPDATE DATE Date on which essential records should be reviewed for currency and accuracy USERS PERMITTED ACCESS Names of users permitted access, defaulted to ALL CHARGED TO/DATE Name of user(s) to whom the object is checked out, and name(s) of all users who have checked out the object, and date(s) checked out 8

BF/DATE Name of user(s) for whom object reserved, and date(s) due LAST ACCESS All names and dates of users who have accessed the object, and when LOCATION (NEAR-LINE, OFF-LINE) PROGRAM RECORD ATI locator number, as appears in INFOSOURCE PERSONAL INFORMATION BANK Personal Information Bank number as appears in INFOSOURCE ACTIVE/DORMANT RETENTION PERIOD Dates on which object should be transferred to inactive storage and/or disposed RECORDS DISPOSITION AUTHORITY NUMBER National Archives authority number, showing approval of disposition action ARCHIVAL VALUE Yes or No, as agreed upon with the National Archives, or To be Determined DISPOSITION ACTION Including delete, preserve and transfer. DISPOSITION DATE Date disposed, means of disposal, etc. Additional profile fields specific to non-electronic objects While the preceding profile fields apply to electronic and/or non-electronic objects, these additional profile fields are specific to describing/profiling non-electronic objects. PHYSICAL LOCATION Address or identifier of office in which non-electronic objects are located SUBJECT NUMBER SUBJECT TITLE SUBJECT DESCRIPTION FILE/VOLUME NUMBER FILE TITLE CROSS-REFERENCE NUMBER(S) PREVIOUS NUMBER(S) FILE DATES FILE/VOLUME OPEN DATE FILE/VOLUME CLOSE DATE BARCODE

9

2.7 USER

Roles

Know what is filed and can easily find/retrieve and re-use relevant information, as and when required, from this software as well as other systems. Able to share/make available information efficiently and effectively. Responsible for: ensuring what should be filed is filed; identifying final version; routing/transmitting information to the relevant people; ensuring correct information is on profile; ensuring documents can be accessed as appropriate; ensuring their own personal security level is adequate to access the information; ensuring adequate protection of security designated information; and ensuring the retention period is appropriate. RECORDS MANAGEMENT Keep abreast of best record keeping practices, rules, legislation and practices. Establish departmental policies/practices and guidelines for record keeping. Become aware of user requirements and ensure that they are built into the software/process in conjunction with departmental IT people. Provide training/advice to users on the records management system, principles, practices Negotiate with National Archives for Records Disposition Authorities, transfer arrangements, preservation methods, etc. Provide information and advice to National Archives and the Treasury Board on records policies and practices. In the records/document/information software, ensure: classification system management (set up and maintain, automatically fed from financial coding structure, and/or other classification structures, etc.); retention/disposition management, i.e. dormant and archival storage (electronic and non-electronic), transfers to other organizations (including National Archives), disposition; access based on need to know (security); other departmental rules incorporated; etc. Manage non-electronic objects (realia) as determined by department (file, retrieval, practices and services. In some cases, capture the non-electronic information (i.e. scan) as determined by department. 10

May perform reporting activities as per ATI&P and other legislation, as determined by department. Perform management and statistical reporting. Perform audits as required. Perform training as required. NETWORK MANAGER / SYSTEM ADMINISTRATION (E.G. LAN/WAN MANAGER) Provide support to users, including records management staff. Ensure that the software is operating properly on the workstations. Establish and maintain security rights on the LAN. Provide systems administration. IT SPECIALIST Provide the tools and support for maintaining and operating the software (including training, expertise, etc.) Ensure requirements of user and records management are incorporated into the software. Ensure technology is there to support user and system requirements, e.g.: hardware including that at the workstation; networks; interoperability, interconnectivity. Establish and maintain security rights at the software level.

11

3.

DETAILED FUNCTIONAL REQUIREMENTS

An array of technical features and capabilities will be presented, designed specifically to support end users performing each of the document management processes outlined. 3.1 Receipt covers the main activities involved as government departments collect, receive, create and generate objects.

3.1.1 Objects are automatically stored on creation and on receipt from internal and external sources (auto-file and auto-save), with an optional override to this feature at the user, departmental and distributed repository levels. 3.2 Capture covers the capture of electronic and non-electronic objects.

3.2.1 Information in electronic format such as e-mail and attached files is captured at creation and receipt. 3.2.2 Information generated in electronic format such as reports, spreadsheets, flowcharts, images is captured. 3.2.3 Information in paper format is captured: (1) as images or (2) OCR/ICR d 3.2.4 Non-electronic objects such as unscanned paper documents and realia are able to be profiled. 3.2.5 Multi-media is supported, including input and output capability, e.g. voice and video. 3.2.6 Items may be sent to the user before the store action takes place, concurrently with it, or after it, at the discretion of the department and based on business rules. 3.2.7 Version control of draft and final objects is provided. 3.2.8 User are notified when they create duplicate objects.

12

3.3

Store includes the processes involved in identification, organization, classification, and storage.

3.3.1 Objects are managed and stored in: a central repositories distributed repositories replicated repositories 3.3.2 Objects are converted to newer versions of the native software as well as to different software. The conversion maintains readability and editability. The preferred approach is to automatically convert the objects, as required, when the native software is upgraded. 3.3.3 Objects are retained in their native format and software version, with an option to convert. 3.3.4 A viewer is available. 3.3.5 Objects can be converted to the format of different software, based on business requirements. The preferred approach is to automatically convert the objects when the object is retrieved by the new software. 3.3.6 The software is able to integrate/interconnect and interoperate to and from other systems seamlessly including other repositories, databases, to search, retrieve, view, extract, and re-use information. 3.3.7 The software has the ability to accept documents which have utilized various mark-up languages, e.g.: (1) SGML (2) HTML (Vendors should be asked to list all the mark-up languages they support.) 3.3.8 File format conversion tools are available. These should be available for all versions of the software published in the last three years for: Microsoft Word Microsoft Excel WordPerfect Ami Pro Lotus 1 2 3 (Vendors should be asked to list the formats available with the software and the means used for conversion.)

13

3.3.9 Compound documents are able to be managed. Users are able to recreate complete compound documents at any time in the future. 3.3.10 Stored profiles are linked to stored objects, including objects with attachments (i.e. attachment with link to objects and link this to the stored profile). 3.3.11 Electronic profiles for non-electronic objects (realia) are able to be prepared and stored electronically. 3.3.12 Active Storage - On-line: Immediate (on-line) access is provided for objects and their associated profiles in active (daily/constant) functional use. 3.3.13 Dormant Storage - Near-line: Secondary or off-site storage for dormant objects is supported (for objects that are no longer in constant use but that may be required at some future time). The associated profiles are maintained in active storage to provide immediate reference/access for as long as the objects are retained. 3.3.14 Archival Storage -Off-line: Long term storage for objects and associated profiles that have an enduring retention value for the organization is facilitated. The associated profiles remain accessible to provide a record of all objects which have been transferred to archival storage. 3.4 Profile includes description of how the profile fields are to be completed and managed.

3.4.1 A profile is automatically generated and completed with as much information as possible for every object stored. There is an override feature for this function meaning that the user may change any of the information which is automatically generated. 3.4.2 Also, information is automatically extracted to and from other systems with an override (import/export). 3.4.3 Before storing an object, a search is automatically made for duplicate objects. If a duplicate profile is found, the user is notified that a duplicate exists and is given options for how to proceed. 3.4.4 The retention of profiles after the object has been disposed is permitted. 3.4.5 The profiles are automatically updated to reflect the disposition of the object.

14

3.4.6 Profile fields are configurable, including: either mandatory or not mandatory editable or not editable defaultable displayed or not displayed scrollable searchable length 3.4.7 A generic classification scheme is accommodated, which is based on the existing Responsibility Centre (RC) coding structure (department, program, activity, subactivity, RC code). This could be accomodated through the profile or other means. 3.4.8 Objects are automatically classified according to the generic classification scheme based on user (creator and/or recipient of the object) information established in the system, (department/program/ activity/sub-activity/RC code). Information such as RC code is automatically drawn from existing coding structures in other systems, with an option to override. 3.4.9 Multiple classification structures as required by individual departments are also accommodated and maintained (established, updated, modified). 3.4.10 Global modifications are permitted. Additions, modifications transfers or deletions to any profile field values and any level of the department /program /activity /subactivity/RC structure and other classification structure(s) must be reflected at all corresponding levels and profile fields within the structure. When a change occurs, it is imperative that all related information is added, modified, transferred or deleted as well. 3.4.11 A delete capability that will take human error into account is provided, i.e. re-create feature, a holding area, or other method of correction of erroneous deletion. (Vendors should be asked to describe how their feature will work.) 3.4.12 The global update function has an optional confirm message before the actions are taken. 3.4.13 The global update function has an interrupt function.

15

3.4.14 The global update function predicts the length of time to do the update before the user starts the update. 3.4.15 The global update function has an undo function. A history is required of revisions to guide the user to select the right revision to undo. (Vendors should be asked to describe how errors will be corrected.) 3.4.16 The global update function permits batch processing (e.g., add same profile to 50 objects or more at a time, move ranges of objects at once). Re-indexing occurs as soon as the global processing action occurs, and an audit trail of all actions is kept. 3.5 Retrieve covers search, retrieval and accessibility, including reserving (BF) and charging out of the stored objects.

3.5.1 Objects and profiles are retrievable via any profile field. 3.5.2 A powerful, efficient, and uniform means of searching and retrieving the objects stored is provided. 3.5.3 Objects and profiles stored in other document repositories can be searched and retrieved. 3.5.4 A search of the profile, object contents, or both the profile and object contents as appropriate is supported. 3.5.5 Any profile may be searched whether the object itself is in electronic form or not, or whether the object is stored on-line, near-line or off-line. 3.5.6 The user is able to choose the order in which the search results are presented. 3.5.7 Other retrieval tools as required by individual departments may also be used, including: (1) thesaurus (including faceted) (2) dictionaries (3) knowledge bases. 3.5.8 User are informed of the number of hits as a result of the search. Also: (1) Alternate strategies are offered if the search is too broad. (2) Users have the option either to continue, or to re-define the search criteria. (3) The result list is formatted as a report with a print or save option.

16

3.5.9 The user is able to set the maximum number of hits and is able to save search criteria and results. 3.5.10 Full text retrieval capabilities for objects and profile fields are provided. The full text retrieval capabilities include: (1) client/server architecture for wide-scale deployment across LANs and WANs (2) open architecture, multi-platform support to provide effective performance scalability and hardware independence 3.5.11 Features are included that help ensure the maintenance of the integrity and quality of the original object. 3.5.12 Users are able to retrieve copies simultaneously, or not, as required. 3.5.13 An audit trail is created of all users who retrieve and/or return the objects. 3.5.14 To reserve (BF) an object for future reference or use, the user and records management specialist are able to add BF criteria to an object, i.e. person requesting BF, due date, action to be taken. The object is then automatically issued when the BF is due. 3.5.15 Multiple BFs from different sources are able to be handled concurrently. 3.5.16 Users are able to enter more than one BF date and action. 3.6 Create New/Reply covers the work flow processes, including editing, approval and version control.

3.6.1 An object may have attachments (electronic or non-electronic), therefore attachments to E-mail are able to be managed. Also, attachments to other types of electronic documents are able to be managed. (Vendors should be asked to describe their method of managing attachments in electronic format or as realia.) 3.6.2 Multi-level approval of objects is supported, including transactions and electronic authorization and tracking (who has what, when), across all processes, based on predefined work flow rules and processes.

17

3.6.3 These approval capabilities are supported across geographical and organizational boundaries. 3.6.4 A method of final validation is provided to uniquely identify and/or render a version finalized (authorized). 3.7 Transmission/Output covers the processes surrounding sending, or communicating the objects.

3.7.1 Transmission and/or output of information to a wide variety of recipient systems is supported, including: (1) e-mail (2) Internet, including a Web Server-type environment (3) fax (4) bulletin board 3.7.2 Document transmission/output to a wide variety of recipient systems is permitted, across a wide geographical area, across systems, applications and platforms and in a wide variety of media, including: (1) electronic (2) paper (to printer) (3) voice (4) video (5) image (Vendors should be asked to specify methods of addressing this requirement, including the point at which and how document security is passed to the telecommunications system.) 3.8 Disposition covers retention and disposition of the objects, including destroying and/or transferring the objects.

3.8.1 Departmental Storage: Retention periods and disposition actions are able to be entered at as high a level as required or at any level in the hierarchical structure (department/ program/ activity/ sub-activity/RC code). The appropriate retention and disposition information is then automatically attributed to the objects under that level of the structure, and an override feature is provided.

18

3.8.2 Dormant Departmental Storage: The movement of electronic objects(s) and profiles from active storage to dormant storage is facilitated, based on pre-determined criteria (i.e. a length of time associated with each activity/sub-activity/RC code as appropriate). The profile is changed to reflect the disposition. Profiles are kept in active storage for all objects transferred to dormant storage. 3.8.3 The destruction, preservation/archiving and transfer of objects and profiles is managed. 3.8.4 The disposition of objects before the expiry of the retention period is possible, that is at any time. 3.8.5 Before disposition is carried out, the facility to notify and/or seek authorization for disposition actions is provided (based on departmental requirements). 3.8.6 A profile may be destroyed, if required. 3.8.7 It is possible to transfer active, dormant, or archival electronic objects and profiles to another government department or to a non-federal-government organization (e.g. a university research facility or another level of government). (1) Where such a transfer occurs with another government site using the software, it is possible to import/export the data, profiles and electronic objects in bulk to the organization receiving the information. (2) An audit trail is maintained. 3.8.8 It is possible to transfer objects from dormant back to active storage. 3.9 Reports

3.9.1 A wide variety of reports, which could be used once or saved for later use, are able to be produced. Examples of reports are: Objects added, modified, transferred and deleted Objects retrieved and not edited Objects retrieved and edited Last access date Access history Charge-in/out history Destroyed/deleted Date deleted/destroyed Destruction method. 19

Transferred to archives Date transferred Accession information Transferred to inactive storage Date transferred Location (internal) Accession (external) Statistics on all actions performed Active/dormant status Security level/designation Subject Classification Identifier Lists Realia - Volume, container, storage information 3.9.2 The report formats are easily configurable. 3.9.3 An ad-hoc reporting facility is provided. 3.9.4 Reports may be electronically saved for re-use or printed as and when required. 3.9.5 All reports can be automatically (system initiated) created and electronically forwarded to the intended recipients. 3.10 System Maintenance - System Administration includes the management of user accounts, passwords, and management of databases:

3.10.1 Users accounts, passwords and access are able to be managed. 3.10.2 Software is able to be managed, in terms of: install, replace/upgrade, recover, backup and journal file (transaction file). 3.10.3 The master database, files, and tables are able to be managed. 3.11 Workflow Management - System Administration

3.11.1 Tables of authority are able to be maintained. Examples are: (1) directory of Staff Groups and members (2) types of information items (by document type, priority, level) (3) status types (4) classification, indexes, keywords (5) roles (6) rules/procedures 20

(7) (8) (9) (10) (11) 4. 4.1

task categories task lists routings action types distribution, destinations

USEABILITY REQUIREMENTS User Interface

4.1.1 The software integrates/interconnects/interoperates or interfaces with commonly used electronic work environments at the desktop without compromising functionality. For example: (1) E-mail users are able to store E-mail messages in document management repository while using E-mail software. (2) The user has the ability to cut and paste to word processing, spreadsheet, database, schedule software. 4.1.2 Software must not disable existing application software. 4.1.3 Application error and reject messages are precise, comprehensive, relevant, and content sensitive. The messages suggest a course of action to be taken by the user with appropriate navigation prompts. 4.1.4 Navigation is provided in a consistent fashion. Most navigation and command features are usable both from the keyboard, as well as with a mouse or other pointing device (keyboard equivalents for most functions). The user is able to access features without leaving the current screen. 4.1.5 The ability to do electronic sticky notes or comments is provided. 4.1.6 Users are enabled to enter information quickly using "hot-keys", short-cuts or other features. (Vendors should be asked to describe the features.) 4.1.7 The following are provided: (1) graphical controls such as buttons, pull-down menus, pick lists, check boxes (2) multiple windows can be opened at the same time, and be kept open in an intermediate state (3) windows are: I) moveable ii) sizeable 21

(4)

iii) dynamically adjusted to differences in resolution across display types users are able to read the contents of any resized windows

4.1.8 User-defined preferences are possible, such as display, command defaults, and other useability features. 4.2 Workflow & Process Features includes features to manage the movement of objects.

4.2.1 Third party workflow/work management software can be integrated or supported, in addition to any proprietary workflow/work management capabilities included. 4.2.2 Information can be shared and synchronized with other software and sub-systems. 4.2.3 Process templates are available for common processes (i.e. a process template library). 4.2.4 Work processes and rules can be changed/configured. 4.2.5 Workflow features are available when the user is working outside the office via remote access. 4.2.6 Process work teams within a distributed work flow environment are supported. 4.2.7 The development of custom on-line help features for business processes are supported. 4.2.8 The facility to use electronic signatures as required by departments is provided. 4.3 Bilingualism includes the features needed to meet Government of Canada language requirements in accordance with the Official Languages Act

4.3.1 The following are bilingual: (1) screens (2) on-line help (3) reports (4) user documentation (5) training (including training materials) (6) system messages 4.3.2 Bilingual support is provided (hot-line, system maintenance and technical support).

22

4.4

Training and User Support includes the training required to install the software.

4.4.1 Training courses are available. 4.4.2 On-line help is provided throughout the modules in a windows help system format. The following on-line help features are provided: (1) navigational aids (2) hints and tips (3) tutorial (4) context sensitive help (5) guidance through query process (6) hypertext links to "related topics" 4.4.3 Ability to customize on-line help is provided. 4.4.4 On-line help customization made by departments can be called forward into new versions of the software. 4.4.5 Software support services are provided to: (1) Technical Support/Service Provider (2) Users This support is available from 7:30 hrs to 17:00 hrs in all Canadian time zones, Monday through Friday, exclusive of statutory holidays observed by Canada, with contact to representative within one hour. 4.4.6 Emergency support is provided from 17:00 hrs to 23:00 hrs in all Canadian time zones, Monday through Friday, and from 8:00 hrs to 18:00 hrs on weekends and statutory holidays observed in Canada. 4.4.7 A process exists for resolution of user problems. (Vendors should be asked to describe the time frames for the resolution of problems by type of problem, as well as a process for the escalation of problems. 4.5 Functional Scalability includes features that provide for use in both small scale and large scale installations.

4.5.1 Some functions can be turned off or on as required to satisfy requirements. For example, end user may not want to view profile screen when an object is stored if profile is always automatically filled in. (Vendors should be asked to describe.) 4.5.2 Processes and functions are able to be configured. 23

4.5.3 Results of new configuration are able to be previewed before implementation. 4.5.4 Multiple drives may be used for database, i.e., not be limited to one hard drive. 4.5.5 Multiple server environments are supported with one or more server per major workgroup. (Vendors should be asked to describe the efficiency and performance scalability.) 4.5.6 A wide range of transaction volumes are supported for user filing and searching. (Vendors should be asked to describe their range.) 4.5.7 Profile searches are supported across all departments and agencies that are using the software. 4.6 Security protects the integrity of information throughout each stage of the life cycle.

4.6.1 The security functionality ensures protection of objects, data, and the software. 4.6.2 Standard security and protection are provided, including: (1) physical access controls by: I) application ii) function iii) table row, table column level iv) scope of authority (2) controls to: I) log number of unsuccessful attempts ii) lock out user after a predefined number of unsuccessful attempts (3) user ability to change password (4) system requirement for user to change password at pre-defined frequencies (5) security logs of administrative activity are kept and password protected 4.6.3 Security and protection are provided for objects requiring higher levels of security than Unclassified and Protected. 4.6.4 Access is based on the concept of access privileges rather than the need for different directories or drives. Access privileges are based on: (1) security classification of users (2) RC Codes (Cost Centres) 4.6.5 Access privileges can be assigned to: (1) individuals (2) work groups 24

4.6.6 Information such as user security level is automatically drawn from other databases. 4.6.7 Authorized public access is accommodated, e.g. through a special RC code, or other means. One of the access methods is via the Internet. (Vendors should be asked to describe their approach.) 4.6.8 No unauthorized access to the system, objects or data is permitted (additional control with use of password, key). 4.6.8 Profile information is defaulted to unlimited access. There is an override capability at the departmental level and the distributed repository level to limit access. 4.6.9 The system administrator assigns access rights and controls access based on: (1) user (2) group (3) role 4.6.10 Multiple classes and levels of security must be able to be defined/assigned. 4.6.11 Security classes and levels are able to be defined by the system administrator. 4.6.12 Access to the master database is controlled. 4.6.13 Ability to update/downgrade security classification of documents automatically is provided.

25

5. 5.1

TECHNOLOGY REQUIREMENTS Tool sets and Application Utilities includes items such as APIs and utilities to customize.

5.1.1 The following tool sets are included: (1) Application Program Interfaces (API's) or other facility to permit the development of cross-platform linkages and applications. (2) tools to enable configuration. (3) Utility to import and validate data, especially data from legacy systems. (4) Tools to identify customization for migration to a new release and to provide automatic retrofit of customization with new upgrade. (5) Automatic software release version control validation across client installations. (6) Automated implementation of changes to client installations. (7) Tools to facilitate capacity planning, performance, and optimization, and to alert systems technical support when approaching capacity limits. (8) Tools to facilitate data recovery in the event of loss or corruption of data and indexes. (Vendors should be asked to indicate whether the tool/tool set is proprietary or third party, with the name of the third party vendor.) 5.2 New Releases includes rules to implement new releases.

5.2.1 New releases are made available across a variety of database platforms simultaneously. 5.2.2 New releases and documentation are available in both official languages simultaneously. 5.3 Application Models includes descriptions of how these models are presented.

5.3.1 The following application models are current and available (on a non-disclosure basis if required): a) entity relationship diagrams b) database schema c) data flow diagrams d) data dictionary e) workflow process diagrams (Vendors should be asked to advise what is available at the detailed architectural level.)

26

5.4

Architecture defines the operating environment.

5.4.1 The following architectural scenarios are accommodated: (1) The software and database management operates in client/server mode. (2) The software will run on a server separate from the database server and separate from the clients. (Vendors should be asked to explain how client/server works in the product environment and to provide options pertaining to the distribution and processing of the application.) 5.4.2 An environment based on multiple architectures and servers is accommodated. 5.4.3 The facility to ensure data transaction integrity is provided. 5.4.4 Referential integrity is ensured. 5.4.5 In a distributed environment, a 2-phase commit (or other approach to 2-phase commit) or data replication is ensured. 5.4.6 Consolidation of data for reporting in a distributed environment is provided 5.5 Data Sharing & Application Integration defines how the software must integrate with other products and systems.

5.5.1 Integration with other windows-based software compliant with the following standards: (1) OLE 2 (2) MAPI (3) SMTP (4) VIM (5) Apple 5.5.2 Data sharing/access requirements via batch/periodic methods: (1) ODBC (2) ANSI Standard SQL (3) Remote procedure calls (4) CORBA 5.5.3 Data sharing/access requirements on-line methods: (1) ODBC (2) ANSI Standard SQL (3) Remote procedure calls (4) CORBA 27

5.5.4 Other software: Synchronization of data e.g. automated real-time, sharing common tables. 5.6 Technology Platforms lists the operating systems and hardware that the software must operate under.

5.6.1 The software operates on an ANSI SQL compliant relational database system. 5.6.2 The software operates on the following relational database systems: (1) Oracle 7 (2) MS SQL Server for NT (3) Sybase System 10 (4) Informix (5) Ingres (6) DB2 (7) Other (please state versions) (Vendors should be advised that software which operates on multiple database systems is highly desirable and will be scored accordingly). 5.6.3 The software should run on the following server hardware and operating system combinations: (1) Intel - Windows NT AS (2) RISC - Windows NT AS (3) DEC - OSF (4) DEC - Windows NT (5) HP - HP-UX (6) IBM - AIX (7) IBM-MVS (8) SMP Intel - Windows NT AS (9) Unix 5.6.4 The software runs on the following other server hardware and operating system combinations: (1) Sun - Solaris (2) SMP Intel - UNIX (3) IBM AS400 (4) HP - MPE-UX (5) HP - MPE-XL (6) Avion (UNIX) (7) Motorola (UNIX) (8) Other (please identify)

28

5.6.5 The software operates with the following client configurations: (1) 386 with minimum 8 megs of RAM (2) 486/33 with 8 megs of RAM (3) Pentium (4) Macintosh 5.6.6 The software operates with the following (or latest subsequent) client operating systems: (1) Windows 3.1 (2) Windows NT 3.5 (3) Windows for Workgroups 3.11 (4) Windows 95 (5) OS-2 (32 bit) 2.1 or latest equivalent (6) MAC System 7 or latest equivalent 5.6.7 The software operates with the following (or latest) network operating systems: (1) Novell 3.x (2) Windows NT AS (3) Pathworks (DEC) (4) Banyan Vines (5) MS LAN Manager (6) Appletalk 5.6.7 The software operates with the following wide area network protocol: (1) TCP/IP (2) DECNET (3) ATM 5.6.8 The software operates with commercially available e-mail environments including: (1) MS Mail (2) WordPerfect Office (3) Banyan Mail (4) Novell Groupwise 4.1 (5) cc mail 2.x (6) Lotus Notes 3.x (7) Beyond Mail (8) Teamlinks 5.6.9 The software operates with external e-mail and messaging systems. (1) Internet (2) X400 (3) X500 (4) Other (please specify) 29

Additional Information Requirements which should be requested from the Vendor: A1. A2. A3. A4. A5. A6. A7. A8. A9. Describe database server requirements for software, specifying minimum and recommended requirements. Describe mass storage hardware requirements for software. Describe database repository approach for the software, and recommendations. Describe integrated hardware components required by the software, including optional components such as: scanning equipment, OCR equipment, WAN requirements. Provide generic workflow and information flow model and descriptions aligned with the software. Provide generic integrated hardware platform topology diagrams and information flow models. Provide generic software platform model, including suggested third party software addon requirements. Provide certification obtained as part of software solution as appropriate. The capability to search multiple document repositories is being addressed in the new Document Management Alliance (DMA) specification. Future versions of the software must comply with emerging document management standards such as DMA, ODMA, etc. Please describe your company's strategy in this regard.

A10. Provide description of the approach and underlying technologies used to manage and effect the storage of user provided data. Specifically, identify how both the profiles and objects are stored.

30

APPENDIX A- Glossary of Definitions BF (Bring Forward): A method of requesting an object, either electronic or non-electronic, to be retrieved and delivered on a future date. Compound document: An electronic document comprising information in more than one format (e.g. a wordprocessing file, a spreadsheet, and an e-mail cover message). Document management: A system for managing the capture (when created or received), classification (cataloguing), storage, retrieval, revision, sharing, reuse and disposition of documents. Dynamic document: A document including hot links to other objects (OLE, spreadsheets, databases, etc.) File: According to context, can be either: a) a computer file containing data of some sort; or b) a collection of documents related by subject or some other attribute. The latter are physical files stored in filing cabinets in the paper world or virtual files in the electronic world. Object: According to context, may refer to an object in the generic sense (OLE, object-oriented, etc.) or to a "document". In the latter sense the object may be a paper or electronic document, a video, a sound recording, a photograph, a rock sample, or any other information item to be managed. Profile: The set of structured data fields describing attributes of an object (document). Profile data may be extracted from electronic sources such as the message header, the object itself, the classification or financial database, or may be entered by people. Profiles may describe electronic or non-electronic objects. Non-electronic objects: Includes items such as paper, photographs, maps, artwork, realia, etc., which exist in physical form. Some such items may be converted to electronic form and managed as such, or they may be managed in their original physical form. In some cases it may be necessary to manage both the physical and electronic form. Realia: Actual objects (specimens, artefacts) as opposed to replicas.

31

RC (Responsibility Centre) code: A component of the government financial coding system that identifies a specific work unit. Also known as a cost centre code. Different terminology may exist in different government departments and agencies. User: Everyone utilizing the system, including knowledge worker, operational staff, records management specialist, the public, etc.

32