Sample Only

City Of Kent
Electronic Document Management System
Request For Proposal

Issued: July 28, 2000
Date Due: August 18, 2000
Time Due: 4:00 p.m. Pacific Time

Address Responses To:

City of Kent
220 4th Avenue South
Kent, Wa 98032-5895

1. INTRODUCTION 1

1.1. Background 1

1.1.1. City Information 1

1.1.2. The Technology Plan 2

1.1.3. Technology Environment 2

1.1.4. Records Management Program 4

1.1.5. Kent's Imaging Experience 5

1.1.6. Project Personnel 6

1.2. Objectives 6

1.3. Scope of Work 7

1.3.1. Phase I - EDMS Software 7

1.3.2. Phase II - Image Conversion 9

1.3.3. Phase III - Image Enable Permit Tracking System (KIVA) 11

1.3.4. Phase IV - Image Enable Enterprise Resource Planning System (J.D. Edwards) 12

1.3.5. Items Not Included in RFP Scope 14

2. PROCUREMENT PROCESS 15

2.1. Procurement Schedule 15

2.2. Proposal Date, Time, Location 15

2.3. Communications with the City of Kent 15

2.4. Vendor Clarifications and Questions 16

2.4.1. Clarifications 16

2.4.2. Vendor Contact 16

2.5. Summary of RFP Process 16

2.5.1. Vendors' Pre-Proposal Conference 16

2.5.2. RFP Changes or Amendments 17

2.5.3. Vendor Submits Proposal 17

2.5.4. City Evaluates Proposals 17

2.5.5. City Announces Finalists 17

2.5.6. City Evaluates Vendor Documentation 17

2.5.7. Vendor Demonstration 17

2.5.8. Hands-On Demonstration of Proposed Products 18

2.5.9. City Visits Vendor Client Sites and/or Vendor Product Laboratories 18

2.5.10. Final Vendor Selection 18

2.5.11. Acceptance Test Plan 19

2.5.12. Progress Payment Schedule 19

2.5.13. Finalize Contract 19

2.5.14. Contract Approval 19

2.6. Proposal Process 20

2.6.1. Reference Checks 20

2.6.2. Costs Incurred by Vendors 20

2.6.3. Right of Selection or Rejection of Proposals 20

2.6.4. Incorporation of RFP and Proposal in the Final agreement 20

2.6.5. Errors in Proposals 20

2.6.6. Vendor Prime Contractor Responsibility 20

2.6.7. Period of Validity of Proposals 21

2.6.8. Proprietary Material 21

2.6.9. Proposal Confidentiality 21

2.6.10. Proposal Disposition 21

3. VENDOR INSTRUCTIONS 22

3.1. Prime Contractor 22

3.2. Partial Solutions 22

3.3. Proposal Format 22

3.4. Response to Requirements Questionnaire 24

3.5. Response to Questionnaires 25

4. EDMS FUNCTIONAL REQUIREMENTS 26

4.1. Document Imaging 27

4.2. Electronic Folder Management 30

4.3. Image Enabling Applications 32

4.4. Document Management 33

5. TECHNOLOGY REQUIREMENTS 35

5.1. Overall Requirements 35

5.2. System Design 36

5.3. Operating Environment 37

5.4. Administration 39

5.5. Security 40

5.6. Customization 41

5.7. Professional Services -Support 42

5.8. Product History and Vision 43

6. IMPLEMENTATION QUESTIONNAIRE 44

6.1. Implementation Methodology 44

6.2. Implementation Team Size 45

6.3. Training 45

6.4. Post-Implementation Support 45

6.4.1. Implementation Customer Reference 46

APPENDIX A - VENDOR RESPONSE FORMS

APPENDIX B - TERMS AND CONDITIONS

APPENDIX C - INDEXING

1. Introduction

The City of Kent, hereinafter referred to as the "City", is seeking proposals for an Enterprise Document Management System (EDMS). The City defines EDMS as:

An integrated software product suite that can electronically capture, process, index, store, access, view, revise, reproduce, distribute, and dispose of information in a "document" in both a client/server and web environment.

This Request for Proposal (RFP) scope is to select a vendor(s) to provide EDMS software, documentation, implementation, training, and conversion services. This document details the EDMS software, service and vendor information on which the City will base its selection. The topics included in this section include:

· Background

· Objectives

· Scope of Work

The information in this section is intended to provide a City overview and convey this project's priorities to the vendor.

1.1. Background

This subsection provides background information on the City. The vendor should use this information to gain a sense of the City's size and scope of services provided to both internal departments and the citizens.

1.1.1. City Information

The City is the eighth largest city in Washington, with a population of 73,060 and a 28.5 square mile geographic area. The City's population is projected to grow to 100,000 or beyond within the next few years.

The City has approximately 750 employees receiving benefits. The number of temporary employees on the payroll varies from 100 to 350. The City is a full service city. City Departments include:

· Administration · Law · Human Resources

· Finance Services · Fire & Life Safety · Information Technology

· Municipal Court · Parks and Recreation Planning

· Police · Public Works

The City operates over 25 facilities including:

· City Hall

· Centennial Center

· Several Parks and Recreation Facilities

· Public Works Maintenance Facilities

· Police Department

· Corrections Facility

· Municipal Court

· 8 Fire Department facilities.

1.1.2. The Technology Plan

In April 1998, the City Council approved a three-year, $12.8 million Technology Plan. The Technology Plan's goal is to provide the resources necessary to address the City's technology infrastructure and information system needs. In the first two years of this technical renaissance, the City's technology accomplishments include:

· Network Infrastructure Replacement

· Desktop Standardization

· Increased Support Staff

· Telephone System Replacement

· Permitting System Replacement

· Parks and Recreation System Replacement

· Email System Implementation

· Web Presence

In addition to maintaining and enhancing the systems listed above, the City has a number of other projects currently underway. The City's most encompassing project is the implementation of an Enterprise Resource Planning (ERP) application. The City selected the J.D. Edward's OneWorld product to support the City's financial and human resources management needs.

1.1.3. Technology Environment

This sub-section describes the City's technology environment. The City currently supports more operating systems and databases than are shown within this sub-section. However, the City is striving to consolidate around a standard viable technology set using the products and standards identified within this subsection. Table 1, shows the standard server operating systems and databases supported by the City.

Table 1. Business Application Standards

Business Application Components	Standard
Database Servers	NT/Windows 2000 (planned)
Application Servers	NT/Windows 2000 (planned)
Web Server	Microsoft IIS
DBMS	Oracle 8.x and SQL Server 7.0

Table 2, shows the network configuration and network operating systems currently supported by the City.

Table 2. Network Infrastructure

Network Component	Standard
Network Backbone	ATM
Network Operating System	Novell 4.11 (current), Novell 5 (planned), Microsoft NT/Windows 2000
Network Protocols	IPX, TCP-IP
Topology	Switched Ethernet to the desktop (Ethernet II)
Cable Infrastructure	Category 5
File and Print Services	Novell NetWare 5.x
Application Servers	HP Net Server
Backup	Veritas
Messaging Server	Microsoft Exchange 5.5

Table 3, shows the City's standard desktop environment.

Table 3. Desktop Environment

Desktop Component	Standard
Desktop Machines (Minimum Configuration)	Pentium-166 PCs with 32MB RAM, 1GB hard drive, and CD-ROM drive, SCSI-2 interface for Imaging Workstations.
Desktop PC Make and Model	HP Vectra and HP Kayak
Desktop Operating Systems	Microsoft Windows 95, 98
Business Software Suite	Microsoft Office 97/2000 (planned)
Browser	Microsoft Internet Explorer 4.01
Email Client	Microsoft Outlook 98

1.1.4. Records Management Program

In March 1999, a facility study was completed to determine the City's space requirements to meet the demands of a growing population. The study identified large areas being used for paper file storage. Instead of adding more storage space, the City identified document management technology as a more viable solution. However, to utilize the technology effectively, the City determined that a records management inventory was necessary prior to implementing an EDMS solution.

In May 1999, the city retained Cary Information Consulting (CIC) to design and implement a citywide records management program. The project objectives included:

· Creating the City's official records retention schedules.

· Determining the best storage media based on the retention schedule, rate of retrieval, and volume.

· Determining if the City should establish a records center.

The data collected included 40 attributes, many associated with identifying document management, imaging, and workflow needs. In June 2000, the project inventory totaled 600 individual record series. Department teams began working together in subject affinity groups to develop common document terminology for the business processes they have in common.

CIC is continuing work on the citywide record retention schedule and anticipates assisting the City in presenting the schedule to the Washington State Local Records Committee by September 2000. The information produced from the Records Management Project will be made available to the successful EDMS vendor to assist in system design.

The City must comply with the Records Management Standards set in the Revised Code of Washington (RCW) see http://wsl.leg.wa.gov/wsladm/rcw.htm Title 40 Public Documents, Records and Publications and the Washington Administrative Code (WAC) Title 434-663 Imaging systems, standards for accuracy and durability for details. Some consideration must be given to storing long-term documents by retention date and establishing a mechanism for systematic document purging and destruction. While this functionality will not be implemented in this project, the vendor's ability to deliver this functionality will be taken into consideration during RFP evaluation.

Table 4, shows preliminary results from the Records Management project indicating the EDMS functionality that may be useful in the City's environment.

Table 4. Preliminary Records Management Data

Functionality	Percentage of Records Series That Would Benefit from Functionality	Estimated Annual Number of Pages
		Low	High
Imaging	40 - 45%	880,000	990,000
Document Management	10 -15%	220,000	330,000

1.1.5. Kent's Imaging Experience

In 1992, the city began a pilot project using Compulink's Laserfiche imaging software, Three years later, in 1995, the project had grown to include the City Clerk, Planning, Public Works and Police Departments, each with a separate imaging database. In this growth period a seamless interface was developed to share index data between the Planning Department's permit tracking system and the imaging database. A number of conversions took place from 1997 to 1999 that consolidated the image formats and imaging databases into a single networked entity. These endeavors taxed the city's ability to enforce a level of quality control to make these events successful. While there are approximately 1 million index document images in the image database, there are an estimated 4,000 phantom documents with an estimated 30,000 imaged pages. Given these circumstances in addition to adding application integration and with the JD Edwards and KIVA products, the City feels the current document imaging solution has reached its capacity and other document management solutions should be explored.

Current imaging work within the city includes:

· City Clerk: Ordinances, Resolutions, Council Minutes, Agendas, and Contracts

· Police: Incident Reports, and Correctional Facility Files

· Planning: Construction Permits

· Public Works: Business Files, and Storm Files

The imaging application is in continual use in an effort to provide rapid information retrieval. It is anticipated that the existing imaging application will coexist with any proposed solution until image conversion can be completed and applications moved forward to the new EDMS solution.

Table 5, represents the City's current imaging environment. These items may change based upon responses to this RFP.

Table 5. Current Imaging Environment

Desktop Component	Standard
Current Imaging Application Server	HP LC 3 512MB RAM; Novell 4.11
Current Imaging Storage	Data Silo; RAID-5 with 91GB
Current Imaging Database	Pervasive SQL7
Image Scanners:	4- Ricoh Model IS-420 ; 1-VisionShape Model VS-1250
Imaging Software	Vendor: Compulink Product: Laserfiche 4.3 for Novell

1.1.6. Project Personnel

The project team will include both experienced imaging staff and members who are familiar with the business processes in each project phase.

· Project Manager - Jim McKenney

· Extended Project Team - 5 department liaisons with imaging experience, and 10 business process liaisons available on an as-needed basis.

1.2. Objectives

The project associated with this RFP has several objectives. The successful vendor must demonstrate to the City's satisfaction that they can best assist the City in meeting these objectives. The City's project objectives include:

· Establishing a relationship with an EDMS vendor that has a proven track record and long-term viability.

· Selecting an EDMS that will scale across the enterprise.

· Planning and designing a responsive EDMS system.

· Developing and Implementing an EDMS that will address the City's current document imaging needs and grow with the City to encompass more advanced document management concepts.

· Improving customer service quality and timeliness.

· Reducing the reliance on paper for large volumes of business information.

· Web-enabled imaging and document management.

· Integrating document images with other electronic processes.

· Streamlining business processes by reducing document retrieval and management time.

· Reducing lost documents.

· Improving document security and disaster recovery capabilities.

· Establishing a reliable document management repository that is easily accessed by the City staff.

This project will lay the foundation for expanding the use of document management within the City and solutions that demonstrate the ability to address each objective will be given greater consideration.

1.3. Scope of Work

This subsection details the software functionality and services the City expects to implement through this RFP. The project is divided into four phases.

1.3.1. Phase I - EDMS Software

Phase I will design and implement the EDMS infrastructure based on the proposed solution. Software functionality to be delivered in Phase I includes:

· Document Imaging: This functionality involves capturing paper documents in digital form. These digital documents may then be indexed, annotated, archived, searched, retrieved, or viewed. See Section 4.1 for detailed requirements.

· Electronic Folder Management: This functionality involves virtual folders, that can contain not only images but also multiple objects or formats. A virtual folder can hold images, word-processing documents, spreadsheets, graphics, Portable Network Graphics (PNG), HTML, XML, PDF, etc. Images and text counterparts can be stored together in folders or they can be converted to final form documents such as Adobe PDF. The user can see any of these documents using a universal or web browser. See Section 4.2 for detailed requirements.

· Image Enabling Applications: This functionality involves using the imaging engine within another business application. The imaging engine is not the dominant application and can operate without modification to any source code. Data transfer from the host application can populate the image indexes without user intervention. See Section 4.3 for detailed requirements.

· Document Management: This functionality includes, indexing, library services such as version control, search, retrieval, check-in, check-out, and document security regardless of media type, location, or format. See Section 4.4 for detailed requirements.

· Web Browser Support: The EDMS suite must support both a web-browser and desktop client for viewing imaging and document management documents.

The City's priority requirements are for desktop and web-enabled imaging and document management functionality. There will be a need for workflow and Computer Output Laser Disc (COLD) functionality in the future, but not at this time. Vendors will be evaluated on the level of integration and scalability of their solution.

1.3.1.1. System Design

The vendor will provide the architectural design specification necessary to implement the EDMS. This specification will be used to order all necessary hardware for implementation.

The vendor will analyze the City's environment and provide recommendations on the management of electronic files, email, scanned images, objects and indexed data across the City's network. The vendor will be required to work closely with City staff during this process.

The records management project identified the records volumes, retrieval rates, access requirements and retention period for all city records. The vendor will have both detailed and summarized data necessary to perform a storage requirements analysis. Analysis will include but not be limited to:

· Determining the total annual storage requirements, as well as on-line, near-line and off-line requirements including anticipated growth rates.

· Evaluating the volume and characteristics of active storage requirements per day. Recommend appropriate storage devices depending upon document characteristics (i.e. magnetic/RAID, optical/worm, optical/erasable, and optical/CD).

· Analyzing and recommending the storage method or methods to be used by the City. This shall include the appropriate use of distributed and centralized file storage based upon their volume and characteristics, including the need for bulk data transfer to other storage locations.

· Recommending method(s) and media for appropriate data and file backup.

1.3.1.2. Implementation Plan

The vendor will develop a detailed Phase I implementation plan document in conjunction with the City's project team. The implementation plan document will at a minimum include:

· Software installation.

· Hardware configuration.

· Testing.

· Validation.

· Client deployment.

· User training.

· Schedule.

The implementation plan will be used to monitor the progress of Phase I and provide system documentation.

1.3.1.3. Software Installation

The vendor will install, configure, test, and validate that the EDMS software is fully functional in the server, desktop, and web environments. Client licenses deployment will be based on the successful conclusion of work performed in each project phase. The software licenses to be deployed in Phase I include:

· 10 concurrent users

· 40 viewers

· 10 desktop scanning capture engines

The vendor shall include a detailed explanation on how software installation and upgrades are handled.

1.3.1.4. Training

The City's past experience with imaging has provided some foundation skills, but a training effort will be required to leverage the EDMS solution's functionality. The vendor must list training options, time requirements, and "Best Practices" recommendations in the cost proposal. Training options should include:

· End User (full client and web client).

· System Administration

· Applications Development

· Software and Hardware Support

· Interface Development

Vendor must list in the cost proposal whether the training is provided offsite or onsite, training duration, and the training level. Vendor shall also specify what training a third party supplier must provide. See Appendix A for cost model details.

The vendor will work with City project staff to determine exact training requirements prior to application installation.

1.3.1.5. Support and Maintenance

The vendor will describe their support organization, problem escalation process, and options for technical problem resolution. The vendor must list in the cost proposal whether costs are free, flat-fee or per incident.

1.3.2. Phase II - Image Conversion

Phase II involves migrating the City from the current document-imaging environment to the EDMS selected by this RFP. The subsections below detail the work to be completed in this phase.

1.3.2.1. Implementation Plan

The vendor will develop a detailed Phase II implementation plan document in conjunction with the City's project team. The implementation plan document will at a minimum include:

· Software installation.

· Hardware configuration.

· Testing.

· Validation.

· Client deployment.

· User training.

· Schedule.

The implementation plan will be used to monitor the progress of Phase II and provide system documentation.

1.3.2.2. Software Installation

The vendor will install, configure, test and validate that the application software is fully functional in both the desktop and web environments. Client license deployment will be based on the successful conclusion of work performed in each project phase. The software licenses in this phase include:

· 6 desktop scanning capture engines

· 20 viewers

1.3.2.3. Existing Image Conversion

The existing digital image counts are listed in Table 6, and provide an estimated volume of images to be converted in this project. The conversion effort will move the City from the current imaging product to the proposed solution. Technical information including data specifications are contained in Appendix C.

Table 6. Estimated Image Conversion Volumes

Department/Subject Data	Documents	Pages	Index Fields
City Clerk
Ordinances and Resolutions	4,900	24,000	6
Minutes	2,800	11,000	3
Contracts	1,000	25,000	10
Planning
Permits	5,100	54,000	16
Public Works
Business Files	1,000	40,000	7
Police
Un-indexed Case Files	4,000	30,000	0
Police Incident Reports	36,000	350,000	2
Corrections	28,000	470,000	4
Estimated Images to be Converted	82,800	1,004,000

There are approximately 4,000 cases (documents) with 30,000 raw TIFF images that did not convert from an earlier version of the imaging database, Police Un-indexed Case Files. The current image database contains a reference entry that provides the number of pages that should be associated with the case (document). Each raw TIFF image contains the case file number.

The vendor will work with City project staff to develop a written statement of work and schedule by which this work will be accomplished prior to beginning any conversion work. The vendor will develop a schedule and implementation plan for migrating all existing TIFF images including the hardware, software, and staff resources necessary to implement this conversion. The vendor is expected to accomplish a knowledge transfer to City project staff of the techniques involved with this task.

1.3.3. Phase III - Image Enable Permit Tracking System (KIVA)

The City's Permit Tracking is through the KIVA software application ( http://www.kiva.com/). KIVA maintains land, permit, inspection, and business license information. Because each area requires interaction with people inside and outside the City, KIVA provides a mechanism for relating documents to specific information. These documents are then made available to anyone working on an area (land, permit, inspection, etc.) through file associations. When a document is requested, the application used to create the document is started and the document is displayed. This functionality does not currently extend to scanned documents.

The Phase III objective will be to retrieve and view scanned document attachments within the KIVA application. These documents may include any document types described in Section 1.1.6 but will primarily consist of 8 1/2 x 11 documents and "E" (34" x 44") size maps and drawings. The vendor will need to address images that have been converted from the existing imaging application per Section 1.3.3, scanned as part of Section 1.3.5, and newly received documents to be scanned during land development processing.

