Appendix_1_(Excel)_CDMS_Requirements_Matrix.xlsx
XLSX spreadsheet 96 KB Posted
- Attached to
- Claims Document Management System (Re-Bid)
- Solicitation number
- 26-P-00037
- Issued by
- Hillsborough County, Florida
About this file
This document is an Appendix to a Request for Proposals issued by the City of Tampa, Florida for a Claims Document Management System (CDMS) that will support the Risk Management Department's insurance claims processing operations. The CDMS requirements matrix outlines functional and technical specifications across multiple categories including structure features, capture capabilities, storage and retrieval, management functions, preservation, delivery, and technical infrastructure. The City requires a cloud-hosted solution that integrates with the existing Assure Claims system and supports document and records management, workflow automation, collaboration, and business process management. A pre-proposal conference is scheduled for December 9, 2025, at 2:00 pm, with proposal submissions due December 23, 2025, at 3:00 pm. The contract will have an initial five-year term with potential renewal options. Key functional requirements include integration with Microsoft Office applications and MS SQL Server, support for various document formats (PDFs, images, videos, audio files, GIS content), comprehensive audit trail capabilities, metadata management, version control, check-in/check-out functionality, advanced search and retrieval features, workflow automation with role-based access controls, retention and disposition scheduling aligned with Florida records retention requirements, redaction capabilities for public records requests, and reporting and analytics functions.
The City's total budget for implementation is $120,000. The requirements matrix identifies 622 total specifications across priority levels, with Priority 1 requirements deemed critical and mandatory to include in the fixed-price bid without customization, Priority 2 requirements necessary but allowing business process adjustments, and Priority 3 requirements considered important but potentially requiring additional costs identified separately by the vendor. The evaluation criteria include scope of services (15 points), company experience (10 points), cost (40 points), project schedule (10 points), references (5 points), criminal history screening practices (5 points), and Small Local Business Enterprise (SLBE) participation (15 points). Both the primary contractor and any SLBE subcontractors must hold City of Tampa SLBE certification prior to the RFP opening date to qualify for rating points. The system must support integration with the City's existing technology infrastructure, comply with records management industry standards including MoReq2 and DoD 5015.2 specifications, accommodate the State Library and Archives of Florida General Records Schedules, and provide comprehensive implementation support including onsite training, documentation, content migration assistance, and ongoing technical support with service level agreements.
View the file
Other files
Show all 32
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Cover Document Management System - Requirements Matrix
Functional Requirements Processes
| Please state the level that your proposed system satisfies each requirement against the following table: | Score |
| Provided for in the base system as Standard Functionality using standard configuration options | SF |
| Provided as part of base system in Next Release | NR |
| Provided for by a Modification/Customization to base system | MD |
| Provided for through a Standard Report in base system | RQ |
| Provided through Third Party Software Add-On to base system | TP |
| Cannot Meet Requirement | NA |
&"Tahoma,Bold"&12APPENDIX 1
Priority Levels Document Management System - Requirements Matrix
Requirements Matrix Priority Levels
| Priority 1 and 2 Specifications |
| The Proposer is required to include in their fixed-price bid all functionality identified as Priority 1 and Priority 2 which are deemed critical to the City. |
| Priority 3 Specifications |
| The City understand that an optimal balance must be found between configuration of a base product, and customization to meet requirements specific to the City. It is therefore important to discern where this balance lies for each of the solutions it takes under consideration. For answers that require detailed explanation, the responder must include the requirement reference ID. The respondents are encouraged to explain in detail, how their system's flexibility will accommodate change. |
| Priority | Definition | Comments |
| Priority 1 | Critical | The City must have this requirement; therefore, the City is not asking for detailed pricing that may be attributed to the item, but is requesting the Proposer's all-inclusive pricing to include compliance with the requirement. The solution must meet the requirement and City business process without customization. |
| Priority 2 | Required | The City must have this requirement; therefore, the City is not asking for detailed pricing that may be attributed to the item, but is requesting the vendor's all-inclusive pricing to include compliance with the requirement. The solution must satisfy the requirement, but the City is not prescribing how the solution is satisfies the requirement. The City will adjust business processes to meet the solution. |
| Priority 3 | Important | The City would like this requirement fulfilled but recognize that it may or may not be fulfilled without some additional work from the Proposer. Therefore, the City would like further information regarding any additional costs from the Proposer prior to committing to it. The Proposer must list out all Priority 3 requirements that are NOT met with the 'base' solution, along with the associated pricing. All Priority 3 items that are not listed out will be assumed to be included in the solution. |
&"Tahoma,Bold"&12APPENDIX 1
Requirements
| Claims Document Management System - Requirements Matrix APPENDIX 1 |
| Detailed Requirements |
| Response Codes and Descriptions | Priority | Count | Percent | |
| SF | Standard Function ("Out-of-the-Box") | 1 | 0 | 0.00% |
| 2 | 0 | 0.00% | ||
| 3 | 0 | 0.00% | ||
| NR | Provided in Next Release | 1 | 0 | 0.00% |
| 2 | 0 | 0.00% | ||
| 3 | 0 | 0.00% | ||
| MD | Modification | 1 | 0 | 0.00% |
| 2 | 0 | 0.00% | ||
| 3 | 0 | 0.00% | ||
| RQ | Provided Through Standard Report | 1 | 0 | 0.00% |
| 2 | 0 | 0.00% | ||
| 3 | 0 | 0.00% | ||
| TP | Third Party Software Required | 1 | 0 | 0.00% |
| 2 | 0 | 0.00% | ||
| 3 | 0 | 0.00% | ||
| NA | Cannot Meet Requirement / Not Applicable | 1 | 0 | 0.00% |
| 2 | 0 | 0.00% | ||
| 3 | 0 | 0.00% |
| XX | No Response Provided | 1 | 282 | 45.34% |
| 2 | 279 | 44.86% | ||
| 3 | 61 | 9.81% | ||
| TOTAL | 622 | 100.00% |
| Req ID | Requirement Detail | Priority | Response Code | Cost | Exceptions | Proposer Comments |
| 1. STRUCTURE FEATURES | ||||||
| 1.1. Primary Relationships | ||||||
| 1.1.1. | System should allow a Record to link to (or associate with) other Records. | 1 | XX | |||
| 1.1.2. | System should allow a Document to link to (or associate with) other Documents. | 1 | XX | |||
| 1.1.3. | System should allow a Document to include one or more Records. | 2 | XX | |||
| 1.1.4. | System should allow a Record to be included in one or more Documents. | 2 | XX | |||
| 1.1.5 | System should allow a Retention & Disposition Schedule to apply to one or more Record Series. | 2 | XX | |||
| 1.1.6 | System should allow a Record Series to apply to one or more Records. | 2 | XX | |||
| 1.1.7 | System should allow a Retention & Disposition Schedule to apply to one or more Records. | 2 | XX | |||
| 1.1.8 | System should ensure a Record cannot be changed (i.e. locked to prohibit updates). | 1 | XX | |||
| 1.1.9. | System should allow a Record to be deleted if it is not designated as permanent and if its associated retention date(s) have been reached. | 2 | XX | |||
| 1.1.10. | System should allow a Document to be changed at the discretion of its designated author/owner. | 2 | XX | |||
| 1.1.11. | System should allow a Document to become a Record. | 1 | XX | |||
| 1.1.12. | System should ensure a Document, which is included in a Public Records Request, audit, or other legal discovery, becomes a Record (i.e. locked and classified). | 2 | XX | |||
| 1.1.13. | System should allow for the condition if changes to a Record are necessary, then a new version should be created as a Document. | 2 | XX | |||
| 1.1.14. | System should ensure a Component linked to a Record cannot be deleted. | 2 | XX | |||
| 1.1.15. | System should ensure a Component included (linked) in one or more Records is locked to prohibit updates. If changes to a Component are required, a new version of the Component should be created and then changes applied as appropriate. | 2 | XX | |||
| 1.1.16. | System should allow a Record to have more than one administrative hold applied. | 2 | XX | |||
| 1.1.17. | System should allow for Records that are cross-referenced (i.e. linked) to other Records, and if any Record has a permanent retention, then all related Records should also be permanently retained. Further, before any linked Record can be deleted, the longest retention period should be reached; once this condition occurs, then all related Records can be released for deletion. | 1 | XX | |||
| 1.1.18. | System should support the definition and maintenance of Record types. | 2 | XX | |||
| 1.1.19. | System should ensure that all Records have exactly one Record type. | 2 | XX | |||
| 1.1.20. | System should restrict the definition and maintenance of Record types to an administrative role. | 2 | XX | |||
| 1.1.21. | System should enable an administrative role to restrict the creation of records of specified Record types to specific groups of users, based on business needs. | 1 | XX | |||
| 1.1.22. | System should enable an administrative role to define a Record type as the default Record type for users allowed to capture records. | 3 | XX | |||
| 1.1.23. | System should seamlessly integrate major components with RiskMaster. | 1 | XX | |||
| 1.1.24. | System should allow administrative roles to retrieve, display and re-configure system parameters and settings made at configuration time or at any time during the life of the system. For example, the configuration settings of access rights or classification codes. | 2 | XX | |||
| 1.2. Metadata | ||||||
| 1.2.1. | System should provide mechanisms for the identification of specific metadata/attributes of a document or record to facilitate retrieval. | 2 | XX | |||
| 1.2.2. | System should provide the ability to associate key words and summary information with content. | 2 | XX | |||
| 1.2.3. | System should include auto assignment and manual assignment of metadata using business rules. | 2 | XX | |||
| 1.2.4. | System should include tools to facilitate metadata generation during content item creation, including keyword "pick lists" to allow metadata to be chosen from a pre-defined schema. | 1 | XX | |||
| 1.2.5. | System should provide the ability to define and manage City metadata at the directory level in addition to metadata defined at the record level. | 2 | XX | |||
| 1.2.6. | System should provide the capability to add metadata attributes to the definition of content types including but not limited to the ability to specify the metadata characteristics (string, number, etc.), default values, and valid values (drop-down lists for example). | 2 | XX | |||
| 1.2.7. | System should provide the ability to specify metadata requirements for specific content types (such as asset records, employee records, email) including the ability to specify additional required fields and/or reduce the number of fields required for a particular content type. | 2 | XX | |||
| 1.2.8. | System should automatically capture the file format, including the version, of each component when it is captured and should store it in the metadata of the component. Some information about file format is usually implicit in the component’s filename extension, e.g. “.htm” or “.pdf”; and on occasion it is ambiguous, e.g. “.doc” can specify several unrelated formats. However, the extension alone frequently does not indicate the file format version and sometimes not even the file format itself. File formats are numerous and subject to frequent change. It therefore is not realistic to expect the system to capture information for all file formats. It is therefore acceptable for the system to: |
· specify a list of file formats that can be recognized;
| · rely on reference to an established file format registry (preferably one designed specifically to support digital preservation). | 2 | XX | ||
| 1.2.9. | System should validate the values of metadata entered for all capture processes. | 1 | XX | |
| 1.2.10. | System should be able to automatically capture values from fields defined by an administrative role within the specified document types, using these values automatically to populate metadata elements. Many documents including some office documents and .PDF files include user-configurable metadata elements. It should be possible to configure the system to automatically capture the values of these elements and retain them with the content. | 1 | XX | |
| 1.2.11. | System should allow users who wish to capture content, but who are unable to provide all the mandatory metadata values for it, to store it temporarily in the system. In other words, the system should provide a means of storing information without all its metadata that is without completing the normal capture process. This implies exception reporting and progress monitoring; it does not imply any requirement to treat such content as normal for the purpose of export, transfer, retention, etc. Only the editable metadata values can be changed at a later stage, and fixed metadata (e.g. email transmission data) should remain unchanged. | 3 | XX | |
| 1.2.12. | System should provide automated assistance in capturing electronic content, by automatically extracting as much metadata as possible, for as many kinds of content as possible. | 1 | XX | |
| 1.2.13. | System should provide automated assistance in the capture of outgoing and internal documents (e.g. memoranda or word-processed letters in a specified layout and file format) as records, by automatically extracting the following metadata from them: |
· document date (as in the body of the document);
· recipients;
· any copy recipients;
· subject line (title);
· authors
| to the extent that these are present. The metadata extraction may be achieved by locating metadata within the content, by using a template to identify the metadata and populate a blank document, or by any other means. | 2 | XX | ||
| 1.2.14. | System should log the capture date and time of content both as metadata and in the audit trail. | 2 | XX | |
| 1.2.15. | System should be able to present metadata on-screen. | 2 | XX | |
| 1.2.16. | System should ensure that all mandatory metadata is present for every captured record. | 1 | XX | |
| 1.2.17. | System should prompt the user to enter any required metadata that has not automatically been captured. | 1 | XX | |
| 1.2.18. | System should allow the assignment of multiple keywords (or key terms) to captured content. | 3 | XX | |
| 1.2.19. | System should allow an administrative role to configure whether keywords are mandatory or optional, at configuration time or at any time during the life of the system. | 3 | XX | |
| 1.2.20. | System should provide a capability for the keyword values and other metadata element values to be selected from, or validated against, controlled vocabularies. For example, by means of a pick list or thesaurus. | 3 | XX | |
| 1.2.21. | System should include scanning features with automatic capture of metadata, which should interpret this information for automated classification. | 2 | XX | |
| 1.2.22. | System should be able to capture automatically the metadata associated with content during a bulk import (allowing for manual input of missing or incorrect metadata). | 2 | XX | |
| 1.2.23. | System should validate metadata during import using the same rules as would be used for the manual capture of the content. When the validation process finds errors (such as absence of mandatory metadata, or format errors) it should bring these to the attention of the user performing the importation, in all cases identify the metadata involved, and log errors and actions in the audit trail. | 1 | XX | |
| 1.2.24. | System should enable changes to selected metadata values, subject to access control rights, for example title. | 2 | XX | |
| 1.2.25. | System should automatically record the history, for example dates and details, of any changes to security category, in the metadata of the relevant class or content. For each change made, the history should include: date, user, values before and after the change, and reason. | 2 | XX | |
| 1.3. Audit Trails | ||||
| 1.3.1. | System should keep an unalterable audit trail by automatically capturing and storing information about: |
· any action taken on any content;
· the user undertaking the action;
· the date and time of the action.
By way of illustration, the actions logged in the audit trail should include, but need not be limited to:
· capture of all electronic content;
· re-classification of content within the classification scheme;
· any change to a retention and disposition schedule;
· the placing or removal of a disposal hold on content;
· any change made to metadata, documents, components or electronic records;
· amendment and deletion of metadata by a user;
· changes made to access permissions;
· creation, amendment or deletion of a user or group;
· export or transfer;
· deletion/destruction of records.
| The term “unalterable” in this requirement means that it should be impossible for any user or administrator to change or delete any part of the audit trail. | 1 | XX | ||
| 1.3.2. | System should support the transfer of audit trail data to off-line storage, with secure processes for managing the off-line data, and demonstrate how off-line data can be brought back on-line as and when required. The system should ensure it is not possible for this mechanism to be used as a means of by-passing the controls imposed by the system (for example, by simply moving audit trail data out of the system, then changing or deleting it externally to the system). | 2 | XX | |
| 1.3.3. | System should be able to automatically log in an audit trail any access to any content, and whether the access was to read, print or otherwise. | 2 | XX | |
| 1.3.4. | System should allow for audit trail parameters to be configurable so that administrative roles can configure which actions are automatically logged. | 3 | XX | |
| 1.3.5. | System should log all changes to audit trail parameters in the audit trail. It should not be possible to turn off the auditing of changes to audit trail parameters, so the system does not record in the audit trail, who changed them and when. | 1 | XX | |
| 1.3.6. | System should log in an audit trail all actions performed on records, documents, and components, classes and retention and disposition schedules, regardless of whether the action affects one or more of them. | 1 | XX | |
| 1.3.7. | System should log in an audit trail all changes to metadata values. | 2 | XX | |
| 1.3.8. | System should log in an audit trail all changes to metadata values of physical items. | 2 | XX | |
| 1.3.9. | System should log an annotation of, or amendment to, a record within the record’s audit trail. | 1 | XX | |
| 1.3.10. | System should automatically log in an audit trail all changes made to administrative parameters. | 1 | XX | |
| 1.3.11. | System should ensure that audit trail data is available for inspection on request, so that a specific event can be identified and all related data is accessible. | 2 | XX | |
| 1.3.12. | System should include features that allow all authorized users, including those who have little or no familiarity with the system, to search for information in audit trails. | 2 | XX | |
| 1.3.13. | System should allow users to search audit trails for specified events, content, users, groups, roles, date ranges, and/or time intervals. | 2 | XX | |
| 1.3.14. | System should be able to export audit trail data for specified content and classes without affecting the audit trail stored by the system in any way except for the addition of an audit trail of the export process. | 2 | XX | |
| 1.3.15. | System should allow administrative roles to produce reports on all or part of audit trails. These reports should include but not be limited to, reporting based on any selected: |
· class;
· record;
· document;
· component;
· user;
· group;
| · metadata. | 1 | XX | ||
| 1.3.16. | System should automatically log in its audit trail all details of link changes, if it changes links within content during capture. | 2 | XX | |
| 1.3.17. | System should be able to import audit trail records that show the history of the imported content. | 2 | XX | |
| 1.3.18. | System should not import audit trail content into its audit trail; instead it should store imported audit trail content separately. The imported audit trail should be linked to its related content and maintained separately to avoid producing a mechanism that allows administrative roles to change or compromise the integrity of the audit trail. | 2 | XX | |
| 1.3.19. | System should log audit trail actions for all content affected by relocating and combining activities. | 2 | XX | |
| 1.3.20. | System should log information (preferably using audit trails) about the movements of a physical item including but not limited to: |
· current location;
· previous locations;
· date moved from location;
· date received at location;
| · user responsible for the move. | 2 | XX | ||
| 1.3.21. | System should integrate a workflow audit trail with the system audit trail. | 2 | XX | |
| 1.3.22. | System should ensure a workflow audit trail cannot be changed. | 3 | XX | |
| 1.3.23. | System should provide comprehensive workflow audit trail logging, including read only access of who, what, when. | 1 | XX | |
| 1.3.24. | System should store in the audit trail any changes resulting from record redactions or modifications. | 2 | XX | |
| 1.3.25. | System should automatically log all changes to security category values in the audit trail. | 2 | XX | |
| 1.3.26. | System should capture and store the following information, at a minimum in the audit trail, when an authorized user applies or removes an administrative hold: |
· the date the hold was applied or removed;
· the identity of the authorized user;
| · the reason for the action. | 2 | XX | ||
| 1.3.27. | System should require the administrative role changing or deleting a retention and disposition schedule to enter a reason, with the reason stored in the audit trail. | 2 | XX | |
| 1.3.28. | System should maintain an unalterable history of changes and deletions (possibly in the audit trail) that are made to retention and disposition schedules, including the date of the change or deletion, and the user making the change. | 2 | XX | |
| 1.3.29. | System should keep an unalterable history of decisions and actions taken by the reviewer during reviews, including reasons. The information should be stored as metadata or possibly in the audit trail. | 2 | XX | |
| 1.4. Classification Scheme | ||||
| 1.4.1. | System should support and be compatible with the State Library and Archives of Florida General Records Schedules. | 1 | XX | |
| 1.4.2. | System should include a strategy that uses a diverse set of classification methods enabling multiple access paths to content. Methods should include but are not limited to keyword(s), a taxonomy, and a thesaurus. | 1 | XX | |
| 1.4.3. | System should provide automatic indexing, keyword generation, and full-text searching. | 1 | XX | |
| 1.4.4. | System should provide indexing of content (including Microsoft Office documents, Adobe PDF, scanned images with OCR applied, etc.) within the system. | 1 | XX | |
| 1.4.5. | System should support indexing of content across a number of repository types, including other file systems and databases. | 2 | XX | |
| 1.4.6. | System should provide the ability to categorize content using a classification scheme and business rules. | 2 | XX | |
| 1.4.7. | System should allow for classification of content at time of store into the repository. | 2 | XX | |
| 1.4.8. | System should allow user to select from a personal custom classification list (reflecting previously used or desired categories) along with access to the entire list of searchable categories. | 1 | XX | |
| 1.4.9. | System should associate a new occurrence of content with the Classification Scheme whenever it is created in or captured by the system. | 2 | XX | |
| 1.4.10. | System should allow management of the classification scheme only by an administrative role. | 2 | XX | |
| 1.4.11. | System should allow management of individual classes by specified user roles and/or by a specified group of users. | 2 | XX | |
| 1.4.12. | System should not limit the number of levels in the classification scheme. | 1 | XX | |
| 1.4.13. | System should include the creation of a classification scheme at configuration time in readiness for the capture and/or importation of electronic content. This requirement is intended to allow the classification scheme to be created and modified while the system is being configured, and before used for the management of content. | 2 | XX | |
| 1.4.14. | System should allow the entry of descriptions for all classifications. Descriptions are narrative and used to clarify intended use and/or exclusions of content for the benefit of users. | 1 | XX | |
| 1.4.15. | System should support the importing of all or parts of the classification scheme, at configuration time or at any time during the life of the system. Where any parts are imported, this may be to add to an existing scheme, or to create a new classification scheme if none exists. | 2 | XX | |
| 1.4.16. | System should allow the import of associated metadata, and retention and disposition schedules when importing all or part of the classification scheme. | 2 | XX | |
| 1.4.17. | System should allow administrative roles to add new classes at any point within the classification scheme. | 2 | XX | |
| 1.4.18. | System should support the definition and simultaneous use of multiple classification schemes. This requirement allows some of the content in the system to belong to one classification scheme, while other content belongs to another. | 2 | XX | |
| 1.4.19. | System should allow the classification identifier and related title to be used separately or together. | 2 | XX | |
| 1.4.20. | System should not impose any practical limit on the number of classifications that can be defined. | 1 | XX | |
| 1.4.21. | System should be able to export a list of all content with a specific classification (and its child classifications) in XML format and/or in a human-readable format. | 2 | XX | |
| 1.4.22. | System should allow an administrative role to configure a classification so that it can or cannot store content directly. | 2 | XX | |
| 1.4.23. | System should ensure that during relocation all electronic content remains correctly allocated to the classifications being relocated; and that all content relationships remain correctly linked. | 2 | XX | |
| 1.4.24. | System should allow any user working with a classification to discover its context, in other words, the metadata and parent classes; and should be able to navigate to these parents from the classification. It should be possible to discover the context without having to leave the classification, in a way that allows work with the content to be continued without interruption. | 1 | XX | |
| 1.4.25. | System should require that whenever any classification keyword is changed, an administrative role to enter the reason for the change. | 2 | XX | |
| 1.4.26. | System should require that whenever any classification keyword is changed, the system should keep a clear trace of its status prior to the change so that its history can be determined easily. These controls over keyword changes are required to mitigate the risk of content being concealed by changes to keywords. | 2 | XX | |
| 1.4.27 | System should ensure that all content is classified as appropriate, when captured. | 1 | XX | |
| 1.5. Access and Security | ||||
| 1.5.1. | System should have the ability to interface with external directory services for security and authentication for single sign on (SSO). City utilizes Okta as IDP. | 1 | XX | |
| 1.5.2. | System should not allow any person to carry out any action in the system unless the person is an authorized user who is successfully identified and authenticated. A user-id and password mechanism is considered sufficient authentication. | 1 | XX | |
| 1.5.3. | System should support multifactor authentication. | 2 | XX | |
| 1.5.4. | System should enable access by means of an integrated network log-on. | 1 | XX | |
| 1.5.5. | System should provide role-based security across all templates, content, processes and repositories for individual users, groups of users, individual content, and content groups. | 1 | XX | |
| 1.5.6. | System should provide individual security defined at the class, content, and process levels. This may override role-based security, so that an item such as a specific record may have restrictions applied at the discretion of an administrator or the owner/author. | 1 | XX | |
| 1.5.7. | System should allow for encryption of data between the system and a user computer through standard web encryption (SSL). | 2 | XX | |
| 1.5.8. | System should only allow individuals access to content to which they have been granted access. | 1 | XX | |
| 1.5.9. | System should allow administrators to control who may set, change or override content security settings. | 2 | XX | |
| 1.5.10. | System should provide for the capture and secure storage of electronic signatures including details of the certification. | 1 | XX | |
| 1.5.11. | System should be able to store with the electronic record, the electronic signature associated with the record and the electronic certificate verifying the signature. | 1 | XX | |
| 1.5.12. | System should include features, which demonstrate that integrity has been maintained of records with electronic signatures. | 1 | XX | |
| 1.5.13. | System should be capable of checking the validity of an electronic signature, including checking the certificate of a record. | 2 | XX | |
| 1.5.14. | System should have a standards-based interface, which permits the introduction of new electronic signature technologies as they are introduced. | 2 | XX | |
| 1.5.15. | System should support compartmentalization of content repositories based on department, division, section, or other organizational groupings. | 1 | XX | |
| 1.5.16. | System should support customized role/security definition, allowing for individual system functions to be grouped, assigned to or removed from an individual user or role profile. | 1 | XX | |
| 1.5.17. | System should provide an audit of all user transactions, including system actions such as the addition of a new class in the classification scheme. | 1 | XX | |
| 1.5.18. | System should provide a content audit trail. The audit trail shall indicate all activity associated with the content and individuals accessing the file. | 2 | XX | |
| 1.5.19. | System should provide methods to control printing rights. | 1 | XX | |
| 1.5.20. | System should have the ability to control access to content from a site map, search, and/or other index based on security roles; and specifically, users should only see facilities for which they have access. | 2 | XX | |
| 1.5.21. | System should ensure all user interactions are completely respectful of security, including search results. Specifically, if a user is not authorized to access content, the existence of the content should not be revealed, even as a result of a search. | 1 | XX | |
| 1.5.22. | System should allow administrative roles to allocate access to content and metadata to specified users, user roles, and/or user groups and for specified periods of time. | 1 | XX | |
| 1.5.23. | System should not limit the number of roles or groups that can be configured. | 1 | XX | |
| 1.5.24. | System should allow administrative roles to maintain permissions for all roles and groups. These determine the functionality, metadata elements, and content in which the roles and groups have access, and the kinds of access allowed. | 1 | XX | |
| 1.5.25. | System should allow administrative roles to use permissions to: |
· restrict access to specific content and metadata;
· restrict access to specific classes of the classification scheme;
· restrict access according to the user’s rights;
· restrict access to particular features and functions (e.g. view, copy, print, add, update, delete);
· deny access after a specified date; and
| · allow access after a specified date. | 1 | XX | ||
| 1.5.26. | System should allow administrative roles to add and remove users to and from roles and groups at any time. It is acceptable for administrative roles to manage groups by means of separate directory management software. | 2 | XX | |
| 1.5.27. | System should allow administrative roles to mark an individual user as inactive, without deleting the user from the system. It is acceptable for administrative roles to manage users by means of separate directory management software. | 2 | XX | |
| 1.5.28. | System should allow the allocation of administration rights over different sections of the classification scheme to different administrative roles. | 2 | XX | |
| 1.5.29. | System should allow administrative roles to define the same access rights for user roles as for users. This feature allows administrative roles to manage and maintain a limited set of role access rights rather than for each individual user. Examples of roles might include Manager, Security Analyst, and Database Administrator. | 1 | XX | |
| 1.5.30. | System should be able to apply selections of access requirements across roles. | 2 | XX | |
| 1.5.31. | System should allow an administrative role to set up and maintain groups of users. Examples of groups might be Budget and Human Resources. | 2 | XX | |
| 1.5.32. | System should allow a user to be a member of one group, more than one group, or no group. It is likely that some users will have different access requirements for different parts of the classification scheme. In all cases, users are assigned to groups by administrative roles in response to business needs and policies. | 1 | XX | |
| 1.5.33. | System should allow administrative roles to set up ad hoc lists of individual users in order to control access to specified parts of the classification scheme or content. | 2 | XX | |
| 1.5.34. | System should restrict system functions (such as backup and recovery jobs) and related events to administrative roles only. | 1 | XX | |
| 1.5.35. | System should provide for segregation and assignment of administrative functions, so that individual functions may be assigned to a customized role. | 2 | XX | |
| 1.5.36. | System should allow only administrative roles to set up user profiles and allocate users to groups and roles. | 1 | XX | |
| 1.5.37. | System should allow administrative roles to allocate functions to users and roles, and allocate one or more users to any role. | 1 | XX | |
| 1.5.38. | System should allow administrative roles easily to move users between user groups and roles. In particular, it should be possible to move a user without having to delete the user from the system and re-enter the user’s details. | 1 | XX | |
| 1.5.39. | System should allow roles with ownership of content to specify which other users or groups can access the content. Ideally, ownership should be with administrative roles. | 1 | XX | |
| 1.5.40. | System should restrict the ability to make changes, such as adding, amending and deleting profiles for groups, roles or users to administrative roles. This includes attributes such as access rights and privileges. | 1 | XX | |
| 1.5.41. | System should allow administrative roles to set up and manage rules to govern user access to system functions, so that different roles have access to different combinations of functions. | 1 | XX | |
| 1.5.42. | System should provide one of the following actions, based on the response selected at system configuration or at any time during the life of the system, for which a user requests information that they do not have permission to access: |
· provide no information about the item, thus providing no indication of whether the item does or does not exist;
· confirm the existence and optionally the owner of the item but not its title or other metadata;
· display title, type of item, date of creation and owner only; or
· display title and other metadata of the object.
| The first option specifies the same outcome desired as for content searches. The other three options provide other possibilities to be determined by City management policy; they are shown here in order of decreasing security. This should be configured by administrative roles, and this requirement applies only to access attempts that do not involve searching on record content. | 2 | XX |
| 1.5.43. | System should allow one of the following options to be selected at configuration time or at any time during the life of the system: |
· security categories are assigned to classes (and not to individual content items);
· security categories are assigned to individual content items (and not to classes); or
· security categories are assigned both to individual content items and to classes.
| City staff will determine which strategy is appropriate. | 2 | XX | ||
| 1.5.44. | System should allow an administrative role to specify, at configuration time or at any time during the life of the system, which roles can specify and change the security category of content and aggregations. | 2 | XX | |
| 1.5.45. | System should allow specific implementations of complex or unique security rules; these may be provided by suitable application program interfaces (APIs). | 2 | XX | |
| 1.5.46. | System should allow security for content to be inherited from a class. Where security is inherited from a class, the system should allow different security to be applied to the content. | 2 | XX | |
| 1.5.47. | System should allow security to be allocated to a role and inherited by users. Where security is inherited from a role, the system should allow different security to be applied at the individual user level. | 2 | XX | |
| 1.5.48. | System should allow an administrative role to determine the security of any content by means of one simple inquiry. | 1 | XX | |
| 1.5.49. | System should allow an administrative role to change the security of a class or content. | 2 | XX | |
| 1.5.50. | System should support routine, periodic, scheduled, review of security categories, where a review consists of: |
· allowing a user (with appropriate clearance and permissions) to view specified content and its security categories; and
| · allowing the user to change the security categories. | 2 | XX | ||
| 1.5.51. | System should allow users who have rights that allow them to see content to see the current security category and any history. | 2 | XX | |
| 1.5.52. | System should support the allocation of a security category to a class, which is valid for a defined period of time. | 2 | XX | |
| 1.5.53. | System should support notification to an administrative role of the expiration of a selected time period for which a security category has been allocated to a class. | 2 | XX | |
| 1.5.54. | System should not allow a user to apply a security category to a class that the user does not have access to. | 2 | XX | |
| 1.5.55. | System should allow an administrative role to change the security category of all records and child items in a class in one operation. | 2 | XX | |
| 1.5.56. | System should when a user changes the value of a security category, allow the user to enter a reason for the change, and the system should store the reason with the history as metadata. | 2 | XX | |
| 1.5.57. | System should restrict the ability to add, change, and delete classification scheme items and related metadata. | 2 | XX | |
| 1.5.58 | System search or retrieval function should never reveal to a user any information (metadata or content) where the access and security controls prevent access by that user. | 1 | XX | |
| 1.5.59. | System should restrict to authorized administrative roles the ability to change the keywords associated with content. This feature is intended for exceptional circumstances only, such as to correct clerical errors. | 2 | XX | |
| 1.5.60 | System should provide the ability to control permissions to digital content. | 2 | XX | |
| 1.5.61. | System should ensure document use is restricted to the users rights associated with the document. For example, if the user only has the right to view the document, then printing, copying, changing, or deleting should not be allowed. | 1 | XX | |
| 1.5.62. | System should restrict changes of pre-programmed workflows to administrative roles or authorized users. | 2 | XX | |
| 1.5.63. | System should allow the definition of distinct workflow roles to different users. Examples of these roles include: |
· workflow administrative role (having permissions to reassign tasks or actions to another user or group);
· supervisor role (having permissions to designate a workflow for exception handling in specific cases);
· ordinary workflow users or groups.
| These workflow roles are distinct from other system roles. | 2 | XX | ||
| 1.5.64. | System should allow administrative roles to allocate permissions to individual users so that they are able to reassign tasks/actions in a workflow to a different user or group. A user may wish to send a document or record to another user because of the content, because the assigned user is on leave, or for other reasons. | 1 | XX | |
| 1.5.65. | System should allow administrative roles to restrict access to selected reports. | 1 | XX | |
| 1.5.66. | System should allow administrative roles to change any user-entered metadata element. This functionality is intended to allow administrative roles to correct user entry errors and to maintain user and group accesses. | 2 | XX | |
| 1.5.67. | System should allow only administrative roles to create and maintain retention and disposition schedules. | 1 | XX | |
| 2. CAPTURE FEATURES | ||||
| 2.1. Human Created and Rich Media Input | ||||
| 2.1.1. | System should not impose any practical limit on the number of items that can be captured and classified, nor on the number of records, which can be stored in the system. | 1 | XX | |
| 2.1.2. | System should provide a managed method of inserting and migrating ongoing individual electronic files into the repository. | 1 | XX | |
| 2.1.3. | System should support a variety of file formats and types. | 1 | XX | |
| 2.1.4. | System should include the creation of custom electronic forms with the capability to directly populate the repository (or a linked database). | 1 | XX | |
| 2.1.5. | System should include the processing of additional electronic forms including fillable PDF's with the capability to populate the repository (or a linked database). | 2 | XX | |
| 2.1.6. | System should include web forms processing with the capability to populate the repository (or a linked database). | 2 | XX | |
| 2.1.7. | System should integrate (lookup & seed) information from other business applications based on form data entry. | 2 | XX | |
| 2.1.8. | System should save Microsoft Office Suite content to the repository, directly from the Microsoft file creator program, including but not limited to DOCX, PPTX and XLSX file formats. | 1 | XX | |
| 2.1.9. | System should save Portable Document Format (PDF) content to the repository, directly from the 3rd party PDF creator program. | 1 | XX | |
| 2.1.10. | System should save Geographic Information System (GIS) content to the repository, directly from the 3rd party GIS creator program, including but not limited to ESRI ArcGIS, and Oracle Spatial file formats. | 3 | XX | |
| 2.1.11. | System should save image content to the repository, directly from the 3rd party image creator program, including but not limited to BMP, GIF, JPG, PNG, and TIF file formats. | 2 | XX | |
| 2.1.12. | System should save video content to the repository, directly from the 3rd party video creator program, including but not limited to AVI, MOV, MPG, MP4 and WMV file formats. | 1 | XX | |
| 2.1.13. | System should save audio content to the repository, directly from the 3rd party sound file creator program, including but not limited to MP3, WAV, and WMA file formats. | 2 | XX | |
| 2.1.14. | System should save Internet based content to the repository, directly from the 3rd party file creator program, including but not limited to ASP, CSS, HTM, JS, and XML file formats. | 2 | XX | |
| 2.1.15. | System should save other content types to the repository, directly from the 3rd party file creator program, including but not limited to TXT file formats. | 2 | XX | |
| 2.1.16. | System should support drag & drop functionality for moving files into the repository, specifically from Windows Explorer, Microsoft Office products, web interfaces, and email. | 1 | XX | |
| 2.1.17. | System should retain the original file type and format characteristics without modification (.doc, .jpg, etc.) for all imported content. | 1 | XX | |
| 2.1.18. | System should automatically generate a read-only PDF version of any captured document or image. | 1 | XX | |
| 2.1.19. | System should generate alternate versions of captured images for repurposing including different color depths, formats, resolutions, height & width sizes, file sizes, and other quality factors. | 2 | XX | |
| 2.1.20. | System should generate alternate versions of captured videos for repurposing including different formats, height & width sizes, and other quality factors. | 2 | XX | |
| 2.1.21. | System should capture all of its components, when capturing content made up of several components. | 2 | XX | |
| 2.1.22. | System should allow users to create cross-references (or links) between related content. | 1 | XX | |
| 2.1.23. | System should allow more than one item to be created using the same classification and/or combination of keywords. | 2 | XX | |
| 2.1.24. | System should allow a user creating an item to populate its keyword values by copying them all from another item, in one action. | 2 | XX | |
| 2.1.25. | System should allow entry of descriptions and other metadata at the time of capture and/or at a later stage of processing. | 2 | XX | |
| 2.1.26. | System should allow a record or document to be managed as a single unit, retaining the relationship between the components, and retaining structural integrity, when capturing electronic content that has more than one component. Examples of such instances are: |
· web pages with embedded graphics;
· a word-processed document linked to a spreadsheet.
In some cases, the components will be related by links that do not work if simply copied into the system repository. For example, many web pages contain links to graphics and other objects with addresses (URLs) that are external to the repository; and linked spreadsheets typically contain links to addresses (file names) external to the repository. When capturing electronic content that has more than one component the system should modify the content, if necessary, to preserve the ability to present it. This is likely to mean that the system changes the internal references (links) within some of the components. This requirement applies only to file formats specified for the system – it is not intended to apply to unspecified formats. Examples include:
· HTML pages that include links to graphics and other objects;
· spreadsheets that include links to other spreadsheets.
| Making such changes is contrary to the general principle of not changing content, but is unavoidable if it includes components etc. that are to be stored in its original formats without losing all functionality and fidelity. The changes will generally be acceptable so long as the changes are logged in the audit trail. An alternative approach involves rendering the content into some other file format (such as PDF/A) that preserves the static appearance; however, even though this avoids changing links, it is likely to result in losing them. | 2 | XX |
| 2.1.27 | System should allow the user to choose at least one of the following, when capturing content that has more than one version: |
· declare all versions as one record;
· declare one specified version as a record;
| · declare each version as individual records. | 2 | XX |
| 2.1.28 | System should be able to provide automated support for decisions on the classification of electronic content by means of at least one of the following: |
· making only a subset of a classification scheme accessible to a user or role;
· suggesting the classes used most recently by that user;
· suggesting the classes used most frequently by that user;
· suggesting classes by inferences drawn from record metadata elements (for example, significant words used in the title or email subject line);
| · suggesting classes by inferences drawn from the contents. | 1 | XX | ||
| 2.1.29. | System should allow the ability to amend the title of electronic content for an administrative role or other authorized user. | 1 | XX | |
| 2.1.30. | System should warn the user if an attempt is made to capture an object with a title, which already exists in the same classification group, or to re-title an object with a title, which already exists in the same classification group. | 1 | XX | |
| 2.1.31. | System should allow the process of capturing content to be completed by more than one user. In other words, the system should allow the capture process to be divided between users. Typically this will mean that one user enters some metadata then passes the electronic content to another user, who enters the remaining metadata and classifies it. | 3 | XX | |
| 2.1.32. | System should issue a warning if a user attempts to capture content that has already been registered. | 1 | XX | |
| 2.1.33. | System should provide a warning if an attempt is made to capture content, which is incomplete or inconsistent in a way that will compromise its future apparent reliability. | 1 | XX | |
| 2.1.34. | System should issue a warning if a user attempts to capture content that has the same values of identifying metadata as other content, which has already been registered. The identifying metadata for this requirement is: |
· Title;
· Date;
| · Author. | 1 | XX | ||
| 2.1.35. | System should incorporate a method of ensuring duplicate content is not unintentionally entered into the repository using controls such as a byte for byte comparison of digital content and issuing a warning of an exact match. This action should result whenever an attempt is detected to store a file in the repository where a file with the same size and type already exists. | 1 | XX | |
| 2.2. Scanning / Imaging | ||||
| 2.2.1. | System should provide a method to facilitate paper to electronic conversion. | 1 | XX | |
| 2.2.2. | System should include Optical Character Recognition (OCR) capabilities. | 1 | XX | |
| 2.2.3. | System should include Optical Mark Recognition (OMR) capabilities. | 2 | XX | |
| 2.2.4. | System should include handprint recognition capabilities, a.k.a. Intelligent Character Recognition (ICR). | 2 | XX | |
| 2.2.5. | System should support scanner and copier input. | 1 | XX | |
| 2.2.6. | System should support scanning of multi page and double-sided documents, including but not limited to business reports, blueprints, CAD drawings, photographs, and bound documents. | 1 | XX | |
| 2.2.7. | System should provide image clean up capabilities including noise reduction and straightening. | 2 | XX | |
| 2.2.8. | System should be capable of integration with other scanning solutions. Other scanning solutions may provide the interface to scanning equipment and allow an operator to perform several processes related to scanning such as rotating, de-skewing, de-speckling along with emailing, faxing, etc. | 1 | XX | |
| 2.2.9. | System should integrate (lookup and seed) information from other business applications based on scanned image OCR data. | 2 | XX | |
| 2.2.10. | System should include exporting data read from a scanned image with the capability to identify fields/zones and populate the repository (or a linked database). | 2 | XX | |
| 2.2.11. | System should include "scan to file" functionality providing direct loading of scanned images to the repository. | 2 | XX | |
| 2.2.12. | System scanning features should support both monochrome and color scanning capable of saving images in color or grayscale. | 1 | XX | |
| 2.2.13. | System scanning features should be capable of saving images in standard formats, including, but not limited to: |
· TIFF;
· JPEG;
| · PDF. | 1 | XX | ||
| 2.2.14. | System scanning features should be capable of saving images at different resolutions. Ideally the scanning feature should provide a menu of options, programmable for the input of different types of content. | 1 | XX | |
| 2.2.15. | System scanning features should be capable of handling standard paper sizes including, but not limited to: |
· Letter (8.5” x 11”);
· Legal (8.5” x 14”);
· ANSI B (11” x 17”);
· ANSI C (17” x 22”);
· ANSI D (22” x 34”);
· ANSI E (34” x 44”);
· ANSI F (44” x 68”);
· ANSI G (68” x 88”);
| · ANSI H (88” x 136”). | 1 | XX | ||
| 2.2.16. | System OCR functionality should be capable of managing the scanned image and the text resulting from the OCR as a single unit. In other words, the OCR text should be regarded as metadata of the content rather than as content in its own right. | 1 | XX | |
| 2.2.17. | System OCR functionality should support full text searching based on the text. | 1 | XX | |
| 2.2.18. | System scanning features should be capable of automatically sending scanned images to a queue after scanning. For example: indexing, quality assurance. | 2 | XX | |
| 2.2.19. | System should provide automated quality assurance for scanned images, including checks to validate the scanning process was complete, validation of readability, re-scanning of poor quality images, verification of page counts and security for each document. This includes the ability to accept or reject images; and, when they are rejected, to request a re-scan. The inspection may be carried out by a scanner operator, by a dedicated quality check user, or by other users who perform quality checking as a part of their work. | 1 | XX | |
| 2.2.20. | System scanning features should allow an administrative role to set a threshold for image information content such that below the threshold an image is discarded as representing a blank page. | 2 | XX | |
| 2.2.21. | System scanning features should be able to store scanner set-up parameters (such as single/double sided, resolution, contrast, brightness) for different document types. | 2 | XX | |
| 2.2.22. | System should allow users to annotate images. This feature can be used to note exceptional scanning problems, or to make notes (similar to handwritten annotations that are sometimes used with paper documentation). | 1 | XX | |
| 2.2.23. | Where the system allows users to annotate images that are held as records, it should prevent the alteration and removal of these annotations. This is intended to prevent records from being modified (or from appearing to be modified) temporarily. | 2 | XX | |
| 2.2.24. | Where the system allows users to annotate images, it should store with each annotation the identity of the user making the annotation and the time and date, in an unalterable way. It is intended to ensure that any annotations are appropriate and traceable. | 2 | XX | |
| 2.2.25. | System scanning features should log each scanning session with the following details: |
· user login;
· workstation identifier;
·…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .