Community Development Software System RFP#16-11

REQUIREMENTS MATRIX

Complete the Requirements matrix below. Under the description for each item, please detail/describe the related component or the functionality in your system. For each item, please indicate the module(s) which contain the requested functionality. If the item is not available, please indicate as such. A response is required for all items.

1.0 General Requirements
Item# / Description
1.1 / Must include an Electronic Plan Submittal solution for Preliminary Plans, Commercial Site Plans, Construction Plans, Engineering Plans and any other plans as described herein.
1.2 / Must include a mobile solution for employee field use.
1.3 / County system administrators must be able to configure and maintain all system settings without the need to rely on the vendor.
1.4 / County system administrators must be able to create an unlimited number of new fields after the system has been implemented. Please detail where County created fields are allowed (e.g., fields associated with permits, fields associated with inspectors, etc.).
1.5 / County system administrators must be able to establish validation and editing rules for created fields. Please describe types of fields that can be created and provide list of field definition parameters.
1.6 / County system administrators can inactivate county created fields. Include explanation as to what happens to data when a field is inactivated.
1.7 / Must include a configurable workflow component to automate business processes performed.
1.8 / System documentation and context-sensitive user help is available within the program itself at all screen and field levels.
1.9 / Users must be able to set up personalized home page. Users must be able to configure the items on and display of their personalized home page.
1.10 / System must include a real-time dashboard, displaying dynamic charts and graphs. Users must be able to configure the items on and display of their personal dashboard.
1.11 / Must provide comprehensive searching functionality in all modules.
1.12 / System must allow certain records (specific permit, specific case, specific project, etc.) to be password protected.
1.13 / System must provide ability to generate letters and mailings. Please indicate tools and processes utilized, including any external report generators.
1.14 / System must provide ability to export all data. Detail process and tools used to select and export data. Detail formats in which data can be exported.
2.0 Technical Requirements
Item# / Description
2.1 / Must be a web based solution.
2.2 / Must be an on premise solution.
2.3 / Must interface with GroupWise. Please describe what functions/modules interface with GroupWise and how.
2.4 / Must interface with Laserfiche.
2.5 / Ability to integrate with MS Office.
2.6 / Describe the processes/methods available for interfacing with other applications (such as APIs, web services, etc.).
2.7 / Must be compatible with all industry standard web browsers including, but not limited to, Internet Explorer, Chrome, Firefox, Safari, etc. Detail compatible browser versions in response. Please detail all user and public side device, browser and operating system requirements and limitations.
2.8 / Application is capable of running on a separate server from the database.
2.9 / Supports Windows Active Directory (AD) authentication.
2.10 / Explain method for authenticating external users (not AD users).
2.11 / Describe what is installed and/or stored on the client desktop (e.g. cookies, plug-ins, preferences, etc.).
2.12 / User preferences should be saved on the server, not on the desktop.
2.13 / Describe what information can be viewed by the system administrator for active users. Detail any tools available for use by the system administrator to manage active user sessions.
2.14 / System is capable of automatic session timeouts. Describe options for configuring session timeouts.
2.15 / If concurrent licensing model is used, allows a configurable timeout period for users not active in the system, ensuring that licenses are freed up when not being used.
2.16 / Detail all software, tools, add-ons, etc. which must be installed on a workstation to access any portion of your solution.
2.17 / Uses an industry recognized relational database management system that is non-proprietary. Please indicate database system used in your solution.
2.18 / System allows efficient and simultaneous access to data by concurrent users and prevents the loss of information by simultaneous updates from different users.
2.19 / Provides ability to encrypt sensitive data fields. Detail which fields can be encrypted. Please describe encryption methodology and management policy/procedures.
2.20 / Validation rules and indices to prevent duplication of data (e.g. permit/case numbers, logins, account numbers, contacts/contractors).
2.21 / Allows for system backup without interrupting public facing web applications and other external interfacing applications.
2.22 / Provides for audit capability and recovery in the event of a system failure.
2.23 / System must include archival and purging processes.
2.24 / Application meets requirements of Payment Application Data Security Standard (PA-DSS) and is compliant with Payment Card Industry Data Security Standards (PCI-DSS). This applies to any 3rd. party vendor required by the proposed solution.
2.25 / Applications are integrated and separate modules work together seamlessly and cohesively.
2.26 / Ability for system administrators to broadcast a message to all system users, including mobile.
2.27 / Users do not need local administrator or other elevated rights on their desktop machines to run any component of the system.
2.28 / Per Appendix 8, the County’s current standard is Windows 7 and Internet Explorer 11. Please indicate any specific Windows and IE settings necessary for proposed solution.
2.29 / Allow for a full test environment at no additional cost.
2.30 / Allow for a full development environment at no additional cost.
2.31 / Vendor has ability to provide remote desktop support.
2.32 / The County’s current computing environment is outlined in Appendix 8. Please assess the standard hardware in use and recommend any additional hardware needed to optimize the proposed solution.
2.33 / System must be capable of operating in the County’s standard computing environment as outlined in Appendix 8.
3.0 General Reporting Capabilities
Item# / Description
3.1 / Must include a report generator with robust selection and design capabilities. Please describe report generator, including selection and design tools.
3.2 / Users must be able to save created reports for future use.
3.3 / Users must have ability to select favorite reports (either standard system reports or user created reports) and group them for ease of accessibility.
3.4 / Users must be able to attach dynamic and static reports (either standard report or user created report) to a specific record (permit, inspection, case, project, etc.) Please describe process used to attach a dynamic report.
3.5 / Must provide ability to export reports into Adobe PDF, MS Excel and MS Word format.
3.6 / Must provide ability for users to merge data into MS Word documents.
3.7 / Reports (particularly permits) must provide the following data for each permit: Election District and Census Tract where permit is located.
3.8 / Need ability to create status, business or locational reports on all the projects noted.
3.9 / List and describe all standard reports not already detailed in other Requirements Matrix sections.
4.0 Security
Item# / Description
4.1 / County system administrator(s) must be able to control all user security.
4.2 / System must allow for multiple system administrators.
4.3 / Must be able to establish user groups and user group access.
4.4 / Must be able to establish individual users, assign them to user groups and override group access rights with individual access rights.
4.5 / Must be able to set security access levels of full, read only or no access.
4.6 / Must be able to control access by record type (permit type, inspection type, etc.).
4.7 / Must be able to control access by function (enter permits, approve inspections, change fees, etc.).
4.8 / Must be able to control access by module.
4.9 / Must be able to control access at the field level.
4.10 / Must be able to control access based on configurable workflow.
4.11 / Must be able to establish and maintain the menus that groups/individual users view in each module.
4.12 / Must be able to control access to a permit based on status and permit type.
4.13 / Must be able to control access to an inspection based on status and inspection type.
4.14 / Must be able to establish security for 3rd. party inspection and plan review agencies.
4.15 / Must be able to establish security parameters for contractors to apply for permits online.
4.16 / Must be able to establish security parameters for citizens to apply online.
4.17 / List and describe all standard Security reports.
5.0 Permitting
Item# / Description
5.1 / Must provide ability to track any type of permit and to add additional permit types as needed.
5.2 / Unlimited user defined permit types.
5.3 / Unlimited user defined fields may be assigned to each permit type.
5.4 / Ability to duplicate part or all of the data from one permit record to another.
5.5 / County system administrators must have the ability to establish fee schedules.
5.6 / Ability to calculate permit fees based on various fee schedules.
5.7 / Unlimited fees may be attached to a permit.
5.8 / System must provide ability to override calculated fees based on user security.
5.9 / System must have ability to inactivate permit fees based on user security.
5.10 / System must include methodology to ensure that fees are collected.
5.11 / System must provide ability to apply credits to fees.
5.12 / System must provide ability to process refunds for fees.
5.13 / System must provide ability to inactivate fees.
5.14 / System must automatically establish inspections, reviews and fees based on permit type.
5.15 / System must provide ability to set various functionality by permit type (e.g., certain types of permits allow issuance of a Temporary Certificate of Occupancy, certain types of permits have required fields, etc.).
5.16 / Ability to attach unlimited number of electronic documents to a permit. Please detail file types that may be attached to a permit.
5.17 / Ability to link permits together creating parent-child-sibling relationships.
5.18 / Must be able to enter permits involving multiple structures.
5.19 / Must be able to enter permits involving multiple parcels and address locations.
5.20 / Restrict the issuance of permits for certain parcels based on access authority (e.g., certain permits require approval by flood plan administrator, fire chief, engineer, planning or building official, etc.).
5.21 / Ability to flag a permit with a particular status (hot, problem, etc.).
5.22 / Ability to list any warnings, locks, holds, notices or restrictions for a parcel during permit process.
5.23 / Automatically verify contractor’s license status for validity by providing ability to look up contractor information on Contractors State License Board website.
5.24 / Must include ability to review full history of permit activity including changes made, who made them and when they were made in a timeline view.
5.25 / Must provide ability to insert a QR code on a permit form.
5.26 / Must include ability to obtain notifications of all changes made related to specific, identified permits.
5.27 / Provide ability to track contact information for various parties (contractor(s), applicant(s), property owner(s), etc.).
5.28 / Provide the ability to track multiple addresses, phones and email addresses for various parties.
5.29 / Ability to automatically communicate electronically with various parties throughout the permit process.
5.30 / System must automatically assign sequential permit numbers by permit type.
5.31 / Permit number must include the year.
5.32 / Ability to allow manual entry of a permit number.
5.33 / Must include ability to enter permits on properties which have not yet received property ID # in the system and be able to carry over all entered information when actual property ID# is assigned. Please describe process involved.
5.34 / List and describe all standard Permitting reports.
5.35 / Ability to create permits associated with entities other than parcels.
5.36 / Ability to start a permit process directly from a map. Describe steps involved.
5.37 / Ability to start a permit process without a map. Describe steps involved.
5.38 / Ability to export data to spreadsheet. Describe steps involved.
5.39 / Ability to produce a report of raw permit data from a defined map area, such as a report of all active permits, including permit detail, within a mapped area.
5.40 / Must track time and costs associated with daily activities by employees.
6.0 Inspections
Item# / Description
6.1 / Provide ability to create inspector profiles.
6.2 / Provide ability to define inspector availability.
6.3 / Provide ability to define daily maximum inspections or units per inspector.
6.4 / Provide ability to define inspector disciplines.
6.5 / Provide ability to assign a standard amount of time to each inspection type to allow for a daily cap of inspections.
6.6 / Track inspections by type, inspector, scheduled date and completed date.
6.7 / Ability to quickly re-assign a group of inspections to another inspector.
6.8 / Allow different checklists for each inspection type.