The vendor will work with City project staff to develop a written statement of work and schedule by which this work will be accomplished prior to beginning any integration work. The statement of work will at minimum include:

· Process for attaching existing images.

· Process for attaching new images.

· Description of interface to allow image viewing from KIVA application.

· Indexing scheme (see Appendix C).

The vendor is expected to accomplish a knowledge transfer to City project staff of the techniques involved with this task.

1.3.3.1. Interface Design Document

The vendor will develop a detailed interface design document in conjunction with the City's project team. The interface design document will provide a framework for integrating the EDMS solution into the KIVA application and will at minimum include:

· Problem description.

· Integration design description.

· Expected outcome.

This document will detail the EDMS application integration concepts and provide system documentation.

1.3.3.2. Implementation Plan

The vendor will develop a detailed Phase III implementation plan document in conjunction with the City's project team. The implementation plan document will at a minimum include:

· Software installation.

· Hardware configuration.

· Testing.

· Validation.

· Client deployment.

· User training.

· Schedule.

The implementation plan will be used to monitor the progress of Phase III and provide system documentation.

1.3.3.3. Software Installation

The vendor will install, configure, test, and validate that the EDMS software is fully functional in both the desktop and web environments. Client license deployment will be based on the successful conclusion of work performed in each project phase. The software licenses associated with Phase III include:

· 10 concurrent users

· 2 desktop scanning capture engines - for large format scanners

· 20 viewers

1.3.4. Phase IV - Image Enable Enterprise Resource Planning System (J.D. Edwards)

The City recently selected J.D. Edward's ( http://www.jdedwards.com/) OneWorld software as the City's Enterprise Resource Planning (ERP) application. The ERP application will contain all the City's financial and human resource data. The project will begin in the September 2000 with the following modules:

· Finance

_ General Ledger

_ Job Cost

_ Budget Development

_ Accounts Payable

_ Purchasing

_ Fixed Assets

_ Accounts Receivable

· Human Resources

_ Applicant Tracking

_ Employee Relations

_ Position Control

_ Classification and Compensation

_ Benefits

_ Payroll

The Phase IV objective will be to obtain seamless integration between the successful EDMS solution and the J.D. Edwards OneWorld application. An ERP user must be able to be in a OneWorld screen doing research and be able to retrieve any related business document regardless of type or format from the proposed EDMS solution. Document capture and indexing should be accomplished using the minimum of tasks from within the ERP.

The vendor will work with City project staff to develop a written statement of work and schedule by which this task will be accomplished prior to beginning any integration. The statement of work will include at a minimum:

· Process for attaching new images.

· Description of interface to allow image viewing from the J.D. Edwards OneWorld application screens.

· Indexing scheme (see Appendix C).

1.3.4.1. Interface Design Document

The vendor will develop a detailed interface design document in conjunction with the City's project team. The interface design document will provide a framework for integrating the EDMS solution into the OneWorld application and will at minimum include:

· Problem description.

· Integration design description.

· Expected outcome.

This document will detail the EDMS application integration concepts and provide system documentation.

1.3.4.2. Implementation Plan

The vendor will develop a detailed Phase III implementation plan document in conjunction with the City's project team. The implementation plan document will at a minimum include:

· Software installation.

· Hardware configuration.

· Testing.

· Validation.

· Client deployment.

· User training.

· Schedule.

The implementation plan will be used to monitor the progress of Phase III and provide system documentation.

1.3.4.3. Software Installation

The vendor will install, configure, test, and validate that the application software is fully functional in both the desktop and web environments. Client license deployment will be based on the successful conclusion of work performed in each project phase. The software licenses associated with Phase IV include:

· 30 concurrent users

· 40 viewers

1.3.5. Items Not Included in RFP Scope

The vendor will not include hardware or database licensing in the RFP pricing. However, the vendor is expected to recommend hardware and software items necessary for a successful EDMS implementation.

The following functionality will be evaluated but is NOT within the RFP scope:

· Workflow: Automates electronic document routing for a business process. Components include workflow design maps, rule-based engines, client interfaces or "in-boxes," and run-time administration and monitoring utilities.

· Computer Output to Laser Disc (COLD): Indexes print stream files originating from a host computer system and provides on-line access to the report pages and data. Key features include data stream translation, indexing, storage, searching, and the ability to render the information in a viewer.

2. Procurement Process

This section provides information regarding the City's procurement process for this RFP.

2.1. Procurement Schedule

Table 8, summarizes the procurement process milestones.

Table 8. Schedule of Contract Events

Milestone	Scheduled Date
Release RFP	August 18, 2000
Vendors' Pre-proposal Conference	August 25, 2000
Proposals Due	September 29, 2000
City Announces Finalists	October 13, 2000
Demonstrations /Proposal Validation/Site Visits	Demo 1 October 30, 2000 Demo 2 October 31,2000 Demo 3 November 1, 2000 Sites November 2 - 8, 2000
City Announces Apparently Successful Vendor	November 10, 2000
Contract Negotiations and Detailed Planning	November 13,- December 31, 2000
Operations Committee	January, 2001
City Council	January, 2001
Contract Signed	day after City Council approval

The City reserves the right to modify the schedule as circumstances may warrant.

2.2. Proposal Date, Time, Location

See Vendor Response Section for proposal format.

Proposals must be received at the City address listed below no later than September 29, 2000, 3:00 PM, Pacific Time. Vendors are solely responsible for ensuring that proposals are delivered on time. Delays caused by any delivery service, including the US Postal Service, will not necessarily be grounds for a waiver of the deadline requirement. Proposals submitted after the deadline may be rejected. Electronic proposal copies, such as fax or E-mail, will not be accepted. All Proposals must be delivered to:

City Clerk's Office

Enterprise Document Management System RFP

City Of Kent

220 4th Avenue South

Kent, WA 98032

2.3. Communications with the City of Kent

All communications regarding this RFP from vendors and other sources must be directed as follows:

Jim McKenney

City of Kent

Information Technology

220 4th Avenue South

Kent, WA 98032

Phone: (253) 856-4606

Fax: (253) 856-4735

Email: jmckenney@ci.kent.wa.us

2.4. Vendor Clarifications and Questions

The City will address specific issues unique to this RFP at the vendors' pre-proposal conference on August 25, 2000.

Specific vendor questions concerning the RFP must be submitted in writing (may be faxed or sent via e-mail). However, questions must be received by 8:00 a.m., PDT, August 25, 2000. Copies of questions relevant to the RFP process, together with the City's response will be distributed to all participating vendors.

Vendors who seek information, clarification, or interpretations from City employees without using this written submission process are advised that such material is used at the vendor's own risk and the City shall not be bound by any such representations, whether oral or written.

2.4.1. Clarifications

