infor · web viewspecify which of the following two methods are used to relate retention...

RFP 1605-B Electronic Document and Records Management System

Appendix A – System Requirements

Proponents are required to complete this appendix and include it with their submission.

The System Requirements Matrix below is organized into categories of requirements and/or functionality. The Town will use Proponent’s responses in this matrix to determine suitability of the solution proposed.

The Matrix consists of five columns; from left to right these are:

1. Item # - For reference purposes2. Requirement – Description of the requirement, feature or functionality of the EDRMS desired by

the Town.3. M/R – Specificities if the requirement is Mandatory or Rated. If Mandatory, the requirement

must be satisfied or the proposal may be rejected. If Rated, the proposal should contain these features and the response will be evaluated and rated based on the response.

4. Response – Vendor’s response to the requirement, to be limited to one of the following four items in the Response column of the table below:

Response Meaning Definition

Y Yes This requirement currently exists and can be demonstrated.

P PendingThis requirement is scheduled for future release and will be incorporated at no additional charge prior to system implementation. Please state the estimated release date.

E ExtraThis requirement is not currently available, but can be provided as a modification at an additional cost. Please details in the Explanation column along with the number of hours and cost for the modification.

3rdThird Party

Indicates that the requirement is provided by a 3rd party product or service. Provide detailed information in the Explanation column.

N NoThis requirement is not supported and/or is not provided as part of this proposal.

5. Explanation - Explain, in as much detail as necessary, how the proposed solution meets the requirement. The more detailed the response provided by the Proponent, the more chance there is of obtaining a higher rating for the stated requirement. Proponents shall provide as much detail as necessary to ensure a clear understanding.

Depending on the system platform being either on-site installable client/server or a hosted system, some of the system requirements may not apply to your proposed solution. If this is the case, please indicate “Not Applicable” in the column 5, Explanation.

of 28


Section 1 – System General

Item # Feature Description Weighting Response (Y/P/E/N) Explanation

1-1 Explain in specific terms what the user experience (UX) will be like for the EDRMS user. Include the approach to SharePoint configuration (Content types, locations, metadata, security, etc.), what the end user will see on their screens, how they will interact with the system, etc.

M

1-2 Content Types. Explain how content types will be defined and implemented.

M

1-3 Retention schedule. Explain how the retention schedule is implemented/deployed in the SharePoint environment

M

1-4 Locationing. Where will end user content be stored? Explain your overall approach to implementing and deploying the following SharePoint elements. For each, explain when and why these elements would be utilized.

1. Sites2. Libraries3. Folders4. Document sets

M

1-5 Access Control. Explain your general approach to, and specific implementation of, access control in the proposed solution. How will end user access to content be determined? Specify your usage of:

M

of 28


1. Groups (of users)2. Document-level permissions3. Document Access Restrictions (restrict access to specified documents to specified end users)

1-6 Case Management. Explain how records management cases will be deployed within SharePoint, including any usage of libraries or document sets or folders as cases.

M

1-7 Site navigation. Explain how end users will navigate to sites, libraries, or other SharePoint locations of interest.

M

1-8 Shared Lists. Explain where and how Managed Metadata (taxonomy, term stores) will be utilized as a means of selection of metadata values, versus non-managed metadata selection lists.

M

1-9 Dashboard. Explain how the user's SharePoint landing pages will be structured, configured, and presented onscreen. What are the elements that will be presented to the user, and how are they laid out on the screen? Are any third party products to be utilized? How does a user navigate to the projects/pages of interest?

M

1-10 Office Integration. Explain how the solution will be configured such that a user of Microsoft Office will be able to store documents into SharePoint with minimal keystrokes.

M

1-11 List all pre-configured reports supplied with the R

of 28


proposed solution.1-12 Explain how custom reports

would be produced using the proposed solution. Such reports must include data from tables supplied by the proposed solution, such as events, categories, physical records, etc. Identify any third party tools that may be required or recommended.

R

1-13 List and briefly explain the purpose/function of each SharePoint web part included in the proposed solution.

M

1-14 List the name and function of all SharePoint timer jobs that are supplied with the proposed solution.

M

of 28


Section 2 – Basic Records Functions

Item # Feature Description Weighting Response (Y/P/E/N)

Explanation

2-1 Specify which of the following three architectural approaches (models) the proposed solution utilizes:

1) Augmentation: Utilizes and builds upon native SharePoint recordkeeping features.

2) Toolkit: Recordkeeping maintained outside SharePoint, and applied to SharePoint via a connector.

3) Displacement; Recordkeeping is carried out exclusively within SharePoint, does not utilize native SharePoint recordkeeping capabilities.

M

2-2 Specify which of the following native SharePoint recordkeeping features the proposed solution utilizes:1) Content Organizer2) Information Management Policies3) Records Center

M

2-3 Allow bulk updating of records-related document metadata fields such as Record ID, Category ID (classification against File Plan), Vital, etc.

R

2-4 Define a relationship between a specified Record, and a second specified Record (Record relationship).

R

2-5 Define a relationship between a specified Record, and multiple additional

R

of 28


specified Records (Record relationship)

2-6 Allow for a "records policy" (one or more retention stages) to be applied to a Document in SharePoint that has not been declared as a Record. Specify which of the following capabilities this feature provides:1) Retention period2) Permitted actions following retention period3) Audit trail of actions carried out by this policy4) Policy triggers (if applicable specify the triggers).

R

2-7 Specify which of the following a Records retention policy can be applied to:1) Individual Document2) All Documents in a specified SharePoint library/folder3) All Documents with specified content type

M

2-8 Solution provides a programmatic interface whereby a custom external program/process can carry out the following operations:1) Create a new Category in the File Plan.2) Update the Event Date field for events related to a File Plan Category. e.g. enter the date value for contract end date.

M

2-9 Allow a Document to be declared a rendition of an existing Record.

R

2-10 User is unable to edit/delete either the content or the metadata of a declared

M

of 28


record2-11 RM administrator is able to

edit any metadata field of any declared record, but NOT the content.

M

Section 3 – Vital Records


Explanation

3-1 Allow an individual declared record or physical record to be marked as Vital.

M

3-2 Allow an entire category to be designated as Vital. All records classified against the specified category will be automatically marked as Vital, both current and any future records classified against that category.

M

3-3 Allow all records in a search result to be marked as Vital. M

Section 4 – Declaration - General


Explanation

4-1 Provide a means of on-screen navigation of the file plan within a document metadata field during manual document declaration

R

4-2 Allow declaration to be automatic based on storage in a specified SharePoint location (library or folder).

R

4-3 Allow a document to be declared in-place, i.e. made immutable, classified against the file plan, and

M

of 28


marked as a record without moving to the records center.

4-4 Allow a document set to be declared as a single record R

4-5 Allow a document set to be declared as individual records within a single category

R

4-6 Allow a document to be declared a record automatically upon upload into SharePoint

M

4-7 Allow a user to declare a document as a record via the Send To method of sending a document to SharePoint

R

4-8 Allow a user to declare a document as a record via the Save As action within Microsoft Word, PowerPoint, or Excel

R

4-9 Allow a user to declare an existing document in SharePoint to be declared as a record.

M

4-10 Allow a user to declare a selection of multiple documents to be declared as records, all to the same file plan category

R

4-11 Allow a user to declare a selection of multiple documents to be declared as records, where different documents can be classified against different file plan categories

R

4-12 Provide a SharePoint ribbon button for manual declaration of documents as a record.

M

4-13 Allows SharePoint objects to be declared as records. List which SP objects can be declared (Sites, Calendar,

R

of 28


Workflows, Lists, Folders, Libraries, etc)

Section 5 – Declaration – Rules Based


Explanation

5-1 The proposed solution allows declaration to be automated via the creation of Document Handling Rules (DHR) rules that automatically trigger declaration

M

5-2 A DHR must able to specify the timing of a document declaration (i.e. when it will be declared).

M

5-3 A DHR must be able to specify the location (library or folder) to which a document will be routed when declared.

M

5-4 A DHR must be able to specify the classification (file plan category) to be assigned to a document.