The City reserves the right to obtain clarification of any point in a vendor's proposal or to obtain additional information necessary to properly evaluate a proposal. Failure of a vendor to respond to such a request for additional information or clarification may result in rejection of the vendor's proposal. The City's retention of this right shall in no way reduce the responsibility of vendors to submit complete, accurate, and clear proposals.

2.4.2. Vendor Contact

The proposal must include the name of the specific individual who will act as the primary vendor contact during proposal evaluation. The proposal must identify the contact's organization, position in the organization, address, telephone number, fax number, and e-mail address.

2.5. Summary of RFP Process

The outline given below describes the City's procurement process after RFP release.

2.5.1. Vendors' Pre-Proposal Conference

Vendors are encouraged, but not required, to attend a vendor pre-proposal conference at the City. The vendor pre-proposal conference will be held in the City Hall building located at 220 4th Avenue South, Kent, WA 98032 on August 25, 2000, from 9:00 AM to 12:00 PM. The contact person is Jim McKenney, who can be reached at (253) 856-4606. The meeting's purpose is to provide a forum for open discussion and to resolve questions relative to the RFP.

2.5.2. RFP Changes or Amendments

Any RFP revisions will be issued in the form of an addendum and will be distributed to all vendors prior to the proposal due date.

2.5.3. Vendor Submits Proposal

Reference vendor instructions in Section 3 of this document for the required vendor response format and content.

2.5.4. City Evaluates Proposals

The vendor responses will be evaluated based on their proposal's merits as described in Section 3.0. The City's evaluation team will determine which vendor solution can best serve the City's goals and environment. The evaluation will focus on the following aspects:

· Vendor Qualifications

· Software Functionality

· Ease of Use

· Data Requirements

· Technical Environment and Support

· System and Software support

· Costs

· References

2.5.5. City Announces Finalists

The City will announce up to three finalists. The City reserves the right, at any time during the selection process, to include additional vendors for final evaluation activities. The selected vendors will be notified and a time will be scheduled for the vendor to participate in scripted demonstrations. Finalist vendors will be asked to provide the City with system documentation.

2.5.6. City Evaluates Vendor Documentation

The City will evaluate the vendor documentation. The City may also request additional documentation.

2.5.7. Vendor Demonstration

The vendor demonstration consists of two activities taking place in one day, as described below:

Scripted Demonstrations

The City will provide demonstration scripts to each finalist vendor at least 1 week before the vendor's scheduled demonstration. Each vendor will demonstrate their products based on the issued scripts. The scripted demonstration will take approximately 4 hours.

The City may require vendor technical experts to participate at this time in discussions with City Information Technology staff. Scripts will include some sample data. Such sample data will be minimal and sample data preparation is not expected to be burdensome.

Proposal Validation

The second half of the vendor demonstration is for proposal validation. The intention is to discuss the City's needs and the proposed solution, including the cost model. The purpose of this activity is to:

· Begin developing a partnership.

· Enable the City to fully understand the proposal's cost element in order to equitably compare competing proposals.

· Initiate contract discussions.

· Discuss technical architecture.

· Discuss vendor business qualifications.

· Discuss scope of potential system modifications.

· Discuss potential team members.

2.5.8. Hands-On Demonstration of Proposed Products

Finalist vendors may be required to arrange the on-site availability of vendor proposed products to give selected City personnel the opportunity to work with the proposed products. At minimum, access to the proposed products must be available for a two-week period. The vendor may be required to provide assistance to the City during this period of time.

2.5.9. City Visits Vendor Client Sites and/or Vendor Product Laboratories

Vendor(s) may be required to make arrangements for a team from the City to visit up to three (3) representative customer sites for purposes of viewing first hand the proposed products being used in a live, production environment. The vendor may also be required to prepare and coordinate an agenda prior to the visitations. In addition, vendor(s) may be required to make arrangements for a technical team from the City to meet with members of the vendor's development team or visit the vendor's product laboratories.

2.5.10. Final Vendor Selection

The City reserves the right to negotiate with all vendors deemed qualified based on the evaluation process. Qualified vendors are those vendors identified as viable by the evaluation team. At this stage in the process, the City prefers to work with a single vendor on the terms of its proposal; however, the City may elevate more than one viable vendor to the next level. The City reserves the right to review the most recently audited financial statements for selected vendor(s).

The City will invite the selected vendor(s) to participate in separate, on-site "discovery" sessions. The purpose of these sessions is to allow the vendor(s) to ask questions and find answers that will enable the vendor to develop a detailed Statement of Work. The Statement of Work, including updated costs, will be submitted to the City for evaluation. A final vendor will be selected based upon the overall benefit/cost ratio of each proposal. The selected vendor will be notified and a time scheduled for final contract negotiations.

2.5.11. Acceptance Test Plan

The City will develop (in consultation with vendor) and reach mutual agreement with vendor on an acceptance test plan detailing the scope of testing and specific test cases for each module of the software products purchased. All testing will be done using City equipment.

2.5.12. Progress Payment Schedule

The City expects to make staged progress payments based upon on-time completion of specific work packages and delivery of corresponding functionality. These units of work and performance requirements are to be defined prior to contract execution.

The City anticipates issuing progress payments at the following milestone points:

· Phase I - EDMS Software, System Design, Installation, and Training Completed

· Phase II - Image Conversion Completed

· Phase III - Image Enable Permit Tracking System (KIVA) Completed

· Phase IV - Image Enable J.D. Edwards Completed

The costs and terms shall be in effect until January 1, 2002, or one year from the date of final acceptance, whichever occurs later. The final contract will be financially binding and will include a non-performance clause.

2.5.13. Finalize Contract

This selection phase will be used to finalize the contract terms and conditions. See Appendix B for details. If the City and the selected vendor are unable to agree on terms and conditions at this point, the City may exercise its right to negotiate with other vendors. The City reserves the right to add terms and conditions during contract negotiations. These terms and conditions will be within the scope of the RFP and will not affect the proposal evaluations.

2.5.14. Contract Approval

The City's obligation will commence when the City Council, Mayor, and Information Technology Director approve the contract. Upon written notice to the vendor, the City may set a different contract starting date, and all warranties and price guarantees, and other time sensitive conditions will be adjusted accordingly. The City will not be responsible for any work done by the vendor, even work done in good faith, if it occurs prior to the contract start date set by the City.

2.6. Proposal Process

This section outlines the responsibilities of both the City and vendor in the creation and disposition of materials contained in the vendor's proposal.

2.6.1. Reference Checks

The City may conduct reference checks on competing vendors throughout the procurement process. The City may also contact any person or organization for information regarding a vendor regardless of the references provided by the vendor.

2.6.2. Costs Incurred by Vendors

The City shall not be liable for any costs incurred by a prospective vendor for preparing or submitting a proposal to the City or for any subsequent demonstrations required by the City. Proposals should be prepared simply and economically, providing a straightforward, concise description of vendor capabilities to satisfy the proposal requirements.

2.6.3. Right of Selection or Rejection of Proposals

The City offers this proposal for software products and technical services as a competitive negotiation. The City, at its sole option, may select or reject any or all proposals for any reason, may waive any informality in the proposals received, and may waive minor deviations from the specifications and shall be the sole judge thereof. Selection of a vendor shall not be construed as a contract award. The City may award a contract on the basis of information in addition to that received in a proposal. Therefore, it is emphasized that all proposals should be complete and submitted with the most favorable financial terms.

2.6.4. Incorporation of RFP and Proposal in the Final agreement

This RFP and the vendor's proposal, including, without limitation, all promises, warranties, commitments, demonstrations and representations made during the proposal selection process, shall be binding and incorporated by reference into the City's contract with the vendor.

2.6.5. Errors in Proposals

Vendors are responsible for all errors or omissions in their proposals and any such errors or omissions will not serve to diminish their obligations to the City. Vendors will not be allowed to alter proposal documents once proposals have been submitted. The City reserves the right to allow corrections or amendments due to errors identified in the proposals by either the vendor or the City. The City may waive minor administrative irregularities contained within the proposal documents.

2.6.6. Vendor Prime Contractor Responsibility

If a vendor's proposal includes equipment, hardware, software, or services to be supplied by other entities, it is desirable that the proposing vendor acts as prime contractor for the procurement of all products and services. The vendor, as the prime contractor, should be the sole point of contact, including payment of any and all charges resulting from the purchase of the proposed software and services. The vendor, acting as the prime contractor, should take full responsibility for the demonstration, construction (if required), delivery, installation, and acceptance testing of the proposed items supplied by its subcontractor(s). Each subcontractor used by the vendor on this project shall be identified to the City on the form titled Subcontractor Identification, found in Appendix A of this document.

2.6.7. Period of Validity of Proposals

The vendor must certify that its proposal will remain in effect for 180 days after the completion of vendor demonstration. The City may request an extension beyond the 180 days.

2.6.8. Proprietary Material

The City will attempt to protect legitimate trade secrets of any vendor. Examples of such information would be unpublished descriptions of proprietary system design. Any proprietary information contained in the proposal must be designated clearly and should be separately bound and labeled with the words "Proprietary Information." Marking the entire proposal proprietary may result in the rejection of the proposal. Vendors should be aware that the City is required by law to make its records available for public inspection, with certain exceptions. This legal obligation may not require the disclosure of proprietary, descriptive literature that contains valuable designs, drawings, or documentation. However, the vendor, by submission of materials marked "Proprietary Information," acknowledges and agrees that the City will have no obligation or liability to the vendor in the event that either must disclose these materials.

2.6.9. Proposal Confidentiality

Additionally, The City intends to keep each proposal confidential. By submitting itself to the City's proposal process, each vendor agrees that it will not seek to obtain, review, or compare any other proposal until final selection is complete. Accordingly, if the City receives any such requests from any vendor, the City will refuse that request, and will not disclose any part of any other proposal. If a vendor nevertheless persists in its efforts to obtain, review or compare any other proposal, the City may, at its sole option, eliminate that vendor from further consideration.

2.6.10. Proposal Disposition

All materials submitted in response to this RFP shall become the City's property.

3. Vendor Instructions

This section provides the format and description of the information required for a vendor's response to be considered by the City. The vendor must submit three (3) hardcopies (paper) and one (1) electronic copy of their proposal at the date, time, and location given in Section 2.1.1 of this document.

3.1. Prime Contractor

The City prefers to work with a single prime contractor for all product and implementation services. Nevertheless, if vendors wish to partner, they must submit a single proposal with an established entity that shall be the primarily responsible point of contact. For example, a software vendor/systems integrator team should propose jointly. Vendors wishing to propose separate contracts must clearly state this intention in their proposal.

Vendors may choose to partner with other software providers to provide enhanced functionality to the City. For example, a software vendor may choose to partner with another software provider to input functionality or storage management, etc. A single proposal should be provided, with prime responsibility clearly delineated

3.2. Partial Solutions

Proposals for partial solutions will be evaluated on the basis of their potential role in the overall solution set. The City would prefer to receive proposals for all required modules.

3.3. Proposal Format

The vendor's proposal shall be submitted in the format outlined in this section. Failure to comply with the specified format may result in the City's rejection of vendor proposal. The City reserves the right to reject all proposals. Other subject headings may be added as the vendor believes necessary. The City reserves the right to require additional information or materials after the proposals are submitted.

Vendors must respond to all requirements stated in this RFP and all of the appendices for the solution(s) they are offering, whether the vendor is proposing a complete software solution or a partial software solution.

The proposal must be signed by an officer authorized to negotiate for and contractually bind the vendor. The vendor must demonstrate this authority by completing the Vendor Authorization located in Appendix A.

Submit one original of your proposal, along with three (3) copies, and one (1) diskette in Microsoft Word 97/2000, with the cost model in Microsoft Excel 97/2000. The entire proposal must be submitted to the City Clerk in a sealed envelope or box.

The following is an outline of the proposal contents. Guidelines for completion of each section are included below.

I.

Cover Letter

The cover letter is to identify the vendor(s) and provide a summary of the proposal.

II. Table of Contents

III. EDMS Requirements

Complete section 4 of this document. See section 3.2 for instructions.

VI. Technology Requirements

Complete section 5 of this document.

VII. Implementation Requirements

Complete section 6 of this document.

VIII. Vendor Response Forms - Appendix A

Vendor characteristics that should be demonstrated in response to this section include:

_ A proven track record for both software use and implementation services for public sector organizations similar in size and complexity to the City.

_ Experience building document-enabled applications that can be scaled vertically within single departments and horizontally across city departments.

_ Dedication to ongoing development of and support for the proposed solution(s).

Vendor Profile

The vendor must complete the vendor profile provided in Appendix A.

Vendor Authorization

The vendor authorization must certify that this is the vendor's response to the City's RFP and identify both a vendor contact point for the vendor and the person authorized to negotiate for and contractually bind the vendor. A format is provided in Appendix A.

Subcontractor Identification

The vendor must provide information for each subcontractor included in the proposal. A format is provided in Appendix A.

Software Customer References

The vendor must provide at least three (3) references. These references should be as similar as possible to the City in function and size. In addition, at least two references should describe projects completed by the proposing software vendor/implementation team combination. A format is provided in Appendix A.

Cost Model