M

5-5 A DHR must be able to be applied to a document not declared to be a record.

R

5-6 A DHR can be applied to all documents associated to a specified SharePoint Content Type

M

5-7 A DHR can be applied to all documents located in a specified SharePoint Location (library or folder).

R

5-8 A DHR can be applied to all documents located in a specified SharePoint Location (library or folder) AND a specified content type

R

5-9 A single DHR must be able to include any document M

of 28


metadata field (column property)

5-10 Specify all operators that can be used within a DHR, for example: = >= < <= NOT =

M

5-11 Specify the maximum number of single expressions that can be contained in a single DHR, where a single expression is a property, an operator, and a value, such as:Field <Approved> = Yes

M

5-12 Allow for a regular expression within a rule to be used for pattern matching

R

5-13 Allow DHR rules to be joined together as a group R

5-14 DHR rules allow a "Like" operator to provide for fuzzy searches

R

5-15 Allow multiple rules to be evaluated on a given document or document(s) at the same time

R

5-16 Provide a priority ranking for multiple rules that could apply to a given document(s) at the same time.

R

5-17 Allow for DHR Variable Substitution. The rule can specify a variable for a specified document metadata property, and automatically substitute the value of the property for the variable. With this capability for example, only a single rule would need to be created for all tertiary-level

M

of 28


case categories under a secondary-level case parent category.

5-18 Allow for a DHR rule to be extended with custom coding, such as C# or scripting language

R

5-19 Allow a DHR to contain a record category metadata field value

R

5-20 A DHR rule can specify that declaration will occur immediately upon upload to SharePoint

M

5-21 A DHR rule can specify that declaration will occur after a specified time period following upload to SharePoint

M

5-22 A DHR rule can specify that declaration will occur when a document metadata field contains a specified value.

M

5-23 A DHR rule can specify that declaration will occur following a period of time during which the document has not been modified (inactive)

R

5-24 A DHR rule can specify that declaration will occur when a specified external event occurs (event trigger)

R

5-25 A DHR rule can undeclared a document previously declared to be a record

R

5-26 Allow for each DHR rule to be assigned a name/title. Specify the maximum number of characters allowed in a DHR title.

M

5-27 Provide a test mode for DHR rules that allows the operator to test the rule by evaluating the rule and presenting affected documents prior to running

R

of 28


the actual rule.5-28 Specify the number of

conditions that can be included in a DHR

R

Section 6 - Disposition


Explanation

6-1 Allow disposition to be carried out on declared records NOT stored in the records center (in-place disposition).

R

6-2 Require an authority code (or similar record metadata field) to be present before a record will be disposed.

R

6-3 Require business unit approval to be present prior to disposition taking place

R

6-4 Allow a business unit approval workflow to be defined and assigned to individual SharePoint users or groups for the purpose of disposition approval

R

6-5 Allow a retention rule cut-off to be a pre-defined event (event-based retention rule)

M

6-6 Allow a retention rule cut-off to be a period of time (time-based retention rule)

M

6-7 Allow a retention rule cut-off to be based on a relationship to another record (record relationship-based retention rule), such as superseded.

M

6-8 Allow a retention rule cut-off to be a custom-defined condition (customized retention rule)

R

6-9 Allow for an event trigger date to be recurring. If the proposed solution supports

R

of 28


a recurring event date, specify the types of recurrences allowed (e.g. daily, weekly, monthly, etc.)

6-10 Allow for the units of time measurement to be specified for the retention period, as shown: Days (optional) Weeks (optional) Months (Mandatory) Years (Mandatory)

M

6-11 Explain how the proposed solution would provide for non-recoverable disposition, where records deleted via disposition cannot be recovered following disposition completion. Include the cost of any third-party products that may be required.

R

6-12 The proposed solution must allow for more than one retention stage (phase) to be assigned to a given category in the file plan. Specify how many stages are allowed in total for any given category.

M

6-13 It must be possible for a given retention rule(s) to be assigned to more than one specified category in the file plan.

M

6-14 The trigger date for non-case records (records classified against administrative categories) must be definable as any specified document metadata date field.

M

6-15 Specify which of the following two methods are used to relate retention stages to one another in a multi-stage retention, as

M

of 28


shown:

Synchronous. A stage has to complete before the next stage can begin. Once stages are defined, they cannot be rearranged, as each stage is linked to the prior stage.

Asynchronous. Any given stage can begin without needing the prior stage to complete. Stages can be re-arranged into any order.

6-16 Specify the maximum allowable number of characters allowed in the name of a retention stage

M

6-17 Specify which of the following triggers can trigger a retention stage: Cutoff (event or document metadata field) Document Date (document metadata date field) Previous Stage End Event Date Category Closed

M

6-18 Specify which of the following actions can be specified at the end of a retention stage: Advance to next stage Move Declare Undeclare Delete Keep Permanent Transfer (out of system) Workflow (trigger a named workflow) Close Category

M

6-19 Print disposition certificates that show which records were destroyed, providing for a signature by the attending Records Manager

R

of 28


6-20 Produce a list of physical records that must be manually destroyed

R

6-21 Deletes links from the workspace once the linked record has been destroyed or transferred from the record centre

R

6-22 Move/Transfer of records will retain associated Metadata.

R

Section 7 – Legal Holds


Explanation

7-1 Explain how the proposed solution applies legal holds. In particular, explain the relationship (or lack thereof) between SharePoint's native legal hold capability, and the proposed solution's legal hold capability.

M

7-2 A hold will prevent the following actions to all held documents as long as the hold is in effect:1) Disposition2) Deletion3) Modification of document content4) Modification of document metadata

M

7-3 Allow a hold on an individual record (electronic or physical)

M

7-4 Allow a hold on an undeclared electronic document in SharePoint

R

7-5 Apply a hold to the entire contents of a specified Library.

R

7-6 Apply (and remove) a hold to a specified SharePoint R

of 28


site7-7 Apply (and remove) a hold

to a specified file plan category

M

7-8 Apply (and remove) a hold to all documents in a search result list

M

7-9 If a hold is applied to a location (library or folder), the hold automatically propagates to all subordinate locations

R

7-10 If a hold is applied to a location (Library or folder), all documents added to the location in the future are automatically held

R

7-11 If a hold is applied to a file plan category, all documents against that category in the future are automatically held

R

7-12 Allow for all new versions of a held document to be automatically held by the same hold applied to the prior version.

R

7-13 Dis-allow new versions of a document that is on hold R

7-14 A hold will dis-allow a held documents(s) from advancing to another disposition stage/phase

R

Section 8 – File Plan Management


Explanation

8-1 Allow any alpha-numeric characters to be included in Category ID field

M

8-2 Allow any alpha-numeric characters to be included in Category Title field

M

8-3 Allow a dash "-" symbol to be included within a

R

of 28


Category ID field8-4 Specify the maximum

number of characters allowed in a Category ID field

M

8-5 Specify the maximum number of characters allowed in a Category Title field

M

8-6 Specify the maximum number of characters allowed in a Category Description field

M

8-7 Automatically prevent any two categories from having the same Category ID within the same hierarchical level of the file plan

R

8-8 Specify which symbols are not permissible in the Category ID field (e.g. *&^%#_-+)

M

8-9 Enforce the condition that no two file plan categories can have the same complete category ID (where a "complete" category ID contains all levels, separated by dashes or similar symbol).

R

8-10 Provide for an Authority field for each Category R

8-11 Automatically assign next available Category ID field when creating a new category

R

8-12 Each category must specify whether the category is of type Case or not

M

8-13 Specify an Open Date and Closed Date fields for each category

R

8-14 Allow custom-created fields to be added to any Category M

of 28


Section 9 – Import\Export


Explanation

9-1 Provide a process whereby physical records (folders, boxes, artifacts) can be imported into proposed solution from a data file.

R

9-2 Allow for mapping of record metadata fields in the source data file to corresponding target fields in the proposed solution.

R

9-3 Allow for an import/export of electronic and physical records, including the records and all associated metadata field values.

R

9-4 Allow for an import of file plan categories R

Section 10 – Search & Retrieval


Explanation

10-1 Explain how the proposed solution allows for search/retrieval of records, including physical records, where the search includes fields defined by the proposed solution, i.e. that are not native to SharePoint. Include any SharePoint web parts needed for searching, and/or for viewing of search results.

M

10-2 Must be able to search for both electronic and physical records in a single query

M

10-3 Explain how electronic and physical records are combined in a single search result list within SharePoint

M

of 28


10-4 Specify which of the following actions can be carried out on a physical record selected from a search query result list:1) Request the record (mandatory)2) Charge in/out the record (mandatory)3) Pass record along to another user (optional)4) View the record's descriptive metadata (barcode, history, status, etc.) (optional)

M

10-5 Specify which of the following actions can be carried out on a record (electronic or physical) selected from a search query result list:1) View record Properties (mandatory)2) Check in/out (optional)3) Move to a different location (optional)4) View all versions of the record (optional)5) View all other records classified against the same category. (optional)

M

10-6 Browse for declared records (only), filtered on either of the following three elements:1) All records2) Filter by file plan category3) Filter by box

R

10-7 Search file plan categories by any category field value M

10-8 Search Physical records by any physical record field M

10-9 Search electronic records by any document metadata field

M

10-10 Search all records, both electronic and physical, by M

of 28


any combination of electronic and physical record metadata fields

10-11 Search for records and/or or non-records, including any physical records

R

10-12 Search electronic records and electronic non-records within the same query

R

10-13 Allow the administrator to specify the maximum number of search results per display page in the results screen

R

10-14 Allow the administrator to specify the maximum number of total search results allowed per query

R

10-15 Specify the total maximum allowable search results per query

M

10-16 Specify the maximum allowable search results per onscreen display page

M

10-17 All search results are displayed in accordance with security restrictions/permissions as applied by both Sharepoint and RM add-in.

M

10-18 Related records are located and idenified as realted in search results.

M

10-19 Specify on which properties the search results can be filtered, such as: Content Type User/Group name Metadata field Category ID

M

10-20 Allow Boolean operators within a search query such as AND, OR, NOT etc. Specify which Boolean operators are supported

M

10-21 Allow a grid or list view of search results R

of 28


10-22 Provide a refinement panel within the search result list. R

Section 11 – Security & Information Management


Explanation

11-1 System provides a login and authentication mechanism for staff accessing the system, preferably Active Directory integrated.

M

11-2 Explain how the proposed solution applies security control to declared records. Explain the relationship between SharePoint's native security control and the security features of the proposed solution. Identify the various functions (menu option or capability) that can be granted to users or roles. Explain how access control is carried out in the on records in the proposed solution.

R

11-3 Specify which permissions can be assigned and what actions can be carried out on declared records, and which can in turn be assigned to roles, users, or groups

R

11-4 Assign a permission to all records in a specified file plan category

M

11-5 Allow a list of authorized users to be assigned to an individual record (supplemental marking). Access to this record will be restricted exclusively to the users in the list assigned to the record. This access restriction over-rides all

R

of 28


other access to the record.11-6 Allow a list of authorized

users to be assigned to an individual file plan category (supplemental marking). Access to all records in that category will be restricted exclusively to the users in the list assigned to the category. This access restriction over-rides all other access to the records in the category.

R

11-7 Allow a record metadata field to constrain the access to the record (Access Constraining Metadata). Only users associated with the field can access the record, and only when the metadata field contains a specified value.

R

11-8 Allow a category metadata field to constrain the access to the records in the category (Access Constraining Metadata). Only users associated with the field can access the records in the category, and only when the metadata field contains a specified value.

R

11-9 System provides an activity log detailing user logins and transactions

R

11-10 System has the ability to enforce definable password complexity, expiration and configurable failed login lock-out rules.

M

11-11 System has account security functionality to limit user access to sections of the application and/or restrict access to read-only. Please provide details on levels and

M

of 28


granularity of the security model.

11-12 Security rights can be applied to definable groups of users in addition to individual users.

M

11-13 Specify encryption and authentication methods and protocols used when storing, transmitting and/or accessing data.