City representatives will review the cost model with finalist vendors following system demonstrations. Instructions are provided along with the cost model in Appendix A.

Year 2000 Compliance Statement

The vendor must certify that all proposed software and hardware is Year 2000 compliant according to the City's definition. A compliance statement is included in Appendix A for the vendor to review, sign, and return with their proposal. The vendor may substitute their own Year 2000 Compliance Statement.

Non-Collusion Covenant

The vendor must certify that it has in no way entered into any contingent fee arrangement with any firm or person and that the vendor has not in any manner sought by collusion to secure any advantage over other vendor(s). A Non-Collusion Covenant is located in Appendix A for the vendor to review, sign, and return with their proposal.

Equal Employment Opportunity Declaration

The vendor must certify that they comply with the City's Minority and Women Contractors Policy. A copy of the City's Administrative Policy and a declaration are included in Appendix A for the vendor to review, sign, and return with their proposal.

IX. Proposal Price Guarantee

The vendor must provide a written guarantee to maintain the prices proposed in the cost summary for 180 calendar days beyond completion of the vendor demonstration.

X. Acceptance of Terms

An authorized vendor representative must submit a statement demonstrating the vendor's acceptance of all parts of the RFP including terms outlined in Appendix B. If the vendor cannot provide this acceptance statement, the vendor must enumerate each specific exception to the City's RFP, together with the vendor's proposed changes. The City will not accept substitutions by the vendor with the vendor's own boilerplate documents.

XI. Additional Materials Submitted by Vendor

VENDORS SHOULD BE AWARE THAT THIS DOCUMENT, THE VENDOR'S RESPONSE AND AN IMPLEMENTATION SCHEDULE WILL BE ATTACHED TO THE NEGOTIATED SALES CONTRACT. IN ADDITION, THE WARRANTY CLAUSE IN THE SOFTWARE LICENSE AGREEMENT MUST STATE THAT THE SOFTWARE WILL OPERATE IN CONFORMANCE WITH VENDOR'S RESPONSE TO THIS RFP.

3.4. Response to Requirements Questionnaire

Proposals must respond to the RFP requirements questionnaire based on the functionality existing in the most current installed product version. Vendors shall clearly indicate if customization is necessary to meet a required or optional specification. The customization cost shall be itemized in the Cost Worksheet. If customization is necessary, the vendor shall provide an explanation that details the customization's extent.

The vendor must indicate the version number(s) in Section 5, Technology Questionnaire. If the feature does not exist in the most current installed version, the vendor must respond with NO, but may indicate if the feature will be provided in a future version.

3.5. Response to Questionnaires

The vendor will indicate whether the feature or functionality is provided (Yes), not provided (No), can be customized to provide it (Cust). The comments column shall be used to answer describe questions. The vendor may use this section to clarify a response, state any modifications needed to realize the feature, indicate if the feature is provided in a future version and/or specify if the feature is provided by a third party. The City expects that comments will be provided for any feature that the vendor cannot respond to by checking yes or no.

4.

5. EDMS Functional Requirements

This section describes the anticipated processing and operations that the proposed system must support and details the specific system requirements that must be fulfilled. The City is only interested in "commercial off the shelf "(COTS) products. These products shall be implemented and seamlessly integrated by the software manufacturer and/or a network of experienced integrators certified by the software manufacturer. The vendor shall have verifiable experience in the design and implementation of imaging and document management applications.

Vendors must clearly specify any and all parts of the proposed system that are not "out-of-the-box" and that require development and/or customization. If development or customization is required, vendors must indicate what tools will be used, resources required, time frames, and costs.

Vendors are encouraged to propose additional or enhanced features, components and designs if they feel that important issues have been overlooked and/or if they can improve the proposed system functionality or efficiency.

Legend for EDMS and Technology Questionnaires:

The vendor will indicate by a check (_) whether the feature or functionality is provided (Yes), not provided (No), or can be customized to provide it (Cust). If the feature can be provided by the use of 3^rd party vendors, indicate so in the Comment column. When asked to describe how the proposed solution would fulfil the requirement, use the Comment column for the response.

5.1. Document Imaging

This functionality involves capturing paper documents in digital form. These digital documents may then be indexed, annotated, archived, searched, retrieved, or viewed.

Ref #	Imaging	Vendor Response
	Application Feature/System Requirement	Y	N	Cust	Comment
4.1.1	Does the proposed solution support ISIS standards?
4.1.2	Does the proposed solution support 256 shades of gray?
4.1.3	What is the range of scanning resolution (in dot per inch, DPI) that the proposed solution supports? (200, 300, or higher)
4.1.4	Does the proposed solution allow an operator to change DPI settings on the fly?
4.1.5	List all formats and compression standards supported by the proposed solution.
4.1.6	Does the proposed solution use propriety bits in the TIFF header? If so, please describe.
4.1.7	Does the proposed solution support both pre-defined scanner settings such as brightness, contrast, and resolution and allow the scanner operator to manually adjust the settings?
4.1.8	Does the proposed solution allow the scanner to sense the characteristics of a document and automatically adjust the scanner settings to optimize the image?
4.1.9	Does the proposed scanning solution support a scan restart in mid-batch in case of an interruption?
4.1.10	Does the proposed solution support duplex scanning? If yes, are blank pages created when there is nothing on the reserve side?
4.1.11	Is the proposed scanning process able to sense and eliminate blank pages automatically?
4.1.12	Does the proposed solution allow additional pages to be inserted into a scanned document?
4.1.13	Does the proposed solution allow individual pages to be deleted?
4.1.14	Does the proposed solution support Optical Character Recognition (OCR)?
4.1.15	Describe how annotations are stored?
4.1.16	Does the proposed system have the following markup capabilities: highlighting,_"sticky notes", blackout__digital stamp,_digital signatures?
4.1.17	Does the proposed solution's annotation functionality alter the original image? If yes, please describe.
4.1.18	Does the proposed system have the following repair tools: De-skewing, speckles and artifact removal, cropping, line removal, line smoothing, rotation, automatic scaling for output, and fill for holes?
4.1.19	Does the proposed solution support searchable annotations?
4.1.20	Does the proposed solution provide any quality assurance or image review processing tools? If yes, please describe.
4.1.21	Does the proposed solution support bar code recognition?
4.1.22	Does the proposed solution support automatic indexing based on bar codes?
4.1.23	Does the proposed solution support large format scanning? Describe how the product would address this requirement, listing any special drivers or interfaces necessary and identifying any costs associated in the cost estimate.

5.2. Electronic Folder Management

This functionality involves virtual folders that can contain multiple objects of differing formats. A virtual folder can hold images, word-processing documents, spreadsheets, graphics, Portable Network Graphics (PNG), JPEG, HTML, XML, PDF, etc. Images and text counterparts can be stored together in folders or they can be converted to final form documents such as Adobe PDF. The user can see any of these documents using a universal viewer or web browser. For each response, distinguish the characteristics between the thick client viewer and web browser.

Ref #	Electronic Folder Management	Vendor Response
	Application Feature/System Requirement	Y	N	Cust	Comment
4.2.1	Describe how folders are created, number of levels within a folder, naming conventions, and how users can dynamically customize folder views and indices.
4.2.2	Describe how images are assembled into folders/documents.
4.2.3	Does the proposed solution provide the ability to move images individually or as a group between folders?
4.2.4	Does the proposed solution provide the ability to drag and drop folders created in a Web browser?
4.2.5	Does the proposed system support fax documents, e-mail documents, e-forms, and other non-imaged documents in the folders?
4.2.6	Does the proposed solution include a universal viewer? (One that does not require launching the native software application). Please describe.
4.2.7	Does the proposed solution support thumbnails?
4.2.8	Does the proposed solution support storing a single image in multiple folders to limit redundant images?
4.2.9	Can more than one user view the same document at once?
4.2.10	Does the proposed solution allow for simultaneous multiple image viewing with window and image scaling?
4.2.11	Does the proposed solution support the ability to pan, zoom (in/out), and scale an image?
4.2.12	Does the proposed solution retrieve all the pages of a document or just the first page? Describe the method of page retrieval.
4.2.13	Does the proposed solution have system administration tools to control page retrieval? Describe the functionality.
4.2.14	Can documents be printed from the viewer?

5.3. Image Enabling Applications

This functionality involves using the imaging engine within another business application. The imaging engine is not the dominant application and can operate without modification to any source code. Data transfer from the host application can populate the image indexes without user intervention.

Ref #	Image Enabling Applications	Vendor Response
	Application Feature/System Requirement	Y	N	Cust	Comment
4.3.1	Does the proposed solution support data extraction from ODBC compliant host applications for automatic indexing? For example, address, project name, project number, assessors parcel number depending on the ODBC data source. Please describe tools used to support this requirement.
4.3.2	Does the proposed solution require any proprietary plug-ins for image viewing? If so please describe.
4.3.3	Does the proposed solution support searching on multiple index fields?
4.3.4	Does the proposed solution support a shared repository? For example, a property deed would be scanned, and indexed using the EDMS imaging. Could a user search and retrieve this property deed from within the image-enable permit tracking system using the same indexes?
4.3.5	Does the proposed solution support storing indexes in SQL Server 7.0?

5.4. Document Management

This functionality includes, indexing, library services such as version control, search, retrieval, check-in, check-out, and document security regardless of media type, location, or format.

Ref #	Document Management	Vendor Response
	Application Feature/System Requirement	Y	N	Cust	Comment
4.4.2	Does the proposed solution support document version control?
4.4.3	Does the proposed solution support check in/check out of document objects? Describe.
4.4.4	Describe the proposed system's indexing capabilities (maximum number of indexes per document) and any limitations in combination of types (character, numeric etc.)
4.4.5	The City expects over time to have to add or delete selected index structures from a document group structure. Describe how changing the index structures (as opposed to individual data elements) can be accomplished.
4.4.6	Does the proposed system have the capability of indexing electronic documents such as e-mail, electronic forms, and intranet/internet forms without converting these types of documents to paper documents for scanning and indexing?
4.4.7	Does the proposed solution support full text searching?
4.4.8	Does the proposed solution have a web client? If so please describe the capabilities.
4.4.9	Does the proposed solution require a proprietary image viewer ?
4.4.10	Does the proposed system include a search engine? Describe the search engine's features and capabilities.
4.4.11	Does the proposed solution include metadata in the indexing process?
4.4.12	Does the proposed system support a feature that will allow an operator to view the document and re-index if necessary? Please describe.
4.4.8	Does the proposed solution support complex document types? (email, spreadsheets, AutoCAD, Word, etc)
4.4.9	Does the proposed solution provide for Microsoft Office Integration? Please describe.
4.4.10	Does the proposed solution provide for Microsoft Exchange Integration? Please describe.

6. Technology Requirements

This section contains requirements pertaining to the proposed solution' s technology and operating system platforms.

6.1. Overall Requirements

The overall requirements address general system elements that are not addressed by the other technology system requirements.

Ref #	Overall Requirements	Vendor Response
	Application Feature/System Requirement	Y	N	Comment
5.1.1	List the software version number and release date for each proposed module, including third party solutions.
5.1.2	Does the system provide context sensitive help based on the cursor location?
5.1.3	Does the system provide the ability to create user-customized help at all levels? (e.g. system, module, screen, field)
5.1.4	Is the Information Model published? If yes, describe how and in what form the Information Model is made available to users, (CD, the web, hardcopy, etc.)
5.1.5	Describe how changes to the information model due to configuration, customization, or upgrades are documented. Attach additional documentation if desired.
5.1.6	Describe/list technical and user documentation provided with the proposed solution.

6.2. System Design

The system design requirements deal with how the proposed solution is architected. These requirements and questions attempt to identify elements that exist in the City's environment and those that may be introduced by the proposed solution.

Ref #	System Design Requirements	Vendor Response
	Application Feature/System Requirement	Y	N	Cust	Comment
5.2.1	Attach diagrams and other documentation describing the proposed Application Architecture, e.g., application servers, cache server, clients, index database, image database, middleware, etc. Show the interaction of the components. Attach and/or describe the proposed solution's open architecture standard, include middleware, APIs, etc. Indicate where processing takes place and where processing power is critical.
5.2.2	Does the proposed solution need proprietary hardware to work properly?
5.2.3	Describe the proposed solution's scalability. What additional software licensing costs will be incurred as the system scales up.
5.2.4	What database systems are certified for use with this product?
5.2.5	Does the system provide COM support?
5.2.6	Does the proposed system provide database backup and recovery functions? If yes, describe in detail how database backup and recovery functions operate.
5.2.7	What is your XML strategy? Please describe.

6.3. Operating Environment

The operating environment requirements evaluate the proposed solution's compatibility with the City's current technical environment. Reference the City's technical operating environment description located in Section 1.5.5.

Ref #	Operating Environment Requirements	Vendor Response
	Application Feature/System Requirement	Y	N	Cust	Comment
5.3.1	Is the system 100% compatible with the desktop components as described in the section 1.1.3 Technology Environment? Describe any known conflicts with the proposed technology environment components.
5.3.2	Based on the technology proposed, describe the minimum, recommended, and optimal client hardware configuration for a user. Describe for both a "power user," and a browser user.		&nb