M

11-14 The Town is required to comply with the Freedom of Information and Protection of Privacy (FOIP) Act in Alberta. All data stored in the system must comply with the FOIP Act.

M

Section 12 – Audit Trail


Explanation

12-1 Describe your products audit and logging facility/capabilities. Include: -Types of security events -How and where events are logged -Access controls to the audit records-How audit records are protected from deletion and unauthorized disclosure and modification -Administrator privileges -Configuration capabilities

M

12-2 Please confirm which of the following information yourproduct is capable of logging and including in an audit record: Please provide as much additional information

you feel is applicable.- User ID or process ID

M

of 28


causing the event- Success or failed attempts to access security file- Date/Time of event- Event type- Success or failure of event- Success or failure of login attempt- Denial of access resulting from excessive number of login attempts- For add, change or delete events: name of data object written or deleted- Granting elevated privileges- For identification and authorization: origin of request (originating host IP address)- Discreet auditing of specific data elements

12-3 Is the audit function configurable to allow the administrator to select which events are to be logged and which data elements are captured about each event?

M

12-4 Describe how your system audits access and security, logging user usage etc.

M

12-5 Describe how your system reports security and audit information. Is the information shown intuitive for an investigation?

M

Section 13 - Technical


Explanation

13-1 Any software included in the proposal is the latest release and the vendor is

M

of 28


authorized to license the software to the Town.

13-2 The system is compatible with at least Microsoft Windows 7 and newer desktop operating systems and PC hardware. Provide system requirements and/or hardware/OS/software recommendations.

M

13-3 Solution is based on SharePoint 2013 in an on-premise infrastructure

M

13-4 The system supports operation on Microsoft 2012 or 2016 Server as the server platform.

M

13-5 The System is fully compatible with SQL Server 2012 and above.

M

13-6 The system supports deployment in a VMware virtualized server environment.

M

13-7 The system and its supporting software do not require the use of hardware dongles for licencing enforcement.

M

13-8 Identify any dependant software components that must be deployed to the desktop, such as Acrobat, browser plug-ins, Java, etc.

M

13-9 Describe the method(s) of integration with other systems. For example, Web Services or API.

13-10 All software applications and any recommended hardware must be compliant with a routed IP network.

M

13-11 Describe the process of announcing, providing, deploying and scheduling

M

of 28


of system updates/patches.13-12 Do you utilize any third

party software or products to support system functionality? If yes, please identify.

M

13-13 Identify hardware requirements for any other required peripherals or network attached hardware

M

13-14 Provide a list of non-functional requirements that the Town would require in order to achieve ideal infrastructure performance, capacity and compatibility for the proposed software solution.

M

Section 14 - Support


Explanation

14-1 The Town will be assigned an account representative act as a central point of contact.

M

14-2 Provide details of your standard support agreement including priority levels and escalation procedures as required in Section 1.6 of the main RFP document.

M

14-3 The Proponent has a dedicated support website with product information, support and software release downloads. Please provide a link.

M

14-4 The Proponent’s support provides a ticketing or issue tracking system that is

M

of 28


accessible on online.14-5 The Proponent provides

Phone support. Please indicate hours of operation for the Mountain Time zone in which Canmore is located.

M

14-6 The Proponent will have the ability to remotely access the Town’s systems in order to provide support. Please explain methods used.

M

14-7 System documentation and training materials are available online.

M

14-8 End user training can be provided remotely via the Internet.

M

14-9 Please indicate the rate for customizations and modifications (i.e. custom reports)

M

14-10 Describe how support could be maintained and/or system operation be preserved in the case the vendor should cease operating.

M

14-11 The proponent shall be able to provide the Town the following minimum maintenance requirements:- Major product revisions & upgrades- Software Patches- Performance Enhancements- Capacity Recommendations- New Versions/Releases

M

14-12 Maintenance shall include enhancements to customizations made to satisfy the deliverables

M

of 28


described in the RFP.14-13 New Versions, releases and

patches shall provide backwards compatibility for the customizations, if any, that are utilized to satisfy the deliverables outlined within the RFP.

M

of 28